From: Francis Dupont Date: Sat, 19 May 2018 11:21:04 +0000 (+0200) Subject: [5549a] Updated examples and guides X-Git-Tag: 136-add-global-host-reservation-examples_base~4^2~2^2~4 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a9941bac981d6a5083c778c1005787a7f48a8024;p=thirdparty%2Fkea.git [5549a] Updated examples and guides --- diff --git a/doc/examples/kea4/advanced.json b/doc/examples/kea4/advanced.json index 608a154d2f..894b0489ab 100644 --- a/doc/examples/kea4/advanced.json +++ b/doc/examples/kea4/advanced.json @@ -44,6 +44,12 @@ "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. @@ -142,6 +148,31 @@ "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" } + ] } ] }, diff --git a/doc/examples/kea6/advanced.json b/doc/examples/kea6/advanced.json index 2d324b1a9d..aa587de7ed 100644 --- a/doc/examples/kea6/advanced.json +++ b/doc/examples/kea6/advanced.json @@ -23,6 +23,12 @@ "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. @@ -139,6 +145,31 @@ "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" } + ] } ] }, diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index b17cd80b86..ff3b15cb51 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -2239,11 +2239,22 @@ It is merely echoed by the server - 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. + + + + 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. diff --git a/doc/guide/dhcp6-srv.xml b/doc/guide/dhcp6-srv.xml index f1e8d8b3da..76ceec3d1d 100644 --- a/doc/guide/dhcp6-srv.xml +++ b/doc/guide/dhcp6-srv.xml @@ -2237,11 +2237,22 @@ should include options from the isc option space: - 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. + + + + 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.