HowToFixMe
Port Recovery

Juniper Switch Port stuck disabled by UDLD: How to Fix

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
VendorJuniper
Operating systemJunos OS
CategoryPort Recovery
Skill levelIntermediate to advanced
DIY-able?Yes with CLI access; some scenarios need JTAC + RMA.

What this guide covers

Resolve a Juniper switch port UDLD.

Cause + fix

Unidirectional link detected, usually a fibre cable or SFP fault. Replace one end.

CLI / commands

show interfaces terse
show interfaces ge-0/0/0 extensive

# Apply the fix above, then bounce the port:
configure
# (interface shutdown / no shutdown. vendor-specific)
commit

Avoid recurrence

Frequently asked questions

Will this work on my specific Junos OS version?

The procedure reflects current Junos OS behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.

Should I open a JTAC case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the Juniper official documentation?

https://kb.juniper.net/: search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

Related guides worth a look while you sort this one out:

References

Reference material, not professional advice. Validate against your specific Junos OS version and test in a non-production environment before applying.

Common patterns we see

When this symptom shows up on a Juniper device, three patterns repeat:

1. Recent firmware update changed behavior, the symptom started within a week of an OTA push. Rollback or wait for the hotfix. 2. Environmental trigger. temperature, humidity, line voltage, network changes. Look at what changed in the environment. 3. Cumulative wear, components like batteries, gaskets, fans degrade over time. Replace the consumable rather than chasing a software fix.

Knowing which pattern applies saves time on the wrong fix.

Before you start

A few things to confirm so the Juniper device fix goes cleanly:

How to confirm it's actually fixed

On a Juniper device, the test is rarely "reboot and see". Use this list:

Escalation guide

For a Juniper device, the right escalation depends on impact:

More frequently asked questions

Should I update firmware first or last?

Update firmware first if a release note specifically mentions your symptom. Otherwise, finish the troubleshooting flow first, then update; that way you can isolate whether the update or the underlying fix solved it.

What if the fix returns after a reboot?

Persistent fault returns mean either: a hardware fault (escalate), a configuration that's being overwritten by a sync source (check cloud profiles), or a regression in a recent firmware update (rollback).

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

Why is this happening on a brand-new unit?

Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.

Does this affect other devices on my network?

Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.

Topology deep dive, Juniper EX access switch in a BFSI floor

The Juniper EX4300/EX3400 access fleet I run for an NBFC in Lower Parel terminates 1,200 user ports across 14 IDF rooms, each room hanging off a pair of EX4600 aggregation switches via dual-homed 10G LAGs. The switch port stuck disabled by udld symptom usually arrives as a desk-phone or a trading turret going silent. The trader does not know the port; the floor coordinator does not know the switch; the only data I have at minute zero is the LDAP login name and a desk number on a Lower Parel floor plan.

The piece that matters: Juniper does not use the Cisco "errdisable" name, but the behaviour is identical. EX switches will disable a port for BPDU on a non-trunk, for storm-control thresholds, for MAC-limit hits, or for loop-detection events. Each cause writes a distinct log line that you can grep before you ever touch a cable. The lazy fix is clear ethernet-switching port-error and pray; the engineer fix is to identify the cause, fix the cause, then clear.

Cost frame for the people scoping projects: EX4300-48P landed cost on a recent BSE-cleared GeM tender was INR 3.85L, JNP-NDC AMC is INR 48,000 per year per switch, and the 1.5-hour SmartNet ProactiveCare upgrade for the BSE colo cage came to INR 6.2L for 24 switches in one PO line.

Configuration walkthrough. port-error diagnosis on EX

Juniper EX uses ethernet-switching port-error as the umbrella for what Cisco people call errdisable. The cause-specific commands are what give you the real root cause:

# What ports are currently disabled and why
show ethernet-switching interface ge-0/0/12 detail
show interfaces ge-0/0/12 extensive | match "Last flapped|Input errors|Output errors"

# BPDU guard / loop-detect events
show spanning-tree bpdu-block
show ethernet-switching layer2-protocol-tunneling
show log messages | match "BPDU|loop|MAC-limit|storm"

# Port security / MAC-limit
show ethernet-switching mac-learning-log
show ethernet-switching table interface ge-0/0/12

# Storm control
show interfaces ge-0/0/12 extensive | match "input rate|broadcast"

# Clear after you have logged the cause
clear ethernet-switching port-error interface ge-0/0/12

# Or auto-recovery with a timer
configure
set protocols layer2-control bpdu-block disable-timeout 300
commit

The disable-timeout knob is the one I push in every new BFSI deployment, it converts a permanent shutdown into a 5-minute pause and saves the 02:00 IST call-out from a desk-side user who plugged a personal switch into a trading floor port.

