Troubleshoot › Symptom cases › Port Keeps Going Err-Disabled
Switching · Interfaces
Port Keeps Going Err-Disabled
Engineers search this as: 'port err-disabled link flap' · 'how to fix errdisable'
Evidence: Cisco documentation · Lab reproduction: in progress
In plain English: The switch shut one of its own ports off on purpose, to protect the network, because the link kept dropping and coming back. The port is the messenger, not the culprit. Find what makes the link flap, fix that first, and only then turn the port back on.
The symptom
A switch port shuts itself off. Everything plugged into it — a desk, a printer, a whole access point — goes offline. You re-enable the port and it works… for an hour, or a day, then it is down again. The log shows the switch disabled it on purpose: err-disable, cause link-flap.
%PM-4-ERR_DISABLE: link-flap error detected on Gi1/0/24, putting Gi1/0/24 in err-disable state
SW1# show interfaces status err-disabled
Port Name Status Reason ErrDisabled Vlans
Gi1/0/24 err-disabled link-flap
Check first — in this order
show interfaces status err-disabledThe full list of ports the switch has shut off. One port is a local fault; many ports at once is a bigger event.
show logging | include ERR_DISABLEThe recorded cause and the timeline. Disables at random hours suggest failing hardware; disables at 9 AM daily suggest a person or a docking station.
show interfaces Gi1/0/24 counters errorsClimbing CRC/input errors say the physical path is degrading. Clean counters with constant flapping point at the device on the other end dropping its link.
The swap sequence — cheapest firstNew patch cable. Then move to a spare switch port. Then a different end device if one is available. Where the problem stops following tells you which part was guilty.
Look at the other endCheck what is actually plugged in: a failing NIC, a laptop dock with power-saving, a small unmanaged switch under a desk, or a cable run damaged where it passes a door or a chair wheel.
What the evidence means
Err-disable is a protection, not a malfunction. For link-flap, the switch counts the link dropping and returning — 5 times in 10 seconds by default — and decides the port is unsafe to leave in service. So the port is the messenger. Re-enabling without finding what flaps is like resetting a breaker without finding the short: it works until it doesn't, and the log fills with the same warning.
Root causes, ranked
Root cause
How you recognize it
Failing patch cable or termination
Flexed, kinked, run over by chairs, or terminated badly years ago. The number one cause, and the cheapest to test.
Failing optic or dirty fiber ends
On fiber-connected devices: an optic that is dying drops and recovers as it warms up and cools down.
The end device drops its own link
Bad NIC drivers, aggressive power management on docks and laptops, or a device rebooting itself repeatedly.
Physical reality
A cable being unplugged and replugged — cleaners, shared desks, a kiosk someone keeps moving. The log times give this away.
Before you touch production: Re-enabling the port restores service to everything plugged into it — and if the physical fault is still live, it can flap and shut off again at the worst possible moment. Fix the cause first, then re-enable.
The fix
Replace the patch cable first. If errors continue, clean or replace the optic and fiber patch lead.
Move the run to a spare switch port to separate 'switch hardware' from 'everything past the wall jack'.
Re-enable the port (shut, then no shut) only after the physical cause is addressed, then watch the log for a full day.
Resist automatic recovery as the 'fix'. 'errdisable recovery cause link-flap' has a place after the cause is known, with a long interval — as a bandage during a parts wait, not as the cure.
Verify it worked
show interfaces status err-disabledThe list is empty and stays empty.
show logging | include ERR_DISABLENo new entries for at least 24 hours of normal use.
show interfaces Gi1/0/24 counters errorsError counters have stopped climbing — note the current numbers and compare tomorrow.
Did this fix it for you? One tap — anonymous, nothing to type, and nothing you send is ever published.
Which cause was yours?
Thanks — your tap helps the next engineer. A run of "still broken" reports sends this page back to the top of our re-check list.
Going deeper — production notes
Swipe sideways to see the full diagram →
The syslog line names the culprit. Five reason strings, five different faults, five different playbooks — read the label before touching the port.
The reason string is the diagnosis
The reason string is the diagnosis. 'show interfaces status err-disabled' names the cause per port — link-flap is this case, but the same shutdown arrives with other labels and each has its own playbook: bpduguard (a spanning-tree message arrived on an access port), udld (one-way link), loopback (the switch heard its own keepalive come back), psecure-violation (port security). Two of those labels have their own decoder entries. Treat the label as the first branch of the tree, not a footnote.
Desk port vs uplink
Severity depends on what the port carries. An err-disabled desk port is a ticket. An err-disabled uplink between switches is a severity-one pattern: whatever shut it — UDLD and loopback especially — was protecting the network from a loop or a black hole, and re-enabling it without understanding it can take the whole LAN down. On uplinks, identify the cause before the port comes back. Every time.
Read the settings first
Read the settings before touching the port: 'show errdisable detect' lists which causes your switch watches — and whether a predecessor disabled any of them, a common landmine. 'show errdisable recovery' shows whether automatic recovery is armed and at what interval (300 seconds by default when enabled).
Auto-recovery: use and abuse
Automatic recovery has one legitimate use: after the physical cause is fixed, it saves walking to every closet switch by hand. The abuse is enabling it first — the port then flaps on a timer, user complaints turn into 'the network drops every five minutes', and the original fault never gets found.
Alert on the first event
Alert on the event, not the aftermath. The %PM-4-ERR_DISABLE family of syslog lines should create a ticket the moment one fires — it is a free early-warning system for dying cables, failing optics, and unauthorized switches, and it only works if someone sees the first occurrence rather than the fiftieth.
The vendor-case bundle
If you open a vendor case, collect: the exact syslog lines with timestamps, 'show interfaces status err-disabled', 'show errdisable detect', and the interface error counters. That bundle gives TAC the cause, the timeline, and the physical evidence without a single callback.
Same event, very different urgency
Desk portA ticket. One user down — fix it today, calmly.
Uplink between switchesSeverity one. The shutdown was protecting the whole LAN — find the cause before the port comes back.
Reproduce this failure: Packet Path's hands-on labs run this class of fault in a simulated network, so you can break it, run the checks above, and fix it there before touching production. Open the labs.
Prevention
Leave errdisable detection ON — it has saved more networks than it has inconvenienced.
Alert on err-disable events instead of auto-recovering them silently; each event is a free early-warning ticket.
Keep known-good spare patch cables and optics at each site; the fix for the top cause costs a few dollars.
Still stuck? Before you open a TAC case
Work this ladder before you open a case. Err-disable is the switch protecting you — the fault is almost always physical, and physical faults are proven by swapping, not by opening tickets.
The last checks — the ones that close most "unsolvable" cases
The ten-minute physical swap, in this order: known-good cable, known-good optic, different switch port. The physical layer causes most of this fault class — eliminate it before touching software again.
Move the device, not the config: plug the same end device into a different switch. Fault follows the device — the device, its NIC, or its driver is guilty. Fault stays on the port — the switch side is.
Hunt the pattern in the logs: search a month of syslog for ERR_DISABLE. One port, once — an accident. The same port weekly — a dying optic confessing slowly. Many ports at the same minute — a loop or a power event.
Read the optic's own diary: 'show interfaces transceiver details' (DOM readings). Low receive power or climbing temperature predicts the next flap days before it happens.
Check Cisco's field notices for your exact switch model and software train. There are documented defects where ports err-disable for reasons that are not real.
It really is a TAC case when
Ports err-disable for a reason you have proven cannot be true — UDLD on a verified two-way link, loopback with no loop. That is a sensor or software defect until proven otherwise.
The fault follows a line card or a stack member across known-good cables, optics, and end devices.
Error counters climb on a link carrying clean traffic from a verified known-good source. Hardware is confessing.
If you do open one, hand them this bundle
The exact syslog lines with timestamps — the first occurrence, not the fiftieth
'show interfaces status err-disabled', 'show errdisable detect', and the interface error counters
Transceiver DOM readings for the port, if it is optical
Your swap log: what you changed, in what order, and what happened each time. It is the single most valuable page in the case.