You want to configure your router to pass DHCP requests from local clients to a centralized DHCP server.

The ip helper-address configuration command allows the router to forward local DHCP requests to one or more centralized DHCP servers:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Ethernet0
Router1(config-if)#ip helper-address 172.25.1.1
Router1(config-if)#ip helper-address 172.25.10.7
Router1(config-if)#end
Router1#

The traditional role of a router in DHCP has been to act as a proxy device that forwards information between the client and server. This proxy function is still the most common for routers, but Cisco routers have had DHCP server and client features since IOS level 12.0(1)T.

Because the initial DHCP request comes from a client that typically doesn’t have an IP address, it must find the server using a Layer 2 broadcast. So, if the router is not able to function as a proxy for these broadcasts, there must be a DHCP server on every network segment.

The DHCP server needs two critical pieces of information before it can allocate an IP address to the client: the subnet that the client is connected to and the client device’s MAC address. The subnet information is needed to ensure that the address that the server allocates will actually work on client’s network segment, while the MAC address allows the server to find any information that is unique to a workstation. This is essential if you need to ensure that a particular end device gets the same IP address every time it connects to the network.

So the DHCP proxy, which is the router itself, must convert the local broadcast from the client to a unicast packet and forward it to the server. This is what the ip helper-address command does.

When the DHCP client sends the DHCP request packet, it doesn’t have an IP address. So it uses the all-zeros address (0.0.0.0) as the IP source address. It also doesn’t know how to reach the DHCP server, so it uses a general broadcast address (255.255.255.255) for the destination.

The router must replace the source address with its own IP address, for the interface that received the request. And it replaces the destination address with the address specified in the ip helper-address command. The client device’s MAC address is included in the payload of the original DHCP request packet, so the router doesn’t need to do anything to ensure that the server receives this information.

The DHCP server now has enough information to assign an address from the correct address pool, since it now knows what the originating subnet was for the DHCP request. The server then sends a unicast response back to the proxy router, which in turn sends the request back to the correct MAC address.

The example shows two ip helper-address commands. You should include one of these commands for each of your DHCP servers. The router will forward the DHCP broadcasts to all of these addresses. Most organizations use at least two DHCP servers because, although the utilization is light, the functionality is critical. If the client device receives several responses to a DHCP request, it will usually select the one it receives first.

It is important to note that the ip helper-address command does not just forward DHCP requests. In fact, although you can configure it to forward any UDP broadcast you want, it will forward UDP broadcast packets for several different UDP ports to the specified address by default. In some cases, this unwanted traffic can cause problems on the network or the DHCP server. Recipe 20.2 focuses on this issue.

The show ip interface command includes information about the helper addresses configured on an interface:

Router1#show ip interface Ethernet0
Ethernet0 is up, line protocol is up
  Internet address is 192.168.30.1/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper addresses are 172.25.1.3
                       172.25.1.1
  Directed broadcast forwarding is disabled
  <lines removed for brevity>
Router1#

Recipe 20.2

After configuring your router to use IP helper addresses, you suffer from high link utilization or high CPU utilization on the DHCP server.

The ip helper-address command implicitly enables forwarding of several different kinds of UDP broadcasts. You can prevent the router from forwarding the unwanted types of broadcasts with the no ip forward-protocol udp configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#no ip forward-protocol udp tftp
Router1(config)#no ip forward-protocol udp nameserver
Router1(config)#no ip forward-protocol udp domain
Router1(config)#no ip forward-protocol udp time
Router1(config)#no ip forward-protocol udp netbios-ns
Router1(config)#no ip forward-protocol udp netbios-dgm
Router1(config)#no ip forward-protocol udp tacacs
Router1(config)#end
Router1#

As mentioned in Recipe 20.1, if the DHCP client and server are on different network segments, the router on the client’s segment must be configured with a helper address for DHCP to work. However, the helper address configuration forwards a variety of different UDP broadcasts, not just DHCP packets. This can cause network and CPU loading problems on the DHCP server.

By default, when you configure the ip helper-address command on an interface, the router will automatically forward UDP broadcasts for all of the protocols shown in Table 20-1.

