The Anatomy of Dynamic VLAN Assignment
Dynamic VLAN assignment in 802.1X works through three RADIUS Tunnel attributes that ISE includes in the Access-Accept response:
- Tunnel-Type (64): Value 13 (VLAN)
- Tunnel-Medium-Type (65): Value 6 (802)
- Tunnel-Private-Group-ID (81): The VLAN number as a string (e.g., "10")
When the switch receives all three attributes with correct values, it moves the authenticated port from its configured access VLAN to the RADIUS-assigned VLAN. The endpoint's traffic is then forwarded on the new VLAN.
When VLAN assignment fails, one of these is true:
- ISE is not sending the VLAN attributes in the Access-Accept
- ISE is sending the attributes but with incorrect values
- The switch is not processing the attributes (misconfiguration, VLAN not in database)
- The switch is processing the attributes but cannot apply them (host mode conflict, trunk conflict)
The diagnostic sequence covers each of these in order.
Step 1: Confirm What the Switch Is Actually Applying
SW9300# show authentication sessions interface GigabitEthernet1/0/5 details
Sample output — wrong VLAN applied:
Interface: GigabitEthernet1/0/5
MAC Address: a4b1.c2d3.e4f5
IPv6 Address: Unknown
IPv4 Address: 10.0.1.25
User-Name: CORP\jsmith
Status: Authorized
Domain: DATA
Reauthentication: Timer Running (1800s remaining)
Session timeout: 36000s (server), Remaining: 33800s
Common Session ID: 0A0063010000002B1A3F4C92
Acct Session ID: 0x0000002C
Handle: 0x98000029
Current Policy: POLICY_Gi1/0/5
Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_MUST_SECURE (priority 150)
Server Policies:
ACS ACL: xACSACLx-IP-Employee-12345678
Method status list:
Method State
dot1x Authc Success
The problem: the Server Policies section shows an ACS ACL but no Vlan Group entry. ISE sent an Access-Accept, authentication succeeded, but no VLAN was assigned. The switch left the port on its configured access VLAN (whatever switchport access vlan is set to on this interface).
Compare to correct output with VLAN assignment:
Server Policies:
Vlan Group: Vlan: 10
ACS ACL: xACSACLx-IP-Employee-12345678
Vlan Group: Vlan: 10 confirms the switch received and applied the VLAN assignment from ISE.
If the VLAN Group shows Vlan: 1 when you expect Vlan: 10, ISE sent VLAN 1 in the Tunnel-Private-Group-ID attribute — or ISE sent nothing and the switch defaulted to VLAN 1 (default VLAN).
Step 2: Verify What ISE Sent in the Access-Accept
Enable RADIUS attribute debugging on the switch and trigger a re-authentication:
SW9300# debug radius attributes
SW9300# clear authentication sessions interface GigabitEthernet1/0/5
Sample debug output — ISE sending VLAN attributes correctly:
*Mar 19 11:05:22.441: RADIUS: Received from id 1645/52 10.0.0.10:1812 Access-Accept, len 198
*Mar 19 11:05:22.441: RADIUS: authenticator 9A 3F C2 44 ...
*Mar 19 11:05:22.441: RADIUS: User-Name [1] 14 "CORP\jsmith"
*Mar 19 11:05:22.441: RADIUS: Class [25] 52 ...
*Mar 19 11:05:22.441: RADIUS: Session-Timeout [27] 6 36000
*Mar 19 11:05:22.441: RADIUS: Tunnel-Type [64] 6 VLAN(13)
*Mar 19 11:05:22.441: RADIUS: Tunnel-Medium-Type [65] 6 ALL_802(6)
*Mar 19 11:05:22.441: RADIUS: Tunnel-Pvt-Group-ID [81] 7 "10"
*Mar 19 11:05:22.441: RADIUS: Cisco AVPair [1] 42 "ACS:CiscoSecure-Defined-ACL=#ACSACL#..."
Tunnel-Type: VLAN(13), Tunnel-Medium-Type: ALL_802(6), Tunnel-Pvt-Group-ID: "10" — all three attributes present and correct. If the switch is not applying VLAN 10 despite receiving these, the issue is at the switch level (Step 4).
Sample debug output — ISE not sending VLAN attributes:
*Mar 19 11:05:22.441: RADIUS: Received from id 1645/52 10.0.0.10:1812 Access-Accept, len 142
*Mar 19 11:05:22.441: RADIUS: User-Name [1] 14 "CORP\jsmith"
*Mar 19 11:05:22.441: RADIUS: Class [25] 52 ...
*Mar 19 11:05:22.441: RADIUS: Session-Timeout [27] 6 36000
*Mar 19 11:05:22.441: RADIUS: Cisco AVPair [1] 42 "ACS:CiscoSecure-Defined-ACL=#ACSACL#..."
No Tunnel-Type, Tunnel-Medium-Type, or Tunnel-Pvt-Group-ID attributes. ISE sent an Accept but no VLAN assignment. The issue is in ISE's authorization profile configuration (Step 3).
Sample debug output — ISE sending wrong VLAN number:
*Mar 19 11:05:22.441: RADIUS: Tunnel-Pvt-Group-ID [81] 7 "VLAN10"
The Tunnel-Private-Group-ID value is "VLAN10" instead of "10". Some IOS XE versions can resolve VLAN names, but it is unreliable. Always use the numeric VLAN ID in the ISE authorization profile.
Disable debug after collection:
SW9300# undebug all
Step 3: Check the ISE Authorization Profile
Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles > [Profile Name]
Scroll to the "VLAN" section under Common Tasks. Verify:
- VLAN checkbox is checked
- ID/Name field contains the numeric VLAN ID (e.g.,
10notVLAN10orData_VLAN) - The radio button is set to "ID" (numeric) not "Name" (string)
The authorization profile translates to these RADIUS attributes when sending the Access-Accept:
Tunnel-Type = VLAN (13)
Tunnel-Medium-Type = 802 (6)
Tunnel-Private-Group-ID = 10
If the VLAN checkbox is unchecked, ISE sends the Access-Accept without VLAN attributes and the switch assigns no VLAN (the port stays on its configured access VLAN).
If the VLAN is configured as a name string (e.g., "Data") instead of a number, the behavior depends on whether the switch has a VLAN name entry that matches. Avoid using VLAN names — always use numeric IDs.
Check which Authorization Profile is actually being returned for this endpoint.
Navigation: Operations > RADIUS > Live Logs > [Click on the authentication entry] > Authentication Detail
Scroll to the Authorization section. Verify:
- Which Authorization Profile was selected
- What VLAN is configured in that profile
- Whether the VLAN attributes appear in the "Other Attributes" section at the bottom of the detail report
If the profile returned is not the one you intended, re-check the Authorization Policy rule order:
Navigation: Policy > Policy Sets > [Policy Set] > Authorization Policy
ISE evaluates rules top to bottom. If a higher-priority rule matches the endpoint and that rule's profile has no VLAN, the endpoint gets no VLAN assignment even though a lower-priority rule would have provided the correct VLAN.
Step 4: Verify VLAN Exists on the Switch
This is the most common cause of VLAN assignment appearing to succeed at the RADIUS level but not taking effect on the port.
SW9300# show vlan brief
Sample output — VLAN 10 missing:
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/0/1, Gi1/0/2
20 Voice_VLAN active
30 Guest_VLAN active
40 AuthFail_VLAN active
50 Critical_VLAN active
99 Management_VLAN active Gi1/0/48
VLAN 10 is not in the VLAN database. The switch received VLAN 10 from ISE, tried to assign it, and silently fell back to the default VLAN or the port's configured access VLAN. No error message is generated in the syslog.
Add the missing VLAN:
SW9300(config)# vlan 10
SW9300(config-vlan)# name Data_VLAN
SW9300(config-vlan)# exit
Verify all VLANs referenced in ISE authorization profiles exist:
SW9300# show vlan brief | include active
VLAN 10, 20, 30, 40, 50, and 99 should all be active. After adding the VLAN, clear and re-authenticate the session:
SW9300# clear authentication sessions interface GigabitEthernet1/0/5
The port should now receive VLAN 10 and the endpoint should get a DHCP address from the 10.0.10.0/24 scope.
Step 5: Verify VLAN Is Allowed on the Uplink Trunk
Even if the VLAN exists on the access switch, the access port can be placed in VLAN 10, but if VLAN 10 is not allowed on the trunk uplink to the distribution switch, endpoints in VLAN 10 have no upstream connectivity.
SW9300# show interfaces GigabitEthernet1/0/49 trunk
Sample output:
Port Mode Encapsulation Status Native vlan
Gi1/0/49 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/0/49 20,30,40,50,99
Port Vlans allowed and active in management domain
Gi1/0/49 20,30,40,50,99
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/49 20,30,40,50,99
VLAN 10 is not in "Vlans allowed on trunk." Endpoints in VLAN 10 have no path upstream. Add VLAN 10 to the trunk:
SW9300(config)# interface GigabitEthernet1/0/49
SW9300(config-if)# switchport trunk allowed vlan add 10
Verify:
SW9300# show interfaces GigabitEthernet1/0/49 trunk | include allowed
Gi1/0/49 10,20,30,40,50,99
Step 6: Multi-Domain Authentication and VLAN Conflicts
On ports configured for multi-domain authentication (data + voice), the VLAN assignment behavior has specific constraints that cause failures not seen on single-host ports.
SW9300# show running-config interface GigabitEthernet1/0/5 | include host-mode
authentication host-mode multi-domain
In multi-domain mode:
- The DATA domain receives its VLAN from ISE (Tunnel attributes) — VLAN 10
- The VOICE domain receives its VLAN from ISE or from the port's configured
switchport voice vlan— VLAN 20
Common failure: the phone authenticates first and gets placed in its VLAN correctly. The PC authenticates second. ISE sends VLAN 10 for the PC. But if the PC is already on a port where the voice device occupied the DATA domain slot before the PC connected, the VLAN assignment can fail.
Check current multi-domain state:
SW9300# show authentication sessions interface GigabitEthernet1/0/5 details
Sample output showing both domains:
Interface: GigabitEthernet1/0/5
MAC Address: 001e.f7a1.b2c3 (Cisco IP Phone - Voice domain)
User-Name: 001e.f7a1.b2c3
Status: Authorized
Domain: VOICE
Vlan Group: Vlan: 20
MAC Address: a4b1.c2d3.e4f5 (Windows endpoint - Data domain)
User-Name: CORP\jsmith
Status: Authorized
Domain: DATA
Vlan Group: Vlan: 10
Both domains authorized with correct VLANs — this is the goal. If the DATA domain shows the wrong VLAN or no VLAN, but the VOICE domain is correct, the DATA endpoint's authorization profile is the issue.
For full multi-domain authentication configuration details, see Article 17 — 802.1X with IP Phones: Configuring Multi-Domain Authentication on Cisco IOS XE.
Step 7: VLAN Assigned but Endpoint Gets Wrong IP
Authentication is authorized, show authentication sessions shows the correct Vlan Group: Vlan: 10, but the endpoint's IP address is from the wrong subnet (e.g., 192.168.1.x when VLAN 10 should give 10.0.10.x).
This is a DHCP configuration issue, not a VLAN assignment issue. The VLAN assignment worked — but the DHCP server is not configured for VLAN 10, or the DHCP relay agent is not forwarding requests from VLAN 10 to the DHCP server.
Verify the DHCP relay is configured on the VLAN 10 SVI at the distribution switch (or wherever the Layer 3 gateway for VLAN 10 lives):
DistributionSW# show running-config interface Vlan10
interface Vlan10
ip address 10.0.10.1 255.255.255.0
ip helper-address 10.0.0.100
If ip helper-address is missing, DHCP requests from endpoints in VLAN 10 are not forwarded to the DHCP server. The endpoint falls back to APIPA (169.254.x.x) or a cached lease from a previous VLAN.
If the VLAN 10 SVI does not exist at all on the distribution switch, VLAN 10 traffic cannot be routed. Create the SVI:
DistributionSW(config)# interface Vlan10
DistributionSW(config-if)# ip address 10.0.10.1 255.255.255.0
DistributionSW(config-if)# ip helper-address 10.0.0.100
DistributionSW(config-if)# no shutdown
Troubleshooting
Symptom: VLAN assignment works for some users but not others on the same switch — users assigned to the same VLAN get it correctly, but one specific user always lands on the default VLAN
Cause: The specific user's account is matching a different Authorization Rule in ISE — one that does not include a VLAN assignment. This happens when a user is in a different AD security group than expected, or when a catch-all rule at the bottom of the policy is matching first due to rule ordering.
Fix: Check which rule ISE applied for this specific user.
Navigation: Operations > RADIUS > Live Logs — find the specific user's authentication entry and click it. In the authentication detail, look at the "Other Attributes" section — which Authorization Profile was returned? Then go to:
Navigation: Policy > Policy Sets > [Policy Set] > Authorization Policy
Find the rule that ISE matched for this user. Compare its Authorization Profile VLAN configuration against what you expect. Check the user's AD group membership:
Navigation: Operations > Reports > Endpoints and Users > Authentication Summary — filter by username, look at the identity group ISE resolved.
If the AD group condition in your VLAN assignment rule uses a specific group (e.g., "Domain Users - IT"), and this user is not in that group, the rule does not match and a lower-priority rule (without VLAN) applies instead. Add the user to the correct group or adjust the rule conditions.
Symptom: VLAN assignment succeeds on all ports except those on a specific line card — those ports always stay on the default VLAN
Cause: IOS XE software bug or line card incompatibility with VLAN push via RADIUS. This has been observed in specific 17.x releases on certain Catalyst 9300 hardware configurations. A secondary cause is the line card not being in the VLAN database at the switch level — some modular switches require VLAN propagation to be manually verified per module.
Fix: First verify the switch software version and check Cisco's Bug Search Tool for known issues with dynamic VLAN assignment on this specific hardware/software combination. Update to the latest recommended 17.9.x release.
Second, verify the VLAN exists on the switch at the hardware level:
SW9300# show vlan id 10
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Data_VLAN active Gi1/0/1, Gi1/0/2, Gi2/0/1
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
10 enet 100010 1500 - - - ieee - 0 0
If ports on the affected line card are not listed in the VLAN's port membership, run:
SW9300# clear mac address-table dynamic
SW9300# clear authentication sessions interface GigabitEthernet2/0/1
And trigger re-authentication.
Symptom: After CoA-triggered VLAN change (posture remediation), endpoint stays in the old VLAN despite show authentication sessions showing the new VLAN
Cause: The switch successfully applied the new VLAN assignment to the port, but the endpoint still holds a DHCP lease from the old VLAN. Until the lease expires or the endpoint performs a DHCP release/renew, it continues to use the old IP from the old subnet. The switch shows VLAN 10, but the endpoint's IP is still from VLAN 40's scope.
Fix: Switch from reauthenticate CoA to port-bounce CoA for posture-based VLAN transitions. Port-bounce cycles the port, forcing the endpoint to release its link, reconnect, receive the new VLAN assignment, and obtain a new DHCP address.
Navigation: Policy > Policy Elements > Results > Authorization > Authorization Profiles > [PostureRemediation profile]
Change the CoA type from "Reauthenticate" to "Port Bounce." For the full CoA configuration details, see Article 19 — Change of Authorization (CoA) in 802.1X: How It Works and How to Configure It.
Alternatively, if disrupting the port is unacceptable (e.g., the endpoint is a VoIP-adjacent device), configure the Cisco AnyConnect ISE posture module to trigger a DHCP release/renew upon compliance — this avoids port-bounce while still refreshing the IP address.
What's Next: Article 24 — dACL Not Applying Correctly in 802.1X: Troubleshooting Downloadable ACLs — covers the specific failure modes for downloadable ACLs: dACLs not downloading, applying with wrong content, or being ignored entirely, with the full diagnosis sequence using show ip access-lists and ISE authorization detail reports.
