802.1X and MAB Rollout with Legacy Controllers and Shared Phone Ports
Your company is deploying 802.1X and MAB on 60 Catalyst access switches with Cisco ISE. The endpoint inventory includes 3,000 Windows laptops with a supplicant, 900 printers and cameras that support only MAB, 200 legacy controllers with no supplicant and no documented MAC addresses, and 150 IP phones. The business requires that corporate laptops land in VLAN 100, IoT devices in VLAN 200, and unknown devices in a quarantine VLAN 999 with limited access. Some wiring closets serve a single office with a laptop and an IP phone on the same port. The current network is open, and a failed authentication must not take down the phone. You have a six-week change window and cannot replace hardware.
1. Design the authentication and authorization order for a port that may have an IP phone and a laptop. State the fail policy.
Read the worked answer
Use multi-domain authentication. The voice domain authenticates the phone first, using CDP or LLDP to identify it and MAB or 802.1X as the method; the data domain then authenticates the laptop with 802.1X and MAB as fallback. Configure authentication order dot1x mab, host-mode multi-domain, and a voice VLAN so the phone is placed correctly before the data session is authorized. For fail policy, do not use a single closed-mode policy that can disable the phone. Put the voice domain in a critical VLAN or critical authorization profile that permits the phone to reach its call control even if ISE is unreachable. Put the data domain in closed mode after the pilot, with unknown or failed laptops falling to quarantine VLAN 999 rather than VLAN 100. Test with show authentication sessions interface and verify that a laptop failure does not change the phone's authorization. This separates voice availability from data enforcement.
2. How do you handle 200 legacy controllers with unknown MAC addresses without creating a security hole?
Read the worked answer
Do not create a blanket MAB allow rule for unknown MACs. First run monitor mode on the relevant closets for two weeks and collect MAC addresses from the switch MAC tables and ISE endpoint database. Group the controllers by function and required destination, then create static MAB entries and an authorization profile that places them in a dedicated legacy VLAN with a dACL permitting only the specific controller and management destinations. If a MAC is still unknown, let it fall to quarantine VLAN 999, where an administrator can validate it before adding it to the allow list. Use profiling where possible to corroborate the MAC, but do not rely on MAC alone as a security control. Segment the legacy controllers from user and IoT VLANs so that a spoofed MAC gains only the limited legacy access. Document the exception and set a review date. This keeps the rollout moving without opening a permit-any-MAB hole.
3. What migration sequence and ISE policy set would you use to avoid an outage?
Read the worked answer
Use monitor mode, then low-impact mode, then closed mode. In monitor mode, enable authentication but do not enforce VLAN or dACL changes; collect endpoints, MACs, and authentication results for at least two weeks. Build ISE policy sets for corporate laptops, IoT, voice, legacy controllers, and unknown devices, with authorization profiles for VLAN 100, VLAN 200, a voice critical VLAN, the legacy VLAN, and quarantine VLAN 999. Pilot low-impact mode in a few closets, using dACLs and VLAN override only for known-good endpoints, and verify CoA, reauthentication, and phone behavior. Then move to closed mode building by building. Keep a critical VLAN for voice and a documented fail-open or quarantine fallback for data, and test rollback by disabling 802.1X on one pilot port. Use show authentication sessions, ISE live logs, and switch syslog to confirm results before each wave.