IP client-tracker causes large numbers of BAD_ADDRESS on DHCP server
When Windows client requests for an IP address, It performs a duplicate IP address detection procedure after a successful DHCP IP address assignment -also know as DAD (Duplicate Address Detection) process .
While performing DAD process, Client after receiving a successful DHCP lease, sends an ARP probe packet with assigned IP address. If a reply is received for this ARP packet, the client will treat the assigned DHCP address as duplicate address.
But when Client tracker is enabled, the switch sends an ARP probe (as part of the ip client tracker learn process) for all the learned IP addresses.
In the case of Windows clients, the client tracker's behavior can interfere with the client's DAD (Duplicate Address Detection) process,
The client sees this ARP from the switch as a conflict and sends DHCP decline, which results in BAD_Address in the DHCP server.
To overcome the above scenario, we have to make sure that ARP probe from the client tracker and DAD (Duplicate Address Detection) process are not sent at the same time.
The ARP probe sent by the client tracker can be delayed using the "IP client-tracker probe delay" option.
Most Windows clients send ARP probes within 10 secs and some VMs take longer. Its recommended to configure probe delay of 120 secs.
# ip client-tracker probe-delay 120
(By default it is 15 secs on Aruba switches)
This conflict happens only on L2 VLANs. n case the VLAN has an IP address assigned on it, then the packets sent from the switch will have the source IP filled and the client will not see this as a conflict.