09-13-2021 11:56 AM
Hi Guys,
I'm working on a customer deployment and got some issues using ExtremeControl and XCC (5.36.03).
If I send RFC3580 Vlan Attributes to XCC from the Control, the 802.1x session from the client can't authenticate, even with the VLAN created under Policy > Vlans and the same vlan associated to the Device Group's Profile.
Taking the "Guest Access" role as example, it is configured on the XCC to use the "Default Network VLAN" (as it is in sync with the policy domain, applied to the wired infrastructure too). I've created the VLAN 40 and marked as Bridge@AP Tagged and associated it with the Device Group's Profile (https://extremeportal.force.com/ExtrArticleDetail?an=000094691),
If I send only the FilterID 'policy=Guest Access' the client, the client get's authenticated, but still on the default WLAN VLAN (120). If I send the VTA attributes as follows, the same client can't authenticate:
Filter-Id=Enterasys:version=1:%MANAGEMENT%policy=%POLICY_NAME%
Login-LAT-Port=%LOGIN_LAT_PORT%
Service-Type=%MGMT_SERV_TYPE%
Tunnel-Private-Group-Id=%VLAN_ID%:%VLAN_TUNNEL_TAG%
Tunnel-Type=13:%VLAN_TUNNEL_TAG%
Tunnel-Medium-Type=6:%VLAN_TUNNEL_TAG%
The policy mapping is done on the Control for the dynamic vlan I want to apply.
Any ideas?
Solved! Go to Solution.
09-17-2021 01:32 PM
Hi PeterK,
I've just posted the config where I got issues… In summary: B@AC works perfectly, B@AP don't work. Below follows more info...
As far as I discovered, the Dynamic VLAN assignment works without a "Role-to-VLAN pair" static creation on XCC, using RADIUS VLAN attributes, on B@AC topologies, but is not working o B@AP or FabricAttach topologies, even with the association of the VLANs to the Device Group's profile.
Creating the "Role-to-VLAN pairs" is not an option, as the customer is using a single Policy Domain for Wired and Wireless, and this solutions "would not fit" on the environment. Using B@AC solution is not an option as well.
Best regards,
-Leo
09-17-2021 01:39 PM
Hi Leo,
ok; understand.
In this case you should open a Case.
09-17-2021 01:32 PM
Hi PeterK,
I've just posted the config where I got issues… In summary: B@AC works perfectly, B@AP don't work. Below follows more info...
As far as I discovered, the Dynamic VLAN assignment works without a "Role-to-VLAN pair" static creation on XCC, using RADIUS VLAN attributes, on B@AC topologies, but is not working o B@AP or FabricAttach topologies, even with the association of the VLANs to the Device Group's profile.
Creating the "Role-to-VLAN pairs" is not an option, as the customer is using a single Policy Domain for Wired and Wireless, and this solutions "would not fit" on the environment. Using B@AC solution is not an option as well.
Best regards,
-Leo
09-17-2021 01:21 PM
oh, ok… good to know...
I always had a lot of trouble with vlan assignment at XCC.
AFAIK you need a policy role for every VLAN at the XCC, otherwise the tunnel-attribute is not accepted. I can’t see that in your screenshots and this is what was the solution for me...
09-17-2021 01:15 PM
Hi PeterK,
This design works perfectly on Wired and on the IdentiFi solutions… There's no problem with the VLAN/Topology/Role change… The problem is, when NAC tells XCC to reauth user (and XCC "obeys") and the client tries to reauth receiving the new RADIUS ATTRIBUTES, the client simply can't connect.
If I don't send the VLAN Attributes (just the very same ROLE), and this role is set statically to the desired VLAN, it works flawlessly.
It seems that the XCC is not working fine with this attibutes on B@AP topologies.
By the way, as I stated in previous posts, it WORKS PERFECTLY FINE when, with the very same config BUT the topology is set to Bridge@AC, sending the very same VLAN ATTRIBUTES, it just crashes when the topology is set to Bridge@AP and we pass the VLAN attributes.
Best regards,
-Leo