cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

Steve_Ballantyn
Contributor
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
3 REPLIES 3

Steve_Ballantyn
Contributor
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
Extreme Employee
Steve,

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

Thanks,

Doug

Doug Hyde
Director, Technical Support / Extreme Networks

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