kea/doc/examples/kea4/mysql-reservations.json

// This is an example configuration file for the DHCPv4 server in Kea.
// It contains configuration of the MySQL host database backend, used
// to retrieve reserved addresses, host names, DHCPv4 message fields
// and DHCP options from MySQL database.
{ "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" ],

// Specify connection to the database holding host reservations. The type
// specifies that the MySQL 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": "mysql",
    "name": "kea",
    "user": "kea",
    "password": "kea",
    "host": "localhost",
    "port": 3306
  },

// 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 and fatal) should be
// logged to stdout.
"Logging": {
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output_options": [
                {
                    "output": "stdout"
                }
            ],
            "severity": "INFO"
        }
    ]
}

}