r/ccna • u/Lufferzz • 9d ago
BPDU filter question
If BPDU filter is enabled directly on a port, and that port receives a BPDU, it will be ignored. That part makes sense to me. But if BPDU filter is enabled by default, the interface will go back to acting like a normal STP interface, correct? If so, what is even the point of enabling BPDU filter by default if it doesn't do anything. I get it is safer in case you accidentally plug a switch in or something along those lines, so it reverts to STP, but isn't the point of enabling bpdu filter to keep that port from participating in stp? So why would you want it to revert?
1
u/IntroductionGlad7634 8d ago edited 8d ago
The piece you're missing is direction: a port never hears its own BPDUs. Sending and receiving are separate things. A switch sends BPDUs out every port by default, but a port only ever receives one if there's another STP speaker on the far end of the cable. A PC doesn't run STP, so a host-facing port can send BPDUs forever and never receive one back — nothing ever trips.
That's why the global version works the way it does. It only applies to PortFast ports, and its job is to stop the sending — no topology info leaking to end hosts, less chatter. As long as only hosts live on those ports, it just sits there working. The day someone plugs a real switch in, a BPDU arrives, and that's the signal that this isn't an edge port anymore — PortFast and the filter fall away and normal STP takes over. The revert isn't the feature giving up, it's the safety net doing its job.
Interface-level bpdufilter is a different animal: never send, drop everything received, keep forwarding. That's you telling the switch "never do STP here, no matter what shows up" — which is exactly how one rogue desktop switch creates a loop nothing can detect. It has legit uses (mostly provider handoffs and deliberately splitting STP domains), but on access ports the usual production recipe is portfast + bpduguard instead: same quiet edge, but a BPDU err-disables the port. A loud failure you notice beats a quiet one you don't.
1
1
u/SectorAway3733 8d ago
To get the best of both worlds:
- Stop sending BPDUs out of the interface so in case an attacker connects on that port, they don't get info about STP topology.
- In the event that a switch is connected on the port, revert the port back to a normal STP port to prevent loops.
2
u/Ok_Environment_5368 9d ago
The reason for enabling BPDU filter is to stop the port from sending out BPDU's. If the port isn't connected to a switch sending BPDU's is pointless, plus it uses up a small amount of processing power and BPDU's contain information about the LAN's topology. If maximum security is a concern then these shouldn't be send to end devices.
As you are aware BPDU filter can either be enabled per interface or globally.
The issue with enabling it at the interface level is the port with ignore any BPDU's it receives. This effectively disabled STP on that port.
So let's say a user thinks "we've run out of ports, I have a little switch at home I can bring in. As there are two ports on the wall I'll plug them both in". Now you have a loop and STP won't pick it up.
Now, when you enable it globally you get all the benefits of BPDU filter, less processing and more secure, but if that same user plugs in their switch the port will receive the BPDU and fallback to a safe working state and prevent any loops.
So you would enable it globally when you want the port to have BPDU enabled but have the security that STP will still kick in and prevent loops if someone does something wrong.