I recently bumped into some devices that needed the Avenda-Tag-Id = 0 being set in the Enforcement profile in order to work correctly. As I didn't fully understand, and returning and Avenda VSA to different vendor equipment feels strange, I decided to find out what this exactly does and why it works in those cases. Here is my write up:
Some network devices, like (certain) Instant On switches, Dell switches, Cisco SG300 (SMB) switches, need to have the Avenda:Avenda-Tag-Id = 0 attribute in their VLAN enforcement.
Side note: Avenda is the original name of the vendor who created ClearPass. The name has not been changed everywhere in the product for compatibility reasons.
Unlike what it suggests, this Avenda-Tag-Id is not a VSA, but it's controlling how ClearPass returns the VLAN-Id in the Tunneled-Private-Group-Id IETF RADIUS response.
Let's compare two authentications where the VLAN is returned as part of the 'IETF standard way of returning a VLAN':
On the left you see the situation where the Avenda:Avenda-Tag-Id is included in the enforcement. On the right you see the default behavior where that attribute is not included in the enforcement. As you can see the Avenda-Tag-Id is not an attribute that is included, but it changes how ClearPass returns the IETF:Tunneled-Private-Group-Id, which contains the VLAN. The Tag: 0x01 is suppressed when Avenda-Tag-Id is set to 0 in the enforcement.
To understand this better, let's have a look at the RFC 2868 that defines RADIUS (updated by RFC 3575, but that doesn't include the following details), more specific on the Tunneled-Private-Group-Id:
A summary of the Tunnel-Private-Group-ID Attribute format is shown
below. The fields are transmitted from left to right.by
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
81 for Tunnel-Private-Group-ID.
Length
>= 3
Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. If the value of the Tag field is greater than 0x00
and less than or equal to 0x1F, it SHOULD be interpreted as
indicating which tunnel (of several alternatives) this attribute
pertains. If the Tag field is greater than 0x1F, it SHOULD be
interpreted as the first byte of the following String field.
String
This field must be present. The group is represented by the
String field. There is no restriction on the format of group IDs.
The Tag field is defined as a 'SHOULD', which in RFC terms means that a device can ignore it and still be following the RFC. If it ignores the Tag field, it will read it as part of the VLAN number/name, which of course makes the VLAN invalid and assignment will fail.
Most equipment will just accept responses with the Tag included, but if you have equipment that doesn't you may need to include Avenda:Avenda-Tag-Id = 0 in your VLAN enforcement.
Also note this ONLY applies if the Tunneled-Private-Group-Id is used to return the VLAN. It's not applicable if you don't enforce VLAN, just enforce a role, or use other attributes like Aruba-User-VLAN or HPE-Egress-VLAN.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------