In particular, networks that include Microsoft Windows networking features use a lot of NetBIOS packets. The DHCP server receives broadcasts from many end device segments throughout the network. It is possible to have enough traffic aggregating on this point to cause serious problems.

This recipe disables each unnecessary protocol, one at a time, using the no ip forward-protocol configuration command. Some organizations choose to disable only the NetBIOS protocol because this is usually the one that most frequently causes problems.

We strongly recommend using the no ip forward-protocol command to ensure that only the required protocols are being forwarded to your DHCP server. Note, however, that this command cannot forward different protocols to different helper addresses. If you have two different servers handling different UDP broadcast protocols, they will both receive all of the local broadcasts that the router accepts. If you need more detailed control over these types of applications, you may find that the broadcast-to-multicast conversion features discussed in Chapter 23 are more effective.

Recipe 20.1; Chapter 23

You want the router to dynamically obtain its IP addressing information.

The ip address dhcp configuration command allows the router to dynamically obtain the address information for an interface:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Ethernet0
Router1(config-if)#ip address dhcp client-id Ethernet0
Router1(config-if)#end
Router1#
Interface Ethernet0 assigned DHCP address 172.25.1.57, mask 255.255.255.0
Router1#

Cisco started to include DHCP client functionality in IOS Version 12.1(2)T. This allows routers to obtain interface IP address information via DHCP. While we don’t recommend using dynamic addressing for routers in an internal network, this can be extremely useful for routers that connect to the Internet through an ISP. It is increasingly common for service providers to use DHCP to give address information to allocate information to client devices.

When an interface on the router is configured as a DHCP client like this, it is able to dynamically learn its IP address, netmask, and default gateway via DHCP. You can also configure the router to accept domain name and DNS server information through DHCP.

In the following screen capture, the router has learned its default route via DHCP. The router displays this DHCP route as a static route and assigns it an administrative distance of 254. This ensures that the default address learned via DHCP is the absolutely last possible route, and any other static or dynamic routes will take precedence:

Router1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.25.1.1 to network 0.0.0.0

     172.25.0.0/24 is subnetted, 1 subnets
C       172.25.1.0 is directly connected, Ethernet0
S*   0.0.0.0/0 [254/0] via 172.25.1.1
Router1#

In the ISP situation, the end devices will also need domain name and DNS server information. You can see this information with the show host command. This example shows domain name and DNS server information learned via DHCP:

Router1#show host
Default domain is oreilly.com
Name/address lookup uses domain service
Name servers are 255.255.255.255, 172.25.1.1

Host                      Port  Flags      Age Type   Address(es)
www.oreilly.com           None  (temp, OK)  0   IP    192.168.22.57
Router1#

Note that the router dynamically learned about the domain name and name server information via DHCP, but this information will not overwrite statically configured information. For example, if you manually configure the router with a domain name, the router will quietly ignore the one that it learns through DHCP. The router will simply add any name servers that it learns through DHCP to the static list of manually configured name servers.

The show ip interface command tells you that the router learned IP address from DHCP:

Router1#show ip interface
Ethernet0 is up, line protocol is up
  Internet address is 172.25.1.57/24
  Broadcast address is 255.255.255.255
  Address determined by DHCP
  MTU is 1500 bytes
  <removed for brevity>

Cisco routers do not currently include a way to specify which options the router will request from the server. You also can’t see the address lease time remaining. Hopefully Cisco will include these options in a future IOS release.

Although controlling your router addresses from a centralized DHCP server might seem like a good idea, we don’t generally recommend it. Routers are the core architecture of a network and should never rely on an external server to obtain IP addressing. Unless a DHCP server is available on every segment, the router needs a DHCP proxy, which is usually another router with a hardcoded IP address. In disaster scenarios in which many routers fail simultaneously, it can be extremely difficult to bootstrap the network back into operation.

So, except for specific circumstances (such as using a router at the edge of the network to connect to an ISP), we strongly discourage using this DHCP client functionality.

You want to configure your router to be a DHCP server and allocate dynamic IP addresses to client workstations.

