Spanning-Tree BPDUGuard

Hi Said,

If you configure an interface in access mode then the interface only belongs to a single VLAN. The alternative is trunk mode, where multiple VLANs can cross the interfaces and they get tagged with the VLAN ID (using 802.1Q or ISL).

An interface in access mode still sends, receives, and processes BPDUs, this behavior doesn’t change. If your access mode interface connects to end devices then it’s a good idea to enable BPDU guard. You don’t want to process BPDUs from computers / laptops or anything like that.

Portfast is used to put interfaces in the forwarding state right away. It doesn’t go through the listening and learning states anymore. It also doesn’t trigger a TCN when the interface goes up/down. You can find a detailed explanation here:

1 Like

In the Portfast tutorial, it was mentioned that once portfast is enabled on an access port it won’t send topology change notification. Will it still send BPDUs?
Is that why we use BUDUGuard to stop BPDUs on Accessport?

Hello rosna

By default, all ports on a switch, including those configured with portfast SENDBPDUs. (It is possible to disable BPDU sending on these ports using BPDU filtering.) Portfast essentially skips the listening and learning states to enter the forwarding state immediately but does not disable STP. It also applies the global BPDUGuard feature (if it is enabled) to all ports configured using portfast.

In addition, as you mentioned, it won’t send any TC information on that port because by definition, there should be no switches connected to the specific port.

The reason we use BPDUGuard is because we don’t want any switches to be connected to a port configured with portfast. It is only for end devices. So if a BPDU is RECEIVED, the port goes into err-disabled state, essentially shutting down.

I hope this has been helpful!



Good explanation !!
I really enjoy reading your topics and make me feel more comfortable and confident.

1 Like


What do you recommend if want to make point to point Trunk connection,

Core sw (3850) -------> Access switch (2960X) (single leg)
If I configure my Core switch trunk interface with Bpduguard enable and root guuard, and the interface was going to error disable mode after sometime. I want to understand can we keep Bpduguard enable on trunk iterface or not ? could you please explain ?


Hello Durga

BPDUguard should be enabled on interfaces to which you should never receive BPDUs such as those interfaces connected to end devices and hosts. BPDUGuard is often combined with portfast to protect these interfaces from creating an unwanted loop. You should never configure BPDUguard on interfaces where you expect BPDUs to arrive such as a link between switches. In your case, you should expect to receive BPDUs on the link between your core and access switch so BPDU guard should never be implemented there. BPDUs will be sent and the interface will go into errdisable state, something that is not desirable.

Rootguard on the other hand can be implemented on the interface on the core sw connecting to the access switch. This is because you want the core switch to always be the root and you should not accept any BPDUs that are incoming to change that.

I hope this has been helpful!



why bpdu guard is not recommend on ports having uplink fast enabled?

1 Like

Hello Pinki

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.

I hope this has been helpful!


1 Like

I think the command should be SW2(config)#spanning-tree portfast bpduguard default
One last word missed in the guide.

Hi Dmitriy,

It seems they changed this. I’m looking at this document:

Cisco IOS Software Command
CatSwitch-IOS(config)# spanning-tree portfast bpduguard 

It seems that since the 3560, they use this command:

spanning-tree portfast bpduguard default

I’ll change it :+1:


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.

1 Like

Hello Austin

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.

I hope this has been helpful!


1 Like

Hello NetworkLessons team.

I need help.
Portfast and BPDUGuard have been enabled on SW in the topology below.


Sometimes SW receive a BPDU in voice VLAN and the port goes into err-disabked state. What’s happened?

config example:

SW1#sh spanning-tree summary
Portfast Default             is enabled
PortFast BPDU Guard Default  is enabled
interface FastEthernet0/2
 switchport access vlan 6
 switchport mode access
 switchport voice vlan 3


Hello Boris

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:

  1. 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.
  2. 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.
  3. Although rare, it has happened that faulty cables have caused problems with BPDU guard being tripped.

I suggest you check out the following:

  1. Verify that the err-disable reason is indeed due to BPDU Guard
  2. 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…

I hope this has been helpful!



Hello Laz
Thanks a lot.

1 Like

Hi Rene,

Don’t do access ports by default already receive BPDU’s in case there is a topology change or only on trunk ports?


Hello Walter

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.

I hope this has been helpful!


Hi Laz,

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

Hello Walter

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.

I hope this has been helpful!