Decoding BPDU's to determine sender

[ed_fair]

Hi,

I'm trying to inter-operate a large Cisco switch with a small non-Cisco switch.  There is a single connection between the two.  In basic configurations the two work fine together, but in more complex configurations the Cisco is (correctly) err-disabling the connection due to BPDUGUARD.  I have tried a few approaches to prevent the small switch from transmitting BPDU's towards the Cisco, but the err-disabling persists.  In the Cisco logs, I see error messages like:

%SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet1/25 with BPDU Guard enabled.  Disabling port.

%SPANTREE-SP-4-ERR_DISABLE: bpduguard error detected on Gi1/25, putting Gi1/25 in err-disable state

It would be very helpful if these log messages included the Bridge ID or source MAC address of the BPDU that generated the message.  Is it possible to add either to the log?  Unfortunately, these switches are remote and I don't have any wiresharks in the area.

If you can share some practical experience I'd appreciate the detailed steps.

Thanks,

ed

[David Ruess]

Hello,

You can try the command:

sh port-security int g1/25

I believe it might show you the last MAC address that caused the violation

sh port-security int g1/25
Port Security : Disabled
Port Status : Secure-down
Violation Mode : Shutdown
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 1
Total MAC Addresses : 0
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address:Vlan : 0000.0000.0000:0
Security Violation Count : 0

[MHM Cisco World]

debug spanning-tree bpdu receive

try above command and connect small sw one by one.  

[ed_fair]

Thank you - do you know if this command shows the SRC MAC or Sending Bridge ID of the BPDU when BPDUGUARD is enabled?  I've not tested this myself but I've seen some comments that indicate a BPDUGUARD block prevents debug output.

ed

[MHM Cisco World]

This events for stp show all bpdu receive by stp,

Bpdu guard go to err disable when stp receives bpdu.

But best reulst you get is by connect one by one and monitor debug.

[David Ruess]

Hello,

After labbing up the scenario and testing the 'debug spanning-tree bpdu receive' suggested by @MHM Cisco World it will only show you the MAC address if its not err-disabled. So it looks like you are correct in that once its err-disabled it wont receive BPDUs and the debug will not show anything.

I am still a little unlcear as to why you want to stop sending BPDUs from a switch. Since that's basically Spanning-Tree trying to work and its an industry standard (with some CISCO proprietary flavors). If you connect 2 switches and stop sending BPDUs on one it could cause a loop in your network when you deploy your "complex configurations", and not to mention redundant ports may not work if some links fail.

Since you are connecting these switches to each other would you not want a trunk interface connected between them with bpdu guard removed? Also your statement:

but in more complex configurations the Cisco is (correctly) err-disabling the connection due to BPDUGUARD

If you are connecting 2 switches the ports should NOT have bpdu guard if you want them to function correctly.

Can you explain a bit more what you are trying to accomplish besides not wanting to send BPDUs from the non-CISCO switch and can you send the output of the show run int g1/25 port and the other port connected to it please.

-David

[MHM Cisco World]

@David Ruess before the port go to err-disable do you see mac address of BPDU that cause err-disable?
this as I get from his post what he want.

[David Ruess · Accepted solution]

@MHM Cisco World this is the output I get from the 'debug spanning-tree bpdu receive' command:

*Apr 14 23:34:16.118: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from GigabitEthernet0/0 , linktype IEEE_SPANNING , enctype 2, encsize 17
*Apr 14 23:34:16.121: STP: enc 01 80 C2 00 00 00 50 00 00 0E 00 00 00 07 42 42 03
*Apr 14 23:34:16.132: STP: Data 00000080
*Apr 14 23:34:16.135: STP: VLAN0001 Gi0/0:0000 00 80

I only get this output if the port does not have BPDU Guard on it. Once I enable BPDU guard and try to run it again the BPDU never makes it to the debug. So in @ed_fair case it won't show anything until he disables BPDU guard. I highlighted the MAC address in red. I only know this because I went to the other switch and did a show spanning-tree to see the switches MAC address.

[MHM Cisco World]