The following set of configuration commands allows the router to dynamically allocate IP addresses to client workstations:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#service dhcp
Router1(config)#ip dhcp pool 172.25.1.0/24
Router1(dhcp-config)#network 172.25.1.0 255.255.255.0
Router1(dhcp-config)#default-router 172.25.1.1
Router1(dhcp-config)#exit
Router1(config)#ip dhcp excluded-address 172.25.1.1 172.25.1.50
Router1(config)#ip dhcp excluded-address 172.25.1.200 172.25.1.255
Router1(config)#end
Router1#

Cisco incorporated DHCP server functionality starting in IOS Version 12.0(1)T. This allows routers to dynamically allocate IP addresses to client workstations without needing a centralized DHCP server.

Providing DHCP services from a router has some interesting advantages over using a central server. First, distributing the DHCP functionality into the access routers of a large network reduces the risk of a server configuration problem affecting the entire corporate network. Second, maintaining DHCP services within each remote branch router reduces the utilization over expensive WAN links. Third, when a WAN link fails, workstations are still able to function on the local segment. And fourth, the router-based DHCP services can easily be administered by your network engineers via one common interface, the IOS prompt.

In our example, we have configured the router to dynamically allocate IP addresses for the subnet 172.25.1.0/24. First, we define a range of IP addresses using the network command. Then we need to exclude some addresses from the dynamic range with the ip dhcp exclude-address command. If you do not exclude a range of addresses, the router will assign IP addresses from the entire subnet (254 addresses in total). But in most networks, at least some of the addresses are reserved for other purposes.

At a minimum, you should exclude the router’s own IP address to prevent the DHCP service from trying to assign it elsewhere, causing a conflict. Many network engineers allocate the lower portion of the subnet to static devices such as routers, servers, printers, and other devices that do not support DHCP. Here, we reserved the first 50 addresses for statically addressed devices (172.25.1.1 to 172.25.1.50). We also chose to reserve addresses from 172.25.1.200 to 172.25.1.255 for future use (and to show that you can reserve multiple blocks of addresses).

When DHCP is enabled, the router will allocate IP addresses dynamically by binding them to device MAC addresses in the configured pool. IP addresses are allocated for a defined period of time called a lease, which we discuss further in Recipe 20.6.You can view the address bindings with the show ip dhcp binding command:

Router1#show ip dhcp binding
IP address       Hardware address        Lease expiration        Type
172.25.1.51      0100.0103.85e9.87       Apr 10 2003 08:55 PM    Automatic
172.25.1.52      0100.50da.2a5e.a2       Apr 10 2003 09:00 PM    Automatic
172.25.1.53      0100.0103.ea1b.ed       Apr 10 2003 08:58 PM    Automatic
Router1#

The MAC addresses in this output look a little funny because they have two extra hex digits (one extra octet) at the start. We explain why in Recipe 20.7.

The router maintains an internal database of assigned IP addresses and their associated MAC addresses. We show how to write this database to a remote server for backup purposes in Recipe 20.8.

This example dynamically configures DCHP clients with the default router setting using the default-router command. We discuss these DHCP options in detail in Recipe 20.5.

Recipe 20.5; Recipe 20.6; Recipe 20.7; Recipe 20.8; Recipe 20.9

You want to dynamically deliver configuration parameters to client workstations.

You can configure a wide variety of DHCP parameters for configuring client workstations:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp pool ORAserver
Router1(dhcp-config)#host 172.25.1.34 255.255.255.0
Router1(dhcp-config)#client-name bigserver
Router1(dhcp-config)#default-router 172.25.1.1 172.25.1.3
Router1(dhcp-config)#domain-name oreilly.com
Router1(dhcp-config)#dns-server 172.25.1.1 10.1.2.3
Router1(dhcp-config)#netbios-name-server 172.25.1.1
Router1(dhcp-config)#netbios-node-type h-node
Router1(dhcp-config)#option 66 ip 10.1.1.1
Router1(dhcp-config)#option 33 ip 24.10.1.1 172.25.1.3
Router1(dhcp-config)#option 31 hex 01
Router1(dhcp-config)#lease 2
Router1(dhcp-config)#end
Router1#

The strength of DHCP is its ability to configure client workstations from a centralized location using DHCP options. It greatly reduces support costs if workstations can dynamically learn all of their configuration options instead of having to send a technician to every desk.

