cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
816
Views
4
Helpful
7
Replies

bpduguard vs. bpdufilter

John Blakley
VIP Alumni
VIP Alumni

All,

I was playing around with my switches at the house, and I ran across something that doesn't make sense to me. According to Cisco, if you enable bpdufiltering globally, then if any portfast enabled port receives a bpdu on that port, it will automatically disable portfast on that port and allow bpdus to be sent/received. However, if you enable bpdufilter directly on the interface, it quietly discards bpdus that are sent/received. Well, I found another document from Cisco that states that enabling it on an interface directly effectively disables spanning tree on that port.

So, I created a loop by leaving portfast on and enabling bpdufiltering on that port. (Don't worry; it's a home lab.) I brought the whole network down.

I can understand why enabling globally would be beneficial, but why would you EVER want to enable it locally on the interface?

As far as bpduguard, why wouldn't you just choose this as opposed to bpdufilter?

Thanks,

John

HTH, John *** Please rate all useful posts ***
1 Accepted Solution

Accepted Solutions

Uplinkfast does something quite different. It does allow a redundant link to be brought up much quicker than the normal 45 seconds STP uses but it is not the same as portfast trunk.

I would not turn on portfast trunk on any switch to switch interconnection.

One other thing - depending on the version of STP you are using uplinkfast is either a separate feature ie. in standard 802.1d or it has been intergrated ie. in RSTP 802.1s.

Jon

View solution in original post

7 Replies 7

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello John,

bpuguard is the right tool in an enterprise network to protect from loop.

bpdufilter is out there for L2 Service Provider usage that are using some form of L2 transport and don't want or are asked to avoid to interfere with CPE equipment = CPE switches by sending or processing BPDU frames out specific ports

I would not consider a global config for bpdufilter.

Hope to help

Giuseppe

Jon Marshall
Hall of Fame
Hall of Fame

John

I was going to go in a full blown explanation but instead have a look at this thread (i can't do any better !) - Francois is one of the Cisco experts on STP and it covers pretty much what you are asking about -

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&topicID=.ee71a04&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cbee25c/13#selected_message

Jon

Perfect! Now one more question (I think):

I noticed that the port has to be in portfast in order for bpdu(anything) to work. In order for the bpduguard to shut the port down, I had to make the port an access port. So, I can assume that the port has to be an access port in order for this to work?

Also, I tried to create the port as a trunk port, and then enable portfast trunk, but bpduguard didn't shut the port down. I assume that this is because on a trunk port, it expects to see bpdus?

Thanks!

John

HTH, John *** Please rate all useful posts ***

"Perfect! Now one more question (I think):"

Hmmm, looks like more than one question to me :-)

" noticed that the port has to be in portfast in order for bpdu(anything) to work"

Not necessarily. Bpduguard if enabled globally will only work on ports that have portfast enabled. If enabled on an interface it will shut the port down if it receives a BPDU regardless of whether the port is in portfast mode or not.

Bpdufilter if enabled globally works on portfast enabled ports. If it sees a BPDU it disables portfast and STP beings sending BPDU's on this port. If configured at interface level it doesn't send any BPDU's and drops all BPDU's it receives.

As for the trunk port. I would have assumed that it worked the same way as portfast ie. a BPDU is received it is shutdown. This is because generally speaking you would enable "portfast trunk" on a port connected to a server where the server NIC is capable of running 802.1q. So you shouldn't be getting any BPDU's from this server.

But your'e tests seem to indicate otherwise.

Jon

Well you now have me thinking that I should do more tests. :-)

I forgot to test bpduguard locally on the interface, so I can't attest as to whether it shut the port down regardless of mode (trunking/access). I'm going to test that one tonight.

As far as the portfast trunk, that's generally done for just devices on the edge switch? Would I be able to use portfast trunk in place of uplinkfast, or does it not accomplish the same thing?

Thanks!

John

HTH, John *** Please rate all useful posts ***

Uplinkfast does something quite different. It does allow a redundant link to be brought up much quicker than the normal 45 seconds STP uses but it is not the same as portfast trunk.

I would not turn on portfast trunk on any switch to switch interconnection.

One other thing - depending on the version of STP you are using uplinkfast is either a separate feature ie. in standard 802.1d or it has been intergrated ie. in RSTP 802.1s.

Jon

Thanks Jon! I'm going to do some more testing on the bpduguard without switching it to an access port and see what happens.

--John

HTH, John *** Please rate all useful posts ***
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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco