Spanning-Tree Bridge Assurance

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hello Rene,

If I understand Rapid-PVST+ correctly, with rapid-pvst+ configured, it syncs with its neighbors by sending BPDU every hello time interval as a keep alive. Does Bridge assurance play a role with rapid-pvst+? Or by natural it’s not supported in rapid-pvst+ as it’s not needed?

Thanks!!

3

Hello Ray

As mentioned by Rene, bridge assurance is only supported by PVRST+ and MST. PVRST+ is the same as Rapid PVST+. So to answer your question, bridge assurance does indeed play a role and it is supported. Note in the following Cisco documentation of the bridge assurance command that it states that it is compatible with Rapid PVST+ and MST.

I hope this has been helpful!

Laz

4

Thanks Laz!

Isn’t BA built-in in PVRST+ ? By defualt, it syncs with its neighbors by sending BPDU every hello time interval as a keep alive. Why do we need a separate command to enable it ?

1 Like
5

Hello Ray

Depending on the platform, the default state of bridge assurance may differ. On the 6500 series for example, bridge assurance is enabled globally by default and is enabled only on spanning tree network ports that are point to point links. On Nexus switches, it is enabled globally but disabled on individual ports and must be manually enabled.

The feature is specifically used to protect against a unidirectional link failure or other software failure and against a device that may continue to forward data traffic when it is no longer running the spanning tree algorithm.

Now there are times when you may want to disable this feature (or enable it on a port where it is disabled by default). Such instances are if you have a device on the other side of the point to point link that may not support it. If it is enabled only on one side of a link, the port will go into the blocking state.

You can find out more about how it works (at least for the 6500 catalyst platform) at this Cisco Documentation.

I hope this has been helpful!

Laz

1 Like
6

Hello Rene,

whats the difference between loopguard and bridge assurance?

Thanks a lot.

7

Hello Lukas

In its operation, STP relies on a continuous reception and transmission of BPDUs to determine the port role. Typically, a designated port transmits BPDUs and a non-designated port receives BPDUs.

Now when one of the ports in a redundant topology no longer receives BPDUs, STP believes that the topology is loop free. A blocked port in such a situation would become a designated port and move into ta forwarding state and this creates a loop. Now a topology is especially vulnerable to this when there is a unidirectional failure, that is, that traffic begins to flow only in one direction on a link.

Now loopguard makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into an STP loop-inconsistent blocking state, thus maintaining the loop free topology.

Bridge Assurance adds additional check to this procedure. Specifically, unlike loopguard, BPDUs are sent out of ALL operational network ports wherever it is enabled including alternate and backup ports. Similarly to loopguard, if a port does not receive a BPDU for a specified period, the port moves into an inconsistent state.

This fact allows bridge assurance to perceive situations that loopguard cannot such as:

  1. the fact that loopguard can only be enabled on root and alternate ports and not on designated ports
  2. loopguard is ineffective at detecting a port that has been unidirectional since link-up.

Bridge Assurance causes BPDUs to travel in both directions on all ports verifying health and awareness of switches. In other words, in the worst case scenario, if STP fails for whatever reason, it will fail by blocking rather than by unblocking an port, thus ensuring that a loop is not inadvertently created.

I hope this has been helpful!

Laz

4 Likes
8

Thanks a lot :slight_smile: this was really helpful

1 Like
9

Hello Lazaros,
your post has been very helpful for me, but I still can come up with a (“2.loopguard is ineffective at detecting a port that has been unidirectional since link-up.”) situation. If you can give an example.
The loop problem come when a block port decide to change to forwarding when it shouldn’t.
The thing is if I have loopguard enable in all my blocked ports ( and root port (non-designated)), whenever they stop receiving bdpu they will go to an inconsistent state.
From my understanding only root or alternate ports are the ones who can change the state, for the same reason they are the ones that not send but receive bdpu, and its where you should have loop guard enable.
Thanks in advance.

10

Hello Ignacio

Such a situation would occur if a fibre optic port is initially connected with only one of the two fibres resulting in unidirectional link from the moment the link goes up. Loopguard will not “kick in” unless both fibres were initially connected and then one of them subsequently failed.

Let’s think about ports that rely on timely arrival of BPDUs to maintain their current role and state. These are root ports, alternate ports and backup ports. Loopguard is especially useful for the alternate and backup ports because these ports are in a discarding state. If they cease to receive BPDUs, they will move into the forwarding state possibly creating a loop.

So, Loopguard should be applied at least to alternate ports. However, because in a per-VLAN environment each trunk port can have various diverse roles or states for individual VLANs, it is good practice to simply configure loopguard on all ports using the global configuration level command spanning-tree loopguard default.

I hope this has been helpful!

Laz

1 Like
11

Hello guys,

What`s the difference between loopguard, dispute and bridge assurance?

Thanks!

12

Hello Marcelo

Without bridge assurance, a switch with a blocked port will not receive BPDUs on that port. This means that it cannot detect any changes (or malfunctions) that may occur on the switch connected to that port. With bridge assurance, even blocked ports will receive and process BPDUs allowing them to detect the STP state of the switch attached to their blocked ports. Bridge assurance is enabled by default on all ports participating in STP by default. Bridge assurance is supported on high end IOS platforms such as the 6500 and on nexus platforms as well.

Loopguard seems to do the same thing, but it’s purpose is slightly different. It is used to deal with unidirectional link failures, where communication in one direction is lost and BPDUs are lost as a result. When loopguard is enabled, any interface that does not receive BPDUs will go into loop-inconsistent state to prevent such an occurrence.

Now here are a couple of differences:

  1. Loopguard is not enabled by default
  2. Loopguard is a feature available on all IOS platforms, unlike bridge assurance
  3. Loopguard can only be enabled on root and alternate ports, but cannot run on designated ports
  4. Loopguard is ineffective at detecting a port that has been unidirectional since the link came up. It only detects a change in the behaviour (lack of BPDUs) and will not kick in if no BPDUs were ever seen on the link.

I hope this has been helpful!

Laz

1 Like
13

Hi Laz
When you say “Without bridge assurance, a switch with a blocked port will not receive BPDUs on that port. This means that it cannot detect any changes (or malfunctions) that may occur on the switch connected to that port. With bridge assurance, even blocked ports will receive and process BPDUs allowing them to detect the STP state of the switch attached to their blocked ports.”

I want to disagree with you. I thought a non-designated (blocking) port without bridge assurance relied on BPDUs sent from the designated port on the link to maintain the role?

14

Hello Matt

Let me clarify what I meant. The bridge assurance feature must be applied on the switch opposite the blocked port, not on the blocked port itself. That way, the blocked port will be able to detect changes through the received BPDUs. However, because the port roles are dynamically assigned, the feature should be enabled network-wide. That way, all switches will continue to send/receive BPDUs.

You’re correct that in STP, a non-designated (blocking) port does indeed rely on BPDUs from the designated port to maintain its role and state. However, what Bridge Assurance adds to this is a mechanism to prevent loops in the network when there’s a unidirectional link failure.

Without BA, if a switch stops receiving BPDUs on its blocking port (due to a unidirectional link failure or malfunction on the other switch), it would not be aware of this and would continue to block, potentially leading to a loop.

With BA enabled, both switches (designated and non-designated) send out BPDUs on all operational ports, including blocking ones. If a switch stops receiving BPDUs on a port, it will move that port into an inconsistent state, effectively disabling it and preventing possible loops.

So, while you’re right that a blocking port without BA relies on BPDUs from the designated port, BA provides an additional layer of protection against certain types of network failures. Does that make sense?

I hope this has been helpful!

Laz