DHCP can assign default routes, domain names, name server addresses, and WINS server addresses, to name just a few. RFC 2132 defines a large number of standard configurable options and includes provisions for further vendor-specific options. However, most networks only use a small subset of these options. To make configuration easier, Cisco provides human-readable names for several of the most common options, as shown in Table 20-2.

However, since it would be impossible to create user-friendly names for every possible DHCP option, Cisco allows you to manually configure any option by its number, using the option command.

You can also use the option command instead of the custom name. For example, option 6 in RFC 2132 is reserved for name server addresses. Instead of using the Cisco-provided, user-friendly command dns-server, as we did in the recipe example, we can define it manually:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp pool 172.25.2.0/24
Router1(dhcp-config)#option 6 ip 172.25.1.1
Router1(dhcp-config)#end
Router1#

The router will then translate the manual entry to its user-friendly equivalent in its running configuration file. It can be a little confusing when you look at the router configuration and it isn’t what you typed, but both forms are completely equivalent.

Some options will accept multiple entries. For example, the default router option and the dns-server option will both accept up to eight IP addresses, in order of preference. However, you will rarely require that many possible entries for a single option. For the default router option in particular, we recommend using defining a single default router address. If there are several routers on a segment, the default router would be the HSRP address. You would use multiple default routers only if you have many routers, but are not running HSRP. This is not a design that we would generally endorse. For more information about HSRP, see Chapter 22.

To make configuration easier, you can create a hierarchy of DHCP pools. Parent DHCP pools are determined by IP address ranges. For instance, in the following example we configure a parent DHCP pool called ROOT, which is used to assign options to the entire classful network range, 172.25.0.0/16. We then configure two other DHCP pools for specific subnets of 172.25.1.0/24 and 172.25.2.0/24. These two child pools will automatically inherit the options defined within the ROOT pool. You can then overwrite some of the inherited options within the child pools, if necessary:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp pool ROOT
Router1(dhcp-config)#network 172.25.0.0 255.255.0.0
Router1(dhcp-config)#domain-name oreilly.com
Router1(dhcp-config)#dns-server 172.25.1.1 10.1.2.3
Router1(dhcp-config)#lease 2
Router1(dhcp-config)#exit
Router1(dhcp)#ip dhcp pool 172.25.1.0/24
Router1(dhcp-config)#network 172.25.1.0 255.255.255.0
Router1(dhcp-config)#default-router 172.25.1.1
Router1(dhcp-config)#exit
Router1(dhcp)#ip dhcp pool 172.25.2.0/24
Router1(dhcp-config)#network 172.25.2.0 255.255.255.0
Router1(dhcp-config)#default-router 172.25.2.1
Router1(dhcp-config)#lease 0 0 10
Router1(dhcp-config)#end
Router1#

The example in the solution section of this recipe also includes several option statements to define parameters that don’t have convenient mnemonics:

Router1(dhcp-config)#option 66 ip 10.1.1.1
Router1(dhcp-config)#option 33 ip 192.0.2.1 172.25.1.3
Router1(dhcp-config)#option 31 hex 01

These option codes are defined in RFC 2132. In this case, option 66 identifies a TFTP server, option 33 specifies static routes, and option 31 tells the client to use ICMP Router Discovery Protocol (IRDP).

The static route statement tells the end device to send all traffic destined to the host, 192.0.2.1/32, to the router at 172.25.1.3.

IRDP allows the client workstation to listen for periodic updates from local routers to determine its default gateway. IRDP is discussed in the introduction to Chapter 22.

Recipe 20.4; Chapter 22; RFC 2132

You want to change the default lease period.

To modify the default DHCP lease time for a pool of IP addresses, use the lease configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp pool 172.25.2.0/24
Router1(dhcp-config)#lease 2 12 30
Router1(dhcp-config)#end
Router1#

The lease command takes up to three options: lease days [hours] [minutes] with hours and minutes being optional. You can specify a maximum period of 365 days, 23 hours and 59 minutes, and a minimum of 1 second. The default is 1 day.

