Getting error history for a particular interface

[7387]

Hello,

I had some ports /interfaces  go into err-disable. when I checked the reason i found out it was bpduguard. I was trying to determine when that actually happened, but i cannot seem to find the right command or commands to get that information from a particular interface.  example Gi1/0/24 is one of the ones I am interested in, are their particular port/ interface history type commands? or is it as matter of stringing a few commands together. Any Input would be greatly appreciated.

Thanks!!

[MHM Cisco World]

VLAN0001 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 1, address aabb.cc00.0100
Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 17 last change occurred 00:01:41 ago <<- check this time
from Ethernet0/0 <<- check if this interface is what recovery from err-disable 
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300

[7387]

Hello and thank you for the quick response!!

what command did you use to generate that output ?

[MHM Cisco World]

show spanning tree detail 

[Peter Paluch]

Hello MHM,

I am afraid that what you suggested would lead to misleading conclusions. The topology changes reported by STP are more general events than just ports coming up or down. You perhaps remember that for STP, a topology change event is one of four possible events:

1. non-edge port becoming Forwarding and the switch having at least one Designated port
2. non-edge Learning or Forwarding port becoming Blocking
3. TCN received
4. becoming the new root switch

For RSTP, a topology change event occurs in two cases:

1. non-edge port becomes Forwarding
2. BPDU with TC flag is received

Hence, the information in the show spanning-tree detail you highlighted, depending on the STP version you're running, refers to any of the events above, and may be entirely independent of a port getting err-disabled. Especially with RSTP, a port getting err-disabled won't register as a topology change.

To trace the events that lead to a port become err-disabled, and their timing, I would not use the show spanning-tree detail command as that one speaks about different types of topology change events. Here, the show logging is usually sufficient and self-explanatory.

Best regards,
Peter

[MHM Cisco World]

That totally true, his log not show the err-disable and hence we can not see when it happened. 
so two methods I know if I am correct 
depend on STP <<- as I mention above 
or show interface x/x <<- check the last input/last output since the port go to errdisbale and up again then this also can give us time where is UP again. 

[Peter Paluch]

Hello,

Events causing ports to go to err-disabled state are usually logged. My first recommendation is to simply verify the show logging output. It may be wise to make sure that the locally kept logging buffer is sufficiently large by configuring

logging buffered 1000000 6

This will allocate 1MB of RAM for all logging messages, starting with the importance (severity) of informational (6).

Best regards,
Peter

[7387]

Thank you Mr. Paluch, for your speedy reply.

What I am trying to do is see the information for the interface below. to see if I can determine when it happened. 

F2Z2#sh interface status err-disabled

Port Name Status Reason Err-disabled Vlans
Gi1/0/24 err-disabled bpduguard

[Peter Paluch]

Hello,

As I mentioned, show logging would be your friend : )

Sw2# show logging
[snip]
*Feb 14 21:44:17.811: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Et0/1 with BPDU Guard enabled. Disabling port.
*Feb 14 21:44:17.811: %PM-4-ERR_DISABLE: bpduguard error detected on Et0/1, putting Et0/1 in err-disable state
*Feb 14 21:44:19.436: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to down

If a port gets err-disabled, the switch will log an event message about it like the one shown above. That's what you're looking for.

Best regards,
Peter

[7387]

Thank you good sir, and apologies I misunderstood. I ran it the first time as you suggested and I got the output below in which I did not see the interface i was interested in. I just assumed that there was another method for drilling down into the interface information. 

Feb 14 21:37:36.249: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet4/0/46, changed state to down
Feb 14 21:37:37.255: %LINK-3-UPDOWN: Interface GigabitEthernet4/0/46, changed state to down
Feb 14 21:37:49.670: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet5/0/16, changed state to down
Feb 14 21:37:50.675: %LINK-3-UPDOWN: Interface GigabitEthernet5/0/16, changed state to down
Feb 14 21:37:53.407: %LINK-3-UPDOWN: Interface GigabitEthernet5/0/16, changed state to up

[MHM Cisco World]

*Oct 5 02:41:21.830: %PM-4-ERR_DISABLE: bpduguard error detected on Gi1/0/1, putting Gi1/0/1 in err-disable state
I think your log level not include level 4 waring that why you dont see it. 

[Peter Paluch]

Hello,

It may be that the logs for the err-disabled interface are located earlier in the output - or the system is so noisy that the logs have already been pushed out. The default size of the logging buffer is 4096 bytes so it gets rolled over rather quickly. That is why I suggested increasing the logging buffer size in my first answer.

@MHM Cisco World , if you check the outputs from @7387 carefully, there are already sev 5 messages present - hence sev 4 and lower messages must be automatically included too.

Best regards,
Peter

[MHM Cisco World]

Thanks a lot.