Not receiving BPDUs...but only for certain VLANs?

[johnnylingo]

Topology - 6500s at the Core, connected by 20 GB EtherChannel.   2950s at the access layer, all connected to the core via 2 GB EtherChannels.  The cores have about 80 VLANs, and each access switch has between 5-10 (VTP is not used).   All switches run Rapid PVST. 

What we've observed in a few cases is that the access switches don't receive BPDUs from one (or both) or the Core Switches, but only for certain VLANs.   These VLANs are allowed in the Trunk (EtherChannels) on both the access and Core side.

We have noticed the root bridge configuration for these VLANs was a bit off, because one of the server distribution switches was configured as root.  However, under RSTP, all bridges should be sending BPDUs, so that still doesn't explain the behavior.

We're working with TAC, but this has been a head-scratcher and wonder if anyone else had encountered anything like this.  Loopguard is enabled on the cores, but not the access switches, so we don't know exactly when the problem started.

[Giuseppe Larosa]

Hello Johnny,

loop guard should be configured also on access layer switches side as described in configuration guides.

in some of our campuses with STP loop guard enabled on all sides of links (including distribution to distribution links) we see sometimes STP loop guard reacting to missing STP BPDUs for specific vlans and then automatically recovering.

We had also a specific issue with WS-6708 10GE linecards where moving to a newer IOS image (from 12.2(18)SXF to 12.2(33)SXH2) provides some benefits and a reduction of this kind of events (STP loop guard events)

In your case do you see constant missing of these BPDUs over time? or they are missing and then they appear again?

also be very careful with debug spanning-tree commands that can make device unusable (it happened indeed)

Cisco TAC had suggested us to setup a local SPAN session in order to see if STP BDPUs were really missing or not when the access layer switch (c4500) was complaining. (STP loop guard events )

I guess they are suggesting  the same to you.

Hope to help

Giuseppe

[johnnylingo]

Yes, Loopguard on the access switches would have been nice, since it would have told when this started happening.  Unfortunately I'm inheriting the network and it hadn't been configured (yet).

I've run in to situations in the past where BPDUs aren't received in time, causing STP to re-calculate.  This is different because they aren't being received by the access switch at all for a certain VLAN, but like I said, I don't know exactly when or why this started happening.   

Here's a sample "debug spanning-tree bpdu receive" from an access switch. Note that BPDUs for VLAN 999 are only received on Po1, but not Po2.

Mar 28 08:48:44.854: RSTP(200): Po1 repeated msg
Mar 28 08:48:44.858: RSTP(200): Po1 rcvd info remaining 6
Mar 28 08:48:44.870: RSTP(500): Po1 repeated msg
Mar 28 08:48:44.870: RSTP(500): Po1 rcvd info remaining 6
Mar 28 08:48:44.882: RSTP(999): Po1 repeated msg
Mar 28 08:48:44.882: RSTP(999): Po1 rcvd info remaining 6
Mar 28 08:48:46.566: RSTP(500): Po2 repeated msg
Mar 28 08:48:46.566: RSTP(500): Po2 rcvd info remaining 6
Mar 28 08:48:46.578: RSTP(200): Po2 repeated msg
Mar 28 08:48:46.578: RSTP(200): Po2 rcvd info remaining 6
Mar 28 08:48:46.802: RSTP(200): Po1 repeated msg

Mar 28 08:48:46.802: RSTP(200): Po1 rcvd info remaining 6
Mar 28 08:48:46.814: RSTP(500): Po1 repeated msg
Mar 28 08:48:46.814: RSTP(500): Po1 rcvd info remaining 6
Mar 28 08:48:46.826: RSTP(999): Po1 repeated msg
Mar 28 08:48:46.826: RSTP(999): Po1 rcvd info remaining 6

Po1 is the root port, Po2 *should* be seen as Alt and put in to blocking state.  But since no BPDUs are seen, that never occurs.

[johnnylingo]

Think I figured out part of the problem.  The secondary core switch (on Po2) has "spanning-tree uplinkfast" configured.   This would cause all it to add 3,000 to all costs, and ports in blocking state which normally would be desg.   A port in blocking state does not send BPDUs if I recall.

[Alexander Proskurnin]

Hello johnnylingo

I have the same issue with rstp. I had not find your question and started mine https://supportforums.cisco.com/thread/2057616?tstart=0.

Does you resolve the problem?

Root switch sends BPDUs successfully but some other switches does not receive BPDUs for certain vlans.

172.16.2.2 69053: Dec 24 07:49:08.077 MSK: RSTP(2303): sending BPDU out Po1
172.16.2.2 69054: Dec 24 07:49:08.077 MSK: RSTP(2303): sending BPDU out Po22
172.16.2.2 69055: Dec 24 07:49:08.081 MSK: RSTP(2316): sending BPDU out Po1
172.16.2.2 69056: Dec 24 07:49:08.081 MSK: RSTP(2316): sending BPDU out Po22

172.16.1.100 239007: Dec 24 07:49:08.200 MSK: SP: RSTP(2303): Po1 rcvd info remaining 6
172.16.1.100 239008: Dec 24 07:49:08.204 MSK: SP: STP: VLAN2316 rx BPDU: config protocol = rstp, packet from Port-channel1
172.16.1.100 239012: Dec 24 07:49:08.204 MSK: SP: RSTP(2316): Po1 repeated msg
172.16.1.100 239013: Dec 24 07:49:08.204 MSK: SP: RSTP(2316): Po1 rcvd info remaining 6

172.16.2.1 306789: Dec 24 07:49:10.081 MSK: STP: VLAN2303 rx BPDU
172.16.2.1 306793: Dec 24 07:49:10.089 MSK: RSTP(2303): Po2 repeated msg
172.16.2.1 306794: Dec 24 07:49:10.089 MSK: RSTP(2303): Po2 rcvd info remaining 6
172.16.2.1 306795: Dec 24 07:49:10.089 MSK: STP: VLAN2316 rx BPDU: config protocol = rstp, packet from Port-channel2
172.16.2.1 306800: Dec 24 07:49:10.089 MSK: RSTP(2316): Po2 repeated msg
172.16.2.1 306801: Dec 24 07:49:10.089 MSK: RSTP(2316): Po2 rcvd info remaining 6

I wonder what does it mean "Po2 repeated msg" and "rcvd info remaining 6".