Category: DHCP

In a previous post I’ve described how useless DHCP logging is when you try to detect change in DHCP-assigned IP address. Fortunately the removal of the old IP address (triggered by the DHCPNAK server response) and configuration of the new IP address (sent in the DHCPACK response) triggers a change in the IP routing table that can be detected with the IP routing table event detector introduced in EEM 3.0 (available from Cisco IOS release 12.4(22)T).

One of the readers sent me an interesting question: he’d like to know the IP address of his home router (to be able to connect to it from the office), but its IP address is assigned through DHCP and changes occasionally.

I wanted to solve the problem by hooking an EEM applet onto the DHCP-6-ADDRESS_ASSIGN syslog message. No good; as it turns out, Cisco IOS generates the logging message only when a DHCP-acquired IP address is assigned to an interface without one. If the IP address is changed via DHCP, the change is not logged.

You would think that an expired DHCP lease is not a big deal for a DHCP client. Although the interface IP address is lost, you can always try to get a new address from the DHCP server.

IOS has a different opinion: when the DHCP lease expires on a router configured with ip address dhcp interface configuration command, the interface is administratively shut down and re-enabled. Here’s a sample printout taken from a router running 15.6(1)T software:

The reader who was concerned about making a loop while connecting a switch to itself was also facing “customer-installed” DHCP servers in his LAN. He wrote:

Some users have installed their own Linksys routers and plug our cable in router's LAN ports, so there is DHCP servers fight in our LAN. How can I sort this out (I cannot physically find the location of the Linsys routers)?

The ideal solution is DHCP snooping (assuming your switch supports it), well documented on www.cisco.com. The basic configuration takes only a few minutes:

Readers of my blog have probably noticed that I’m occasionally documenting the shortcomings of DNS and DHCP servers built into Cisco IOS (I will not even mention the HTTP server, this one gets constantly degraded). On the other hand, although you could centralize all these services, the centralization makes the branch offices completely dependent on the availability of WAN uplinks; without a working uplink, a branch office stops completely.

Pete sent me an interesting question a while ago:

It might be interesting to write an article about ip dhcp database flash:dhcp-db command, documenting the pros of surviving a reboot versus cons of wear on the flash device.

I’ve already written about a few problems that can be solved with the DHCP database (but obviously a longer text is warranted … already stored in my to-do list) and it took me a while to find the time to dig out the relevant information on the flash device wear.

A while ago I've documented how you can cope with DHCP clients that do not send Client identifier (DHCP option 61) in their DHCP Discover/Request messages, but some people are still trying to persuade me that the client-identifier pool configuration command should work. I really wanted to be sure I hadn't missed something, so I started Wireshark and captured the actual DHCP Discover packet generated by a Linux host:

 

 

A while ago I've installed Fedora Linux on one of my workstations and spent enormous amount of time trying to give it a static IP address from the Cisco IOS DHCP server. I though I was the only one dumb enough to have this problem, so I didn’t document my solution, but then one of the readers made a comment to the Assigning server IP addresses with DHCP post describing almost identical symptoms:

The undesired intermittent bridging behavior of Cisco 871 using old ROMMON software can lead to hard-to-diagnose problems if you're connected to an Internet access network through a cable modem that accepts only a single MAC address. The right sequence of events can leave the router/modem combination in a state with no external connectivity requiring a modem power-cycle:

1. The router and the cable modem are power-cycled.
2. The router starts to bridge between all LAN interfaces, effectively connecting inside workstations directly to the cable modem.
3. One of the workstations could detect a LAN failure (due to router reload) and restart the DHCP process (a Windows XP host would definitely do that).
4. The DHCP requests from the workstation are bridged straight to the cable modem which caches the workstation's MAC address and forwards the DHCP request.
5. The workstation is assigned a public IP address (at this time, the workstation is connected directly to Internet and thus vulnerable).
6. The router loads Cisco IOS and reinitializes the Ethernet interfaces. Bridging between internal and external interfaces is stopped.
7. The router sends DHCP request on the outside interface, but the modem ignores it, as the MAC address of the DHCP request differs from the previously cached one.

In most cases, the cable modem has to be power-cycled to lose the cached MAC address.

Cisco has published a series of documents describing how you can connect a SOHO site to two ISPs.

Their configuration also includes a nice trick: the ip dhcp client route track number command is a convenient replacement for a static default route with the track option if one of the upstream interfaces uses DHCP and the router generates the default route based on DHCP replies.