rstp on shared medium

Answered Question
Sep 13th, 2008

hi every body!

Rstp treat half duplex port as shared medium. My question is if a switch loses non-edge half duplex link, how does convergence occur in rstp?

thanks a lot and have a nice weekend!

I have this problem too.
0 votes
Correct Answer by Francois Tallet about 8 years 2 months ago

Hi Sarah,

A designated port only sends a proposal when it is discarding (blocking) and needs to go forwarding. If is receives an agreement, it can go forwarding immediately, else it keeps proposing while expiring its timers.

Here, the designated port on sw4 leading to 0/2 on sw2 is already forwarding. It will not propose at all.

Port f0/2 on switch 2 is not designated, it is a root port and goes forwarding immediately.

Regards,

Francois

Correct Answer by Francois Tallet about 8 years 2 months ago

The answer is that the designated port on sw1 does not have to know;-)

The proposal agreement mechanism is just to allow designated port to go forwarding quickly.

Root ports go forwarding immediately, without proposal agreement (well, there are some few condition, such as the previous root port must be discarding before the new root port goes forwarding).

In your case, sw2 lost its connection to the root. Its port 0/2 is down or moved to discarding, and port the previously alternate 0/1 is immediately selected as a root forwarding port.

Regards,

Francois

Correct Answer by Francois Tallet about 8 years 2 months ago

So if the link is shared, the inital spec of RSTP and MST would just do a slow transition to forwarding. If a port is blocked and needs to go forwarding, it would still propose but will not get an agreement and thus go through the listening/learning states before going to forwarding.

The latest spec have introduced an enhancement. The designated port proposes on the shared segment. The peers send back an agreement (after performing a sync if necessary). The designated port does not go forwarding when it receives the agreement (because it cannot track all its neighbors), but it only waits 2xhello time before going to forwarding.

This mechanism must be supported by all the switches on the shared segment (because the designated port assumes that they would have successfully sync in 2xhello-time). Cisco has not implemented it yet. As you said, there is not much use of shared segments in local area networks. They are somewhat coming back with emulated lans (802.1ad, VPLS etc...) but it's generally a good idea to avoid running STP over them.

Regards,

Francois

Correct Answer by Francois Tallet about 8 years 2 months ago

STP does not care, it does not perform the proposal/agreement mechanism and would be equally slow on shared or p2p links.

Regards,

Francois

Correct Answer by Jon Marshall about 8 years 2 months ago

Sarah

Rstp can only achieve rapid convergence on full duplex point-to-point links. If you have a non-edge port that is running in half-duplex then rstp cannot achieve the fast convergence it can with full duplex non-edge ports.

You can if you want explicitly configure a half-duplex port to be considered as a point-to-point link but rstp will see as it as shared port by default.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Correct Answer
Jon Marshall Sat, 09/13/2008 - 17:20

Sarah

Rstp can only achieve rapid convergence on full duplex point-to-point links. If you have a non-edge port that is running in half-duplex then rstp cannot achieve the fast convergence it can with full duplex non-edge ports.

You can if you want explicitly configure a half-duplex port to be considered as a point-to-point link but rstp will see as it as shared port by default.

Jon

sarahr202 Sat, 09/13/2008 - 19:53

thanks for your reply jon!

So let say sw1,sw2 and sw3 are connected by half duplex links in traingular fashion with sw1 acting as root switch.

If sw2 loses its root port, then how will the network converge considering rstp convergence is only possible for point to point full duplex links ?

thanks !

Francois Tallet Sat, 09/13/2008 - 20:44

In theory there is no relation at all between STP and whether the link is full or half duplex.

What STP can consider that a link is point to point as long as there is a single neighboring bridge on this link (this is important because the proposal agreement only works with a single neighbor).

It's just that by default, we assume that a full duplex link is going to be point to point, while a half duplex link is more likely to be connected to a shared segment and thus have several STP neighbor. In practice, both those assumption can be wrong.

For instance, considering the link as not being point to point because it is half duplex is wrong, because of the example that Sarah has just given. On the other hand, it is possible that a full duplex link connects your port to an emulated lan with several STP neighbor, in which case the assumption full duplex => point-to-point would be wrong.

