summaryrefslogtreecommitdiffstats
path: root/doc/examples/kea4/reservations.json
blob: c00a8e9c0c3742956ad392ea971b303a1dce4e28 (plain)
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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
// 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 eth0 interface only.
  "interfaces-config": {
    "interfaces": [ "eth0" ]
  },

// We need to specify the database used to store leases. As of April
// 2022, three database backends are supported: MySQL, PostgreSQL, 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), circuit-id
// (circuit identifier inserted by the relay agent) and flex-id (flexible
// identifier available when flex_id hook library is loaded). 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", "flex-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').
// The reservation-mode has been replaced by reservations-global,
// reservations-in-subnet and reservations-out-of-pool.

// 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",
        // 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",
        // It is replaced by the "reservations-global", "reservations-in-subnet"
        // and "reservations-out-of-pool" parameters.

        // Specify if server should lookup global reservations.
        "reservations-global": false,

        // Specify if server should lookup in-subnet reservations.
        "reservations-in-subnet": true,

        // Specify if server can assume that all reserved addresses
        // are out-of-pool.
        // Ignored when reservations-in-subnet is false.
        // If specified, it is inherited by "shared-networks" and
        // "subnet4" levels.
        "reservations-out-of-pool": false,

        "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.
        {
            "circuit-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.
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output_options": [
                {
                    "output": "stdout"
                }
            ],
            "severity": "INFO"
        }
    ]
}

}