In a stunning moment of clarity I figured out the two. It did take far longer that what was required but I feel now I can tick these two technologies off as being understood why you would use them and when you would use them.
Bridge Protocol Data Unit’s known also as BPDU’s play a fundamental part in a spanning-tree topology. No matter your flavour you will have BPDU’s.
BPDU – A quick breakdown
BPDU’s are sent out by a switch to exchange information about bridge ID’s and cost’s of the root path. A switch will use it’s MAC address and sent it to the STP multicast address of 01:80:c2:00:00:00. There are Configuration BPDU’s, Topology Change Notification BPDU’s and Topology Change Notification Acknowledgement BPDU’s. Exchanged at a frequency of every 2 seconds by default, BPDU’s allow switches to keep a track of network changes and when to block or forward ports to ensure a loop free topology.
BPDU Guard is designed to protect your switching network. Remember that a Port-fast port is designed to be connected to a device where BPDU’s aren’t expected. This could be a end user device, server or access-point. When an unexpected BPDU is detected (an end-user wants to plug in a switch in his cubicle) the port will shutdown and enter a err-disable state.
When enabled globally this is a fantastic solution to protecting port-fast ports on access switches where you don’t expect a switch to be plugged in. BPDU guard when enabled on a per port interface, is conditional. It requires the port to be portfast enabled. If you require BPDU guard to be enabled unconditionally then you must do that on the port itself.
SW1(config)# spanning-tree portfast bpduguard default
SW1(config)# int gi0/10 SW1(config-if)# spanning-tree bpduguard enable
Initially I was stumped as to why you would use this. Why on earth would you want to stop BPDU’s from being sent or received on a port. I immediate though it was ludicrous. It wasn’t until I had a discussion with the man of infinite wisdom @networkjanitor (Kurt Bales) did I understand it’s use. The point of demarcation is a fantastic place to use BPDU filter. When an ISP hands off a tail in the DC from their switch infrastructure, neither party want’s anything to do with the others STP topology. This one of the uses of this feature. Probably the best one I have found.
First of all, BPDU filter disables spanning-tree on a port period. It does this by restricting sending and receiving BPDU’s. Simple enough. When enabled on a global level, BPDU filter will apply to all portfast ports. When a port links up it will transmit some BPDU’s out before the port starts to filter BPDUs.
Remember that if a BPDU is received on a portfast interface, the interface will lose portfast status and because BPDU filtering relies on this it will become disabled.
SW1(config)# spanning-tree portfast default SW1(config)# spanning-tree portfast bpdufilter default
SW1(config)# int gi0/24 SW1(config-if)# spanning-tree bpdufilter enable
I’ve used BPDU guard a whole lot. After learning at college you could bring down an entire block of lab’s with a switch configured a certain way, I made sure that no network under my jurisdiction would suffer the same fate. Couple BPDU guard with err-disable recovery and you have protection. BPDU filter could also be placed on access layer ports too. Another way to negate pesky attacks from inquisitive minds.
8 thoughts on “Clarity : BPDU Guard vs BPDU Filter”
so I should not have BPDU Guard on a port that an access point is on
Nice explanation and nice example for bpdu filter
Nice cheeteh 🙂
“BPDU guard when enabled on a per port interface, is conditional. It requires the port to be portfast enabled. If you require BPDU guard to be enabled unconditionally then you must do that on the port itself.”
So which is it? Is per-port bpduguard conditional or unconditional?
SZ; When BPDUGuard is enabled globally, it operates on ONLY ports which have portfast enabled. When BPDUGuard is enabled on a single port, it will operate on that port regardless of any other configuration
interesting thread around this with Rckus mesh devices
and then I forgot the thread 🙂
PortFast BPDU filtering allows the administrator to prevent the system from sending or even receiving BPDUs on specified ports.
When configured globally, PortFast BPDU filtering applies to all operational PortFast ports. Ports in an operational PortFast state are supposed to be connected to hosts, that typically drop BPDUs. If an operational PortFast port receives a BPDU, it immediately loses its operational PortFast status. In that case, PortFast BPDU filtering is disabled on this port and STP resumes sending BPDUs on this port.
PortFast BPDU filtering can also be configured on a per-port basis. When PortFast BPDU filtering is explicitly configured on a port, it does not send any BPDUs and drops all BPDUs it receives.
Caution Explicate configuring PortFast BPDU filtering on a port that is not connected to a host can result in bridging loops as the port will ignore any BPDU it receives and go to forwarding.
When you enable PortFast BPDU filtering globally and set the port configuration as the default for PortFast BPDU filtering, then PortFast enables or disables PortFast BPDU filtering.
If the port configuration is not set to default, then the PortFast configuration will not affect PortFast BPDU filtering. PortFast BPDU filtering allows access ports to move directly to the forwarding state as soon as the end hosts are connected.
1) “Spanning-tree bpdufilter enable” on the interface. This disables the sending and receiving of BPDU’s on the port. All BPDU’s incoming on the port are discarded. This effectivly removes the port from ever participating in spanning tree.
2) “Spanning-tree portfast bpdufilter default” in global configuration. What this configuration will do is any port which is in portfast mode will not send out BPDU’s but will receive BPDU’s and when it does will revert the port back to a normal spanning-tree port, and lose it’s portfast state.