"Tag ID" purpose in authorization profile and when should I change it?

[rezaalikhani]

Hi all;

When we want to assign VLAN numbers to interfaces dynamically through ISE authorization profile result, one parameters should we consider is "Tag ID". Right?

My question is, what is the purpose of Tag ID and when we should changes it?

Thanks

[M02@rt37]

Hello @rezaalikhani 

In the context of RADIUS attributes for VLAN and priority support (RFC 4675), the term "Tag ID" refers to the tag indication field. This field is one octet in length and is used to indicate whether the frames on the VLAN are tagged or untagged.

It indicates whether the frames on the VLAN are tagged (0x31 = ASCII '1') or untagged (0x32 = ASCII '2').

This information is relevant in scenarios where RADIUS is used for network access control, and the attributes exchanged between the RADIUS server and network devices (such as switches) include information about VLAN tagging for the user or device.

In practical terms:

- Tagged (0x31): Indicates that frames on the VLAN should be tagged. This is typically used when the network infrastructure supports VLAN tagging, and the user or device needs to be associated with a specific VLAN.

- Untagged (0x32): Indicates that frames on the VLAN should be untagged. In this case, the user or device is placed in a VLAN without VLAN tagging.

In the context of Cisco's TrustSec solution, the tag referred to as the Security Group Tag called "SGT" which is a crucial element for enforcing access control policies. Cisco ISE is often used in conjunction with TrustSec to provide secure access control in enterprise networks.

[MHM Cisco World]

The tag id is always be 1.

This tag relates to SGT which I dont think you use.

MHM

[Rob Ingram · Accepted solution]

@rezaalikhani

"The Tunnel-Private-Group-ID is of type string for use with IEEE 802.1X. Therefore, the VLAN ID integer value is encoded as a string. When these tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in RFC2868, section 3.1—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".  RFC 2868

Reference: - https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/217043-configure-dynamic-vlan-assignment-with-c.html

https://content.cisco.com/chapter.sjs?uri=%2Fsearchable%2Fchapter%2Fcontent%2Fen%2Fus%2Ftd%2Fdocs%2Fswitches%2Flan%2FDenali_16-1%2FConfigExamples_Technotes%2FTechzone_Articles%2FExample_and_Technotes_Denali_16_1_1%2FExample_and_Technotes_Denali_16_1_...

In this context (Dynamic VLAN assignment) the TAG ID is not referring to an SGT (Security Group Tag).

[Karsten Iwen · Accepted solution]

This has nothing to do with tagged/untagged or SGTs ... @Rob Ingram is right with his reference. One more or less important note is that you can use values other than "1," but they are neither needed nor relevant any more. This parameter groups the three attributes together. This is what I have on one of my Authorization profiles:

Access Type = ACCESS_ACCEPT
Tunnel-Private-Group-ID = 2:1032
Tunnel-Type = 2:13
Tunnel-Medium-Type = 2:6

VLAN 1032 is applied to my wireless users without problems because these attributes share the same tag.

It is not relevant nowadays (other than the requirement to have the same tag for all three attributes) because we typically don't have any Group IDs other than VLANs. But when the RFC was written, there were other technologies that could benefit from these IDs, and one RADIUS ACCESS-ACCEPT could transport multiple attributes for multiple technologies. There, the tag was relevant to group the right attributes.