Guest VLAN, Auth-Fail VLAN, and Critical VLAN in 802.1X: When and How to Use Them

Fallback VLANs: What Problem They Solve

The 802.1X standard defines a binary outcome at the port level: authorized or unauthorized. Without fallback mechanisms, any device that cannot complete authentication — whether it lacks a supplicant, presents wrong credentials, or cannot reach the RADIUS server — ends up with no network access at all.

In real enterprise deployments, that binary model breaks down immediately. Printers, conference room AV equipment, legacy IP phones, and guest laptops all need some level of network access without necessarily going through 802.1X credential authentication. The RADIUS server going offline during a maintenance window should not lock every employee off the network.

Cisco IOS XE provides three distinct fallback mechanisms, each targeting a different failure scenario:

These are not interchangeable. Configuring the wrong mechanism for the wrong scenario produces confusing behavior — devices that should be quarantined getting guest access, or devices that should have critical access being locked out.

VLAN Planning for This Lab

The lab topology uses:

• VLAN 30 — Guest VLAN (limited internet access, no internal resources)
• VLAN 40 — Auth-Fail VLAN (quarantine, block all production access)
• VLAN 50 — Critical VLAN (pre-defined access for known endpoints when ISE is down)

Before configuring any fallback VLAN on a switchport, these VLANs must exist in the switch database and the appropriate SVI or upstream routing must be in place.

vlan 30
 name GUEST
vlan 40
 name AUTH-FAIL
vlan 50
 name CRITICAL

Guest VLAN

What It Does

The Guest VLAN is placed on a port when an 802.1X-capable port receives no EAPOL response from the connected device within the configured timeout period. It is the mechanism for handling devices that have no 802.1X supplicant — printers, IoT sensors, legacy workstations, and temporary guest devices.

The switch sends a configurable number of EAPOL Identity Request frames. If no EAPOL response arrives, the switch concludes that no supplicant is present and moves the port to the Guest VLAN. The device then has network access at Layer 2 in that VLAN — limited to whatever the Guest VLAN can reach.

Important behavior note: the Guest VLAN is only triggered by the absence of EAPOL. If a device sends any EAPOL frame — even a malformed one — the switch does not fall back to the Guest VLAN. This distinction separates Guest VLAN from Auth-Fail VLAN.

Configuration

interface GigabitEthernet1/0/1
 description Non-supplicant device (printer, IoT)
 switchport mode access
 switchport access vlan 10
 authentication host-mode multi-auth
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication event no-response action authorize vlan 30
 dot1x pae authenticator
 dot1x timeout tx-period 10
 dot1x max-reauth-req 2
 spanning-tree portfast

Line-by-line:

• authentication event no-response action authorize vlan 30 — places the port in VLAN 30 when no EAPOL response is received after the configured retry count. This is the Guest VLAN command.
• dot1x timeout tx-period 10 — interval in seconds between EAPOL Identity Request retransmissions. Default is 30 seconds. Reducing this speeds up the fallback for non-supplicant devices.
• dot1x max-reauth-req 2 — number of Identity Request retransmissions before concluding no supplicant is present. With tx-period 10 and max-reauth-req 2, a non-supplicant device will be in the Guest VLAN within approximately 20-30 seconds of connecting.

Guest VLAN and MAB Interaction

When both MAB and 802.1X are configured (as in authentication order dot1x mab), the switch first attempts 802.1X. If no EAPOL is received, it falls through to MAB before landing in the Guest VLAN. MAB sends a RADIUS request to ISE using the device's MAC address as both username and password.

If ISE has a policy for that MAC address (for example, a known printer MAC in an endpoint group), ISE can return an Access-Accept and place the device in a specific VLAN — without ever entering the Guest VLAN. The Guest VLAN is the fallback of last resort when MAB also fails or is not configured.

In a production campus environment, the recommended order for access ports serving mixed device types is:

authentication order dot1x mab
authentication priority dot1x mab
authentication event no-response action authorize vlan 30

This gives 802.1X-capable devices first priority, MAB second, and Guest VLAN only if both fail or are absent. See Article 12 (MAC Authentication Bypass (MAB) Configuration on Cisco IOS XE and ISE) for full MAB configuration details.

When Not to Use Guest VLAN

