Showing results for 
Search instead for 
Did you mean: 

XCC - VLAN mapping - no IP address

XCC - VLAN mapping - no IP address


Devices are not getting an IP address when mapped to a certain VLAN after successful authentication.
VLAN mapping on the XCC is configured as below


Switchport where the AP is connected has the VLAN tagged.

Extreme Control is returning:

XCC version: 05.36.02

Any ideas what it could be?

Thank you,

Yes, that issue is only related to the Captive Portal. If you are not flipping the VLANs then you shouldn't have any issues. 
Since I have limited knowledge of your setup, my response below is based on assumptions:

How are you integrating the XCC with Access Control engine? is it via XCC's onboard NAC? what I mean is, if you have created AAA policy under the "Onboard" main configuration tab then it would engage the XXC's onboard NAC. If this is the case, it requires more configuration on XCC related to onboard rule engine and Radius settings. Its not a recommended way of integrating XCC and ExtremeControl anymore. Instead, you should create AAA policy in the Configuration > AAA tab which will allow the auth. request to go straight to the Access Control engine and you won't need any other config on the XCC. 

Another thing to check would be the VLANs and Roles on XCC. Looks like you are using Fabric Attach, make sure you create VLANs in the XCC  with mode set to FA. In addition, make sure the VLANs and correct roles are mapped to the AP profile by checking Configuration > Site > Device Group > AP Profile >  Roles and then VLANs.   


Hi Guys,

Please, allow me, humbly, to try to help...

Customer's XCC:

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):

     I couldn't make it work with NAC ( as it shows as "unsupported attributes".
      This KB haven't helped me on my case, as it was already set.
      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,


Hi guys,

Thank you for sharing your experience.
It is working for us, but I don't know why it didn't work in the beginning.

We are now running:

XCC SW version and

On the XCC only the Enterprise Role is mapped to the Device Group.

Since we have a Fabric network we also switched to VLAN / I-SID mapping on the XCC.
Some of the EXOS switches were running an older 22.x version which caused statically configured VLANs to be removed on the uplink of the EXOS after the AP was disconnected.
An upgrade on the EXOS switch to a 31.x version fixed the issue where the (F) flag which is dynamically added by fabric attach remains on the uplink if the same VLAN is statically configured.

Thank you,