How to stop sending BPDUs

altdrugz

Hi there,

I noticed that even if STP is disabled I can read through the packet capture the BPDU updates that include information such as the priority and the root switch MAC etc. I would like to stop these updates getting sent to access ports so that 'clients' cannot see these updates if they are sniffing.

In the past someone had posted a command per interface here but i cant find it something like bpdu-status or disable pfff cant remember

Thanks

Yanio

I think you'll want to look at BPDU filters on the interface, this will cause the switch to disregard any incoming/outgoing BPDUs on that interface. Use with caution though

altdrugz

Thanks for your reply!

Is it possible to give me an indication of the commands or something? Well I dont think that it will break something since I just want to configure all the access ports not to send any BPDUs updates.

Mooseboost

This may be of some help: https://supportforums.cisco.com/document/45136/importance-bpdu-guard-and-bpdu-filter

BPDU Filter is what you are after.

altdrugz

Thanks!

TWX

The biggest problem is that if you filter BPDU then spanning-tree does not work at all, and you can have users create damaging loops that don't get cut-off.

At the moment, the 'leak' of BPDU information about the root bridge is considered less of a problem than the broadcast storm associated with blocking BPDU information. If you want to stop access interfaces from being able to manipulate or participate in spanning-tree, run bpduguard on your access interfaces (can be enabled per-interface or can be enabled globally) so that if a BPDU packet is received by your switches on end-user interfaces the interface gets err-disabled. It also has the added benefit of err-disabling interfaces that end-users accidentally create loops on, so that the user calling the helpdesk is a way to find the location of the mistake.

You can even play with errdisable recovery timers to allow the interface to be restored shortly after being disabled. Either way, if a Spanning-tree aware device is plugged in then the user will find the data drop cut off.

If you're concerned about the user being able to identify the IP management scheme that you've employed in order to attempt to connect in to manage your devices, hence the desire to turn off the ability to see that information in the BPDU packet, bear in mind that this is security through obscurity rather than true security. You're probably better off adding an ACL to your VTY management lines that explicitly allows only those LANs that you want to be able to manage from and blocks all of the rest.

shortstop20

TWX wrote: »

The biggest problem is that if you filter BPDU then spanning-tree does not work at all, and you can have users create damaging loops that don't get cut-off.

At the moment, the 'leak' of BPDU information about the root bridge is considered less of a problem than the broadcast storm associated with blocking BPDU information. If you want to stop access interfaces from being able to manipulate or participate in spanning-tree, run bpduguard on your access interfaces (can be enabled per-interface or can be enabled globally) so that if a BPDU packet is received by your switches on end-user interfaces the interface gets err-disabled. It also has the added benefit of err-disabling interfaces that end-users accidentally create loops on, so that the user calling the helpdesk is a way to find the location of the mistake.

You can even play with errdisable recovery timers to allow the interface to be restored shortly after being disabled. Either way, if a Spanning-tree aware device is plugged in then the user will find the data drop cut off.

If you're concerned about the user being able to identify the IP management scheme that you've employed in order to attempt to connect in to manage your devices, hence the desire to turn off the ability to see that information in the BPDU packet, bear in mind that this is security through obscurity rather than true security. You're probably better off adding an ACL to your VTY management lines that explicitly allows only those LANs that you want to be able to manage from and blocks all of the rest.

Completely agree, great post.

Yanio

shortstop20 wrote: »

Completely agree, great post.

Agree with your agreement. Fantastic post by TWX!

Hondabuff

I have only had a few sites that I have done that I used bpdu filter. It was connecting a router L2 port into a campus LAN for upstream communication. BPDU guard should be used on all access ports along with port security and limit the mac address limit to 3 per port unless there is a reason for more. I use port security restrict instead of shutdown due to administrative overhead. I also use error recovery of 30 minutes per port for bpdu guard. That way when someone does plug in an unauthorized device that sends bpdu's the port will shut down for 30 minutes. this is enough time for the attacker to believe the port is down and not coming back up. Once you learn about Kali Linux you will see how easy it is to destroy someones network but also learn how to properly setup a network to defend itself from these simple attacks. Just remember bpdu filter=bad, bdpu guard=good!