The shorter the lease period, the faster you can reconfigure DHCP options that may need to change. Short lease periods also permit IP addresses to be returned to the address pool for reallocation more quickly. This can be useful in environments where a large number of end devices frequently connect and disconnect, such as in a public wireless network at an airport. A short lease period of, say, 30 minutes might be useful to ensure that IP addresses are returned quickly to the shared pool. However, short lease periods also mean that workstations must renew their leases more often, which puts an extra strain on the network and DHCP server.

Conversely, a small office with a stable workforce may choose to increase their lease periods. Long lease periods can also reduce the impact of DHCP server failures. Unless a workstation reboots or needs to disconnect and reconnect to the network, most clients will wait until the lease is half expired before asking the server to renew it. If the server is unavailable, the client device will periodically retry the lease renewal until it succeeds. But most organizations have redundant DHCP servers, so there are few real benefits to extremely long lease periods.

In most situations, the default lease period of one day is sufficient. It allows the administrators to change global options in a timely fashion without putting an unnecessary burden on the network or server.

You can also configure the router to assign addresses with infinite lease periods by using the infinite keyword:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp pool COOKBOOK
Router1(dhcp-config)#lease infinite
Router1(dhcp-config)#end
Router1#

Assigning an infinite lease period removes one of the major advantages of using DHCP. It can be extremely useful to be able to use DHCP to make wholesale configuration changes, but this means that the end devices have to check in periodically to renew their leases. Providing an indefinite lease period largely circumvents this advantage, since it forces you to wait until the end device disconnects and reconnects to the network before you can give it new information. Use the infinite keyword with caution.

You can view the lease expiration times of your active clients with the show ip dhcp binding command:

Router1#show ip dhcp binding
IP address       Hardware address       Lease expiration       Type
172.25.1.33      0100.0103.85e9.87      Infinite               Manual
172.25.1.53      0100.0103.ea1b.ed      Apr 11 2003 08:58 PM   Automatic
172.25.1.57      0100.6047.6c41.a4      Apr 11 2003 09:17 PM   Automatic
Router1#

Please refer to Recipe 20.7 for an explanation of the odd-looking MAC addresses in this output.

Recipe 20.4; Recipe 20.7

You want to ensure that your router assigns the same IP address to a particular device every time it connects.

The following commands ensure that the router assigns the same IP address to a device each time it requests one:

Router1(config)#ip dhcp pool IAN
Router1(dhcp-config)#host 172.25.1.33 255.255.255.0
Router1(dhcp-config)#client-identifier 0100.0103.85e9.87
Router1(dhcp-config)#client-name win2k
Router1(dhcp-config)#default-router 172.25.1.1
Router1(dhcp-config)#domain-name oreilly.com
Router1(dhcp-config)#dns-server 172.25.1.1
Router1(dhcp-config)#end
Router1#

The router allows you to statically bind an IP address to a MAC address, which ensures that a particular device always receives the same IP address. This is particularly useful for devices such as servers that must be available for access via a well-known IP address or DNS entry. Any device that accepts inbound sessions will probably require a static address, and allocating these addresses via DHCP provides administrators with greater control over their networks.

The configuration for a static DHCP mapping is slightly different from that of a dynamic pool. In particular, you must assign a separate dhcp pool for each static server. In our example, we created a pool named IAN to allocate a static IP address to user Ian. Also, instead of defining a network range of IP addresses, you can assign a specific IP address using the host command. To avoid address conflicts, make sure that the static address you assign is not part of an already configured dynamic pool. You may need to use the excluded-address command for this.

You must configure the static pool with the device’s MAC address using the client-identifier command. The client identifier is made up of two parts: the media type and the MAC address. The media type numbers can be found in RFC 1700 (“Assigned Numbers”) under the heading “Number Hardware Type.” For 10/100/1000Mb Ethernet, the media type number is 01. The router will combine the media type and MAC address into one large address and automatically add the dots if you don’t type them.

From this point on, the router will accept the same options as the dynamic pool options. Options can be inherited from dynamic pools as well. To view the configured static binding use the show ip dhcp binding command:

