pgsql-reservations.json 3.62 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
# This is an example configuration file for the DHCPv4 server in Kea.
# It contains configuration of the PostgreSQL host database backend, used
# to retrieve reserved addresses, host names, DHCPv4 message fields
# and DHCP options from PostgreSQL database.
{ "Dhcp4":

{
# Kea is told to listen on ethX interface only.
  "interfaces-config": {
    "interfaces": [ "ethX" ]
  },

# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just use memfile, because it doesn't require
# any prior set up.
  "lease-database": {
    "type": "memfile"
  },

# Addresses will be assigned with valid lifetimes being 4000. Client
# is told to start renewing after 1000 seconds. If the server does not respond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
  "valid-lifetime": 4000,

# Renew and rebind timers are commented out. This implies that options
# 58 and 59 will not be sent to the client. In this case it is up to
# the client to pick the timer values according to RFC2131. Uncomment the
# timers to send these options to the client.
#  "renew-timer": 1000,
#  "rebind-timer": 2000,


# Kea supports reservations by several different types of identifiers:
# hw-address (hardware/MAC address of the client), duid (DUID inserted by the
# client), client-id (client identifier inserted by the client) and circuit-id
# (circuit identifier inserted by the relay agent). When told to do so, Kea can
# check for all of those identifier types, but it takes a costly database lookup
# to do so. It is therefore useful from a performance perspective to use only
# the reservation types that are actually used in a given network.

# The example below is not optimal from a performance perspective, but it
# nicely showcases the host reservation capabilities. Please use the minimum
# set of identifier types used in your network.
  "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],

# Specify connection to the database holding host reservations. The type
# specifies that the PostgreSQL database is used. user and password are the
# credentials used to connect to the database. host and name specify
# location of the host where the database instance is running, and the
# name of the database to use. The server processing a packet will first
# check if there are any reservations specified for this client in the
# reservations list, within the subnet (configuration file). If there are
# no reservations there, the server will try to retrieve reservations
# from this database.
  "hosts-database": {
    "type": "postgresql",
    "name": "kea",
    "user": "kea",
    "password": "kea",
    "host": "localhost"
  },

# Define a subnet with a single pool of dynamic addresses. Addresses from
# this pool will be assigned to clients which don't have reservations in the
# database. Subnet identifier is equal to 1. If this subnet is selected for
# the client, this subnet id will be used to search for the reservations
# within the database.
  "subnet4": [
    {
       "pools": [ { "pool":  "192.0.2.10 - 192.0.2.200" } ],
       "subnet": "192.0.2.0/24",
       "interface": "ethX",
       "id": 1
    }
  ]
},

# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
"Logging": {
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output_options": [
                {
                    "output": "stdout"
                }
            ],
            "severity": "INFO"
        }
    ]
}

}