AP3965i Poll Timeout problem with controller (since creating availability pair)

[Steve_Ballantyn]

I created a high availability pair last week. All went well - except for ONE access point. It's the only outdoor AP in my fleet, model AP3965i. As soon as the pair was established, it started going up and down all day long.

I tried doing a cset factory, and reboot. But it went right back into it's disconnecting behavior.

The poll settings are not any different than my other AP's (15 seconds). And the connectivity to the controller seems fine. Is this possibly a bug with this model? All of my other AP's are 3825i, and they are just fine.

My controller is running version 10.31.01.0048.

Here is a /tmp/log/ap.log snippet ...

May 9 14:34:15 cap: 01093:ru_register.c:405-ru_backup_tunnel_register()-Bkup AC 10.10.72.11 KEY=56ab397406670224085e00217b5f23aa

May 9 14:34:23 cap: 01093:ru_mgmt_fastfailover.c:357-ru_mgmt_backup_tunnel_state_trans()-ru_mgmt_backup_tunnel_state_trans: Clear backup WASSP reassembly buf

May 9 14:34:23 cap: 01093:ru_register.c:405-ru_backup_tunnel_register()-Bkup AC 10.10.72.11 KEY=56ab397406670224085e00217b5f23aa

May 9 14:34:29 cap: 01093:ru_mgmt_fastfailover.c:357-ru_mgmt_backup_tunnel_state_trans()-ru_mgmt_backup_tunnel_state_trans: Clear backup WASSP reassembly buf

May 9 14:34:29 cap: 01093:ru_register.c:405-ru_backup_tunnel_register()-Bkup AC 10.10.72.11 KEY=56ab397406670224085e00217b5f23aa

May 9 14:34:31 krn: ieee80211_scanentry.c:1959-ieee80211_scan_entry_update_mesh()-Channel 2412 Warning NF=12 is out of range

May 9 14:34:35 cap: 01093:ru_mgmt_fastfailover.c:357-ru_mgmt_backup_tunnel_state_trans()-ru_mgmt_backup_tunnel_state_trans: Clear backup WASSP reassembly buf

May 9 14:34:35 cap: 01093:ru_register.c:405-ru_backup_tunnel_register()-Bkup AC 10.10.72.11 KEY=56ab397406670224085e00217b5f23aa

May 9 14:34:36 cap: *** ru_AcAvail_task: Poll timeout approaching, Pinging potential controllers ***

May 9 14:34:40 cap: *** ru_AcAvail_task: Poll timeout approaching, Pinging potential controllers ***

May 9 14:34:42 cap: 01093:ru_mgmt_fastfailover.c:357-ru_mgmt_backup_tunnel_state_trans()-ru_mgmt_backup_tunnel_state_trans: Clear backup WASSP reassembly buf

May 9 14:34:42 cap: 01093:ru_register.c:405-ru_backup_tunnel_register()-Bkup AC 10.10.72.11 KEY=56ab397406670224085e00217b5f23aa

May 9 14:34:42 krn: updateMtuForFlowMgr: 6 callbacks suppressed

May 9 14:34:42 krn: tunnelDrv_ioctl:1163 updateMtuForFlowMgr, wassp_sessionID:0.

May 9 14:34:42 krn: netflow_mtu_update ip:a0a480a mtu:1450 src:0.

May 9 14:34:42 krn: netflow_mtu_update set mtu:1450.

May 9 14:34:42 krn: netflow_mtu_update: number_netflow_report_per_packet:12.

May 9 14:34:42 krn: netflow_mtu_update ip:a0a480a mtu:1450 src:0.

May 9 14:34:42 krn: netflow_mtu_update set mtu:1450.

May 9 14:34:42 krn: netflow_mtu_update: number_netflow_report_per_packet:12.

May 9 14:34:42 cap: 01093:ru_mgmt.c:1067-ap_mgmt_main_loop()-Poll Timeout -

May 9 14:34:42 cap: 01093:ru_mgmt.c:1088-ap_mgmt_main_loop()-ap_mgmt_main_loop: Clear active WASSP reassembly buf

May 9 14:34:42 cap: 01093:ru_mgmt.c:1091-ap_mgmt_main_loop()-ap_mgmt_main_loop: NEED_FAILOVER 1 isBackupTunnelActivating 0 restartDisc 0

May 9 14:34:42 cap: 01093:ru_misc.c:854-reset_wassp_tunnelDrv()-reset_wassp_tunnelDrv: Resetting WASSP session

May 9 14:34:42 cap: 01093:ru_discov.c:277-ru_discov_timeout_reqs_reboot()-site 1, modePersist 1, linkPersist 1, role 0, tunnel 1, bridge 0

May 9 14:34:42 cap: 01093:ru_mgmt.c:1126-ap_mgmt_main_loop()-Site is enabled. Skipped disconnect of MUs.

May 9 14:34:42 cap: 01093:ru_mgmt.c:1129-ap_mgmt_main_loop()-ap_mgmt_main_loop: Restart discovery 1

May 9 14:34:42 cap: m3MsgToDiscov: in_opcode 304, in_dstid 0, in_srcid 0

May 9 14:34:42 cap: 01093:ru_mgmt.c:2776-whsl_trans()-whsl_trans: S_EUP->S_EDISC

May 9 14:34:42 cap: resetRuSession2 - Resetting ru mgmt session

[Steve_Ballantyn]

This was easily pinpointed and resolved by support. It turns out that this AP was on the wrong VLAN. Woops! It was likely finding the controller using the DNS entry for "Controller" but then was failing everything else. I'm not sure how it was working before the availability pair was created.

Putting it on the right VLAN corrected the issue instantly.

[Doug]

Steve,

Can you contact support so we can review the complete ap log?

Thanks,

Doug

[Steve_Ballantyn]

Sure thing Doug. I will open a case and attach the traces.