Do not configure Guest VLAN on ports where you do not want any unauthenticated access. If a conference room port should only be active during authenticated sessions, omit the Guest VLAN — or use the closed mode deployment strategy covered in Article 26. Also avoid Guest VLAN on uplink ports, trunk ports, or any port connected to infrastructure equipment.

Auth-Fail VLAN

What It Does

The Auth-Fail VLAN is triggered when a device attempts 802.1X authentication but fails — wrong password, revoked certificate, unknown username, or a RADIUS reject. The device sent EAPOL, went through the EAP exchange, and ISE returned an Access-Reject.

This is a meaningful distinction from the Guest VLAN. A device in the Auth-Fail VLAN has a supplicant and tried to authenticate — it is a known-bad credential scenario. The appropriate response is quarantine, not open guest access. Placing a failed authentication in VLAN 40 allows you to:

• Log the failure and alert on repeated attempts (potential credential stuffing)
• Direct the endpoint to a remediation portal
• Allow helpdesk access without opening production resources

Configuration

interface GigabitEthernet1/0/2
 description Corporate Workstation - Auth-Fail Quarantine
 switchport mode access
 switchport access vlan 10
 authentication host-mode single-host
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication event fail action authorize vlan 40
 authentication event no-response action authorize vlan 30
 dot1x pae authenticator
 dot1x timeout tx-period 10
 dot1x max-reauth-req 2
 spanning-tree portfast

The key line: authentication event fail action authorize vlan 40 — places the port in VLAN 40 when ISE returns an Access-Reject.

Note that both Guest VLAN and Auth-Fail VLAN are configured here. A device with no supplicant goes to VLAN 30 (Guest). A device with wrong credentials goes to VLAN 40 (Auth-Fail). These are independent trigger conditions and can coexist on the same interface.

Auth-Fail VLAN Retry Behavior

By default, a device placed in the Auth-Fail VLAN stays there until the port link cycles or the session times out. The switch does not automatically retry authentication while in the Auth-Fail VLAN. To allow the device to retry after a delay:

authentication event fail action authorize vlan 40
authentication event fail retry 3 action authorize vlan 40

The retry option specifies how many authentication failures the switch allows before locking the device in the Auth-Fail VLAN and stopping further retries. This prevents the switch from continuously retransmitting 802.1X requests while a device sits in a failed state.

Auth-Fail VLAN and ISE Visibility

When a device is placed in the Auth-Fail VLAN, ISE records the authentication failure in its logs. Navigate to Operations > RADIUS > Live Logs and filter by Status = Failed. Each entry shows the failure reason — most commonly 24408 Client certificate revoked in the CRL or 22040 Wrong password or invalid shared secret for EAP failures. Use these reason codes to drive alerting.

Critical VLAN

What It Does

The Critical VLAN is the most operationally significant of the three fallbacks. It is triggered when the 802.1X port cannot reach any configured RADIUS server. The switch detects this condition when all RADIUS servers in the server group are marked as dead (no response to Access-Request retransmissions).

Without the Critical VLAN, a RADIUS outage causes every 802.1X-protected port to deny access — the switch cannot authenticate anyone. In a campus network where every access port enforces 802.1X, a 5-minute ISE outage could prevent hundreds of employees from using the network.

The Critical VLAN provides a pre-defined network segment that known devices can use when ISE is unavailable. The security model accepts a temporary reduction in granular access control in exchange for business continuity.

Configuration

interface GigabitEthernet1/0/3
 description Corporate Workstation - Critical VLAN enabled
 switchport mode access
 switchport access vlan 10
 authentication host-mode multi-auth
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication event server dead action authorize vlan 50
 authentication event server dead action reinitialize vlan 50
 authentication event server alive action reinitialize
 dot1x pae authenticator
 mab
 spanning-tree portfast

Line-by-line:

• authentication event server dead action authorize vlan 50 — when all RADIUS servers are unreachable, new authentication attempts on this port are authorized in VLAN 50.
• authentication event server dead action reinitialize vlan 50 — when RADIUS becomes unreachable while a session is already active, the existing session is moved to VLAN 50. Without this line, already-authenticated sessions stay in their current VLAN but new sessions cannot authenticate.
• authentication event server alive action reinitialize — when RADIUS becomes reachable again, existing sessions in the Critical VLAN are reauthenticated against ISE. Devices are returned to their correct VLAN based on their credentials and the current ISE policy.