Troubleshooting commands by platform

The switch port stuck disabled by udld fault rarely lives in just one layer. Run these in order, time-aligned, so the JTAC engineer can correlate them later:

SRX side (security platform)

show version invoke-on all-routing-engines
show chassis routing-engine
show chassis cluster status
show chassis cluster information
show security flow session summary
show security policies hit-count
show security log

EX/QFX side (access/distribution)

show virtual-chassis status
show virtual-chassis vc-port
show interfaces diagnostics optics ge-0/0/24
show ethernet-switching table
show spanning-tree interface
show lacp interfaces

MX side (core)

show route summary
show bgp summary
show isis adjacency
show mpls lsp
show pfe statistics traffic

Cross-vendor reality check: at BFSI scale, your Juniper is one of 6 vendors in the same path. Cisco N9K leaf-spines for the DC fabric, Palo Alto VM-series for the Internet edge, F5 BIG-IP for app load-balance, Arista for the trading fabric, and Juniper SRX/EX for the branch. If a packet drops, you need the same time-aligned capture from every device. I keep a capture-everything.sh wrapper on the bastion that fans out to every box over SSH and dumps the show output into one timestamped folder.

India compliance and deployment notes

The switch port stuck disabled by udld ticket does not exist in a vacuum: it sits inside the audit trail your regulator will ask for. In Indian BFSI deployments, three frameworks touch this gear:

Procurement angle: SRX340 and SRX380 are both on the MeitY common-list of approved network gear for government and PSU deployments. GeM tender pricing for the SRX340 base bundle ran INR 4.85L on the last refresh I ran for a Karnataka PSU; SRX380 base bundle was INR 7.2L. SmartNet 24x7x4 renewals run INR 85,000 to INR 1.2L per year for the 340, INR 1.4L to INR 1.8L per year for the 380. AMC outside SmartNet, via a local Tier-2 SI, lands at about 60 to 70 percent of SmartNet pricing but the response SLA degrades from 4 hours to next-business-day in practice.

For the BSNL/MTNL backhaul leg, the L2 handoff is usually GigE on copper from the BSNL Exchange to the colo demarc. Tata Communications, Reliance Jio, and Airtel give you fibre handoff at the colo entry. Mixing copper handoff with the SRX ge-0/0/x port works fine, but the SFP/SFP+ choice on the BSNL side has been the cause of 3 of the last 11 "link flap" tickets I have closed: and the BSNL NOC will not admit it until you show the captured optic diagnostics from the Juniper side, which is why show interfaces diagnostics optics matters so much.

Real-world deployment I did, port disabled by udld

January 2026, a private bank's Lower Parel trading floor, 08:52 IST. peak login storm. A floor coordinator phoned: "row 14 desk 7 is dead." I had remote SSH into the EX4300 inside 90 seconds (the bastion latency in Mumbai is forgiving). show ethernet-switching interface ge-0/0/24 detail confirmed the port state was disabled, cause logged in show log messages | match BPDU. The user had plugged a 5-port unmanaged switch under the desk, which started transmitting BPDU that the trunk did not expect.

Fix sequence: walked the floor coordinator through unplugging the rogue switch over WhatsApp call (took 90 seconds, the user was furious for 60 of them), then clear ethernet-switching port-error interface ge-0/0/24 on the switch. Port came up in 3 seconds. Total downtime: 7 minutes 14 seconds. Wrote up the incident note same morning, recommended set protocols layer2-control bpdu-block disable-timeout 300 for the whole access fleet so future switch port stuck disabled by udld events auto-recover. CISO approved that change in the next change window, rolled to 38 switches over 4 days.

Extended FAQs

Why does Juniper EX use "port-error" instead of "errdisable"?

Historical naming. The behaviour matches Cisco errdisable nearly one-for-one: a protection mechanism trips, the port goes down, and stays down until you clear it or a timer expires. Junos splits the causes into spanning-tree, MAC-limit, loop-detect, storm-control, and link-flap event categories. The switch port stuck disabled by udld log entry names the cause directly.

How do I auto-recover ports without manual intervention?

Set disable-timeout under each protection stanza. For bpdu-block: set protocols layer2-control bpdu-block disable-timeout 300. For loop-detect: set protocols loop-detect interface ... disable-timeout 300. 300 seconds is the value I push by default across BFSI access fleets, long enough to deter abuse, short enough to not strand a working user.

Does clearing the port erase the log entry?

No. Logs persist in /var/log/messages, in the RSI bundle, and in any external syslog destination. The clear command only re-enables the port. This matters for the audit trail: never delete the log before the auditor sees it.