Cisco WLC Software Does Not Process Gratuitous ARPs
Hi everyone, I thought I would post this issue with the Wireless LAN Controller software to the support forums in case anyone else runs into this limitation with Cisco’s WLC software as I have not found any other postings regarding this.
We were performing a migration of large Nortel WLC AP installation to a Cisco WLC/WiSM with Cisco AP’s. Since it was a large medical facility with high availability requirements, we obviously needed to have both systems operating simultaneously during the weeks it would take to install new relocated AP’s and complete migrate to the Cisco WLC. Unfortunately, we found that when clients roamed off of the Cisco WLC to the Nortel controller, the clients on the Cisco controller could no longer communicate with those clients on the Nortel controller for several minutes, or until we manually removed the client from the Cisco WLC. We also reproduced this same fault with clients roaming off of the Cisco WLC to simple stand alone Cisco access points.
We determined that if we lowered the client timeout on the Cisco WLC to the minimum of 10 seconds, the clients on the Cisco WLC would be able to communicate with the clients that roamed off of the WLC soon after the 10 second timer expired and the client was automatically removed from the WLC. Unfortunately, this is not a workaround for voice applications that typical medical facilities use such as Vocera badges.
What we eventually found out is that the Cisco WLC does not process gratuitous arps from the LAN, such that if a client moves off of the WLC to either the LAN (or another AP on the LAN), it will run into and issue with communicating with clients on the WLC until it times out. In any typical wireless environment, when a client roams to an AP, a gratuitous arp is sent out to repopulate the MAC address tables of devices on the LAN / any other AP’s to let those devices know where that MAC address is now located. I’m not sure why Cisco decided not even to include processing of gratuitous arps as an option in their WLC software, but I could see this as a problem that other people might run into in mixed environments, or even in advanced environments with medical devices that are connected with wireless dongles and are switched from the wireless network to the wired network on the same subnet. The Cisco BU looked into this for us, and just came back with saying they weren’t’ going to support gratuitous arps, and some baloney about security and other things that made no sense at all. If you’re depending on your wireless infrastructure not accepting gratuitous arps (to possibly prevent the next to almost never circumstance of a rogue clients spoofing a wireless client's MAC address on the same subnet, but wired network) for your security model, you’ve got much bigger issues!!
One other user I found complaining about the WLC not forwarding GARPS is here:
If this post is helpful and/or you think Cisco should fix correct WLC software so that you have the option for it to process gratuitous arps, please post a reply. Thanks!
Basically, the client is not handed off at layer1!!
How does reassociation handled?
How does the new AP/infrastrcture get the keys?
Are the roamed to infrastructure is authenticated?, it could be an Rogue AP?
The above should work seemlessly, if not it'll be failover roaming, that's what happening in this case, and the new infrastrcuture should send garp(as soon as it associated as fresh client) which is sent in this case, the wlc doesn't recognize it because it still thinks the client is still associated with him(no Mobility Announce or handoff happened for that client from wlc perspective). So the client mscb table and arp remain until user idle and arp timesout.
(The issue you're facing is not an garp issue, its WLC dropping the packet sourced from wired side for same MAC address like its associated wireless client. It could be some attacker trying to use similar wireless client MAC address on the wired side to poison the switch arp table. Now the WLC arp table will see the same client on both wired and wireless side interface causes mac flapping.)
Let's say you've X wireless clients, DoS attack - can spoof all of their MACs and if we start sending garp on round robin fashion using that MACs on that wired vlan to update the switch and wlc arp table then none of the clients can reliably send traffic.
the clients on the Cisco controller could no longer communicate with those clients on the Nortel controller for several minutes.
//Because handoff didn't happened to Nortel and that part is not Cisco supported. Cisco doesn't support roaming or handoff to 3rd party or its own IOS mode AP.
if a client moves off of the WLC to either the LAN (or another AP on the LAN), it will run into and issue with communicating with clients on the WLC until it times out.
//Yes, WLC doesn't honour deauths from client either unicast or broadcast. So disconnecting from client won't help here. And the client will stay with WLC until the user idle timer and arp expires for that client. So wireless client moved off WLC will be considered as wired client and cannot receive packet from same client/MAC from wired infrastructure because there is 'no state' maintained between WLC and the wired infrastructure to coordinate this action i.e, handoff/Mobility learning.
*Challenge to open eoip tunnel between 3rd party wlc or its own cisco AP using iapp. Don't think nortel will share their controller code to cisco even if it has to happen
*On roaming, same issue could happen if you're running two cisco wlc with no mobility enabled between them using same switch.
In any typical wireless environment, when a client roams to an AP, a gratuitous arp is sent out to repopulate the MAC address tables of devices on the LAN / any other AP’s to let those devices know where that MAC address is now located. I’m not sure why Cisco decided not even to include processing of gratuitous arps as an option in their WLC software, but I could see this as a problem that other people might run into in mixed environments,
//On L2 roaming btw wlc - The wireless client roamed from WLC will move(remove the client entry on foreign) the client info to roamed(anchor) to WLC, So the future client traffic will forwarded from the new WLC's(anchor) upstream switch, anchor wlc will garp to update the infrastructure.
//On L3 roaming btw wlc - The roamed from WLC(client entry stays) will still forward the client traffic via eoip tunnel and the L2 path didn't change.
Bottomline: Due to Mobility handoff didn't happen for that client, the WLC will ignore the garp for that client is what i'm thinking.
the clients on the Cisco controller could no longer communicate with those clients on the Nortel controller for several minutes,
//you could try these but unsure that its gonna work:
Don't connect the wlc and nortel to same switch. So that nortel connect switch will've updated entry.
Lower the arp timeout on intermediate switches.
Do layer3 roaming instead of layer2 between nortel and cisco wlc. this way arp will not have effect on that l2 vlan.
Turn off the overlapped APs and make sure failover roaming happens smoothly.