Spanning-tree portfast edge & network

Hello Rene,
I received one of the virl switch images and was building a lab testing spanning tree. Can you tell me what is the difference between the commands listed below:

#spanning-tree portfast edge 
#spanning-tree portfast network
#spanning-tree normal  

and when should you use which one? Also i read the lessons on both spanning-tree uplinkfast and spanning-tree backbonefast. Both commands seem to do the same thing , fast convergence if a link or indirect link fails. Maybe i am not understanding the lessons. Is there a preference in using one over the other? Can both commands be enabled at the same time on a switch?
Thakns again,
Cecil

Hello Cecil!

I’ll go through your questions below.

  • portfast edge is used to configure a port on which an end device is connected, such as a PC. All ports directly connected to end devices cannot create bridging loops in the network. Therefore, the edge port directly transitions to the forwarding state, and skips the listening and learning stages. However, the specific command configures a port such that if it receives a BPDU, it immediately loses its edge port status and becomes a normal spanning-tree port.
  • You use the portfast network on trunk ports to enable bridge assurance feature which protects against loops by detecting unidirectional links in the STP topology. But normally bridge assurance is enabled by default.
  • A spanning tree normal port is one that functions in the default manner for spanning tree. Under normal circumstances it will transition from the Listening, Learning, Forwarding stages based on the default timers.

The major difference between the two is the following:

  • Uplinkfast is used when you want to quickly enable the blocked port on a switch when the root port link has failed.
  • Backbonefast is used when the switch under normal circumstances doesn’t have a blocked port and the root port receives an inferior BPDU. Essentially, it is used to quickly recalculate after an indirect link failure, that is, when a bridge has to change the status of some of its ports because of a failure on a link that is not directly attached to it.

You can find more detailed information about these two features and how to configure them in the following two links:

I hope this has been helpful!

Laz

1 Like

Hello Lazaros,
Thanks for answering my question. You have cleared things up for me. Also thanks for the additional reading info…

1 Like

Hi,

please allow one additional question to this old thread: This tells me that the “edge” command disables loop detection. Right? All of our ports connected to IP phones are configured as “edge”. If someone onsite accidentially connects both network ports of the IP phone into the network outlet this would cause a loop, so that we should not use the edge command, right?

Thanks and regards,
Tim

Hello Tim

Edge ports are configured such that they immediately go to the forwarding state. However, this does not mean that there is no loop protection. It is assumed that edge ports will connect to end devices, and thus it is convenient for them to go directly to the forwarding state.

However, someone can try to plug in a switch on such a port and can try to become the root bridge or may connect to multiple ports and create a loop. That’s where you should use BPDUGuard. On all edge ports, BPDUGuard should be enabled so that as soon as such a port receives a BPDU, it will go into err-disabled state, thus preventing an L2 loop.

Now keep in mind that for RSTP, if you don’t enable BPDUGuard, and a BPDU is received on an edge port, the edge port simply loses its edge port status.

For basic STP, BPDUGuard configuration, take a look at this lesson:

I hope this has been helpful!

Laz

1 Like

Hi Lazaros,

thanks, perfect!

Regards
Tim

1 Like