The reinitialize action is critical for operational correctness. Without it, endpoints remain in VLAN 50 even after ISE recovers, and must physically disconnect and reconnect (or wait for reauthentication timeout) to get their correct VLAN assignment.

RADIUS Dead Timers and Detection

The Critical VLAN activation depends on the RADIUS server dead detection mechanism. Configure this globally:

radius-server dead-criteria time 5 tries 3
radius-server deadtime 15

• dead-criteria time 5 tries 3 — a RADIUS server is declared dead if it fails to respond to 3 requests within 5 seconds. Adjust based on your network latency to ISE.
• deadtime 15 — once declared dead, the server is not retried for 15 minutes. Adjust based on your ISE restart time.

Without these timers, the switch may take a long time to declare ISE unreachable, and the Critical VLAN activation will be delayed. In a campus access layer scenario where ISE is in the same building, time 5 tries 3 is appropriate. For a branch office connecting to ISE across a WAN link, increase the time value to account for higher latency.

RADIUS redundancy and failover design — including secondary ISE nodes and RADIUS server groups — is covered in Article 28 (RADIUS Redundancy and Failover in 802.1X Deployments).

Critical VLAN Security Considerations

The Critical VLAN model carries an inherent risk: any device on a Critical VLAN-enabled port gets VLAN 50 access when ISE is down, without authentication. An attacker who knows ISE is offline could connect a rogue device during the outage window and obtain network access.

Mitigations for production environments:

1. Restrict VLAN 50 access tightly — VLAN 50 should provide only the minimum access required for business continuity. DNS, DHCP, and core application servers only. No administrative access, no lateral movement paths.
2. Monitor VLAN 50 activity — log all connections to VLAN 50's DHCP scope and alert on new MAC addresses. Unusual activity during an ISE outage warrants investigation.
3. Combine with MAB for IoT devices — for ports serving known devices (IP phones, printers), configure MAB and store the MAC addresses locally on the switch using fallback local authentication. This provides authentication even when ISE is down.

Verifying Fallback VLAN Operation

Checking the Current Status

SW1# show authentication sessions

Interface  MAC Address     Method   Domain   Status              Fg  Session ID
Gi1/0/1    0021.a0b3.1234  dot1x    DATA     Auth                    0A00630A00000001
Gi1/0/2    c8d9.d2e1.5678  dot1x    DATA     Authz Failed            0A00630A00000002
Gi1/0/3    b8ac.6f22.9abc  N/A      DATA     Inaccessible (Server)   0A00630A00000003

The Status column shows the fallback condition:

• Authz Failed — endpoint is in the Auth-Fail VLAN
• Inaccessible (Server) — endpoint is in the Critical VLAN due to RADIUS being unreachable

Detail for a Guest VLAN Session

SW1# show authentication sessions interface GigabitEthernet1/0/1 detail

            Interface:  GigabitEthernet1/0/1
          MAC Address:  0021.a0b3.1234
         IPv6 Address:  Unknown
         IPv4 Address:  Unknown
           User-Name:  Unknown
              Status:  Authorized
              Domain:  DATA
      Oper host mode:  multi-auth
    Oper control dir:  both
     Session timeout:  N/A
  Common Session ID:  0A00630A00000001
    Acct Session ID:  0x00000001
             Handle:  0x1C000001
     Current Policy:  POLICY_Gi1/0/1

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
        Vlan Group:  Vlan: 30

Method status list:
       Method           State
       dot1x            Failed over
       mab              Failed over

The Local Policies > Vlan Group: Vlan: 30 (not under Server Policies) confirms the device is in the Guest VLAN via local policy, not ISE assignment. The method status showing Failed over for both dot1x and mab confirms neither authentication method succeeded.

Checking Critical VLAN State

SW1# show authentication sessions interface GigabitEthernet1/0/3 detail

            Interface:  GigabitEthernet1/0/3
          MAC Address:  b8ac.6f22.9abc
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.50.22
           User-Name:  Unknown
              Status:  Authorized
              Domain:  DATA
      Oper host mode:  multi-auth
    Oper control dir:  both
     Session timeout:  N/A
  Common Session ID:  0A00630A00000003
    Acct Session ID:  0x00000003
             Handle:  0x1C000003
     Current Policy:  POLICY_Gi1/0/3

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
        Vlan Group:  Vlan: 50

