"re-detect": true
},
+ // Define the unknown client class.
+ "client-classes": [ {
+ "name": "unknown",
+ "test": "not member('KNOWN')"
+ } ],
+
// Option 43 last resort definition can make well-formed messages
// to be rejected because they use not compatible "raw" value,
// and different vendors may define different sub-options.
"relay": {
"ip-address": "192.168.1.1"
}
+ },
+ {
+ // This subnet is divided in two pools for unknown and
+ // known (i.e. which have a reservation) clients.
+ // The built-in KNOWN class is set or not at host reservation
+ // lookup and client classes depending on it are evaluated.
+ // This happens after subnet selection and before address
+ // allocation from pools.
+ "pools": [
+ {
+ "pool": "192.0.8.100 - 192.0.8.200",
+ "client-class": "unknown"
+ },
+ {
+ "pool": "192.0.9.100 - 192.0.9.200",
+ "client-class": "KNOWN"
+ }
+ ],
+ "subnet": "192.0.8.0/23",
+ "reservations": [
+ { "hw-address": "00:00:00:11:22:33", "hostname": "h1" },
+ { "hw-address": "00:00:00:44:55:66", "hostname": "h4" },
+ { "hw-address": "00:00:00:77:88:99", "hostname": "h7" },
+ { "hw-address": "00:00:00:aa:bb:cc", "hostname": "ha" }
+ ]
}
]
},
"re-detect": true
},
+ // Define the unknown client class.
+ "client-classes": [ {
+ "name": "unknown",
+ "test": "not member('KNOWN')"
+ } ],
+
// 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.
"relay": {
"ip-address": "3000::1"
}
+ },
+ {
+ // This subnet is divided in two pools for unknown and
+ // known (i.e. which have a reservation) clients.
+ // The built-in KNOWN class is set or not at host reservation
+ // lookup and client classes depending on it are evaluated.
+ // This happens after subnet selection and before address
+ // allocation from pools.
+ "pools": [
+ {
+ "pool": "2001:db8:8::/64",
+ "client-class": "unknown"
+ },
+ {
+ "pool": "2001:db8:9::/64",
+ "client-class": "KNOWN"
+ }
+ ],
+ "subnet": "2001:db8:8::/46",
+ "reservations": [
+ { "hw-address": "00:00:00:11:22:33", "hostname": "h1" },
+ { "hw-address": "00:00:00:44:55:66", "hostname": "h4" },
+ { "hw-address": "00:00:00:77:88:99", "hostname": "h7" },
+ { "hw-address": "00:00:00:aa:bb:cc", "hostname": "ha" }
+ ]
}
]
},
</para>
<para>
- The process of doing classification is conducted in several steps. The first step
- is to assess an incoming packet and assign it to zero or more classes. The
- second step is to choose a subnet, possibly based on the class information.
- The third step is to assign classes from host reservations and
- evaluate class expressions depending on the "KNOWN" class.
+ In a similar way a pool can be constrained to serve only known clients,
+ i.e. clients which have a reservation, using the build-n "KNOWN" class.
+ One can assign addresses to registered clients without giving a
+ different address per reservations, for instance when there is
+ not enough available addresses.
+ </para>
+
+ <para>
+ The process of doing classification is conducted in five steps.
+ The first step is to assess an incoming packet and assign it to
+ zero or more classes.
+ The second step is to choose a subnet, possibly based on the
+ class information.
+ The next step is to evaluate class expressions depending on the
+ built-in "KNOWN" class after host reservation lookup, and to
+ assign classes from host reservations.
After the list of required classes is built and each class of the list
has its expression evaluated: when it returns true the packet is added
as a member of the class.
</para>
<para>
- The process of doing classification is conducted in several steps. The first step
- is to assess an incoming packet and assign it to zero or more classes. The
- second step is to choose a subnet, possibly based on the class information.
- The third step is to assign classes from host reservations and
- evaluate class expressions depending on the "KNOWN" class.
+ In a similar way a pool can be constrained to serve only known clients,
+ i.e. clients which have a reservation, using the build-n "KNOWN" class.
+ One can assign addresses to registered clients without giving a
+ different address per reservations, for instance when there is
+ not enough available addresses.
+ </para>
+
+ <para>
+ The process of doing classification is conducted in five steps.
+ The first step is to assess an incoming packet and assign it to
+ zero or more classes.
+ The second step is to choose a subnet, possibly based on the
+ class information.
+ The next step is to evaluate class expressions depending on the
+ built-in "KNOWN" class after host reservation lookup, and to
+ assign classes from host reservations.
After the list of required classes is built and each class of the list
has its expression evaluated: when it returns true the packet is added
as a member of the class.
projects / thirdparty / kea.git / commitdiff
