Wireless Access

I've received a few reports of problems from a building that recently got brought up, and it's possible that there might be some packet loss on the building uplink between the APs and controllers. Is there any easy way to verify whether or not this is the case?

HI,

 

We cannot pinpoint the issue but by looking at AP uptime and BSS uptime we can understand whether AP-Controller communication is stable or not.

As a good practice, disable STP on the controller, it will fix most of the issues.

 

Please feel free for any further help on this.

---

@fsweetser wrote:
I've received a few reports of problems from a building that recently got brought up, and it's possible that there might be some packet loss on the building uplink between the APs and controllers. Is there any easy way to verify whether or not this is the case?

---

fsweeter,

 

"show ap debug counters" will tell you if your access points are bootstrapping due to packet loss.  You can also type "show log system 100" and see if any access points have bootstrap events.

Thanks all, that at least gives me a place to start looking.

Please note that the bootstrap threshold for access points is 8 seconds, so if you have an outage that does not last as long as that, the access point will not register a bootstrap and there will be no message.  You can dig deeper by looking at the APs received and sent heartbeats:

 

show ap debug system-status ap-name <name of ap> | begin Heartbeat:

 

Heartbeat Stats of Serving Controller
-------------------------------------
Heartbeats Sent  Sent Seqnum  Heartbeats Received  Rcvd Seqnum  MTUs sent  Misc sent  Measurement Duration
---------------  -----------  -------------------  -----------  ---------  ---------  --------------------
232150           53882        232150               53882        1969       0          since last rebootstrap
246316           n/a          246039               n/a          2095       0          total since bootup

In a perfectly functioning network the heartbeats sent should match the heartbeats received.  These stats are for the time that the access point has been up.  Realistically, there is maintenence and other things that would cause a heartbeat here and there to drop.  If you have hundreds of drops, you have problem between the controller and the AP.  In that case, you could look deeper:

 

show ap debug system-status ap-name <name of ap> | begin Reboot:

 

Reboot Information
------------------
AP rebooted Tue Aug 25 11:07:40 CDT 2015; SAPD: Reboot after successful image upgrade
-------------------------------------------------------------------------------------

Rebootstrap Information
-----------------------
Date       Time     Reason (Latest 10)
--------------------------------------
1969-12-31 16:01:09 New connection, Changing to LMS (192.168.1.3) [cur_lms_index: 0, event: REDUN_EVENT_TUNNEL_UP, cur_state: REDUN_STATE_TUNNEL_MASTER, function: redun_tunnel_up(5301)]
2015-08-25 11:11:25 Switching to LMS 192.168.1.3: Missed heartbeats: Last Sequence Generated=128 Sent=128 Rcvd=120. Last Ctrl message: STATUS_REPORT len=49 dest=192.168.1.3 tries=1 seq=5
2015-08-25 11:11:59 New connection, Changing to LMS (192.168.1.3) [cur_lms_index: 0, event: REDUN_EVENT_TUNNEL_UP, cur_state: REDUN_STATE_TUNNEL_LMS, function: redun_tunnel_up(5301)]
2015-08-25 13:15:48 Switching to LMS 192.168.1.3: Missed heartbeats: Last Sequence Generated=7576 Sent=7576 Rcvd=7568. Last Ctrl message: KEEPALIVE len=45 dest=192.168.1.3 tries=1 seq=16
2015-08-25 13:16:22 New connection, Changing to LMS (192.168.1.3) [cur_lms_index: 0, event: REDUN_EVENT_TUNNEL_UP, cur_state: REDUN_STATE_TUNNEL_LMS, function: redun_tunnel_up(5301)]
2015-08-25 14:56:11 Switching to LMS 192.168.1.3: Missed heartbeats: Last Sequence Generated=13586 Sent=13586 Rcvd=13578. Last Ctrl message: KEEPALIVE len=45 dest=192.168.1.3 tries=1 seq=12
2015-08-25 14:56:56 New connection, Changing to LMS (192.168.1.3) [cur_lms_index: 0, event: REDUN_EVENT_TUNNEL_UP, cur_state: REDUN_STATE_TUNNEL_LMS, function: redun_tunnel_up(5301)]
2015-08-25 15:08:55 Switching to LMS 192.168.1.3: Missed heartbeats: Last Sequence Generated=14349 Sent=14349 Rcvd=14340. Last Ctrl message: KEEPALIVE len=45 dest=192.168.1.3 tries=1 seq=3
2015-08-25 15:09:40 New connection, Changing to LMS (192.168.1.3) [cur_lms_index: 0, event: REDUN_EVENT_TUNNEL_UP, cur_state: REDUN_STATE_TUNNEL_LMS, function: redun_tunnel_up(5301)]


HA Failover Information
-----------------------
Date       Time     Reason (Latest 10)
--------------------------------------
(none found)


Recent Control Messages from AP to Controller
---------------------------------------------
Date       Time               Message Description
-------------------------------------------------
Fri Aug 28 08:49:46 2015(125 secs ago): SENT REQ type=KEEPALIVE len=45 peer=192.168.1.3 seq_num=398 num_attempts=1 rtt=0 secs 0400000028040000000205C0A8015A0455DCCB58040000018E0455E066FA05FFFFFF0005C0A801FE0000000000
Fri Aug 28 08:39:46 2015(725 secs ago): SENT REQ type=KEEPALIVE len=45 peer=192.168.1.3 seq_num=397 num_attempts=1 rtt=0 secs 0400000028040000000205C0A8015A0455DCCB58040000018D0455E064A205FFFFFF0005C0A801FE0000000000
Fri Aug 28 08:29:46 2015(1325 secs ago): SENT REQ type=KEEPALIVE len=45 peer=192.168.1.3 seq_num=396 num_attempts=1 rtt=0 secs 0400000028040000000205C0A8015A0455DCCB58040000018C0455E0624A05FFFFFF0005C0A801FE0000000000


Rebootstrap LMS
---------------
2015-08-25 15:09:40 New connection, Changing to LMS (192.168.1.3) [cur_lms_index: 0, event: REDUN_EVENT_TUNNEL_UP, cur_state: REDUN_STATE_TUNNEL_LMS, function: redun_tunnel_up(5301)]
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A date of 1969 means it did not contact a controller to get its time yet.  Maybe that will give you more info.