Voice VLAN Authentication Failure After RADIUS Failover
A campus uses Dell N3248PX-ON access switches with 802.1X for PCs and MAC Authentication Bypass (MAB) for IP phones. Phones are placed in voice VLAN 200 by a RADIUS Tunnel-Private-Group-ID; PCs land in VLAN 100. Two RADIUS servers are configured: 10.10.20.11 primary and 10.10.20.12 secondary. At 02:00 the primary fails. PCs reauthenticate successfully, but phones on 60 ports lose voice and fall to the guest VLAN 999. show dot1x interface shows MAB attempts being rejected by 10.10.20.12. The secondary server has the 802.1X policy but its MAB service was never enabled. The phones support LLDP-MED but do not have an 802.1X supplicant. The help desk wants to disable 802.1X on all phone ports until the primary is restored.
1. Why did the PCs survive the primary RADIUS failure while the phones did not? Frame the answer around authentication method and server selection, not just 'RADIUS is down'.
Read the worked answer
PCs use 802.1X, so when the primary stopped responding the switch failed over to the secondary, which has a valid 802.1X policy, and the PCs authenticated. Phones use MAB; the secondary RADIUS accepted the request but rejected it because MAB was not enabled or configured there. This is not a generic RADIUS outage; it is a policy inconsistency between servers exposed by failover. The guest VLAN 999 fallback is why phones still had link but not voice; they were authorized into the wrong VLAN. Check show radius-server, show dot1x interface, and the secondary server's MAB policy. Disabling 802.1X globally would restore phones but remove port security for every PC, so it is the wrong first move.
2. What immediate mitigation would restore voice service with the least security exposure, and what would you verify?
Read the worked answer
Keep 802.1X enabled. For the phone ports, use the switch's voice critical VLAN or auth-fail VLAN for voice VLAN 200, so a MAB failure authorizes phones into the voice VLAN rather than guest VLAN 999. If the platform supports per-port critical VLAN, apply it only to ports with known phones; otherwise use a maintenance window and a targeted port range, not the whole campus. Verify show dot1x interface shows the phones in VLAN 200, show vlan shows the correct ports, and a test call and LLDP-MED negotiation succeed. Also confirm PCs remain in VLAN 100. The tradeoff is that an unknown device on a phone port could land in voice VLAN 200, so pair the fallback with MAC limiting, port security, or a phone MAC OUI allow-list and monitor for violations.
3. What configuration and process changes prevent the next failover from repeating this?
Read the worked answer
Make the RADIUS servers functionally identical: enable MAB on the secondary, copy the Tunnel-Private-Group-ID and voice policy, and test both servers with a phone and a PC before production. Configure dead-server detection and reauthentication so the switch returns to the primary cleanly, and monitor RADIUS accept/reject counts per server. Use the same MAB and 802.1X policy in a configuration template pushed by automation, and include a failover test in change management. Add an alert for a spike in MAB rejects and for phones appearing in guest VLAN 999. If voice resilience is critical, design a voice critical VLAN as a deliberate, documented fallback, not as an improvised response.