A switch interface that shows as 'down' is one of the most common and frustrating problems for network engineers, and it's a favorite topic on the CCNA 200-301 exam (Exam Objective 1.3: Troubleshoot Interface and Cable Issues). Understanding why an interface is down—whether it's a physical cable fault, a misconfigured speed/duplex, or a protocol issue like errdisable—is fundamental to keeping a network operational. This chapter will give you a systematic approach to diagnosing and resolving switch interface down conditions, just as you would in a real enterprise network.
Jump to a section
Imagine you work in a secure office building, and you need to enter a colleague's office. The door has an electronic lock that requires both a keycard and a physical key to open. The door being 'down' is like the interface being down—you can't communicate. First, you check if the door is physically closed (cable plugged in). If it's closed but still won't open, you check the keycard reader (speed/duplex mismatch). The reader might be set to accept only magnetic stripes, but your keycard uses RFID—so no communication. Next, you check the physical key (cable type: straight-through vs. crossover). If the key is wrong, the lock won't turn. Then, you check the lock's internal mechanism (interface errors like CRC or runts). If the lock is jammed from too many wrong attempts (errdisable due to port security or BPDU guard), you need to manually reset it. Finally, you check the building's central security system (switch configuration: VLAN, trunking, or spanning-tree). If the system thinks the door is not connected (no link beat), it won't even try to unlock. This analogy mirrors the layered troubleshooting approach: physical layer (cable, power), data link layer (speed/duplex, VLAN mismatch), and higher-level protocols (spanning-tree, errdisable).
What is an Interface Down State?
When a switch interface is 'down', it means the physical layer (Layer 1) is not receiving a signal (link beat) from the connected device, or the data link layer (Layer 2) has detected an issue that prevents the interface from being operational. The interface status in Cisco IOS is shown as 'down/down' (line protocol down) or 'up/down' (line protocol down while physical is up). The two most common states are: - administratively down: The interface has been shut down manually with the 'shutdown' command. - down/down: No physical link (cable unplugged, bad cable, device powered off). - up/down: Physical link is good, but Line Protocol is down—often due to Layer 2 issues like no keepalives, speed/duplex mismatch, or VLAN mismatch. - errdisable: The interface has been automatically disabled due to an error (e.g., port security violation, BPDU guard, UDLD, or loop guard).
How to Check Interface Status
The primary command is show interfaces [interface-id] status. For example:
Switch# show interfaces gigabitEthernet 0/1 status
Port Name Status Vlan Duplex Speed Type
Gi0/1 notconnect 1 auto auto 10/100/1000BaseTX'notconnect' means the cable is unplugged or the other device is off. 'err-disabled' means the interface was disabled by a security feature. 'disabled' means it's administratively down.
For more detail, use show interfaces [interface-id]:
Switch# show interfaces gigabitEthernet 0/1
GigabitEthernet0/1 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is 0011.2233.4455 (bia 0011.2233.4455)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed, 1000BaseTX/FX
input errors: 0, CRC 0, frame 0, overrun 0, ignored 0
output errors: 0, collisions 0, interface resets 0
...Physical Layer Issues (Layer 1)
The most basic cause: no link. Check:
Cable is plugged in securely.
Cable type is correct (straight-through for end devices, crossover for switch-to-switch unless Auto MDI-X is enabled—most modern switches have this).
Cable is not damaged (use a cable tester or swap with known-good cable).
Remote device is powered on and its interface is not administratively down.
Distance limits: Ethernet has maximum cable lengths (100 meters for twisted-pair).
Speed and Duplex Mismatch
This is a classic CCNA trap. If one side is set to 100/full and the other to auto/auto, the auto side will detect speed via auto-negotiation (because speed is signaled via the cable) but duplex defaults to half when negotiation fails. This causes an 'up/down' state or high error rates (collisions, CRC errors).
Default: All modern Cisco switches have speed auto and duplex auto. If you manually set speed/duplex on one side, the other side must also be manually set to match, or both must be auto. Never mix manual and auto.
VLAN and Trunking Issues
If the interface is a trunk, the native VLAN must match on both ends. A mismatch can cause the interface to appear up but not pass traffic, or even cause the interface to go down due to spanning-tree inconsistencies.
For access ports, the VLAN must exist in the VLAN database. If the VLAN is deleted, the interface will show 'up/down' because the VLAN is not active.
Spanning Tree Protocol (STP)
STP can place a port in blocking state to prevent loops. This is normal, but if you expect the port to be forwarding, check the STP state with show spanning-tree interface [interface-id]. Common causes: BPDU guard (errdisable), PortFast not enabled on access ports (causing delay), or loop guard.
errdisable Recovery
When an interface goes into errdisable, it stays down until manually recovered (shutdown/no shutdown) or automatically recovered if errdisable recovery is configured. Common causes:
Port security violation
BPDU guard
UDLD (Unidirectional Link Detection)
Loop guard
Link flap (interface flapping too fast)
Check errdisable with:
Switch# show interfaces status err-disabled
Port Name Status Reason
Gi0/1 err-disabled psecure-violationTo recover:
Switch(config)# interface gigabitEthernet 0/1
Switch(config-if)# shutdown
Switch(config-if)# no shutdownOr configure automatic recovery:
Switch(config)# errdisable recovery cause all
Switch(config)# errdisable recovery interval 300Cable and Connector Issues
Bent pins in RJ45 connector
Faulty patch panel
Interference from electrical cables
Fiber: dirty connectors, wrong mode (single-mode vs multimode), wrong wavelength
Keepalives
By default, Cisco switches send keepalive frames every 10 seconds on Ethernet interfaces. If keepalives are disabled on one side, the interface may stay up but line protocol may go down. Use no keepalive to disable (rare).
Logging and Debugging
Use show logging to see interface up/down messages. For real-time troubleshooting, debug event-trace pm or debug interface [interface-id] can show state changes, but use with caution in production.
Summary of States
administratively down: shutdown command.
down/down: Physical layer problem.
up/down: Layer 2 problem (speed/duplex, VLAN missing, keepalive, etc.).
errdisable: Error condition.
up/up: Operational.
Check interface status
Use `show interfaces status` to quickly see the status of all interfaces. Look for keywords: 'notconnect', 'err-disabled', 'disabled', 'down'. For a specific interface, use `show interfaces [interface-id]`. Example output: 'GigabitEthernet0/1 is down, line protocol is down (notconnect)'. This tells you the physical link is absent. If the output says 'up, line protocol is down', the physical link is good but Layer 2 is broken. If it says 'administratively down', the interface was shut down manually.
Verify physical connectivity
If the status is 'down/down' or 'notconnect', check the cable. Ensure it is plugged in securely at both ends. Try a known-good cable. Check that the connected device is powered on and its interface is not administratively down. For fiber, inspect the connectors for dirt and ensure the transmit and receive are not crossed. Use a cable tester if available. If using a patch panel, verify the patch cable is correctly patched.
Check speed and duplex settings
If the interface is 'up/down', the most common cause is a speed/duplex mismatch. Use `show interfaces [interface-id]` to see the configured and actual speed/duplex. Look for 'Auto-negotiation' and 'Half-duplex' vs 'Full-duplex'. If one side is manually set and the other is auto, the auto side will default to half-duplex. The fix: set both sides to auto, or both to the same manual setting. On Cisco switches, use `speed 100` and `duplex full` under the interface, or `speed auto` and `duplex auto`.
Check VLAN and trunking
For an access port, verify the VLAN exists with `show vlan brief`. If the VLAN is missing, the interface will show 'up/down'. Create the VLAN with `vlan <vlan-id>`. For trunk ports, check native VLAN mismatch with `show interfaces trunk`. The native VLAN must match on both ends. Also check allowed VLAN lists. A common exam scenario: a trunk port is configured with `switchport trunk allowed vlan 10,20` but the other side expects all VLANs, causing traffic issues but not necessarily interface down.
Check for errdisable
If the status is 'err-disabled', use `show interfaces status err-disabled` to see the reason. Common causes: 'psecure-violation' (port security), 'bpduguard' (BPDU guard), 'udld' (UDLD), 'loopback' (loopback detection). To recover, enter interface configuration mode and do `shutdown` followed by `no shutdown`. To prevent recurrence, either fix the cause (e.g., increase port security maximum) or configure errdisable recovery with `errdisable recovery cause all` and `errdisable recovery interval 300`.
Check spanning-tree state
Even if the interface is 'up/up', it might not forward traffic due to STP blocking. Use `show spanning-tree interface [interface-id]` to see the port state. If it is in 'blocking' or 'listening' state, it will eventually transition to 'forwarding' (50 seconds by default). If you need immediate forwarding (e.g., for an access port), enable PortFast with `spanning-tree portfast` under the interface. Also check for BPDU guard: if enabled and a BPDU is received, the port goes into errdisable.
Verify with logs and debugs
Use `show logging` to see recent interface state changes. Look for messages like '%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down'. For deeper troubleshooting, you can use `debug interface [interface-id]` to see real-time state changes, but be cautious in production. Also, `debug ethernet-interface` can show negotiation details. Remember to disable debugging with `undebug all` when done.
In a large enterprise, switch interface issues are a daily occurrence. Consider a campus network with hundreds of access switches. A user reports no network connectivity. The network engineer SSHes into the access switch and runs show interfaces status. They see the user's port shows 'err-disabled'. The reason: 'psecure-violation'. This means the port security feature detected a MAC address change (maybe the user connected a personal router). The engineer can either increase the maximum MAC addresses or clear the violation with clear port-security sticky and then do shutdown/no shutdown. To prevent future issues, they might configure errdisable recovery cause psecure-violation with a 300-second interval so the port automatically recovers.
Another scenario: a new switch is installed in a wiring closet. After cabling, the uplink to the distribution switch shows 'up/down'. The engineer checks speed/duplex: the distribution switch has speed 1000 and duplex full hardcoded, but the new access switch has default auto. The fix is to set the access switch to manual 1000/full or change the distribution switch to auto. This is a classic mistake when network admins hardcode settings to 'stabilize' links but forget to configure the other end.
A third scenario: a server connected to a switch shows intermittent connectivity. show interfaces reveals many CRC errors and collisions. The speed/duplex is auto on both ends, but the server's NIC is faulty, causing negotiation to fail. The engineer manually sets speed and duplex on both sides to 1000/full, and the errors stop. In production, always try to use auto-negotiation unless there's a specific reason not to, as modern hardware handles it well.
Misconfiguration consequences: If an interface is accidentally shut down via shutdown, all users on that VLAN segment lose connectivity until it's re-enabled. If errdisable recovery is not configured, a port security violation can cause a permanent outage until a human intervenes. Always document interface configurations and have a standardized troubleshooting procedure.
The CCNA 200-301 exam tests your ability to troubleshoot interface and cable issues (Objective 1.3). Expect scenario-based questions where you are given a show interfaces output and asked to identify the cause. The most common traps:
Confusing 'up/down' with 'down/down': 'up/down' means physical layer is good (cable, device) but Layer 2 has a problem (speed/duplex, VLAN missing). Many candidates incorrectly replace the cable. The correct action is to check speed/duplex and VLAN.
Speed/duplex mismatch: You will see an interface with 'runts', 'giants', 'CRC errors', and 'collisions'. The wrong answer is to replace the cable. The correct answer is to set both sides to the same speed/duplex (preferably auto).
errdisable recovery: A question might ask: 'An interface is in errdisable state due to a port security violation. What must the administrator do to restore it?' The wrong answer is 'It will automatically recover after 300 seconds' (only if recovery is configured). The correct answer is 'Enter interface configuration mode and issue shutdown then no shutdown.'
VLAN missing: If an access port is assigned to VLAN 100 but VLAN 100 does not exist in the VLAN database, the interface shows 'up/down'. The wrong answer is 'Check the cable'. The correct answer is 'Create VLAN 100 or remove the interface from that VLAN.'
Native VLAN mismatch: On a trunk, if native VLAN differs, the interface stays up but can cause spanning-tree issues. The exam may show an output with 'native VLAN mismatch' in show interfaces trunk. The fix is to match the native VLAN on both ends.
Key values: Default STP timers: 2 sec hello, 15 sec forward delay, 20 sec max age. Default errdisable recovery interval: 300 seconds (if configured). Default port security maximum: 1 MAC address. Default violation mode: shutdown.
Decision rule: When troubleshooting an interface down, always start with show interfaces status to get the state. Then follow the OSI model: Layer 1 (cable, power), Layer 2 (speed/duplex, VLAN, STP, errdisable). Never skip steps.
The command `show interfaces status` quickly shows the state: notconnect, err-disabled, disabled, or up.
An interface showing 'up/down' indicates a Layer 2 problem, most commonly a speed/duplex mismatch or missing VLAN.
Speed/duplex mismatch causes CRC errors, runts, and collisions; always set both sides to auto or both to the same manual setting.
errdisable state requires manual recovery via shutdown/no shutdown unless automatic recovery is configured.
Port security violation (psecure-violation) is a common cause of errdisable; use `show interfaces status err-disabled` to see the reason.
A missing VLAN on an access port causes 'up/down'; create the VLAN or change the port to an existing VLAN.
Always check the cable first when status is 'down/down' or 'notconnect'.
The default keepalive interval on Ethernet interfaces is 10 seconds.
These come up on the exam all the time. Here's how to tell them apart.
down/down
Physical layer issue (cable, power, device off).
No link beat detected.
Check cable, replace cable, power on device.
Often no errors counters increment.
Example: 'GigabitEthernet0/1 is down, line protocol is down (notconnect)'
up/down
Layer 2 issue (speed/duplex, VLAN, keepalive).
Physical link is up (link beat detected).
Check speed/duplex settings, VLAN existence, keepalives.
May see CRC errors, runts, or collisions.
Example: 'GigabitEthernet0/1 is up, line protocol is down'
Mistake
'If an interface shows up/down, the cable must be bad.'
Correct
up/down means the physical layer is good (cable is fine) but the line protocol is down, often due to speed/duplex mismatch, VLAN missing, or keepalive issues.
Candidates confuse the two lines of output: 'is down' vs 'line protocol is down'.
Mistake
'An interface in errdisable state will recover automatically after a few minutes.'
Correct
By default, errdisable does not recover automatically. You must manually do shutdown/no shutdown, or configure errdisable recovery with the `errdisable recovery cause` command.
Some network devices do auto-recover, but Cisco switches require explicit configuration.
Mistake
'Setting speed and duplex manually on one side and auto on the other will work fine.'
Correct
If one side is manually set, the auto side will negotiate speed but will default to half-duplex, causing a mismatch. Both sides must be either auto or both manual with matching settings.
Candidates think auto-negotiation always works, but it fails when one side is forced.
Mistake
'A trunk port with native VLAN mismatch will cause the interface to go down.'
Correct
A native VLAN mismatch does not cause the interface to go down; it stays up but can cause spanning-tree issues or traffic black-holing. The interface status remains up/up.
Candidates assume any misconfiguration brings the interface down, but native VLAN mismatch is a subtle Layer 2 issue.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'notconnect' indicates that the interface has no physical link. This could be because the cable is unplugged, the cable is faulty, the connected device is powered off, or the cable is not properly seated. It is a Layer 1 issue. To troubleshoot, first check the cable and the remote device. If the cable is good and the device is on, try a different cable or port. On fiber, ensure the connectors are clean and the transmit/receive are not reversed.
To recover an interface from errdisable, you must manually bring it down and up. Enter interface configuration mode (e.g., 'interface gigabitEthernet 0/1'), then issue 'shutdown' followed by 'no shutdown'. Alternatively, you can configure automatic recovery using the 'errdisable recovery cause all' command under global configuration, which by default recovers after 300 seconds. The specific cause (e.g., 'psecure-violation') can be specified instead of 'all'.
'down/down' (e.g., 'GigabitEthernet0/1 is down, line protocol is down') means both the physical layer and the data link layer are down. This is usually a cable or power issue. 'up/down' (e.g., 'GigabitEthernet0/1 is up, line protocol is down') means the physical link is good (cable and device are working) but the line protocol at Layer 2 is not operational. Common causes: speed/duplex mismatch, VLAN not existing, keepalive mismatch, or spanning-tree blocking.
A speed/duplex mismatch often does not bring the interface down because the physical link remains up. However, it causes collisions, CRC errors, runts, and frame check sequence errors because one side is transmitting full-duplex while the other is expecting half-duplex (or vice versa). The interface stays up/up but with high error rates, leading to poor performance and retransmissions. The switch will not automatically shut down the port due to these errors (unless error conditions exceed thresholds).
Use the command 'show spanning-tree interface [interface-id]' to see the port's STP state. For example: 'show spanning-tree interface gigabitEthernet 0/1'. Look for 'Port State: blocking' or 'Port State: forwarding'. If it's blocking, the port is not forwarding traffic. To enable immediate forwarding on an access port, use 'spanning-tree portfast' under the interface. Note that PortFast should only be used on ports connected to end devices, not to other switches.
The default errdisable recovery interval is 300 seconds (5 minutes). This only applies if errdisable recovery has been enabled for a specific cause. By default, errdisable recovery is disabled for all causes, so interfaces in errdisable state will not recover automatically unless the administrator manually configures recovery or performs a shutdown/no shutdown. To enable automatic recovery, use 'errdisable recovery cause all' and optionally change the interval with 'errdisable recovery interval <seconds>'.
A native VLAN mismatch on a trunk does not cause the interface to go down; the interface remains up/up. However, it can cause spanning-tree issues (e.g., the port may go into errdisable due to BPDU guard if BPDUs are received on the wrong VLAN) or traffic black-holing. On an access port, if the assigned VLAN does not exist, the interface will show 'up/down' because the line protocol cannot come up without a valid VLAN.
You've just covered Troubleshoot: Switch Interface Down — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?