reservations.json 5.76 KB
Newer Older
1 2 3 4 5
// This is an example configuration file for DHCPv6 server in Kea
// that showcases how to do host reservations. It is
// assumed that one subnet (2001:db8:1::/64) is available directly
// over ethX interface. A number of hosts have various combinations
// of addresses and prefixes reserved for them.
6 7 8 9

{ "Dhcp6":

{
10
// Kea is told to listen on ethX interface only.
11 12 13
  "interfaces-config": {
    "interfaces": [ "ethX" ]
  },
14

15 16 17 18
// 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.
19
  "lease-database": {
20 21
      "type": "memfile",
      "lfc-interval": 3600
22 23
  },

24
// This is pretty basic stuff, it has nothing to do with reservations.
25 26 27 28 29
  "preferred-lifetime": 3000,
  "valid-lifetime": 4000,
  "renew-timer": 1000,
  "rebind-timer": 2000,

30 31 32 33 34 35 36
// Kea supports three types of identifiers in DHCPv6: hw-address (hardware/MAC
// address of the client), duid (DUID inserted by the client) and flex-id
// (flexible identifier available when flex_id hook library is loaded) When told
// to do so, Kea can check for each of these 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.
37
    "host-reservation-identifiers": [ "duid", "hw-address", "flex-id" ],
38

39 40 41
// The following list defines subnets. Subnet, pools and interface definitions
// are the same as in the regular scenario, without host reservations.
// least subnet and pool entries.
42 43 44 45
  "subnet6": [
    {
      "subnet": "2001:db8:1::/48",

Tomek Mrugalski's avatar
Tomek Mrugalski committed
46 47 48 49 50 51 52
      // This directive tells Kea that reservations may be made both in-pool
      // and out-of-pool. For improved performance, you may move all reservations
      // out of the dynamic pool and change reservation-mode to "out-of-pool".
      // Kea will then be able to skip querying for host reservations when
      // assigning leases from dynamic pool.
      "reservation-mode": "all",

53
      "pools": [ { "pool": "2001:db8:1::/120" } ],
54 55 56 57 58 59 60 61 62 63

      "pd-pools": [
          {
              "prefix": "2001:db8:1:8000::",
              "prefix-len": 56,
              "delegated-len": 64
          }
      ],
      "interface": "ethX",

64 65 66 67 68
// Host reservations. Define several reservations, note that
// they are all within the range of the pool of the dynamically
// allocated address. The server will exclude the addresses from this
// pool and only assign them to the client which has a reservation for
// them.
69
      "reservations": [
70 71
// This is a simple host reservation. The host with DUID matching
// the specified value will get an address of 2001:db8:1::100.
72 73 74 75
          {
              "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
              "ip-addresses": [ "2001:db8:1::100" ]
          },
76 77 78 79 80 81 82
// This is similar to the previous one, but this time the reservation
// is done based on hardware/MAC address. The server will do its best to
// extract the hardware/MAC address from received packets (see
// 'mac-sources' directive for details). This particular reservation
// also specifies two extra options to be available for this client. If
// there are options with the same code specified in a global, subnet or
// class scope, the values defined at host level take precedence.
83 84
          {
              "hw-address": "00:01:02:03:04:05",
85 86 87 88 89 90 91 92 93
              "ip-addresses": [ "2001:db8:1::101" ],
              "option-data": [
              {
                  "name": "dns-servers",
                  "data": "3000:1::234"
              },
              {
                  "name": "nis-servers",
                  "data": "3000:1::234"
94 95
              }],
              "client-classes": [ "special_snowflake", "office" ]
96
          },
97 98 99 100 101 102
// This is a bit more advanced reservation. The client with the specified
// DUID will get a reserved address, a reserved prefix and a hostname.
// This reservation is for an address that it not within the dynamic pool.
// Finally, this reservation features vendor specific options for CableLabs,
// which happen to use enterprise-id 4491. Those particular values will
// be returned only to the client that has a DUID matching this reservation.
103 104
          {
              "duid": "01:02:03:04:05:06:07:08:09:0A",
Tomek Mrugalski's avatar
Tomek Mrugalski committed
105
              "ip-addresses": [ "2001:db8:1:cafe::1" ],
106
              "prefixes": [ "2001:db8:2:abcd::/64" ],
Tomek Mrugalski's avatar
Tomek Mrugalski committed
107 108 109 110 111 112 113 114 115 116
              "hostname": "foo.example.com",
              "option-data": [ {
                  "name": "vendor-opts",
                  "data": "4491"
              },
              {
                  "name": "tftp-servers",
                  "space": "vendor-4491",
                  "data": "3000:1::234"
              } ]
117

118
          },
119 120 121 122 123
// 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.
124 125
// Expression can be specified either as hex or plain text using single
// quotes.
126 127
// Note: flexible identifier requires flex_id hook library to be
//loaded to work.
128 129 130 131
         {
             "flex-id": "'somevalue'",
             "ip-addresses": [ "2001:db8:1:cafe::2" ]
         }
Tomek Mrugalski's avatar
Tomek Mrugalski committed
132

133 134 135 136 137
      ]
    }
  ]
},

138 139 140
// The following configures logging. It assumes that messages with at
// least informational level (info, warn, error and fatal) should be
// logged to stdout.
141 142 143 144 145 146
"Logging": {
    "loggers": [
        {
            "name": "kea-dhcp6",
            "output_options": [
                {
147
                    "output": "stdout"
148 149
                }
            ],
150 151
            "debuglevel": 0,
            "severity": "INFO"
152 153 154 155 156
        }
    ]
}

}