TWX

I can't make my port security limitation as low as three MAC addresses, but I can agree to keep it to no more than ten. Too many unmanaged switches were authorized in years past when the number of available drops was too low and we have introduced phones as well. I also can't make my timers 30 minutes because too many people move around too quickly.

What I seek to protect against is malicious software intent on breaking the CAM table so that the switch just floods. 480 local MAC addresses should still leave me an acceptable ceiling for MAC addresses on trunk interfaces.

As far as BPDU filter is concerned, the only application that I've had for it is to prevent sending BPDUs to an entity that does not need them, like the ISP. I also disable CDP on that interface, set that interface to passive in all IGP routing protocols, and block all EGP and IGP routing protocols that aren't to be used as a function of the ACL on that interface. If the ISP is REALLY picky (ie, doesn't want you to have any managed devices on the link) one could even switchport nonegotiate the interface so that it doesn't even use DTP to let the other end of the link know that it's an access port.

I think that the biggest issue with spanning-tree is that people don't really take the time to learn how it's supposed to work even in an ideal setting, so they start looking for ways to disable it. In some senses it's an invisible protocol outside of setting the root bridge and possibly configuring better priorities in a few key places if there is a desire to impact how the network functions. I've encountered environments where bpdufilter and bpduguard were enabled on the same interface (filter makes guard useless) and where filter was used even on trunks, essentially creating little spanning-tree zones.

volfkhat

I should have realized that TWX "knows what he's talkin about" when his MATH-table taught me how to 'flip the bit' by just counting on One hand.

:]

Deathmage

add the following command:

on the interface or port-channel range: "spanning-tree bpduguard enable".

TWX

Deathmage wrote: »

add the following command:

on the interface or port-channel range: "spanning-tree bpduguard enable".

I prefer to do it globally...

From global config, spanning-tree portfast default and spanning-tree portfast bpduguard default as it enables the command on all access interfaces, but doesn't touch trunk interfaces:

! 0/1 is set "switchport mode access"
upstairs-sw#sh spanning-tree int f0/1 portfast
VLAN0010            enabled
! Interfaces 2 through 6 not in use and thus do not report spanning-tree information when queried
! 0/7 is also "switchport mode access"
upstairs-sw#sh spanning-tree int f0/7 portfast
VLAN0040            enabled
! 0/8 is set "switchport mode trunk" with three vlans allowed
upstairs-sw#sh spanning-tree int f0/8 portfast
VLAN0005            disabled
VLAN0020            disabled
VLAN0030            disabled
! 0/9 is "switchport mode access"
upstairs-sw#sh spanning-tree int f0/9 portfast 
VLAN0002            enabled
! 0/10 is "switchport mode trunk" with six allowed vlans
upstairs-sw#sh spanning-tree int f0/10 portfast
VLAN0002            disabled
VLAN0005            disabled
VLAN0010            disabled
VLAN0020            disabled
VLAN0030            disabled
VLAN0040            disabled

As you can see, the switch is intelligent enough to disregard global spanning-tree portfast and global spanning-tree portfast bpduguard on trunk interfaces.

I don't know why this isn't more widely taught or discussed. It seems like it solves a whole lot of problems without having to do a per-interface config. It also works when voice vlans are defined, I've tested it at work and there were no problems with either vlan tagging or with bpdu errdisabling on ports with phones on their own separate voice vlan that also had workstations on the conventional user vlan.

TWX

volfkhat wrote: »

I should have realized that TWX "knows what he's talkin about" when his MATH-table taught me how to 'flip the bit' by just counting on One hand.

:]

Don't put me on too much of a pedestal, I'm still working on my certification and obviously if someone knows better what they're talking about, I'd love to hear what they have to say. For all I know, there are plenty of cases when it actually is good to block spanning-tree that I simply haven't encountered.