@RLitchfield wrote:
Do not use bpdu-filter except for very specific circumstances! And certainly never globally.
BPDU-filter locks the port into forwarding mode - think what that might do for loops... The other thing bpdu-filter does is stop any incoming or outgoing BPDU packets - it filters them out. That is really useful if you want to connect two disparate networks - perhaps if you are at a venue, or you have different spanning tree configs on two networks that need to be joined.
I use it often at venues when we are setting up demos and events, and we need to connect to the venue network. Usually they will have something lile bpdu-protect on the ports, and if my switch does not have bpdu-filter on that port, the port will shut down.
I also use bpdu-filter in the lab when connecting my travelling roadcase networks to the main network. They have different MSTP configs, and filter stops the messages about inconsistency and/or the upstream port shutting down.
Thanks for the reply. Still I have some follow up questions:
In the way Cisco implementats it i see this post:
"However it will work differently depending on where you configure bpdu-filter and bpdu-guard!
The recommended implementation is to (at least IMO):
- -use bpdu-filter in global mode
- -use bpdu-guard in global mode
That way you will enable it for all "portfast" ports and in case BPDU's are detected on those ports, the bpdu-filter will be disabled and the bpdu-guard will kick in. But instead of disabling the port, the bpdu-guard would detect that BPDU's was received and if it does the port would loose it's portfast status and it would go through all the normal phases of spanning-tree and if a loop was detected it would have been blocked.
The interesting thing is here that we can use these two in a couple of combinations depending on how you want your network to behave. But the reason i recommend it using both in global-config is because that would mean that you would still have the protection of STP, and the optimising of your network by not sending out BPDU's. Most other combinations come with pro's and cons.
Basically if you start to use bpdu-guard in interface-configuration, then you will need to shut/no shut the port in case it receives BPDU's. Or enable err-disable auto-recovery. But the port will shutdown.
If you use BPDU-filter in interface-configuration, then you will disable that port form sending and receiving BPDU's....effectively blocking the BPDU-guard function from working. But more importantly - loops can occur since you don't care about BPDU's.
However if you use it in global-config, you have the protection that IF BPDU's are received on the portfast-ports, then the bpdu-filter will be disabled so bpdu-guard WILL be triggered!
Hope that clears some confusion about bpdu-filter vs bpdu-guard. It's an often misunderstood concept."
Does this make any sense? Hence my question regarding the Aruba way of implementing it.
My other thought: would you hide your STP topology by means of this feature? Or is it a moot point since an attacker can craft lower bridge id packets anyway? If the attack vector is to take over the root bridge role, or create an intentional loop. What other L2 attacks would you need to be wary of?
One of the cases I read is that when you connect to a service provider network, you need to use bpdu-filter instead of protect (since you don't want interference with their STP topology). Is it possible in this case that a loop on the service provider network, could bring down your network?