Commit a9941bac authored by Francis Dupont's avatar Francis Dupont
Browse files

[5549a] Updated examples and guides

parent fcbe15be
......@@ -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" }
]
}
]
},
......
......@@ -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" }
]
}
]
},
......
......@@ -2239,11 +2239,22 @@ It is merely echoed by the server
</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.
......
......@@ -2237,11 +2237,22 @@ should include options from the isc option space:
</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.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment