cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
936
Views
10
Helpful
15
Replies

spanning tree

glen.grant
VIP Alumni
VIP Alumni

I am trying to get my hands around the difference between bpduguard and bpdu filtering on a interface , we have both enabled on access ports and we continue to have a problem when a person plugs one of these little unmanaged switches or hubs where the hub gets plugged into a main ciscoswitch on 2 different ports and creates a runaway condition in spanning tree and it kills the whole network. When you enable bpduguard and filtering shouldn't this protect the network and shutdown one of the ports ? Also confused about this in cisco's documents about bpdufilter as we have it enabled on all access ports.

Usage Guidelines

Caution Use care when entering the spanning-tree bpdufilter enable command. Enabling BPDU filtering on an interface is approximately equivalent to disabling the spanning tree for this interface. It is possible to create bridging loops if this command is not correctly used.

15 Replies 15

Jon Marshall
Hall of Fame
Hall of Fame

Glen

BPDU guard and BPDU filter will only work if the unmanaged switch sends BPDU's. If the switch doesn't send BDPU's then those commands won't make any difference.

So does the switch send BPDU's

Jon

Probably not it is one of these little unmanaged type switches that they manage to loop between 2 ports . How can we protect the network against this other than threaten to fire people ? :-)

Glen

As mentioned by Francois, port security is one approach. You can set the port to only allow one mac-address and if the port sees any more the switch can shut the port down.

Obviously this should only be used on client ports.

Jon

Note that a bridge *should* run STP... the IEEE specification does not even imagine that you could not be running STP;-) Generally, when a device does not support STP, it falls back to a hub behavior, which is not making any difference between BPDUs and data traffic. So STP should still be able to run through such a dumb switch.

Now, if the loop is created between ports of the dumb switch, this is another story;-)

Regards,

Francois

Francois Tallet
Level 7
Level 7

Hi Glen,

