BPDU Guard is a feature that is enabled on ports where PortFast has been enabled. PortFast in turn should be enabled only on access ports, that is, ports that connect to end devices and not to other STP switches.
UplinkFast on the other hand is configured on ports that DO connect to other switches running STP. In actuality it is enabled ONLY on ports connected to switches.
For this reason, you would never configure both UplinkFast and BPDUGuard on the same port.
Typically, in Rapid spanning tree, we would want to see the uplinkfast and backbone fast enabled correct? in which cases would you not want this enabled?
Hello Austin,
with Rapid STP we dont need to care about UplinkFast and BackboneFast any more, these features are natively included and automatically enabled in Rapid STP mode.
As @fugazz correctly stated, UplinkFast and BackboneFast are features that are natively included in RSTP. Actually, you will see that these two features will be reported as disabled on your output. This is because RSTP uses its own implementations of these improvements, and these are features that you cannot disable.
This is an unusual situation, but it is not unheard of. Specifically, in your configuration, you are protecting the network from someone connecting a switch to the PC port of the phone. The portfast and BPDU Guard features should both be enabled as you have them, as this is best practice for security. However, it seems that the switch is âseeingâ BPDUs on the Fa0/2 port and going into err-disabled state.
There are several reasons why this would occur:
Someone is connecting a switch to the PC port of the phone. Of course, Iâm sure youâve checked that, but just including this here for completion.
There is some software running on the PC that is sending BPDUs. This would be the case if someone is trying to hack the network using specialized network tools, or if someone is running an emulator on the device using GNS3 for example. Some configuration may have sent some BPDUs over the physical network.
Although rare, it has happened that faulty cables have caused problems with BPDU guard being tripped.
I suggest you check out the following:
Verify that the err-disable reason is indeed due to BPDU Guard
Is the problem reproducible? Do you see it on other ports with other phones? Try to switch cables, switch ports on the switch, and even disconnect the PC for a while and see if that makes any changes. This way you can focus on what is causing the problem (cable, PC, phone, switch port). By changing one element at a time, you can eliminate specific sources of the problem.
Try these out and let us know the results so we can further help you in troubleshootingâŚ
Switches will be able to send and receive BPDUs on access ports. And yes, access ports will by default receive valid BPDUs in the event of a topology change. However, the access ports that are connected to end devices should never receive BPDUs. For this reason, BPDU guard should be enabled only on ports that you know are not connected to any other switches. In other words, it should be enabled only on access ports that serve end devices.
thanks for the clarification, so does it mean its mandatory or best practice to enable BPDU guard on end points connected to end devices? can a network run without the administrator always having to enable bpdu guard on every access port connected to a switch? or what is best practice design so that your access ports never receive bpduâs
It is generally best practice to enable both portfast and bpduguard on ports where you donât expect to see any switches connected. This protects you from employees bringing their own switches and connecting them at their desks and causing a change in the STP topology.
Because most ports on an access layer switch will be used by end devices, it is possible to enable both portfast and bpduguard by default on all ports, and then to remove these features from the few ports that will connect to other switches. This way you donât need to configure each and every access port separately.
In enterprise networks in general, you donât often have changes to these configurations, so itâs not that much of an overhead to go in and configure these ports at the beginning. If youâre in an environment where ports are often changed from being connected to switches to being connected to hosts and visa versa, then you may consider not configuring portfast and bpduguard, but that depends on how vulnerable you consider your network to be to attacks by employees. You have to weigh the pros and cons in each case.
Hello,
consider a customer arrives in my Campus, he wan to add his switch intto my network in trunk (he wants that i pass him 3 vlans) but i dont want his partecipation to spanning tree, what i must put on my side interface:
If you want to cause a specific port to stop participating in STP, the best solution is to enable the Spanning-Tree BPDU Filter. This can be accomplished by issuing the following command on the interface:
Hi,
I just recommended a friend to enable BPDUGuard on all access ports for switches on his network and he doesnât think itâs a good idea because he thinks BPDUGuard would prevent multiple MAC Addresses from working on an access port. I canât see why BPDUGuard would prevent multiple MACs from working on an access port. Can someone verify if this is please?
Thank you,
Gary
You are correct that BPDUGuard does not prevent multiple MAC addresses from working on an access port. BPDUGuard is a feature that protects your network from potential loops by disabling a port that receives a BPDU on access ports. It does not have any direct impact on the MAC address learning or limiting process.
For more information about BPDUGuard, take a look at this lesson:
What your friend is describing sounds more like port security. Take a look at this lesson on port security to learn more: