"client-classes": [ "VoIP" ]
} ],
"interface": "ethX"
- }
+ },
+
+// The following list defines a subnet with pools. For some pools
+// we defined a class that is allowed in that pool. If not specified
+// everyone is allowed. When a class is specified, only packets belonging
+// to that class are allowed for that pool.
+ {
+ "pools": [
+ {
+// This one is for VoIP devices only.
+ "pool": "192.0.4.1 - 192.0.4.200",
+ "client-class": "VoIP"
+ },
+// This one doesn't have any client-class specified, so everyone
+// is allowed in.
+ {
+ "pool": "192.0.5.1 - 192.0.5.200"
+ } ],
+ "subnet": "192.0.4.0/23",
+ "interface": "ethY"
+ }
]
},
"client-classes": [ "cable-modems" ]
} ],
"interface": "ethX"
+ },
+// The following subnet contains a pool with a class constraint: only
+// clients which belong to the class are allowed to use this pool.
+ {
+ "pools": [
+ {
+ "pool": "2001:db8:3::/80",
+ "client-class": "cable-modems"
+ } ],
+ "subnet": "2001:db8:4::/64",
+ "interface": "ethY"
}
+
]
},
</para>
</section>
+ <section id="classification-pools">
+ <title>Configuring Pools With Class Information</title>
+ <para>
+ Similar to subnets in certain cases access to certain address or
+ prefix pools must be restricted to only clients that belong to a
+ given class, using the "client-class" when defining the pool.
+ </para>
+
+ <para>
+ Let's assume that the server is connected to a network segment that uses
+ the 192.0.2.0/24 prefix. The Administrator of that network has decided
+ that addresses from range 192.0.2.10 to 192.0.2.20 are going to be
+ managed by the DHCP4 server. Only clients belonging to client class
+ Client_foo are allowed to use this pool. Such a
+ configuration can be achieved in the following way:
+ <screen>
+"Dhcp4": {
+ "client-classes": [
+ {
+ "name": "Client_foo",
+ "test": "substring(option[61].hex,0,3) == 'foo'",
+ "option-data": [
+ {
+ "name": "domain-name-servers",
+ "code": 6,
+ "space": "dhcp4",
+ "csv-format": true,
+ "data": "192.0.2.1, 192.0.2.2"
+ }
+ ]
+ },
+ ...
+ ],<userinput>
+ "subnet4": [
+ {
+ "subnet": "192.0.2.0/24",
+ "pools": [
+ {
+ "pool": "192.0.2.10 - 192.0.2.20",
+ "client-class": "Client_foo"
+ }
+ ]
+ },
+ ...
+ ],</userinput>,
+ ...
+}</screen>
+ </para>
+ </section>
+
<section>
<title>Using Classes</title>
<para>
class restrictions on subnets, see <xref linkend="classification-subnets"/>.
</para>
+ <para>
+ When subnets belong to a shared network the classification applies
+ to subnet selection but not to pools, e.g., a pool in a subnet
+ limited to a particular class can still be used by clients which do not
+ belong to the class if the pool they are expected to use is exhausted.
+ So the limit access based on class information is also available
+ at the pool level, see <xref linkend="classification-pools"/>.
+ </para>
+
<para>
The process of doing classification is conducted in three steps. The first step
is to assess an incoming packet and assign it to zero or more classes. The
class restrictions on subnets, see <xref linkend="classification-subnets"/>.
</para>
+ <para>
+ When subnets belong to a shared network the classification applies
+ to subnet selection but not to pools, e.g., a pool in a subnet
+ limited to a particular class can still be used by clients which do not
+ belong to the class if the pool they are expected to use is exhausted.
+ So the limit access based on class information is also available
+ at the address/prefix pool level, see <xref
+ linkend="classification-pools"/>.
+ </para>
+
<para>
The process of doing classification is conducted in three steps. The first step
is to assess an incoming packet and assign it to zero or more classes. The