In Part 1 we covered the basic configuration of the DHCP. Now we’ll delve into some of the more advanced configuration aspects.
Inherited Settings
When a DHCPDISCOVER message is received by the router, Cisco IOS matches it against the list of DHCP pools and returns the DHCP options based on which pools matched the subnet the request came from.
Did you catch that? I said pools… plural… if the pools overlap, it is possible for more than one DHCP pool to match a DHCPDISCOVER message. In this case the options are cascaded down through the matching pools with the more specific pool taking priority. Here’s an example:
ip dhcp pool GLOBAL
 network 192.168.0.0 /22
 dns-server 192.168.1.10 192.168.1.11
ip dhcp pool DATA
 network 192.168.1.0 /24
 default-router 192.168.1.1
ip dhcp pool VOICE
 network 192.168.2.0 /24
 default-router 192.168.2.1
dns-server 192.168.2.10
Assuming we get a DHCPDISCOVER request on the DATA VLAN, the request will be matched against the pools above. As you can see, the 192.168.1.0 network will match both the GLOBAL and the DATA pools. Since none of the options overlap, the DHCPOFFER will contain an IP address on the 192.168.1.0/24 network with 192.168.1.1 as the gateway router and dns servers of 192.168.1.10 and 192.168.1.11.
However if the DHCPDISCOVER request was received on the VOICE VLAN, the result would be different. The DHCPOFFER would still contain an address on the 192.168.2.0/24 network with it’s proper gateway. However, the more specific matched pool (VOICE) would override the DNS server settings in GLOBAL. So the DHCPOFFER would only contain one DNS server (192.168.2.10).
Manual Host Bindings
What if we always want a specific host to get a certain IP address?
We can create a manual binding for that host like this :
ip dhcp pool COMPUTER_NAME
 hardware-address 0012.3456.789A
 host 192.168.1.100 mask 255.255.255.0
 client-name COMPUTER_NAME
If you have a lot of these, it helps to minimize the configuration if you use inheritance as discussed above. The DHCP pool name does not have to match the computer name, I just find it helpful if it does. Also, the client-name command is not required except where network devices learn their hostname via DHCP.
It should also be noted that Microsoft DHCP clients send a client identifier rather than the MAC address of their network card. The client identifier includes a media identification byte at the beginning of the value. The value for ethernet media is 1. Therefore the above DHCP pool configuration for a Microsoft Windows client would look like this
ip dhcp pool COMPUTER_NAME
 client-identifier 0100.1234.5678.9A
 host 192.168.1.100 mask 255.255.255.0
 client-name COMPUTER_NAME
See how the client-identifier command includes the media type for ethernet (01) followed by the device MAC address?
Both hardware-address and client-identifier can be configured at the same time.
Persistance
What happens when our router dies due to power failure or some other unfortunate event? We would lose all of our precious DHCP bindings… ok maybe not that big a deal, they are dynamic and all… But this can cause issues, especially on larger networks. If there is no binding table, then the DHCP server will take longer as it tries to find an unused IP address. In a densely populated network, it could take a long time before the server finally found an available IP address. To cause the DHCP binding table to be stored in a more permanent location we can use the following commands.
ip dhcp database ftp://user:password@192.168.1.10/data-dhcp
This tells the system to store the DHCP binding table on an FTP server at 192.168.1.10 using the username ‘user’ and the password ‘password’. The name of the file will be data-dhcp.
By default, this file will only be updated every 5 minutes. And will wait for up to 5 minutes for the FTP transaction to complete. Both of these settings can be adjusted with optional parameters to the ip dhcp database command.
In the above example FTP was used as the transport protocol, but TFTP and RCP are supported as well.