Hi Guys,
Please, allow me, humbly, to try to help...
Customer's XCC: 05.36.03.0017
LAB's XCC: 05.46.02.0019
I got some issues with XCC and VLANs, specially with Dynamic VLAN using ExtremeControl... Trying to assign dynamically VLANs was a pain to make it work on a customer deployment.
Working on my Lab, I could replicate the issue and discover some points and issues, and finally make it work as expected (somehow...).
Initially, I discovered, after several tests, that when the B@AC mode is selected to VLAN it worked perfectly, but on B@AP or FA it simply doesn't work. After several tests (and events related to the VMWare host, will talk about it later, and it HAD a crucial role on the issue).
Checking the GTAC KB I found some "related" infos... some more useful (3):
1) https://extremeportal.force.com/ExtrArticleDetail?an=000063153&q=XCC%20vlan
I couldn't make it work with NAC (8.5.6.17) as it shows as "unsupported attributes".
2) https://extremeportal.force.com/ExtrArticleDetail?an=000094691&q=XCC%20vlan
This KB haven't helped me on my case, as it was already set.
3) https://extremeportal.force.com/ExtrArticleDetail?an=000059011&q=XCC%20vlan
This KB was VERY USEFUL, as there's a SIMPLE detail, that maybe sometimes pass unoticed: the LOGIN-LAT-PORT = 0 is the secret to make it work on my case!
But making it work on LAB wasn't enough to make it work flawlessly on the customer site... I discovered that when I configured the customer's NAC/XCC the same parameters as my LAB's environment it started to work, BUT other issue arised when the customer requested a new VLAN to be configured (customer uses all VLANs on FabricAttach mode), even configuring exactly as the older VLANs (and according NAC configs).
The odd issue was the VLANs that was already configured on XCC worked as expected, but the NEW VLANs do not worked... After a lot of troubleshooting, including looking at AP logs, that reported an odd DEASSOC message (and following the end-system disconnect and trying to connect again):
Nov 29 14:31:41 krn: ieee80211_mgmt_ap.c:1125/ieee80211_recv_asreq()-ni_flags=a rs_nrates=16Nov 29 14:31:41 krn: ieee80211_node_ap.c:863/ieee80211_node_join()-ath1/6E:BA:1B:D5:83:02 sta=1 ni=e6a17fd0 aid=1 refcnt=2 ncnt=2 rss=-47 mfp=0Nov 29 14:31:41 krn: ol_if_mgmt.c:720/ol_ath_net80211_newassoc()-6E:BA:1B:D5:83:02 ni_flags=1000000a ni_wds_tx_policy=0 isnew=1 ni=e6a17fd0Nov 29 14:31:41 krn: ieee80211_mgmt_ap.c:1359/ieee80211_recv_asreq()-exitNov 29 14:31:41 krn: mu_assoc_tab.c:1206/wassp_mu_assoc_handler()-6E:BA:1B:D5:83:02 Not allowedNov 29 14:31:41 krn: mu_assoc_tab.c:1215/wassp_mu_assoc_handler()-chantry1 6E:BA:1B:D5:83:02 DEAUTHed from ASSOC RSP! status=0Nov 29 14:31:41 krn: chantry_export.c:2310/madwifi_send_deauth_imp()-chantry1/6E:BA:1B:D5:83:02 reason=9Nov 29 14:31:41 krn: chantry_export.c:2338/madwifi_send_deauth_imp()-chantry1 wireless_handlers is NULL, will try to convert to a chantry device...Nov 29 14:31:41 krn: chantry_export.c:2353/madwifi_send_deauth_imp()-Deauthing 6E:BA:1B:D5:83:02 on ath1Nov 29 14:31:41 krn: ieee80211_wireless.c:2781/ieee80211_ioctl_setmlme()-ath1 DISASSOC/DEAUTH! 6E:BA:1B:D5:83:02 op=3Nov 29 14:31:41 krn: ieee80211_wireless.c:2823/ieee80211_ioctl_setmlme()-ath1/6E:BA:1B:D5:83:02 ATH_SUPPORT_DEFERRED_NODE_CLEANUP!Nov 29 14:31:41 krn: ieee80211_mlme.c:445/wlan_mlme_disassoc_request_with_callback()-ath1/6E:BA:1B:D5:83:02 wlan_vap_is_pmf_enabled=0Nov 29 14:31:41 krn: ieee80211_mlme.c:499/wlan_mlme_disassoc_request_with_callback()-ath1/6E:BA:1B:D5:83:02 defer_cleanup=1 ni_pmf=0 key_valid=0Nov 29 14:31:41 krn: ieee80211_mgmt.c:993/ieee80211_send_disassoc_with_callback()-ath1 DISASSOC 6E:BA:1B:D5:83:02 reason=9Nov 29 14:31:41 krn: ieee80211_wireless.c:2835/ieee80211_ioctl_setmlme()-DISASSOC rc=0Nov 29 14:31:41 krn: ieee80211_node_ap.c:274/_ieee80211_node_leave()-ath1/6E:BA:1B:D5:83:02 stassoc=1 ni=e6a17fd0 aid=1 kvalid=0 keyix=65535 ncount=2 tm=30 rss=-47 refcnt=2 rtChRegUtil=1Nov 29 14:31:41 krn: ieee80211_node_ap.c:80/chk_ic_counters()-wifi0 Correcting ht40_sta_assoc! orig=65535 new=0Nov 29 14:31:41 krn: ieee80211_node_ap.c:81/chk_ic_counters()-wifi0 num_corrected=1Nov 29 14:31:42 krn: [19/1] FWLOG: [4138309] RATE: ChainMask 3, peer_mac 83:2, phymode 8, ni_flags 0x02211002, vht_mcs_set 0xfffa, ht_mcs_set 0xffff, legacy_rate_set 0x0ff0Nov 29 14:31:42 krn: [31/5] FWLOG: [4138309] RTT_REPORT ( 0x2804, 0x3, 0x479, 0x0, 0x9 )Nov 29 14:31:42 krn: [22/26] FWLOG: [4138309] WAL_DBGID_SECURITY_ALLOW_DATA ( 0x443ba4 )
Googling about it, I found something about the "reason=9" was related to "station not authorized"... Even oddier.
I returned to my LAB and created a new VLAN (and NAC configs) and got the same issue: The old VLANs it worked as expected, BUT on the NEW VLAN it doesn't work...
So I remembered my VMWare host issue, where it needed to be rebooted, rebooting the XCC VM... So I checked the customer's XCC, and it was rebooted on the previous night (so, with the "older" VLANs already created)... MAYBE RELATED??? I've decided to try...
After a simple XCC reboot (without ANY AP REBOOT, I've kept connected via SSH to the AP) and just when the XCC got back online and the AP connected to it... TADAAAA! It worked FLAWLESSLY!!!
Retried, creating a new VLAN and got the same issue... In summary: I needed to reboot the XCC to make a new VLAN to work.
So I opened a case on GTAC (02483956) and they are working on it...
I hope this info could help you.
Best regards,
-Leo
