Extreme Campus Controller

 View Only
  • 1.  XCC - VLAN mapping - no IP address

    Posted 11-16-2021 21:43
    Edited by tfsnetman 11-16-2021 21:50
      |   view attached
    Hello,

    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,
    Klaus


  • 2.  RE: XCC - VLAN mapping - no IP address

    Posted 11-22-2021 23:39
    Opened a TAC case and was given this:
    Detailed steps are provided in the following article which is to create Tunnel-Private-Group-ID for XCC
    https://extremeportal.force.com/ExtrArticleDetail?an=000059011



  • 3.  RE: XCC - VLAN mapping - no IP address

    Posted 11-23-2021 16:09
    Check the levels of code you are running. We are running the below levels and the integration is working fine. We were initially running an earlier version of XMC/Control and had problems as you are noticing.

    XMC/ Control: v8.5.6.17
    XCC: 05.36.03.0017

    Essentially policy takes care of the vlan / isid without any special tweaking. I am having issues getting captive portal to work (in our case it is hosted on control) but the basic vlan assignment & fa works fine.

    Switch Definition for XCC in Control:








  • 4.  RE: XCC - VLAN mapping - no IP address

    Posted 11-29-2021 10:39
    Glenn, 
    Are you using different VLANs for Guest User registration and Guest Access after the successful auth.? If yes, we have recently discovered an issue that prevents the client from getting IP from a new VLAN even if correct role has been assigned after Guest User registration. It has to do with DHCP packet ACKs when the user is in unauthenticated state. it is being looked at and a fix should be introduced in one of the coming releases.
    However, you should not have any issues, if the pre and post registration VLANs are the same. 

    Regards,
    Ovais


  • 5.  RE: XCC - VLAN mapping - no IP address

    Posted 11-29-2021 16:19
    Hi Ovais,

    For our captive portal the vlan is the same. We do have a lot of WPA2 Enterprise networks which switch vlans.. is the bug just related to captive portal?

    Rgds,

    Glenn


  • 6.  RE: XCC - VLAN mapping - no IP address

    Posted 11-29-2021 18:27
    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.   

    Regards,
    Ovais


  • 7.  RE: XCC - VLAN mapping - no IP address

    Posted 12-03-2021 15:49
    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


  • 8.  RE: XCC - VLAN mapping - no IP address

    Posted 12-03-2021 20:12
    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 05.46.02.0019 and
    XMC / NAC 8.5.6.17

    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,

    Klaus