JNCIS-MistAI-Wired study materials
JNCIS-MistAI-Wired study resources

802.1X and MAB for Phones and Badge Readers

JNCIS-MistAI-Wired · Put your knowledge to work in context.

All case studies

802.1X and MAB for Phones and Badge Readers

Riverbend Hospital is enabling wired 802.1X on 900 EX access ports using Mist Access Assurance as the RADIUS service. Clinical PCs use EAP-TLS with certificates. IP phones support 802.1X on current firmware, but 120 older phones only support MAC authentication bypass (MAB). Badge readers are MAB-only. Voice VLAN is 120, data VLAN 110, and guest VLAN 130. Wall ports have a phone with a PC pass-through in most clinical areas. The current pilot shows some phones landing in the guest VLAN, some PCs authenticating but losing the phone, and repeated reauthentication every 15 minutes. The security team wants failed devices to land in guest VLAN, not data VLAN, and wants the phone to stay on voice VLAN even if the PC fails authentication.

1. Design the authentication order and VLAN behavior for a wall port with a phone and a PC behind it. Include 802.1X, MAB, LLDP-MED, and RADIUS VLAN assignment.

Read the worked answer

Enable 802.1X on the port with multiple supplicants so the phone and PC can authenticate independently, and enable MAB fallback for older phones and badge readers. Enable LLDP-MED so the phone learns voice VLAN 120 and tags its voice traffic; the PC should remain untagged on data VLAN 110. RADIUS should return voice VLAN 120 for a recognized phone identity and data VLAN 110 for an authenticated PC. On authentication failure, return guest VLAN 130 for the PC. The phone must not be dragged into guest VLAN just because the PC fails; keep the phone's authenticated session and voice VLAN independent. For older phones, MAB should match the phone MAC or OUI and return voice VLAN. Test the order so MAB does not authenticate the PC as a phone and so 802.1X is preferred for capable devices. The port must carry tagged voice and untagged data, not a single flat VLAN.

2. Why might a phone authenticate as the PC and land in the wrong VLAN? How would you diagnose with Mist and switch CLI?

Read the worked answer

A phone with a PC pass-through may not relay EAPOL from the PC, or the switch may learn the PC MAC first and use it for MAB. If the RADIUS policy maps that MAC to a data VLAN, the phone's voice traffic is either untagged or tagged into the wrong segment. LLDP-MED may be missing, so the phone does not know to tag voice VLAN 120. In Mist, inspect the client list for the switch port and look for two MACs, one authenticated and one failed, plus the assigned VLAN and authentication method. Check LLDP neighbor data to confirm the phone model and voice capabilities. On the CLI, use show dot1x interface, show lldp neighbors, show ethernet-switching table, and authentication session details. If the phone is not identified, enable LLDP-MED, add a phone OUI or MAC policy in RADIUS, and use multiple supplicants so the phone and PC are treated separately.

3. What reauthentication and fail-VLAN settings would you change, and what is the risk?

Read the worked answer

The 15-minute reauthentication is too aggressive for wired PCs and phones and explains repeated authentication events. Lengthen reauthentication to 8-12 hours for PCs and 24 hours for phones, and use RADIUS Change of Authorization for immediate revocation when a certificate or device is disabled. Keep the fail VLAN as guest 130 for PCs, but ensure the phone's voice session is not forced to guest by the PC's failure. Validate that MAB-only devices are placed in the correct VLAN and that failed unknown devices cannot reach data VLAN 110. The risk of longer reauthentication is slower detection of a revoked but still-connected device; CoA and periodic posture checks offset that. Test in a pilot closet before changing all 900 ports, and monitor authentication failures, VLAN assignment, and phone registration after the change.