Method status list:
       Method           State
       dot1x            Server Dead
       mab              Server Dead

Server Dead in the method status and Vlan Group: Vlan: 50 under Local Policies confirms the Critical VLAN is active for this session. The IP address in the 10.0.50.0/24 range confirms DHCP is working in VLAN 50.

Troubleshooting

Symptom: Non-802.1X device is not falling back to the Guest VLAN — port stays unauthorized

Cause: The authentication event no-response action authorize vlan 30 command is missing from the interface, or MAB is configured and ISE is returning an Access-Reject for the device's MAC address. When ISE rejects a MAB request, the port transitions to the Auth-Fail VLAN (if configured), not the Guest VLAN.

Fix: Verify the interface configuration with show running-config interface GigabitEthernet1/0/1. Confirm the no-response event action is present. If MAB is configured, check ISE Live Logs to determine if ISE is receiving and responding to the MAB request. If ISE is returning a Reject for the MAC, either add the MAC to an ISE endpoint group with an Access-Accept policy, or remove the MAC from any deny list.

Symptom: Endpoint credentials are correct in Active Directory but endpoint ends up in Auth-Fail VLAN

Cause 1: ISE cannot reach the Active Directory domain controller to validate credentials. ISE is rejecting the authentication due to an AD connectivity issue, even though the credentials are valid.

Fix: On ISE, navigate to Administration > Identity Management > External Identity Sources > Active Directory > [your AD join point]. Click Test Connection. If the test fails, check network connectivity between ISE (10.0.0.10) and the AD domain controllers. Check the ISE ADE-OS interface routing and any firewall rules between ISE and AD. ISE requires TCP 389, 636, 3268, and optionally 88 (Kerberos) to reach AD.

Cause 2: The certificate used for EAP-TLS authentication has expired or the CA is not trusted by ISE.

Fix: In ISE, navigate to Administration > System > Certificates > Certificate Authority Certificates. Confirm the issuing CA certificate is imported and trusted for client authentication. Check the certificate expiration on the endpoint.

Symptom: Critical VLAN activates but endpoints do not get re-authenticated after ISE recovers

Cause: The authentication event server alive action reinitialize command is missing from the interface configuration.

Fix: Add the command to all 802.1X interfaces:

interface GigabitEthernet1/0/3
 authentication event server alive action reinitialize

This command triggers the switch to initiate reauthentication for all sessions in the Critical VLAN when it detects that the RADIUS server has become reachable again. Without it, endpoints in VLAN 50 will remain there indefinitely until their session times out or the port link cycles.

To force immediate reauthentication after ISE recovers (for testing or emergency recovery):

SW1# clear authentication sessions interface GigabitEthernet1/0/3

This clears the existing session and forces the endpoint to reauthenticate immediately.

Symptom: All three fallback VLANs are configured but the switch is still using the wrong one for a given failure

Cause: The event triggers are being misidentified. The most common confusion is between Auth-Fail VLAN and Guest VLAN: if a device sends a single EAPOL frame (even a malformed or incomplete one), the switch does not treat it as a no-response scenario. Any EAPOL activity moves the session to the 802.1X authentication path. If that authentication fails, the Auth-Fail VLAN is used — not the Guest VLAN.

Fix: Use debug dot1x all to observe the exact event sequence:

SW1# debug dot1x all
SW1# debug authentication all

Watch for messages indicating no-response (Guest VLAN trigger), auth-fail (Auth-Fail VLAN trigger), or server dead (Critical VLAN trigger). The debug output identifies which event the switch is classifying each authentication attempt under. Disable debugging when done:

SW1# undebug all

What's Next

Article 16 — Downloadable ACLs (dACLs) with Cisco ISE and 802.1X: Beyond VLAN placement, ISE can push access control lists directly to the switch at authentication time, providing per-session traffic filtering without static ACL configuration on every switchport. Article 16 covers dACL configuration on ISE and the IOS XE requirements for applying them correctly.