Phones Rebooting Every 90 Seconds

The port is only allowing one authenticated session at a time.

Sequence:

1. The phone boots, LLDP-MED advertises itself, the device profile matches it and (with block-until-profile-applied) the port is placed in voice VLAN 100. The phone then authenticates by MAB.
2. The PC behind the phone starts 802.1X. When it succeeds, the new session replaces the phone's session on the port because the port accepts a single client. The port's authorization state is recomputed from the newest client, so the VLAN becomes the PC's data VLAN.
3. The phone loses the voice VLAN, drops its LLDP-MED assignment, reboots, and around 90 seconds later re-authenticates by MAB - pushing the PC out in the mirror image of step 2.

That alternation in show port-access clients ('client deleted' between two MACs) is the fingerprint of session replacement, not a RADIUS fault. No CoA was sent, so the trigger is local port-access logic.

The property to change: allow more than one client session - raise the client limit to 2 with multi-domain semantics, so one voice device (identified by the device profile) and one data device can coexist. Put the phone's device profile in ignore mode for authentication purposes while still binding it to VLAN 100, and ensure LLDP-MED, not dynamic authorization for the PC, is what sets the voice VLAN.

Verify session coexistence first, VLAN correctness second.

• show port-access clients and show port-access clients detailed interface <port>: two entries should persist simultaneously - the phone identified as a voice/device-profile client in VLAN 100 and the PC as a data client in its authorized VLAN. The alternating 'client deleted' pattern must be gone for at least one full reauth cycle.
• show port-access device-profile: confirm the LLDP-MED profile matches, that its action is the intended ignore/bind behavior, and that block-until-profile-applied is set where you want it.
• show lldp neighbor-info: the phone must be seen with its MED capabilities so the profile can match deterministically rather than by MAC range.
• show port-access port-security interface all: check client counts and any err-disabled or unauthorized states.
• show vlan port <port> and a live check from the PC: PC in the data VLAN, phone in VLAN 100, both stable.

Run the pilot on two or three desks with a phone and PC, leave it a full business day including one 8-hour reauth, and watch for a reboot. Only then apply the template. Keep a rollback in the same window.

The risk: MAB authenticates a MAC address, and a MAC address is trivially spoofable. Anyone who reads the label on a printer, or captures a phone's MAC, can present it and inherit that device's authorization and VLAN. Here the risk is sharper because voice VLAN 100 is a flat segment reachable from every desk.

Containment, in order of value:

1. Scope MAB to the device types that need it. Use device profiles with LLDP-MED or vendor OUI matching so MAB is only attempted on ports where a known device class appears, rather than as a blanket fallback on every port.
2. Give unknown or failed authentications a quarantine role with a restrictive ACL and no inter-VLAN routing, rather than a data VLAN.
3. Add port security as a backstop: cap learned MACs per port (a phone plus a PC is two) and act on violation, which also catches a rogue switch plugged into a wall port.
4. Enable CoA so a device can be re-profiled and moved to quarantine without waiting for the 8-hour reauth.
5. Monitor: alert when a MAC authenticates on two ports, or when a MAC known as a phone authenticates from a desk that has never had one.

The trade-off is explicit: MAB is convenience with weak proof, so it must be paired with least-privilege roles and monitoring, never treated as authentication.