Oh my, reading the many follow on replies, most consider, at least the global default for bpdufilter "bad".
I've reread Cisco documentation, and also read, many comments on these two commands. The latter, also generally places the global bpdufilter into the "bad" category, or using the two commands, bpduguard and bpdufilter, together, as "bad". However, unless the Cisco documentation is incorrect, or these configuration statements don't work as documented, either I, or many others, misunderstand these commands.
Firstly, when you have an option to change global defaults, as applied to interfaces, that's to shortcut much interface configuration using a common configuration different from the Cisco default.
For example, if we want almost every edge/portfast port to use bpduguard, we can configure almost every edge/portfast port to use bpduguard, or we make it the default, an now we only need to configure (few) edge/portfast ports to NOT use bpduguard.
Of course, with the interface range statement, often setting many ports to have a common configuration statement doesn't take much typing, but it does reduce the amount of "verbiage" when you list the config.
I suspect the big worry over bpdufilter is it may open up a path to a potential L2 loop. Possibly, but no more so that using portfast does.
Cisco does note: "Enabling BPDU filtering on an interface is the same as disabling spanning tree on it and can result in spanning-tree loops." but that's when configured on an interface, not for the global default.
For a global default, Cisco has:
Enabling BPDU filtering on PortFast edge-enabled interfaces at the global level keeps those interfaces that are in a PortFast edge-operational state from sending or receiving BPDUs. The interfaces still send a few BPDUs at link-up before the switch begins to filter outbound BPDUs. You should globally enable BPDU filtering on a switch so that hosts connected to these interfaces do not receive BPDUs. If a BPDU is received on a PortFast edge-enabled interface, the interface loses its PortFast edge-operational status, and BPDU filtering is disabled.
So, what the global bpdufilter does is mainly suppress sending outbound BPDUs, but if a BPDU is received, the port then operates as a normal STP non-edge port.
The "gotcha", the global bpduguard only applies to portfast configured ports, so it's possible the incoming BPDU will NOT error disable such a also globally configured bpdufilter port.
I.e. using a global bpdufilter command may implicitly disable the global bpduguard command, but I wouldn't say this is "bad", it's just is what it is.
In my prior reply, I wrote:
But are they a good practice to use?
Usually, yes.
Which I'll revise, because I didn't see using the combination of bpduguard and bpdufilter global defaults as usually "bad", but didn't intend to imply that it's recommended or a best practice.