That's why these assumption can be overridden by the spanning-tree link-type CLI.

Regards,

Francois

sarahr202 Sun, 09/14/2008 - 11:40

Thanks a lot Francois! Does stp also assume half dulex link being a shared medium besides rstp?

In nut shell, we can say if we have switches which are connected by half dupex link and we want to use rstp, then we must expilicity configure the half dupex link as point to point as rstp assume any half duplex being a shared medium,

sarahr202 Sun, 09/14/2008 - 12:30

just want to add to my last post.

how does stp behave if there are several switches on single shared medium like ethernet, some with reduntant links to network?

I understand it is very rare to find a netwotk where some switches are on the same shared medium but just out of curosity what if we such a network.

thanks a lot!

Correct Answer
Francois Tallet Sun, 09/14/2008 - 15:54

So if the link is shared, the inital spec of RSTP and MST would just do a slow transition to forwarding. If a port is blocked and needs to go forwarding, it would still propose but will not get an agreement and thus go through the listening/learning states before going to forwarding.

The latest spec have introduced an enhancement. The designated port proposes on the shared segment. The peers send back an agreement (after performing a sync if necessary). The designated port does not go forwarding when it receives the agreement (because it cannot track all its neighbors), but it only waits 2xhello time before going to forwarding.

This mechanism must be supported by all the switches on the shared segment (because the designated port assumes that they would have successfully sync in 2xhello-time). Cisco has not implemented it yet. As you said, there is not much use of shared segments in local area networks. They are somewhat coming back with emulated lans (802.1ad, VPLS etc...) but it's generally a good idea to avoid running STP over them.

Regards,

Francois

sarahr202 Mon, 09/15/2008 - 11:20

thanks a lot ! your reply raised another question .

let say sw1 sw2 and sw3 are connected by f0/1 ports to hub. All thses switches are connected to root switch sw4 by f0/2 ports which are root ports on each switch.

SW1 port f0/1 is selected as designated port on the shared medium.If sw2 loses its root port f0/2, there are two ways convergence could occur:

1) using initial spec, i.e listening, learning and forwarding states sw2 f0/2 blocked port go through.

2) using latest spec which means designated port proposes

My question is how the designated port which is port f0/2 on sw1 knows that sw2 f0/2 port needs to be unblocked?

Is it because sw2, having lost connection to root, will generate bpdu claiming to be root and send it to designated port f0/2 of sw1, is that how sw1' f0/2 designated find out about that sw1 has lost connection to root?

thanks a lot!

Correct Answer
Francois Tallet Mon, 09/15/2008 - 11:33

The answer is that the designated port on sw1 does not have to know;-)

The proposal agreement mechanism is just to allow designated port to go forwarding quickly.

Root ports go forwarding immediately, without proposal agreement (well, there are some few condition, such as the previous root port must be discarding before the new root port goes forwarding).

In your case, sw2 lost its connection to the root. Its port 0/2 is down or moved to discarding, and port the previously alternate 0/1 is immediately selected as a root forwarding port.

Regards,

Francois

sarahr202 Tue, 09/16/2008 - 08:51

thanks a lot! If designated port does not need to know, then how does it decides when to send proposal to sw2 f0/2 port?

Have a nice day!

Correct Answer
Francois Tallet Tue, 09/16/2008 - 09:10

Hi Sarah,

A designated port only sends a proposal when it is discarding (blocking) and needs to go forwarding. If is receives an agreement, it can go forwarding immediately, else it keeps proposing while expiring its timers.

Here, the designated port on sw4 leading to 0/2 on sw2 is already forwarding. It will not propose at all.

Port f0/2 on switch 2 is not designated, it is a root port and goes forwarding immediately.

Regards,

Francois

Correct Answer
Francois Tallet Sun, 09/14/2008 - 15:48

STP does not care, it does not perform the proposal/agreement mechanism and would be equally slow on shared or p2p links.

Regards,

Francois

Actions

This Discussion