ISR 4331 DHCP woes

[EnricoSavazzi]

I have an ISR 4331 with NIM-ES2-4 module in slot 0/2. I am attaching the output of show running-config.

The 4331 WAN is 192.168.1.0/24, connected to g0/0/0 configured as nat outside, and this interface receives its IP configuration from 192.168.1.1 via DHCP.

The 4331 interfaces g0/0/1 (network 10.10.1.0/24), g0/0/2 (network 10.10.2.0/24) and vlan1 (network 10.10.10.0/24) are configured as nat inside and assign IP configurations to their clients via DHCP pools configured on the router. In particular, these are the DHCP pools for the BORG computer (a Windows 10 workstation):

ip dhcp pool BORGvlan1
host 10.10.10.100 255.255.255.0 
client-identifier 01f0.2f74.16ad.0a
default-router 10.10.10.1
dns-server 8.8.8.8 8.8.4.4 192.168.1.1 10.10.10.1
!
ip dhcp pool BORGg0-0-1
host 10.10.1.100 255.255.255.0 
client-identifier 01f0.2f74.16ad.0a
default-router 10.10.1.1
dns-server 8.8.8.8 8.8.4.4 192.168.1.1 10.10.10.1
!
ip dhcp pool BORGg0-0-2
host 10.10.2.100 255.255.255.0 
client-identifier 01f0.2f74.16ad.0a
default-router 10.10.2.1
dns-server 8.8.8.8 8.8.4.4 192.168.1.1 10.10.10.1

The idea is that BORG will receive a different IP address, based on which network it is physically plugged into. I connect BORG to an L2 port of the NIM, it is assigned IP address 10.10.10.100 as intended, and all is fine (I should note that client-identifier works better for me than hardware-address, which may work until suddenly it stops working for no obvious reason and stays broken no matter what I do).

If I unplug BORG from the NIM, plug it into g0/0/1, and renew the DHCP lease on BORG, its address becomes 10.10.1.100, also as expected. However, if I plug BORG back into the NIM and renew the DHCP lease on BORG, the operation fails with error message: "An error occurred while renewing interface Ethernet 2 : The name specified in the network control block (NCB) is in use on a remote adapter. The NCB is the data." BORG now has the autoconfig IP 169.254.197.105.

I manually assign a static IP (e.g. 10.10.10.100, or 10.10.10.2) to BORG, and get the Internet connection working again. I switch back BORG to DHCP client, and the error still occurs.

The behaviour is the same if I switch BORG between the NIM and g0/0/2 (which is an SFP port) via a known-good Ethernet or fiber SFP transducer.

Eventually, after tens of minutes or after reloading the router, the error no longer occurs. Until now, I still am not sure whether the problem is with the router or the PC.

Is there a problem-free way (that requires no router re-configuration) to give a Windows host a different DHCP configuration, based on the router network it is physically plugged into?

[EnricoSavazzi]

I am attaching here a small part of the DHCP log which may help. Among other things, I see the entry "DHCPD: client's VPN is Mgmt-intf." of which I have no clue (the management interface has a static address 10.10.10.5 and is plugged in the NIM). Unplugging the MGMT interface from the NIM seems to make things slightly better, but this leaves me with the problem of how to use this interface. Maybe connect it to the WAN?

Among other oddities, I can see also DHCP requests coming into g0/0/0 from hosts on the WAN, which the router denies. I can see why, given that the router has no DHCP pool for the WAN. However, is there a way to block these requests coming from the WAN?

[EnricoSavazzi · Accepted solution]

Answering my own post in the lack of replies. I now believe that the DHCP server in the router is at fault: it remembers that the reserved address has already been assigned and that the lease is still valid, but does not check whether the original client that obtained the lease is still connected, does not compare the client-identifier of the original lease with the one of the new request (which would reveal that they are the same machine), and believes that a second computer is requesting a lease for the same, already in-use reserved address.
My impression is that this behavior is questionable, probably at the borderline of being a bug. After all, DHCP lease renewal by request of the client is normal DHCP behavior. If such a legitimate request is denied by the DHCP server and the client is left without a working IP configuration, something is obviously broken.

My workaround is using a pool of multiple addresses shared by all hosts instead of a single reserved address. As long as the pools are not exhausted, the host can be physically reconnected to any network multiple times and continues to receive a valid IP configuration (albeit a different IP address on every reconnection to a given network). It also means that the IP address of the host is no longer predictable.

As for the unexpected behavior of the MGMT interface, it seems it is not meant to be connected to one of the client networks of the router, and should instead be connected to a management-only network, or at least a management-only VLAN. In my case, I am leaving this interface unused, and accessing the router via SSH through its ordinary interfaces.

[EnricoSavazzi · Accepted solution]

A matter related to the ISR 4331 DHCP problem: I am currently working on an ASA 5525-X with firmware 9.17.1, and on this platform it is not allowed to create a DHCP reservation for the same hardware address on two separate networks (only one global reservation per hardware address is allowed). This is a way to avoid the problem I found on the 4331, although somewhat of an artificial limitation to the DHCPD functionality.

A mitigation of the 4331 DHCP problem can be to set a short duration of the DHCP lease (e.g. 5 minutes), so that the problem clears itself once the current lease expires. On the 4331 the lease duration is set within each DHCP pool with e.g.

lease 0 0 5 

(0 days, 0 hours, 5 minutes). On other platforms (e.g. ASA) it can be a global setting.