Router1#show ip dhcp binding
IP address       Hardware address      Lease expiration       Type
172.25.1.33      0100.0103.85e9.87     Infinite               Manual
172.25.1.52      0100.50da.2a5e.a2     Apr 11 2003 09:00 PM   Automatic
172.25.1.53      0100.0103.ea1b.ed     Apr 11 2003 08:58 PM   Automatic
Router1#

This shows that we have successfully mapped a static IP address of 172.25.1.33 to MAC address 0001-0385-e987. DHCP has put the code 01 at the start of this address to indicate that it is an Ethernet MAC.

Note that the router marks the static clients as “Manual” to differentiate them from the others. Although the output indicates that the static lease is indefinite, in reality it is not. The static dhcp pool can be assigned any lease period you desire, but the router will only allocate the single static address. This can be useful if you want to change other DHCP options for this end device.

Recipe 20.5; RFC 1700

You want to back up your DHCP database of address assignments to another device so that you won’t lose it if the router reloads.

You can ensure that your DHCP address assignments are not lost when a router reloads by configuring the router to periodically copy its DHCP database to a remote server.

The first example configures a router to use FTP to copy the DHCP database to a remote server:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp database ftp://dhcp:[email protected]/dhcp-leases
Router1(config)#end
Router1#

The second example uses TFTP as the transport protocol:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp database tftp://172.25.1.1/dhcp-leases
Router1(config)#end
Router1#

The third configures RCP as the transport protocol:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp database rcp://[email protected]/dhcp-leases
Router1(config)#end
Router1#

By default, the router stores its DHCP binding database in memory. So, when the router reloads, all DHCP database information is lost. You can configure the router to periodically send a copy of this database to a remote server to avoid losing this important information. If the router recycles for any reason, it will automatically load the last version of the database file from the remote server and proceed from where it left off.

In our example, we have configured our test router to store its DHCP database to the server at 172.25.1.1 via FTP. FTP uses a simple username and password authentication system, so we have included the user ID dhcp and password bindsave in the command. After authenticating, the router will store its database in a file called dhcp-leases in the default directory for this user ID. If you have multiple routers storing their databases on the same server, make sure to use a unique file name that includes the router name. This can assist in troubleshooting later.

To view the status of the DHCP database, use the show ip dhcp database command:

Router1#show ip dhcp database
URL      : ftp://dhcp:[email protected]/dhcp-leases
Read     : Never
Written  : Apr 09 2003 10:24 PM
Status   : Last write succeeded. Agent information is up-to-date.
Delay    : 300 seconds
Timeout  : 300 seconds
Failures : 1
Successes: 30

Router1#

Note that the router is storing the database to the URL we specified, and that its last write was successful. The output also tells us that the router has successfully written its database to the server 30 times and only experienced a single failure. All of this indicates that the DHCP backup is working well. If we log on to the server and view the contents of the database file, we will see the current DCHP bindings:

Freebsd% cat dhcp-leases
*time* Apr 09 2003 10:24 PM

!IP address     Type  Hardware address   Lease expiration
172.25.1.52     id    0100.50da.2a5e.a2  Apr 10 2003 09:00 PM
172.25.1.53     id    0100.0103.ea1b.ed  Apr 10 2003 08:58 PM

!IP address     Interface-index  Lease expiration       Vrf
*end*
Freebsd%

Fortunately, the file is in human-readable form and lets us see the latest DHCP bindings. Static address bindings never change, so they are not sent to the remote database server.

We will simulate a power failure by reloading the router:

Router1#show ip dhcp database
URL      : ftp://dhcp:[email protected]/dhcp-leases
Read     : Apr 10 2003 10:35 PM
Written  : Never
Status   : Last read succeeded. Bindings have been loaded in RAM.
Delay    : 300 seconds
Timeout  : 300 seconds
Failures : 0
Successes: 1

Router1#

Now when we display the database information, we see that the router successfully read the database from the server and loaded the bindings into memory. Viewing the router bindings now, you can see that the database has been recovered:

Router1#show ip dhcp binding
IP address       Hardware address        Lease expiration        Type
172.25.1.33      0100.0103.85e9.87       Infinite                Manual
172.25.1.52      0100.50da.2a5e.a2       Apr 10 2003 09:00 PM    Automatic
172.25.1.53      0100.0103.ealb.ed       Apr 10 2003 08:58 PM    Automatic
Router1#

