123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156 |
- // This is an example configuration file for the DHCPv4 server in Kea.
- // It contains one subnet in which there are two static address reservations
- // for the clients identified by the MAC addresses.
- { "Dhcp4":
- {
- // Kea is told to listen on ethX interface only.
- "interfaces-config": {
- "interfaces": [ "ethX" ]
- },
- // We need to specify the the database used to store leases. As of
- // September 2016, four database backends are supported: MySQL,
- // PostgreSQL, Cassandra, and the in-memory database, Memfile.
- // We'll use memfile because it doesn't require any prior set up.
- "lease-database": {
- "type": "memfile",
- "lfc-interval": 3600
- },
- // Addresses will be assigned with a lifetime of 4000 seconds.
- "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" ],
- // Define a subnet with four reservations. Some of the reservations belong
- // to the dynamic pool. Kea is able to handle this case, but it is not
- // recommended from a performance perspective, as Kea would not only need to
- // check if a given address is free, but also whether it is reserved.
- // To avoid this check, one can change reservation-mode to out-of-pool, rather
- // than 'all'. If a subnet does not have reservations at all, the reservation
- // lookup can be skipped altogether (reservation-mode is set to 'disabled').
- // Note that the second reservation is for an address which is within the
- // range of the pool of the dynamically allocated address. The server will
- // exclude this address from this pool and only assign it to the client which
- // has a reservation for it.
- "subnet4": [
- {
- "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
- "subnet": "192.0.2.0/24",
- "interface": "eth0",
- "reservation-mode": "out-of-pool",
- "reservations": [
- // This is a reservation for a specific hardware/MAC address. It's a very
- // simple reservation: just an address and nothing else.
- {
- "hw-address": "1a:1b:1c:1d:1e:1f",
- "ip-address": "192.0.2.201"
- },
- // This is a reservation for a specific client-id. It also shows
- // the this client will get a reserved hostname. A hostname can be defined
- // for any identifier type, not just client-id.
- {
- "client-id": "01:11:22:33:44:55:66",
- "ip-address": "192.0.2.202",
- "hostname": "special-snowflake"
- },
- // The third reservation is based on DUID. This reservation also
- // defines special option values for this particular client. If
- // the domain-name-servers option would have been defined on a global,
- // subnet or class level, the host specific values take preference.
- {
- "duid": "01:02:03:04:05",
- "ip-address": "192.0.2.203",
- "option-data": [ {
- "name": "domain-name-servers",
- "data": "10.1.1.202,10.1.1.203"
- } ]
- },
- // The fourth reservation is based on circuit-id. This is an option inserted
- // by the relay agent that forwards the packet from client to the server.
- // In this example the host is also assigned vendor specific options.
- {
- "client-id": "01:11:22:33:44:55:66",
- "ip-address": "192.0.2.204",
- "option-data": [
- {
- "name": "vivso-suboptions",
- "data": "4491"
- },
- {
- "name": "tftp-servers",
- "space": "vendor-4491",
- "data": "10.1.1.202,10.1.1.203"
- }
- ]
- },
- // This reservation is for a client that needs specific DHCPv4 fields to be
- // set. Three supported fields are next-server, server-hostname and
- // boot-file-name
- {
- "client-id": "01:0a:0b:0c:0d:0e:0f",
- "ip-address": "192.0.2.205",
- "next-server": "192.0.2.1",
- "server-hostname": "hal9000",
- "boot-file-name": "/dev/null"
- },
- // This reservation is using flexible identifier. Instead of relying on specific
- // field, sysadmin can define an expression similar to what is used for client
- // classification, e.g. substring(relay[0].option[17],0,6). Then, based on the
- // value of that expression for incoming packet, the reservation is matched.
- // Expression can be specified either as hex or plain text using single
- // quotes.
- // Note: flexible identifier requires flex_id hook library to be loaded to work.
- {
- "flex-id": "s0mEVaLue",
- "ip-address": "192.0.2.206"
- }
- ]
- }
- ]
- },
- // The following configures logging. It assumes that messages with at least
- // informational level (info, warn, error and fatal) should be logged to stdout.
- "Logging": {
- "loggers": [
- {
- "name": "kea-dhcp4",
- "output_options": [
- {
- "output": "stdout"
- }
- ],
- "severity": "INFO"
- }
- ]
- }
- }
|