More on a Switch’s Layer 2 Interface Status

Thinking from the Interface Status Back to the Root Causes

Most people learn new technology by learning topics one at a time, and for each new topic, learning how it relates to the topics already learned. However, to pass the final at the end of a course, or to pass most Cisco cert exams at the end of your study, you need think from the opposite direction. For instance, you might have to think about all the things that might cause a certain status code, a certain failure, or a certain output from a command. This week we'll drill down on one such example: how to go from the interface "down/down" status on the show interfaces command (as also seen with the notconnect status in the show interface status command) to figuring out all the possible causes for that state.

(Check out last week's post for some lead-in info.) 

First, to do an exhaustive analysis of all reasons why a switch interface is down/down would take a good long while, and lots of space, and frankly may be a bit too much to do in blog format. However, I think it's manageable if we constrain the cases a bit. This will make it useful for those studying for CCNA and somewhat useful for those studying for CCNP.

Constraint 1: Focus on switch interfaces connected to a Cisco router.

Constraint 2: Consider physical interfaces only. Ignore VLAN interfaces, portchannels, and the like.

Constraint 3: The state "down/down" is different than "down/down (err-disabled)"

That last point requires some further explanation, which I'll add next. Then I'll get to the CCNA level reasons for down/down aka notconnect. 

Error States on Cisco Switch Interfaces

Some problems cause a switch to place a physical interface in the down/down state, but in other cases, the switch shows additional state information, in parenthesis, after the second word "down". For instance, with the port security feature (a CCNA topic), when a port security failure occurs, the switch changes the second interface state value to "down (err-disabled)". The following output snips show examples of just such a case:

S1#<strong>sh interfaces gi0/1</strong>
GigabitEthernet0/1 is down, line protocol is down (err-disabled)
S1#<strong>sh interfaces status err-disabled</strong>
Port      Name               Status       Reason
Gi0/1                        err-disabled psecure-violation

Note that the show interfaces status command not only lists "err-disabled" (a general category), but it lists the specific reason (psecure-violation in this case), which is shorthand for a port security violation.

Some conditions cause a simple "down/down" interface state, while others cause a "down/down (err-disabled)" state. Additionally, the interfaces behave differently based on these states as well. First, with default configuration, an interface in error disabled state recovers only after the configuration of a shutdown command and then a no shutdown command. An interface in down/down state can recover without the shut/no shut combination, assuming that the conditions that caused the failure have stopped.

For example, if in the figure from last week (repeated here), SW1's F0/4 interface, connected to router R1, was "down/down". Let's assume the reason for the down/down state on SW1 was that R1 is powered off. SW1's F0/4 would move to an up/up state if R1 were powered on and no other problems existed. However, if SW1's F0/4 were in a "down/down (err-disabled)" state due to port security, the root cause of the port security violation may change so it is no longer a violation, but SW1's F0/4 will remain in the error disabled state until the shut/no shut combination is configured on SW1's F0/4 interface.

Note that the above description assumes some default configuration. You can override the requirement for the shut/no shut with the switch errdisable detect command.

The First Dividing Line: Down/Down or Down/Down (Err-disabled)

Based on the above, one key task when troubleshooting a switch interface, based on interface state, is to ask whether the switch interface in a "down/down" state or whether the "err-disabled" code follows the second status code. The following figure shows a working list of causes for each.

The figure shows the more common features that cause an err-disabled state, but particularly for CCNP, when reviewing for SWITCH, it's worth the time to look more deeply. Dave Hucaby's SWITCH OCG book has a good description around page 53, based on the errdisable detect command. You can also look at the errdisable detect command help in Cisco command reference docs, which also list the reasons. Note that the more functional the switch, the longer list of features listed in the help. Here's one such example for a 3560-E.

Finally... Down/Down aka Notconnect for CCNA

The previous figure shows the complete list, best I can tell, of CCNA-level topics that can cause a switch physical interface to reach a down/down state on a Cisco switch. I'm not far enough along in analyzing the CCNP topics that might make the state down/down, so I'll defer that analysis. As usually, chime in if you have ideas or opinions.

Note that when you see down/down (and not err-disabled) in the output of show interfaces on a switch, that interface will always be in the notconnect state per the show interfaces status command. So, when I refer to the down/down state specifically, also consider the state to be "notconnect" per the other command.

The figure shows the list, but it's listed here if you wanted to copy/paste for your notes. Also, for each successive item, assume that the previous item is no longer a problem.

1) The cable is not connected to the switch

2) The cable is connected to the switch, but the other end of the cable is not connected to the other device

3) The cable is bad (physical problem)

4) The device at the other end of the cable is powered off

5) The device at the other end of the cable has its interface shutdown

6) The cable uses opposite pinouts (crossover when straight-thru is required, or vice-versa), and auto MDIX is disabled

7) Speed mismatch

Final Random Notes

We had some great ideas posted last week for possible failure reasons. Those included several in the list that cause the err-disabled state: port security, BPDU guard, power is oversubscribed for PoE.

(A special thanks to Bill, Matt, and Alex for posting last week related to this topic.)

Someone else had suggested that is R1 in the figure were misconfigured for trunking, it might cause SW1's F0/4 to go to down/down. I spent some time verifying my thoughts, and confirmed that the switch interface state remains up/up even with the attached router being misconfigured for trunking. At least I haven't found a combination that makes the switch interface fail. So, I'm still listing "router trunk misconfig" as not being a reason for a switch reaching down/down state. Anyone who sees different, please post!

That's it. Add to the list if anything else comes to mind!

Also... if you're using my ICND1 book to prep for CCENT, or CCNA, check out some new web pages at my Certskills web site that are meant to be helpful when reading the book!

Copyright © 2011 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022