Spanning-Tree BPDUGuard

Hi Ahmed,

In that case it might be wise to enable BPDUguard. If someone connects something that isn’t supposed to send BPDUs then it’s best to shut the interface with BPDUguard :slight_smile:

Rene

Hi,

spanning-tree portfast is enough ? or also spanning-tree portfast bpduguard must be enaled globally

Thanks

Sims,
In almost all cases you want to pair BPDUGuard with Portfast

Hi,

Thanks for easy clarification . Is my below statement correct :

BPDU Guard is only useful when we have ports on a switch where computers/laptops/servers are connected OR may connect in future so that by any chance they don’t send any BPDU on our switch port.

thats it ! right ?

Abhishek,
I would phrase is slightly differently:

BPDUGuard is used on ports where BPDUs are not expected to be received, but if BPDUs are received, the port will be placed into an error state.

BPDUGuard does not prevent devices from sending BPDUs (BPDU Filtering does this). BPDUGuard simply listens for BPDUs and takes an action if it hears them.

thanks Andrew , it clears the doubt.

Hi Rene,

Thank you for your great explanation on this, just got a question here.
In ideal scenario, if we just configure all switch ports which are not connected to other switches to be In access mode (will they still receive BPDUs?) and will that eliminate the need of BPDU guard to be configured on these ports?
Also if you can please explain a bit the difference between portfast and port mode access?

Thanks

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:

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!

Laz

1 Like

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

1 Like

Rene,

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 ?

Thanks
Durga

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!

Laz

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

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!

Laz

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 
CatSwitch-IOS(config)

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

spanning-tree portfast bpduguard default

I’ll change it :+1:

Rene

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?

Thanks,
Austin

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!

Laz

1 Like