I’m noticing a shift in focus in my articles: from theory to a more practical approach. This one, hopefully, is a mix of both: BPDU Guard and BPDU Filter.
Let’s start with the theory first: for those who don’t know, BPDU Guard is a feature on Cisco switches which causes a switchport to shut down as soon as it receives a spanning-tree frame. BPDU Filter doesn’t shut down the port, but instead filters out the BPDU, as if it was never received on that port. Both features can be configured globally on the switch, or on a per-port basis. Now to the practical side of things:
BPDU Guard
A port with BPDU Guard will still send out BPDU frames itself. This comes in handy, as two access ports with PortFast and BPDU Guard connected to each other in a Campus LAN will detect the BPDUs and shut down the port. This is a good practice, as you don’t always control what end users connect to the network: their own switches, hubs, computers with network cards placed in bridging mode… All of these aren’t a real problem until somehow a second connection is made. Using the command ‘spanning-tree portfast bpduguard default’, each PortFast port will automatically have it configured. You can even configure ‘errdisable recovery cause bpduguard’ and the switch will recover automatically from these incidents, no need for manual intervention.
But… There are downsides. First of all, the port isn’t shut down until an actual BPDU frame is received: since spanning-tree does this every two seconds by default, a broadcast frame can still loop for two seconds before the port is disabled. That might not be impressive, but it’s sometimes enough to briefly send a spike through the network. Also, while this does stop most loops made through IP Phones, I’ve heard people say some IP Phones filter out BPDU frames. And while the errdisable autorecovery saves management overhead, the loop will briefly reappear as long as the problematic cable isn’t removed.
BPDU Filter
BPDU Filter on a port filters out any received BPDU frames, but at the same time, it stops sending BPDUs as well. It effectively stops spanning-tree from operating on that port, so this port will stay enabled no matter what happens to the spanning-tree topology. Very tricky, as it’s always possible someone misplaces a cable (and we’re all human, so that will happen eventually).
Also… While ‘spanning-tree portfast bpdufilter default’ seems to enable it globally on the switch, it works different: it doesn’t send out BPDU frames on PortFast ports, but once a BPDU frame is received, the port loses PortFast status and starts working like a normal switchport, sending out BPDUs again.
Personally, I strongly dislike experimenting with spanning-tree in such a way, but in a rare occasion, it might be the only option. That rare occasion usually involves a Nexus 2000 Fabric Extender: the access ports are hardcoded with BPDU Guard enabled, so the only way to connect a switch to it is if that switch does not send out any BPDUs. A risky setup.
Any comments? Feel free to share the bridging loop horror stories!
Reggle 