log messages in enterasys controller C5210 for AP3605
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎05-14-2015 02:35 PM
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.
4 REPLIES 4
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎05-14-2015 03:27 PM
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.
# 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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎05-14-2015 02:45 PM
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...
IdentiFi Access Points reboot due to Poll Timeout
http://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Access-Points-reboot-due-to-Poll...
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎05-14-2015 02:42 PM
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.
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎05-14-2015 02:42 PM
we do have failover setup, but it didn't go to the backup controller,, it just eventually came back up.
