Configure subnet-specific options for shared networks
In the case that shared-networks are in use, with the pool containing
equally-valid IP addresses from multiple subnets, it is necessary to set the
subnet-specific parameters such as DHCP-Router-Address, DHCP-Subnet-Mask
and DHCP-Broadcast-Address based on the IP address that has been allocated.
Consider the ISC DHCP configuration snippet:
option domain-name "example.org";
shared-network bigdept {
option domain-name-servers 10.10.0.2, 10.10.0.3;
default-lease-time 7200;
subnet 10.30.10.0 netmask 255.255.255.0 {
option routers 10.30.10.1;
}
subnet 10.30.20.0 netmask 255.255.255.0 {
option routers 10.30.20.1;
}
range 10.30.10.10 10.30.10.254;
range 10.30.20.10 10.30.20.254;
}Or the equivalent Kea configuration:
"Dhcp4": {
"option-data": [
{ "name": "domain-name", "data": "example.org" }
],
"shared-networks": [{
"name": "bigdept",
"option-data": [
{ "name": "domain-name-servers", "data": "10.10.0.2, 10.10.0.3" }
],
"valid-lifetime": 7200,
"subnet4": [{
"subnet": "10.30.10.0/24",
"pools": [ { "pool": "10.30.10.10 - 10.30.10.254" } ],
"option-data": [
{ "name": "routers", "data": "10.30.10.1" }
]
}],
"subnet4": [{
"subnet": "10.30.20.0/24",
"pools": [ { "pool": "10.30.20.10 - 10.30.20.254" } ],
"option-data": [
{ "name": "routers", "data": "10.30.20.1" }
]
}]
}],
...
}As with the network to pool lookup, an instance of the files modules can be
employed (this time after the allocation of an IP address) to set the correct
reply parameters based on the subnet membership of the assigned address.
To do this, we can use this section of <raddb>/mods-available/dhcp_files:
files dhcp_subnets {
filename = ${modconfdir}/files/dhcp
key = "subnet"
}Additionally, uncomment the dhcp_subnets policy in <raddb>/policy.d/dhcp.
This policy wraps the call to the dhcp_subnets files module with code that
"tightens" the DHCP-Network-Subnet attribute by setting it to the
just-allocated IP address.
The relevant entries in the <raddb>/mods-config/files/dhcp configuration
file might then look something like this:
network
DHCP-Domain-Name := "example.org",
Fall-Through := yes
network DHCP-Network-Subnet < 10.30.0.0/16, Pool-Name := "bigdept"
DHCP-Domain-Name-Server := 10.10.0.2,
DHCP-Domain-Name-Server += 10.10.0.3,
DHCP-IP-Address-Lease-Time := 7200
subnet DHCP-Network-Subnet < 10.30.10.0/24
DHCP-Router-Address := 10.30.10.1
subnet DHCP-Network-Subnet < 10.30.20.0/24
DHCP-Router-Address := 10.30.20.1Example packet processing
For our example, we consider a request arriving from a DHCP relay within
10.30.10.0/24. In the absence of any specific DHCP subnet selection options in
the request, the DHCP-Network-Subnet attribute is calculated to be the
relay’s IP address, say 10.30.10.1.
The request is matched against the first "network" block, setting the domain
name to "example.org". By virtue of Fall-Through being set, the next "network"
block is considered.
Since the network identifier is within the specified subnet (i.e. 10.30.10.1 <
10.30.0.0/16) this second "network" block is matched. This block sets the pool
name to "bigdept", sets some network-specific DNS resolvers and sets the lease
time to 7200 seconds. Fall-Through is not set, so we are now done with
deriving the pool name and network options.
When the dhcp_sqlippool module is called during DHCP DISCOVER processing (in
<raddb>/sites-enabled/dhcp) the bigdept pool will be used for IP address
allocation.
After IP allocation the dhcp_subnet policy and files instance are called.
Before the subnet options are looked up the DHCP-Network-Subnet
attribute is tightened to match the assigned IP address, say 10.30.20.123.
The request does not match the first subnet block since 10.30.20.123 is not
within 10.30.10.0/24. However, the request does match the second subnet block
since 10.30.20.123 < 10.30.20.0/24. This block sets the default gateway
reply parameter. Fall-Through is not set, so we are now done with deriving
the pool name and network options.
The assigned IP address, network and subnet parameters will subsequently be returned in the DHCP reply.
Testing the subnet-specific options
If you have set any subnet-specific reply parameters then you should test these before proceeding further.
For example, in the case that you have a single, large pool spanning two IP subnets you might want to test by repeatedly allocating addresses using sample packets with different MAC addresses, each time checking to ensure that the DHCP parameters correspond to the IP address that has been offered.
dhcpclient: ... ... ---------------------------------------------------------------------- Waiting for DHCP replies for: 5.000000 ---------------------------------------------------------------------- ... DHCP-Your-IP-Address = 10.0.10.50 DHCP-Router-Address = 10.0.10.1 DHCP-Broadcast-Address = 10.0.10.255 DHCP-Subnet-Mask = 255.255.255.255
dhcpclient: ... ... ---------------------------------------------------------------------- Waiting for DHCP replies for: 5.000000 ---------------------------------------------------------------------- ... DHCP-Your-IP-Address = 10.99.99.50 DHCP-Router-Address = 10.99.99.1 DHCP-Broadcast-Address = 10.99.99.255 DHCP-Subnet-Mask = 255.255.255.255
|
If the subnets are large then you might want to temporarily reduce their
size by setting the |