Every time someone throws me an IPv6 curveball, I’m surprised when I discover another huge can of worms (I guess I should have learned by now). This time it started pretty innocently with a seemingly simple PPPoE question:
What happens if an ISP decides to assign dynamic IPv6 subnets? With static assignment, the whole stuff is pretty straight-forward due to ND, RA & DHCPv6, but if dynamic addresses are used, what happens if the subnet changes - how will the change be propagated to the end-user devices? The whole thing is no problem today due to the usage of NAT / PAT...
LAN address allocation with changing DHCPv6 prefix is definitely a major problem, but didn’t seem insurmountable. After all, you can tweak RA timers on the LAN interface, so even though the prefix delegated through DHCPv6 would change, the LAN clients would pick up the change pretty quickly. WRONG ... at least if you use Cisco IOS.
It’s amazing what people would try to patent ... and it’s even more amazing what gets past the examiners. IBM has managed to patent passing ipv6 or dhcp argument to indicate an IP host should network-boot over IPv6 or using DHCP. The idea is so trivial it’s almost not worth mentioning and goes along the lines of: “usually we use BOOTP and TFTP to get network boot parameters, but imagine we could pass DHCP as the argument to the boot routine and then it would use DHCP instead of BOOTP”.
The patent supposedly covers a very specific case, but (to my untrained eye) the claims are written in a way that could cover almost any IPv6- or DHCP-assisted network boot (or at least give lawyers plenty of stuff to charge for) ... exactly what we needed with all the other roadblocks and stumbling stones to IPv6 deployment.
Hat tip to John Curran for bringing this one to my attention.
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)?
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 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:
I have a hp2300n and I want to make a static IP assignment with DHCP. Nothing is working: hardware-address, client-identifier, no prepend, 01 prepend, 00 prepend.
In my case, the Fedora DHCP client did not send any DHCP client-ID in the DHCPREQUEST message. One would think that the IOS DHCP server would use the MAC address as the client-ID, but that's not the case. You have to configure the hardware-address parameter in the host DHCP pool to match the MAC address of the DHCP client with the pool and the static IP address:
ip dhcp pool fedi
host 192.168.200.206 255.255.255.240
dns-server 220.127.116.11 18.104.22.168
- The router and the cable modem are power-cycled.
- The router starts to bridge between all LAN interfaces, effectively connecting inside workstations directly to the cable modem.
- 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).
- 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.
- The workstation is assigned a public IP address (at this time, the workstation is connected directly to Internet and thus vulnerable).
- The router loads Cisco IOS and reinitializes the Ethernet interfaces. Bridging between internal and external interfaces is stopped.
- 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.
This behavior can be observed only if the router and the cable modem are reset at the same time and the cable provider doesn't care much about MAC security and allows the modem to learn the MAC address. If you reset only the cable modem, the router is not bridging (no problem); if you reset just the router, the cable modem still caches the router's MAC address and ignores the DHCP request from the inside workstation(s).
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.
- I've added a Linux box to my home network;
- It used my Cisco router to get a dynamic DHCP address;
- I've inspected the DHCP bindings on the Cisco router to find the new MAC address and configured a host DHCP pool as I'm using the Linux box as a server;
- Even after multiple configuration changes, the IOS would fail to use the host DHCP pool.
The only solution I've found was to restart the IOS DHCP server with the no service dhcp followed by service dhcp configuration commands. Obviously, you lose all DHCP bindings when you restart the DHCP server (which could be a problem if you use conflict logging) unless you've configured the router to store them in an external file.
In a response to my post Redundant DHCP Server I've speculated that a Cisco router should coexist with a Windows-based DHCP server if you configure them with non-overlapping address ranges. I was wrong, Edgar Cahuana discovered that Microsoft's DHCP server wants to have complete control over the LAN it's serving and shuts down if it detects another DHCP server on the same LAN.
The difference between rogue server detection in Windows 2000/2003 and SBS 2003 is explained in this TechNet chat.
Using DHCP to assign server IP addresses is usually not a wise decision. To start with, you have to define static DHCP mappings, which rely on client-id attribute in the DHCP request (usually the MAC address of the client). For me, the easiest way to find the correct client ID is as follows:
- Use DHCP to assign the IP address to the server
- Note the newly assigned IP address
- Use the show ip dhcp bindings | include ip-address command to display the client-id to IP address binding.
- Create a static DHCP mapping (for example, by configuring a host DHCP pool on the router) and release/renew IP address on the server