I am trying to get my hands around the difference between bpduguard and bpdu filtering on a interface , we have both enabled on access ports and we continue to have a problem when a person plugs one of these little unmanaged switches or hubs where the hub gets plugged into a main ciscoswitch on 2 different ports and creates a runaway condition in spanning tree and it kills the whole network. When you enable bpduguard and filtering shouldn't this protect the network and shutdown one of the ports ? Also confused about this in cisco's documents about bpdufilter as we have it enabled on all access ports.
Caution Use care when entering the spanning-tree bpdufilter enable command. Enabling BPDU filtering on an interface is approximately equivalent to disabling the spanning tree for this interface. It is possible to create bridging loops if this command is not correctly used.
BPDU guard and BPDU filter will only work if the unmanaged switch sends BPDU's. If the switch doesn't send BDPU's then those commands won't make any difference.
So does the switch send BPDU's
Probably not it is one of these little unmanaged type switches that they manage to loop between 2 ports . How can we protect the network against this other than threaten to fire people ? :-)
As mentioned by Francois, port security is one approach. You can set the port to only allow one mac-address and if the port sees any more the switch can shut the port down.
Obviously this should only be used on client ports.
Note that a bridge *should* run STP... the IEEE specification does not even imagine that you could not be running STP;-) Generally, when a device does not support STP, it falls back to a hub behavior, which is not making any difference between BPDUs and data traffic. So STP should still be able to run through such a dumb switch.
Now, if the loop is created between ports of the dumb switch, this is another story;-)
The safest is definitely to not have bpdufilter enabled on the access ports. STP can only perform its operation by sending and receiving BPDUs. Configuring BPDU filter prevent it from doing so and makes it totally blind. With bpdufiter, you are in fact sure that your switch will not be able to detect user cabling errors:-(
BPDU guard is not a feature that prevents loop, STP will take care of preventing loops (well, when it receives BPDUs). Instead, BPDU guard introduce a kind of policy enforcement that bring down access ports that wrongfully received a BPDU. That can be useful if a device connected to an access port is blasting BPDUs, because if you don't bring down the interface, those BPDUs will hit the CPU.
STP cannot protect against all the user errors (or attacks). It is possible for a user to introduce a loop, while filtering BPDU. In that case, just like in the BPDU filter case, STP will be helpless. Very often, some form of port security is configured on the access ports. If STP does not catch a loop, the consequence of the loop is very likely to create a port security violation.
Are you referring to spanning-tree bpdufilter or spanning-tree portfast bpdufilter
The former does not send nor receive BDPUs, if you connect a switch on this link, it won't block the port in case there is a loop since STP won't run without BPDUs.
The latter disables portfast and bpdufilter if a link-up it receives a BDPU packet.
For situation where you want to prevent hubs, I recommend implementing port-security with maximum of 2 connections (if using VoIP) and 1 connection (without VoIP).
This is our typical port config, should bpdufilter be enabled on access ports ? To me it seems that bpdu filter is preventing the sending or recieving of bpdu's which is kind of counter productive to bpduguard and thus the port would never see a bpdu from another port if you looped them , maybe I am interpreting the cisco docs incorrectly.
switchport access vlan 39
switchport mode access
no logging event link-status
speed auto 10 100
no snmp trap link-status
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
Short answer is no imo. As Edison pointed out, there is a subtle (well, not that subtle in fact) difference between the port config and the global config for BPDU filter. The port config is definitely too dangerous and should be avoided. The global config could be used, but I would not recommend it if you are concerned with users connecting hubs to your access ports.
I recommend using the global commands
spanning-tree portfast bpdufilfer default
spanning-tree portfast bdpugard default instead http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/12240se/cr/cli3.htm#wp1946892
I checked our switches and these are already there it appears. This setup is not working for us at this point when someone plugs a unmanaged switch .
spanning-tree portfast bpduguard default
spanning-tree portfast bpdufilter default
Sorry for the misunderstanding, these commands won't prevent an unmanaged switch from being inserted into your network.
These commands will fine tune the switchports with portfast enabled.
BTW, you can select either or, not both.
bdpuguard will shut down ports that receive a bpdu packet while bpdufilter removes the port from portfast state and disables bdpufilter.
For better security, bpduguard is the way to go while if you don't want to deal with enabling ports after being shut down (less help desk calls :)), bpdufilter is the way to go.
The commands you've implemented may do more harm than good (bpdufilter and bpduguard interface level commands).
As for preventing unmanaged switches, we've covered that already, that is implementing port-security at the access port.
Lets see if my understanding is correct if you use the global commands this will not put it on all the ports as we currently have them . It will just be the global command and we should not see them on the interfaces themselves or does it put them on all the interfaces when you do the global command ? We should just have the global commands and nothing as far as bdpuguard or filter on the ports ???
Currently it looks like the global command is there along with the port commands , should they not be on the ports ?
> Lets see if my understanding is correct if you use the global commands
> this will not put it on all the ports as we currently have them .
No, the bpdufilter global command disables portfast and bpdufilter on the access port if a bpdu packet is received from a neighbor.
The interface command disables the send/receive of bpdu packets.
> It will just be the global command and we should not see them on the interfaces themselves or
> does it put them on all the interfaces when you do the global command ?
Correct, just apply the global bdpufilter "or" bdpuguard. They both do different things and may conflict on their behavior.
> We should just have the global commands and nothing as far as bdpuguard or filter
> on the ports ???
> Currently it looks like the global command is there along with the port commands ,
> should they not be on the ports ?
Yes, remove them.
The global command will not replicate the CLI on each and every port if this is your question. It is supposed to be a shortcut, allowing the features on all the ports with portfast operational. That's mainly an optimization in the way you configure your switch, not really in the final behavior.
The exception is this bpdufilter, that has a slightly different behavior depending on whether it's configured locally or globally.
Let me come back quickly to this because I don't think that bpdufilter is an alternative to bpduguard. These are two very different features.
BPDU guard will shut down a port that receives a BPDU. Again, even without BPDU guard, STP will protect against the creation of loops (if it can), and this is just a matter of enforcing a different security policy. That might indeed generate help desk calls;-)
Per interface BPDU filter just prevents you from receiving or sending BPDUs on a port. If you configure that, BPDU guard will have no effect.
Global bpdufilter is applied to all the ports where portfast is operational. This feature will mainly filter out BPDU transmitted (in fact, it sends 10 BPDUs when the port comes up, in order to detect cabling error, and then filter out transmitted BPDUs). If a port receives a BPDU, portfast becomes non-operational and thus bpdufilter is disabled. So the feature is overall much less dangerous than per-port bpdufilter.
What is the use for global bpdufilter?
-1- it prevents your hosts from receiving periodic BPDUs. I don't think that any server has crashed as a result of sending a BPDU every two seconds, and the bandwidth wasted is really minimal so I don't think it's that important.
-2- it is more secure because you don't leak your STP information to the users. I'm not a security expert so I'm not paranoid about that either;-)
-3- it saves your cpu from having to send periodic BPDUs. If you are running in PVST mode, you are sending one BPDU every two seconds for each vlan and every port. This has little use and could have an impact on the CPU if you really had a lot of ports.
So if you are not interested in either of those aspect, I don't see why you would bother configuring BPDU filter globally.
I would recommend you just enable portfast and BPDU guard on the acess ports. But it would not be a big deal if you kept global bpdufilter either.
If you want to write the shortest configuration, you can rewrite yours by:
- keeping bpduguard globally enabled
- enabling portfast globally
- disable explicitly portfast on the ports that are not access
- removing bpdufilter, bpduguard and portfast from your access ports.
If you want the minimal change to your config:
- remove bpdufiler from the interfaces
- remove global bpdufilter if you want
- you can keep global bpduguard and per-interface bpduguard in your config, even if there is no reason to have both.
Thanks guys for all your help this is my understanding as well after reading over docs again. Unfortunetly that means we have a "LOT" of fixing to do on dozens of boxes and probably why we keep having these meltdowns because we have both those commands on the interfaces because we have basically turned off bpdu's both xmit and recieve so if someone did plug 2 ports together bpduguard could not work because there are no bpdu's being tranmitted out the user access port . It will probably fix our problem just having the one or the other bpduguard or filter command globally. Thanks again , happy holidays..