Re: spanning-tree explaination

zappo0305 · ‎02-05-2011

could some one please explain to me the following spaning-tree events? My understanding is that the switch did not receive the hello bpdu from the root bridge, therefore stp re-converge?

[1] Feb 6 04:37:26: RSTP(1): Gi1/0/51 rcvd info expired

[2] Feb 6 04:37:26: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/51 on VLAN0010

[3] Feb 6 04:37:26: RSTP(1): Gi1/0/51 is now designated
[4] Feb 6 04:37:26: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/51 on VLAN0010
[5] Feb 6 04:37:26: RSTP(1): initializing port Gi1/0/51
[6] Feb 6 04:37:26: RSTP(1): updt roles, received superior bpdu on Gi1/0/51
[7] Feb 6 04:37:26: RSTP(1): Gi1/0/51 is now alternate

This is Gi1/0/51 configuration:

interface GigabitEthernet1/0/51
description uplink to Root-Bridge
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200,300, x
switchport mode trunk
end

By default Gi1/0/51 is in blocking state:

Switch1# show spanning-tree

Gi1/0/51 Altn BLK 4 128.51 P2p

Any info would be greatly appreciated.

Shashank Singh · ‎02-05-2011

All ports participating in STP keep receving periodic BPDUs from the root switch (even BLK state) when STP is stable.These logs are an indication of the fact that gi1/0/51 did not receive BPDUs from the root for sometime. If we did not have loop guard configured on the switch, gi1/0/51 would have moved to FWD state.

However, loop guard feature makes additional checks when BPDUs are missed on an interface. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.

This is explained at

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml

However, the port moved to its correct state (BLK) when is started receiving BPDUs.

To understand why this port missed BPDUs we need to investigate on a possible poor L2 connectivity of this switch to the root (speed, duplex, physical layer issues) or high CPU utilization on any intermediate switch etc.

Hope this helps,

Shashank

P.S Please rate helpful posts.

hostmaster · ‎03-18-2012

I started seeing the exact same symptoms that Zappo described. Mine are unusual in that they typically occur at the exact time each day and recovers quickly after 1s. The interfaces are 1000BaseSX (fiber), so I've ruled out the janitors firing up a vacuum cleaner or lights going on/off that could cause EMI so consitently. This might be fiber or GBICs going bad.

I've logged a lot more events than these and they usually occur just past 23:00, but here's a recent snippet. I've enabled debug span events (as it appears Zappo had done) and debug span events snapshot too on a few key switches. Any other suggestions before I clean/replace the fiber or GBICs (after I confirm I'm missing BPDUs)? I already have udld port aggressive and logging event link-status and they are not logging anything.

Mar 15 10:02:10.436 PDT: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet3/2 on VLAN0009.

Mar 15 10:02:11.436 PDT: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet3/2 on VLAN0009.

Mar 15 14:58:13.333 PDT: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet3/2 on VLAN0009.

Mar 15 14:58:14.329 PDT: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet3/2 on VLAN0009.

Mar 16 23:02:07.122 PDT: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet3/2 on VLAN0009.

Mar 16 23:02:08.118 PDT: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet3/2 on VLAN0009.

Mar 17 23:02:16.731 PDT: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet3/2 on VLAN0009.

Mar 17 23:02:17.727 PDT: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet3/2 on VLAN0009.

I recommend logging with msec to clearly see the timing of events: service timestamps log datetime msec localtime show-timezone

Only this VLAN9 is logged. There are a couple of other active VLANs on this trunk, but only VL9 has active ports downstream *and* is normally in a STP Altn BLK role/status; Desg ports or those in Altn BLK without active downstream ports in other VLANs are not logged. Switch is in pvst mode.

sdheer · ‎02-05-2011

Hi,

The above messages just means that gig 1/0/51 failed to recieve a periodic BPDU ,due to which it should have changed its state to forwarding but due to the "loopgaurd" fature it didnt do so and reatined its blocking state.

The main point ot be focussed it why gig 1/0/51 failed to recieve BPDU there could be many resons for the same such as

>> link failure

>> layer 2 loop in network

To find out the cuase of the same as preliminary measure two things could be done

>> enable udld using command "udld mode aggressive" on both ends on a link.

>> enable mac flap notification using command " mac address-table notification mac-move"

Hope it helps.

Regards,

Swati

Please rate the useful information