Recipe 20.4; Recipe 20.10

You want to configure multiple routers to act as DHCP servers for the same subnet to ensure availability.

You can configure multiple routers to act as DHCP servers for a single subnet by ensuring that they don’t use the same pool of addresses.

Router1:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp pool 172.22.1.0/24
Router1(dhcp-config)#network 172.22.1.0 255.255.255.0
Router1(dhcp-config)#default-router 172.22.1.1
Router1(dhcp-config)#domain-name oreilly.com
Router1(dhcp-config)#dns-server 172.25.1.1 10.1.2.3
Router1(dhcp-config)#exit
Router1(config)#ip dhcp excluded-address 172.22.1.1 172.22.1.49
Router1(config)#ip dhcp excluded-address 172.22.1.150 172.22.1.254
Router1(config)#ip dhcp database ftp://dhcp:[email protected]/dhcp-leases-rtr1
Router1(config)#end
Router1#

Router2:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#ip dhcp pool 172.22.1.0/24
Router2(dhcp-config)#network 172.22.1.0 255.255.255.0
Router2(dhcp-config)#default-router 172.22.1.1
Router2(dhcp-config)#domain-name oreilly.com
Router2(dhcp-config)#dns-server 172.25.1.1 10.1.2.3
Router2(dhcp-config)#exit
Router2(config)#ip dhcp excluded-address 172.22.1.1 172.22.1.149
Router2(config)#ip dhcp database ftp://dhcp:[email protected]/dhcp-leases-rtr2
Router2(config)#end
Router2#

You can configure multiple DHCP servers to service the same subnet; in fact, we recommend it. However, you must ensure that the two servers do not share the same dynamic pool of IP addresses.

In our example, we chose to let Router1 allocate the addresses between 172.25.1.50 and 172.25.1.149, while Router2 allocates the pool from 172.25.1.150 to 172.25.1. 254. We reserved the range from 172.25.1.1 to 172.25.1.50 for static IP addresses.

You need to map out the allocated address space ahead of time and use the ip dhcp excluded-address configuration command to ensure that there is no overlap. The critical thing about this type of configuration is to ensure that the allocated pool of DHCP addresses on a single router is sufficiently large to handle all of the DHCP clients on the segment if the other router fails. This way, although the two routers do not allocate addresses from the same pool (which would cause problems for the DHCP databases), you still have complete redundancy.

We have also configured the routers to store their DHCP binding databases to separate files on the same server. For added protection, you could opt to store the individual database files to different servers.

The rest of the option settings are identical, although they don’t necessarily have to be. You might want to change the name server order, for instance, to help balance the load between DNS servers.

Recipe 20.4; Recipe 20.5

You want to display the status of the DHCP server functions on the router.

To display the IP address bindings and their associated leases, use this command:

Router1#show ip dhcp binding

The following command displays any IP address conflicts that the router has detected in the DHCP address pool:

Router1#show ip dhcp conflict

You can view the status of remote database backups with this command:

Router1#show ip dhcp database

And you can see the global DHCP server statistics like this:

Router1#show ip dhcp server statistics

To display the status of the DHCP service, use the show ip dhcp EXEC command. If you add the keyword binding, this command displays the current DHCP bindings, which include the assigned IP addresses, the associated client MAC addresses, and the lease expiration time:

Router1#show ip dhcp binding
IP address       Hardware address        Lease expiration        Type
172.25.1.51      0100.0103.85e9.87       Apr 10 2003 08:55 PM    Automatic
172.25.1.52      0100.50da.2a5e.a2       Apr 10 2003 09:00 PM    Automatic
172.25.1.53      0100.0103.ea1b.ed       Apr 10 2003 08:58 PM    Automatic
Router1#

To view the IP addresses that are currently in conflict, use the conflict keyword. This command displays all of the IP addresses that the router has discovered conflicts for, and how the conflict was discovered:

Router1#show ip dhcp conflict
IP address        Detection method   Detection time
172.25.1.51       Ping               Apr 09 2003 09:08 PM
172.25.1.54       Gratuitous ARP     Apr 09 2003 10:00 PM
Router1#

