Hello, I am REALLY sorry for the lengthy post. I would appreciate a sanity check, and to see if anyone else has experience with this issue.
We have multiple Cisco 5508 WLCs running 7.4.121.0. Whilest troubleshooting another issue, I noticed an error message similar to the following: #DTL-3-ARP_CLIENT_IP_DUPLICATED: dtl_arp.c:1847 ARP entry overwrite, conflict detected via ARP Request from client with MAC-ID <ClientA-MAC> and IP Address <IPv4AddrCurrLeasedByClientB>, Old client MAC-ID was <ClientB-MAC> The message is self-explanatory, but it I don't understand why it's occurring. Here is the scenario (the length of times described are arbitrary and made up): 1) ClientA associates to some SSID and receives a lease for 10.0.0.1 2) ClientA goes idle, disassociates, or otherwise stops communicating and doesn’t renew the DHCP lease at half-life; thus, the lease expires and is freed on the DHCP server 3) A few hours later, ClientB associates to the same SSID that ClientA was on, and receives the lease for 10.0.0.1 4) ClientB is active for a lengthy amount of time (8+ hours), sending RENEWs to keep up its lease. Meanwhile… 5) ClientA reassociates to the SSID while ClientB is still associated, ClientA sends a DHCPDISCOVER, and the WLC logs the ARP_CLIENT_IP_DUPLICATED error msg is logged in the WLC. The DHCP logs do not show ClientA trying to use the same lease it had before, but the WLC somehow remembered ClientA had that address on its previous association. Our setup: Infoblox for DHCP (ISC DHCP) - We have two DHCP servers performing load-balancing (not using a virtual IP) Multiple Cisco 5508 WLCs running 7.4.121.0 - We use DHCP Proxy - We use DHCP Addr. Required - Client Exclusion for IP Theft/Reuse is enabled - All APs are in local mode - Global User Idle Timeout = 300 seconds (default) - Global ARP Timeout = 300 seconds (default) - WLANs have session timeout disabled - WLANs have User Idle Timeout = 300 seconds (default) - Open Auth SSIDs (for now; about to push out WPA2 802.1x) It seems like the client record in the association table is not being purged. Based on my understanding, ClientA should not even be in the associated clients table, if the client device really did go idle and disassociated itself from the network. I have tried disabling DHCP Addr. Required, and DHCP Proxy, but it only made matters worse. In fact, with Client Exclusions enabled a lot of clients were being excluded. I have also disabled one of the DHCP servers to rule out load-balancing getting in the way. Regardless, the DHCP logs don't show any abnormal behavior. I have an SR open with TAC, and the dev team is involved. Is anyone else seeing this issue? If so, what version of code are you running? Sorry for the length, Greg --- Greg Koprowski UWEC LTS Networking E: [email protected] ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
