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?
 Feb 6 04:37:26: RSTP(1): Gi1/0/51 rcvd info expired
 Feb 6 04:37:26: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/51 on VLAN0010
 Feb 6 04:37:26: RSTP(1): Gi1/0/51 is now designated  Feb 6 04:37:26: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/51 on VLAN0010  Feb 6 04:37:26: RSTP(1): initializing port Gi1/0/51  Feb 6 04:37:26: RSTP(1): updt roles, received superior bpdu on Gi1/0/51  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
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.
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.
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.
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"
Do you use Cisco DNA Center? Have you used and are you willing to provide your feedback in using the Cisco DNA Center help and documentation?
If so, we’d like you to complete the survey linked below. Your feedback will help provide more effective and easi...
Listen: https://smarturl.it/CCRS9E18Follow us: https://twitter.com/CiscoChampion Reaching the height of your career is no simple feat. It often requires a combination of pursuing the right education, building the right professional network and being ...
In a typical production SD-WAN deployment, we would probably have many remote sites connected via many different Internet connections to a centralized data center or a regional hub. In most regions in the world, Internet providers will always use some typ...