With the database keyword, you can view the database configuration and status. This command shows all of the configured remote database servers and the current read and write status reports:

Router1#show ip dhcp database
URL      : ftp://dhcp:[email protected]/dhcp-leases
Read     : Never
Written  : Apr 09 2003 10:24 PM
Status   : Last write succeeded. Agent information is up-to-date.
Delay    : 300 seconds
Timeout  : 300 seconds
Failures : 1
Successes: 30

Router1#

Finally, the statistics keyword lets you view the overall DHCP statistics:

Router1#show ip dhcp server statistics
Memory usage         17996
Address pools        4
Database agents      1
Automatic bindings   2
Manual bindings      1
Expired bindings     3
Malformed messages   0

Message              Received
BOOTREQUEST          0
DHCPDISCOVER         63
DHCPREQUEST          203
DHCPDECLINE          1
DHCPRELEASE          27
DHCPINFORM           19

Message              Sent
BOOTREPLY            0
DHCPOFFER            63
DHCPACK              139
DHCPNAK              2
Router1#

This command displays high-level DHCP statistics, including the number of bindings, and address pools, as well as the number of sent and received messages.

Recipe 20.4

You want to debug a DHCP problem.

To debug the server events, use the following EXEC command:

Router1#debug ip dhcp server events

The following command will allow you to monitor the actual DHCP-related packets being transmitted and received by the router:

Router1#debug ip dhcp server packet

The following debug capture shows a router performing normal housekeeping duties such as updating its address pools, checking for expired leases, assigning new leases, and revoking expired leases:

Router1#debug ip dhcp server events
Sep 15 00:58:17.218: DHCPD: returned 172.25.1.51 to address pool COOKBOOK
Sep 15 00:58:22.566: DHCPD: assigned IP address 172.25.1.51 to client 0100.0103.85e9.
87.
Sep 15 01:01:15.056: DHCPD: writing bindings to ftp://dhcp:[email protected]/dhcp-
leases-rtr1.
Sep 15 01:01:15.132: DHCPD: writing address 172.25.1.51.
Sep 15 01:01:15.148: DHCPD: wrote automatic bindings to ftp://dhcp:[email protected].
1/dhcp-leases-rtr1.
Sep 15 01:01:58.816: DHCPD: checking for expired leases.
Sep 15 01:03:58.841: DHCPD: checking for expired leases.
Sep 15 01:05:58.859: DHCPD: checking for expired leases.
Sep 15 01:07:58.874: DHCPD: checking for expired leases.
Sep 15 01:09:58.885: DHCPD: checking for expired leases.
Sep 15 01:09:58.885: DHCPD: the lease for address 172.25.1.51 has expired.
Sep 15 01:09:58.885: DHCPD: returned 172.25.1.51 to address pool COOKBOOK.

The next debug capture shows a typical DHCP client transaction between the client and router. The net result is that the router assigns IP address 172.25.1.51 to MAC address 0001.0385.e987:

Router1#debug ip dhcp server packet
Sep 15 01:19:41.211: DHCPD: DHCPDISCOVER received from client 0100.0103.85e9.87 on
interface FastEthernet0/0.1.
Sep 15 01:19:43.212: DHCPD: Sending DHCPOFFER to client 0100.0103.85e9.87 (172.25.1.
51).
Sep 15 01:19:43.212: DHCPD: creating ARP entry (172.25.1.51, 0001.0385.e987).
Sep 15 01:19:43.212: DHCPD: unicasting BOOTREPLY to client 0001.0385.e987 (172.25.1.
51).
Sep 15 01:19:43.216: DHCPD: DHCPREQUEST received from client 0100.0103.85e9.87.
Sep 15 01:19:43.216: DHCPD: Sending DHCPACK to client 0100.0103.85e9.87 (172.25.1.
51).
Sep 15 01:19:43.216: DHCPD: creating ARP entry (172.25.1.51, 0001.0385.e987).
Sep 15 01:19:43.216: DHCPD: unicasting BOOTREPLY to client 0001.0385.e987 (172.25.1.
51).
Router1#