Alas, having expanded the lab I have hit a brick wall which I don't believe is surmountable.
I have a comware 5130 with edge ports authenticating against Clearpass as normal.
I'm able to MACauth a small switch connected to this 5130 and the result is tagged/untagged ports as configured in Clearpass between 5130 and small switch.
However, when a new device is plugged into the small switch, the MAC address hits the 5130 which then attempts to perform MACauth. So even though frames are received on a newly tagged vlan, the 5130 still attempts to do MACauth. As the VLAN is already tagged, authentication fails because the 5130 needs to put this new MAC into an untagged vlan (as is the way with MACauth).
In short, while I can achieve the goal of settings the correct VLANs to the small downstream switch, I'm unable to stop the 5130 from continuing to do authentication, which fails and blocks the end device from transmitting.
The error message for the end device after the initial small switch is authenticated:
Jan 24 11:44:54:177 2024 test5130 MACA/6/MACA_LOGIN_FAILURE: -IfName=GigabitEthernet1/0/1-MACAddr=1111-2222-5502-VLANID=3646-Username=1111-2222-5502-UsernameFormat=MAC address; User failed MAC authentication. Reason:Authorization VLAN process failed.
On ArubaOS there is a custom attribute that sets the port-mode during the session so that in essence no further auth is required. I don't believe this exists within the H3C custom attributes. This is likely the vital step. By stopping further MAC addresses triggering authentication, any end devices are free to communicate on the newly established tagged VLANs.
Original Message:
Sent: Jan 22, 2024 04:18 AM
From: IanNightingale
Subject: send multiple vlans in radius response to comware7 device
Hi, thanks. That is really useful. I have successfully edited the setup such that there is only one of everything meaning this now becomes a scalable solution.
For the benefit of others, the device has the following custom attribute (so the vlans are per authenticating device) and this is referenced as below in the enforcement profile.
The small switch is now authenticated using MACauth and the downlink to it has the specified VLANs.
I'm aware that others recommend authenticating via dot1x to improve the experience (I think so that it guarantees the small switch is authenticated first rather than an end device attached to it) but this is a big step forward.
Ian.
Original Message:
Sent: 1/21/2024 3:31:00 PM
From: Jannie Hanekom
Subject: RE: send multiple vlans in radius response to comware7 device
Yes, with ArubaOS-Switch switches (all recent models of which support RFC4675) you can use the Egress-VLANID attribute to return multiple VLAN IDs as named values. Never got that to work on Comware switches, though.
Just an option...here is what's worked for me from within ClearPass, passing back different VLANs but having a single enforcement policy & profile. I set an attribute on each switch that sets which VLAN ID needs to be returned. This is not as tedious as it sounds; every time I add a new device, I create a copy of a previous one and just update what needs updating. I then reference that attributes on the enforcement profile.
While it won't work for you as-is, you could possibly use the same mechanism to construct the "1u 2t 3t 4t" string you mentioned originally.
Original Message:
Sent: Jan 21, 2024 06:16 AM
From: IanNightingale
Subject: send multiple vlans in radius response to comware7 device
Hi Jannie,
Thanks for the response. The method of having the small switch connected to a port on an upstream switch, that performs all the auth, is what we have now. So the small switch has no VLANs configured and no auth takes place. For the odd phone or PC this works great with the upstream switch taking care of all authentication.
However, add multicast and high bandwidth into the mix and this goes wrong. The small switch has a shared broadcast domain amongst all vlans which causes issues with IGMP etc. In our case we have a large number of these switches that are used for audio visual kit. I'm attempting a better solution where the small switch has VLANs configured and may as well do the auth (i.e. is a fully managed/configured switch).
Comware 5130 will only accept a single named vlan against the port, or a string of numbered tagged/untagged vlans. This isn't scalable in Clearpass because you need a different profile per small switch multiplied by each combination of large switch operating system. So it works in a lab but doesn't scale well. We use named VLANs for normal auth and if we were able to send a list of those all would be perfect.
There are more options with ArubaOS (we have lots of 2930F too) where different radius attributes can be returned. It is down to the authenticating switch how it parses the returned strings etc and it seems ArubaOS permits multiple returned named VLANs. Though I haven't seen for myself.
Ian
Original Message:
Sent: 1/20/2024 11:16:00 AM
From: Jannie Hanekom
Subject: RE: send multiple vlans in radius response to comware7 device
If you're using ClearPass, a relatively easy workaround for environments where switches do not use standardised VLANs is to set an attribute on each switch with a VLAN name/ID mapping, then use that as a variable in your enforcement profile.
Having said that, I've found the simplest solution to just use the standard MAC-VLAN feature. Rather than having all sorts of tagging magic configuration, just return the Private-VLAN-ID for each device. Each device will operate untagged in the PVID set on the port, but the switch will dynamically place packets from each MAC address into the correct VLAN ID returned on the RADIUS packet.
I successfully use this to separate phones with passthrough ports, APs with multiple passthrough ports, topologies that has a PC behind a phone behind an AP... works well.
Original Message:
Sent: Jan 15, 2024 04:01 AM
From: IanNightingale
Subject: send multiple vlans in radius response to comware7 device
Thanks for the link which confirms my observation.
Any combination of numbered tagged/untagged vlans, or a single named which appears as untagged.
I tried to use a vlan-group. If one exists in config the radius response is accepted but an algorithm selects the lowest vlan ID as the untagged VLAN for the port.
Basically, the functionality is geared towards single edge device assignment with the exception of the special string of numbers suffixed with u & t.
Original Message:
Sent: 1/15/2024 3:16:00 AM
From: Holger Hasenaug
Subject: RE: send multiple vlans in radius response to comware7 device
Under the following URL you will find the supported combinations.
https://www.h3c.com/en/Support/Resource_Center/EN/Home/Switches/00-Public/Configure___Deploy/Interoperability_Guides/Third-Party_Authentication_Server_Integration-Long/
Tagged named VLANs seems not to be one of them
Original Message:
Sent: Jan 13, 2024 06:27 AM
From: IanNightingale
Subject: send multiple vlans in radius response to comware7 device
If a 5130 (likely all comware7) receives a radius response to a MAC authentication it can accept multiple vlans (one untagged, multiple tagged). This is sent in the Tunnel-Private-Group-ID field.
If this text string contains just numbers it works fine. For example "1u 2t 3t" will result in the interface having a pvid of vlan1 and tagged for vlans 2 & 3.
What I need is to be able to send multiple named vlans. Sending a single named vlan using the same method works fine. So if the radius response is "tel_vlan" and that vlan exists in configuration it will become the untagged/pvid vlan.
Any combination of named vlans and numbered vlans fails. However several documents state that a list of named and numbered vlans can be returned. The ideal would be to send a string containing a few named vlans and these become tagged on the interface "tel_vlan iot_vlan cake_vlan"
Has anyone succeeded with a radius setup that sends multiple vlans containing a named vlan?
Has anyone documentation that states this is impossible?