@David Ruess this debug use for BPDU receive, and you confirm that with BPDU guard no BPDU receive and appear in debug, and you are right about why he need to use BPDU guard in port connect to two SW.
@ed_fair can you give us more detail about complex design and why you want to use BPDU guard.

[ed_fair]

Your answers all are excellent and thoughtful, thank you. Unfortunately I have no lab at my disposal.

Especially thank you @David Ruess for confirming what I've read previously – that enabling BPDUGUARD prevents debug logging of an offending BPDU. That is most unfortunate! Are there any other debug settings that might reveal the DST and SRC MAC, or a complete hex dump of the incoming BPDU?

As to “why block BPDUS”: the data center where my two small switches are located does not allow “end user” devices to participate in their spanning-tree. This is a defensive policy to protect the local network in the data center. Of course I understand that the ideal solution is to participate, but it is simply not possible in this case.

To clarify “complex configuration”, just as an FYI attached is the final physical configuration I will require.  The large box at the bottom is my chassis, showing my two switches and just one of the ten Linux blades within the chassis.  (All ten blades are identically connected).  The Linux eth0 and eth1 are an active/standby bond, with two VLAN interfaces defined on top of the bond (i.e. bond0.111 and bond0.222).

Because Small-SwA and B cannot participate in STP with DC-Sw1 and 2, and because the Linux blades do not bridge traffic or send BPDU's, there is no technical reason why Small-SwA or B need to run STP - no loops are possible.  Unfortunately, when I shutdown spanning-tree on Small-SwA and B, DC-Sw1 and 2 mysteriously continue to receive BPDU's.  I am trying to determine the source of these mystery BPDU's.

[David Ruess]

Thank you for clarifying those points.

A couple things to note:

1. You can still try to disable BPDU guard on that interface and run the debug and just do a show spanning-tree on all the switches to see what MAC is matching. Its a little convoluted but the MAC is highlighted in RED in my above reply...so basically in the middle of the output.

2. It could be possible that BPDU is coming from a device that IS participating in Spanning-Tree and supposed to. In other words DC-SW1 could be sending a BPDU to Small-SwA and although Spanning-Tree is shut down for that device, it might be forwarding the BPDU back up to DC-Sw2 ( I think this also depends on what flavor of STP you're running)

Just some observations and some more food for thought.

Hope you are able to track it down and get it resolved.

-David

[MHM Cisco World]

@ed_fair The design is not complete the DC-SW1 and DC-SW2 is interconnect via L2 "trunk" as there is HSRP router connect to both SW.

so the Loop is here 
DC-SW1->Small-SW1->DC-SW2->DC-SW1
so there is loop and this design need STP to prevent this loop. 

if you want to make both link from small-SW1 toward DC-SW1 and DC-SW2 not block you must config vPV or VSS or stack.

[ed_fair]

Thank you - yes I agree with you about the loops.  I will investigate further.  My original question is answered but I will add some details to the picture and post them back here.

[ed_fair]

Just to finish this off, for those interested.  I'm not seeking any further assistance, just posting this for your pleasure since you asked.

Below is the the actual physical plant, showing the Data Center Routers and Switches at the top, all Cisco, running "spanning-tree mode pvst", and my equipment at the bottom, Sunblade NEMS running MSTP with a single instance.  NEM0/1 have "spanning-tree priority 61440".

In the original configuration,  DC-SW33/34 ports 1/25 and 1/26  were all configured as access ports with BPDUGUARD enabled; NEM0/1 ports ex0/1 and ex0/2 were all configured as access ports with "spanning-tree bpdu-transmit disabled".  Everything worked as expected - both NEMS set ex0/1 to State=Discarding and ex0/2 to State=Forwarding, with ex0/2 as the root port, and no err-disabling from BPDUGUARD. Why this works is a case study in itself, as it relies on bridge priority settings and/or MAC addresses.

In the new configuration, DC-SW33/34 ports 1/25 and 1/26 and NEM0/1 ports ex0/1 and ex0/2 were converted to VLAN trunks, and did not work - BPDUGUARD on the DC-SW's began err-disabling ports after we did this.  Connectivity remained, but obviously will not survive certain failover scenarios.