Sooner or later, you'll encounter this error message. You will most likely never going to see it in your home or school lab. However, I am willing to bet that you will encounter this error message during your Networking career.
I will only talk about two errors, but there are other things that will cause the interfaces to go to err-disabled state. For more information, please click here.
The first error is the:
%PM-4-ERR_DISABLE: link-flap error detected on Fa0/1, putting Fa0/1 in err-disable state.
This error message basically tells you that the interface has been flapping (going up and down). "The interface is put into the errdisabled state if it flaps more than five times in 10 seconds" (Cisco, n.d.). Once the port goes to error disabled, the port basically is shutdown. So what do you need to fix this error? Well, you basically need to “bounce” the port. Bouncing the port means, issuing shutdown or shut (shortcut), then wait for couple of seconds and then issue the no shutdown or no shut command. Monitor the port for a while and see if it bounces or not. If it still port still bounces, then you may have a bad cable, mismatch duplex setting, or bad Gigabit Interface Converter (GBIC). Though, I suggest is to start replacing cable. Most of the time, replacing cable will permanently fix the problem, but there were times that the NIC (Network Interface Card) actually causes the problem.
Most of the time, if there’s a problem with the duplex mismatch, the error will actually state it. Unfortunately, I can’t seem to find the exact error message that will show up in the log. The usual fix for this is to set the duplex and speed settings to auto/auto. I have been seeing a lot of duplex mismatch lately with the 48-port Cisco 2960G series that we didn’t have problems with Cisco 2950 or 3560.
The last error that I am going to talk about is the:
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/1, putting Fa0/1 in err-disable state
Usually, the port configuration of the switch will be something like this:
interface FastEthernet 0/1
speed 100
duplex full
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable
Let me try to explain what those three commands mean. The first command is the switchport mode access, this basically tells the switch that this will be an access port, meaning the end device will not be a switch or a router so no trunking will be allowed. For security reasons, you want to statically specify each port as access, unless you need a port for a router or a switch. If you leave the port on default settings, you’re risking your network to get “hacked” by allowing DTP (Dynamic Trunking Protocol) to negotiate to a trunk port if the connected device is in trunk, dynamic desirable, or dynamic auto state, default is dynamic desirable. DTP is out of the scope for this post, so we’ll talk about it next time.
The second command is the spanning-tree portfast, this basically tells the switch to move the port from blocking state to forwarding state within 20 seconds. Have you ever looked at the LED of the switch port turn from dark (off) to amber or some people say orange when you connect your Ethernet cable? STP (Spanning Tree Protocol) is enabled by default in Cisco switches (maybe other switches as well) that means, it transitions from Disabled (some text will include it, however, this is actually not part of STP) to Forwarding. The transition actually lasts 50 seconds (blocking 20 seconds, listening 15 seconds, learning 15 seconds). Same as DTP, STP is out of scope for this post.
The command above is not recommended without spanning-tree bpduguard enable, which is the third command. Why? Because, once you issue the spanning-tree portfast you are pretty much disabling the STP on that port. With that being said, you’re risking your network of having a loop. Having a loop in your network will cause some weird network problems. One notable problem that you’re going to have is the broadcast storm. If bpduguard is enabled then you’re telling the switch that if for whatever reason that port receives a BPDU (Bridge Protocol Data Unit) message, immediately go to err-disabled state to prevent loop.
How do you tell if the ports went to err-disabled? There are several commands that you can use, but my favorite command is show int status. A sample output is something like this:
Switch# sh int status
Port Name Status Vlan Duplex Speed Type
Gi0/1 TEST_1 connected trunk full 1000 1000BaseSX
Gi1/2 disabled 1 auto 1000 No Gbic
Gi2/1 TEST_2 notconnect 2 auto 1000 1000BaseSX
Gi2/2 TEST_3 connected trunk full 1000 1000BaseSX
Gi2/3 TEST_4 disabled 111 auto 1000 No Gbic
Gi2/4 TEST_5 connected trunk full 1000 1000BaseSX
Gi2/5 TEST_6 err-disabled 111 full 1000 1000BaseSX
Gi2/6 TEST_7 connected trunk full 1000 1000BaseSX
If you can see above, the Gigabit Ethernet 2/5 went on error disabled. How would you know the reason of why it went to error disabled? Well, you can use the show log or the show int status err-disabled command, as shown below.
Switch# show int status err-disabled
Port Name Status Reason
Gi2/5 GIG/E 2/5 err-disabled bpduguard
----Output has been been deleted for simplicity-----
Switch# show log
----Output has been been deleted for simplicity-----
%PM-4-ERR_DISABLE: bpduguard error detected on Gi2/5, putting Gi2/5 in err-disable state
If the reason is bpduguard error, then bouncing the port usually won’t solve the problem. You will need to take out the spanning-tree bpduguard enable by issuing no spanning-tree bpduguard enable command. Make sure that whatever is connected to that port will not introduce a loop or you’ll have weird problems.
As usual, please feel free to post a comment or question. See you in my next post.
Reference:
Cisco (n.d.). Errdisable Port State Recovery on the Cisco IOS Platforms. Retrieved on May 13, 2009 from http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00806cd87b.shtml
Written By: Andr01d
"I know nothing except the fact of my ignorance" - Socrates
0 comments:
Post a Comment