Symptom

DHCP relay is updating the ARP table with an incorrect MAC entry during rebind. After T1 = Renewal timer (set by default to 50% of the length of the lease) fires, RENEW process will be started. Once T1 expires, client sends Renewal message to the server (UNICAST because client and server know each other). If DHCP does not send a response or the client does not receive it, Rebinding timer (T2) is triggered. Client will send the "Rebind packet" / DHCPREQUEST, which is always broadcast as the client expects the response from any server. == > issue: During the rebind process, DHCP Relay is checking for existing ARP entries to send server responses to the particular client. As the client-identifier in the DHCP message differs from the MAC address in existing ARP entry, DHCP Relay is treating it as mismatch and updates the ARP table with the wrong MAC address (in our case, the one which belongs to SVI in shutdown state). Client (SVI in up state in our case) never receives a BOOTREPLY and therefore never extends its existing lease; ultimately the client loses an IP address.

Conditions

- DHCP relay is running 16.3.x - DHCP client uses a different client ID than the mac address of the management vlan

Workaround

Further Problem Description

- In the lab this is not seen on 3.7.x IOS-XE nor on legacy IOS images - This happens regardless of the IOS image of the DHCP client - The ARP issue is always reproducible on 16.3.x