The safest is definitely to not have bpdufilter enabled on the access ports. STP can only perform its operation by sending and receiving BPDUs. Configuring BPDU filter prevent it from doing so and makes it totally blind. With bpdufiter, you are in fact sure that your switch will not be able to detect user cabling errors:-(

BPDU guard is not a feature that prevents loop, STP will take care of preventing loops (well, when it receives BPDUs). Instead, BPDU guard introduce a kind of policy enforcement that bring down access ports that wrongfully received a BPDU. That can be useful if a device connected to an access port is blasting BPDUs, because if you don't bring down the interface, those BPDUs will hit the CPU.

STP cannot protect against all the user errors (or attacks). It is possible for a user to introduce a loop, while filtering BPDU. In that case, just like in the BPDU filter case, STP will be helpless. Very often, some form of port security is configured on the access ports. If STP does not catch a loop, the consequence of the loop is very likely to create a port security violation.

Regards,

Francois

Edison Ortiz
Hall of Fame
Hall of Fame

Glen,

Are you referring to spanning-tree bpdufilter or spanning-tree portfast bpdufilter

The former does not send nor receive BDPUs, if you connect a switch on this link, it won't block the port in case there is a loop since STP won't run without BPDUs.

The latter disables portfast and bpdufilter if a link-up it receives a BDPU packet.

For situation where you want to prevent hubs, I recommend implementing port-security with maximum of 2 connections (if using VoIP) and 1 connection (without VoIP).

This is our typical port config, should bpdufilter be enabled on access ports ? To me it seems that bpdu filter is preventing the sending or recieving of bpdu's which is kind of counter productive to bpduguard and thus the port would never see a bpdu from another port if you looped them , maybe I am interpreting the cisco docs incorrectly.

switchport access vlan 39

switchport mode access

switchport nonegotiate

no logging event link-status

load-interval 60

speed auto 10 100

no snmp trap link-status

spanning-tree portfast

spanning-tree bpdufilter enable

spanning-tree bpduguard enable

Short answer is no imo. As Edison pointed out, there is a subtle (well, not that subtle in fact) difference between the port config and the global config for BPDU filter. The port config is definitely too dangerous and should be avoided. The global config could be used, but I would not recommend it if you are concerned with users connecting hubs to your access ports.

Regards,

Francois

I recommend using the global commands

spanning-tree portfast bpdufilfer default

and

spanning-tree portfast bdpugard default instead http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/12240se/cr/cli3.htm#wp1946892

I checked our switches and these are already there it appears. This setup is not working for us at this point when someone plugs a unmanaged switch .

spanning-tree portfast bpduguard default

spanning-tree portfast bpdufilter default

Glen,

Sorry for the misunderstanding, these commands won't prevent an unmanaged switch from being inserted into your network.

These commands will fine tune the switchports with portfast enabled.

BTW, you can select either or, not both.

bdpuguard will shut down ports that receive a bpdu packet while bpdufilter removes the port from portfast state and disables bdpufilter.

For better security, bpduguard is the way to go while if you don't want to deal with enabling ports after being shut down (less help desk calls :)), bpdufilter is the way to go.

The commands you've implemented may do more harm than good (bpdufilter and bpduguard interface level commands).

As for preventing unmanaged switches, we've covered that already, that is implementing port-security at the access port.

Lets see if my understanding is correct if you use the global commands this will not put it on all the ports as we currently have them . It will just be the global command and we should not see them on the interfaces themselves or does it put them on all the interfaces when you do the global command ? We should just have the global commands and nothing as far as bdpuguard or filter on the ports ???

Currently it looks like the global command is there along with the port commands , should they not be on the ports ?

> Lets see if my understanding is correct if you use the global commands

> this will not put it on all the ports as we currently have them .

No, the bpdufilter global command disables portfast and bpdufilter on the access port if a bpdu packet is received from a neighbor.

The interface command disables the send/receive of bpdu packets.

> It will just be the global command and we should not see them on the interfaces themselves or

> does it put them on all the interfaces when you do the global command ?

Correct, just apply the global bdpufilter "or" bdpuguard. They both do different things and may conflict on their behavior.

> We should just have the global commands and nothing as far as bdpuguard or filter

> on the ports ???

Correct.

> Currently it looks like the global command is there along with the port commands ,

> should they not be on the ports ?

Yes, remove them.

The global command will not replicate the CLI on each and every port if this is your question. It is supposed to be a shortcut, allowing the features on all the ports with portfast operational. That's mainly an optimization in the way you configure your switch, not really in the final behavior.

The exception is this bpdufilter, that has a slightly different behavior depending on whether it's configured locally or globally.

Let me come back quickly to this because I don't think that bpdufilter is an alternative to bpduguard. These are two very different features.

BPDU guard will shut down a port that receives a BPDU. Again, even without BPDU guard, STP will protect against the creation of loops (if it can), and this is just a matter of enforcing a different security policy. That might indeed generate help desk calls;-)

Per interface BPDU filter just prevents you from receiving or sending BPDUs on a port. If you configure that, BPDU guard will have no effect.

Global bpdufilter is applied to all the ports where portfast is operational. This feature will mainly filter out BPDU transmitted (in fact, it sends 10 BPDUs when the port comes up, in order to detect cabling error, and then filter out transmitted BPDUs). If a port receives a BPDU, portfast becomes non-operational and thus bpdufilter is disabled. So the feature is overall much less dangerous than per-port bpdufilter.

What is the use for global bpdufilter?

-1- it prevents your hosts from receiving periodic BPDUs. I don't think that any server has crashed as a result of sending a BPDU every two seconds, and the bandwidth wasted is really minimal so I don't think it's that important.

-2- it is more secure because you don't leak your STP information to the users. I'm not a security expert so I'm not paranoid about that either;-)

-3- it saves your cpu from having to send periodic BPDUs. If you are running in PVST mode, you are sending one BPDU every two seconds for each vlan and every port. This has little use and could have an impact on the CPU if you really had a lot of ports.

So if you are not interested in either of those aspect, I don't see why you would bother configuring BPDU filter globally.

Summary:

I would recommend you just enable portfast and BPDU guard on the acess ports. But it would not be a big deal if you kept global bpdufilter either.

If you want to write the shortest configuration, you can rewrite yours by:

- keeping bpduguard globally enabled

- enabling portfast globally

- disable explicitly portfast on the ports that are not access

- removing bpdufilter, bpduguard and portfast from your access ports.

If you want the minimal change to your config:

- remove bpdufiler from the interfaces

- remove global bpdufilter if you want

- you can keep global bpduguard and per-interface bpduguard in your config, even if there is no reason to have both.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: