Wireless Access

Hi,

We recently migrated our DHCP Server and we're running into issues with a handful of APs reporting, "Drop hello message from <Conflicting IP> with a different MAC, old MAC <AP MAC>, new MAC <another AP MAC>"  assumingly these appear to be IP Address conflicts.  Coorespondings APs appear to be bootstrapping. 

We're running AOS 6.4.4.16 with a dedicated 7210 master + backup master and 7240 locals paired in VRRP active-active configs.  

We're looking into a proceedural way to address these.

My question is...  When issuing the CLI command "apboot ap-name <AP NAME>" or "apboot wired-mac <AP MAC>" or "apboot ip-addr <AP IP>" how does the controller initiate the sending of the apboot command?  Does it perform a lookup on it's GAP-DB for a cooresponding IP?  

Any additional suggestions to addresses these would be appreciated. 

TIA, 

I think too, that it will into the database

some useful commands:

Display APs known by the controller: show ap database long

Clear old APs from the controller’s database: clear gab-db ap-name

The controller would only attempt  to reboot access points that are UP.  If they are down or have an "I" flag, the controller really cannot control them and you will have to find them and ensure that they do not have duplicate ip addresses.  Ensuring that you are using a DHCP server should help you out of that issue.  If you are using static ip addresses for your access points, I will send you thoughts and prayers.. ;)

Was told from TAC, "...when a device gets a DHCP IP address, it should sent out a gratuitous arp to confirm there is no IP conflict on the Network, we need to verify that on the AP uplink."

"...when we issue the command with apboot along with NAME or IP or MAC, it should trigger the boot based on the NAME on the AP database list. However, in our setup if we do with IP, it should trigger reboot for both the APs which posses the same IP. Please verify it if possible..."

Somehow, I find that (reboot for both) hard to believe.  I did note that some of the APs with duplicates showed up in the AP Database with an I flag - (inactive = APs with no active BSSIDs or wired AP interfaces).

We ended up downing the AP VLAN interface and disabling the DHCP scope.  We though we had waited long enough (15min) for the APs to reboot, then brough up the VLAN; however, many of them still appeared in the GAP-DB with a long enough uptime to suggest that they hadn't rebooted. 

At this point the DHCP scope was still disabled, so once all APs registered as up (I believe we still had a few IP conflicts), I issued an 'apboot all' command which seemed to do the trick.  We waited for a bit longer to make sure they didn't come back with the same IP and finally re-enabled the DHCP scope (verified by seeing a slew of DHCP Request / Offer messages in DHCP logs).  

That was a simple enough process that seemed to have done the trick.

Thanks all,

When you get into an ip address conflict situation, the results are unpredictable and should be avoided at all costs.  Thereis no ip address conflict detection/mitigation on the access point side.  If an access point cannot obtain or maintain a connection with a controller, it will attempt to reboot by itself.  How long would it have to be in a duplicate ip address situation before it reboots?  It is unpredictable and should just be avoided, period.