topic log messages in enterasys controller C5210 for AP3605 in ExtremeWireless (Identifi)

log messages in enterasys controller C5210 for AP3605

Laura4 — Thu, 14 May 2015 21:35:00 GMT

Does anyone know what this log message means? It's Enterasys C5210 with 3605 Enterasys APs. I am not sure why one of our APs went down. I don't understand what the Log Message means.

RE: log messages in enterasys controller C5210 for AP3605

Raffi — Thu, 14 May 2015 21:42:00 GMT

The ap has lost connection to it's primary controller. The poll timeout in this case is 30 seconds.

It will now either move to it's secondary controller ( if failover is configured ), or will enter discovery state again looking for a controller to connect to if there is no backup.

If the ap failed over to a backup, you would have to go to the backup, wireless aps->access approval->select the ap->click release to let it go back to the home controller.

If there was no backup, then the ap will connect back to the primary when it is available.

If the problem continues to happen, you can investigate why the ap lost connection, or you can try to increase the poll timeout value found in wireless aps->ap name->advanced button.

RE: log messages in enterasys controller C5210 for AP3605

Laura4 — Thu, 14 May 2015 21:42:00 GMT

we do have failover setup, but it didn't go to the backup controller,, it just eventually came back up.

RE: log messages in enterasys controller C5210 for AP3605

Raffi — Thu, 14 May 2015 21:45:00 GMT

Also you can check this GTAC knowledgebase article:

IdentiFi Access Points reboot due to Poll Timeout

http://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Access-Points-reboot-due-to-Poll...

RE: log messages in enterasys controller C5210 for AP3605

Raffi — Thu, 14 May 2015 22:27:00 GMT

If you ssh to the ap, you could verify it has the backup controller ip, and you could verify you can ping the backup controller from the ap.

# cget config | grep -i failover
failover bmIp [1] 192.168.2.44
failover bmIp [2] 192.168.2.45
#
# ping 192.168.2.45
PING 192.168.2.45 (192.168.2.45): 56 data bytes
64 bytes from 192.168.2.45: seq=0 ttl=63 time=1.2 ms
64 bytes from 192.168.2.45: seq=1 ttl=63 time=0.9 ms

--- 192.168.2.45 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.9/1.0/1.2 ms
#

Also make sure the data port on the failover secondary controller has the "Ap Registration" checkbox checked under vns-toplogy->data port ( otherwise aps would not be able to connect )

If everything checks out, then either the ap either had a real network issue preventing it from reaching both primary and secondary controllers, and perhaps more, or it had an internal issue preventing causing a network connectivity issue until it timed out and rebooted.

If you suspect internal issue, you can open a ticket with GTAC to investigate further.