Difference between Spanning Tree Protocol (STP) and Rapid Spanning Tree Protocol (RSTP)
1. The main difference between Rapid Spanning Tree Protocol (RSTP IEEE 802.1W) and Spanning Tree Protocol (STP IEEE 802.1D) is that Rapid Spanning Tree Protocol (RSTP IEEE 802.1W) assumes the three Spanning Tree Protocol (STP) ports states Listening, Blocking, and Disabled are same (these states do not forward Ethernet frames and they do not learn MAC addresses). Hence Rapid Spanning Tree Protocol (RSTP IEEE 802.1W) places them all into a new called Discarding state. Learning and forwarding ports remain more or less the same.
2. In Spanning Tree Protocol (STP IEEE 802.1D), bridges would only send out a BPDU when they received one on their Root Port. They only forward BPDUs that are generated by the Root Switch (Root Bridge). Rapid Spanning Tree Protocol (RSTP IEEE 802.1W) enabled switches send out BPDUs every hello time, containing current information.
3. Spanning Tree Protocol (STP IEEE 802.1D) includes two port types; STP Root Port and Designated Port. Rapid Spanning Tree Protocol (RSTP IEEE 802.1W) includes two additional port types called as alternate ports and backup ports.
An alternate port is a port that has an alternative path or paths to the Root Switch (Root Bridge) but is currently in a discarding state (can be considered as an additional unused Root Port). A backup port is a port on a network segment that could be used to reach the root switch, but there is already an active STP Designated Port for the segment (can be considered as an additional unused designated port).
|
Table View STP (802.1d)
|
Rapid STP (802.1w)
|
|
In stable topology only the root sends BPDU and relayed by others.
|
In stable topology all bridges generate BPDU every Hello (2 sec) : used as“keepalives” mechanism.
|
|
Port states
|
|
|
Disabled Blocking Listening Learning Forwarding
|
Discarding (replaces disabled, blocking and listening) Learning Forwarding
|
|
To avoid flapping, it takes 3 seconds for a port to migrate from one protocol to another (STP / RSTP) in a mixed segment.
|
|
|
Port roles
|
|
|
Root (Forwarding) Designated (Forwarding) Non-Designated (Blocking)
|
Root (Forwarding) Designated (Forwarding) Alternate(Discarding)Backup (Discarding)
|
|
Additional configuration to make an end node port aport fast (in case a BPDU is received).
|
- An edge port (end node port) is an integrated Link type which depends on the duplex : Point-to-point for full duplex & shared for half duplex).
|
|
Topology changes and convergence
|
|
|
Use timers for convergence (advertised by the root):
Hello(2 sec)
Max Age(20 sec = 10 missed hellos)
Forward delay timer (15 sec)
|
- Introduce proposal and agreement process for synchronization (< 1 sec).- Hello, Max Age and Forward delay timer used only for backward compatibility with standard STP
|
|
Only RSTP port receiving STP (802.1d) messages will behaves as standard STP.
|
|
|
Slow transition (50sec): Blocking (20s) =>Listening (15s) =>Learning (15s) =>Forwarding
|
Faster transition on point-to-point and edge ports only:Less states – No learning state, doesn’t wait to be informed by others, instead, actively looks for possible failure by RLQ (Request Link Query) a feedback mechanism.
|
|
Use only 2 bits from the flag octet:Bit 7 : Topology Change Acknowledgment.Bit 0 : Topology Change
|
Use other 6 bits of the flag octet (BPDU type 2/version 2): Bit 1 : ProposalBit 2, 3 : Port roleBit 4 : LearningBit 5 : ForwardingBit 6 : AgreementBit 0, 7 : TCA & TCN for backward compatibility
|
|
The bridge that discover a change in the network inform the root, that in turns informs all others by sending BPDU with TCA bit set and instruct them to clear their DB entries after “short timer” (~Forward delay) expire.
|
TC is flooded through the network, every bridge generate TC (Topology change) and inform its neighbors when it is aware of a topology change andimmediately delete old DB entries
|
===
Handling Direct Link Failures:
----------------------------------
* If the port was blocking, nothing happens
* If the port was designated, local bridge does nothing. However,
downstream bridge may detect the loss of a root port and start reconverging
* If the port was root port, information stored with the root port is invalidated
and the bridge attempts to elect new root port based on stored
information. If such port can be found, it is unblocked and transitioned
through Listening/Learning states.
* If there are no more root ports left after the link failure, the bridge declares
itself as root and starts announcing that in BPDUs. Downstream bridges
will ignore this information until old information expires
Handling Indirect Link Failures:
-------------------------------------
* If an upstream bridge loses a root port but has alternate path, new root port is
elected, and BPDUs continue to flow, possible with different root path cost. Local
bridge receives these BPDUs on either its root port or blocked port. Based on the
new information, it may elect to unblock the blocked port and change the root
port. If that does not happen, no re-convergence is required locally. If the new
port is elected, it takes 2xForward_Time to make it forwarding.
Topology Changes in STP:
-------------------------------
* The bridge that originally detected topology change needs
to signal it to the whole domain. One obvious way is to flood this information
through domain using the existing spanning tree, but in STA only the root bridge
is sending the configuration information
-> The bridge that detect a link going forwarding of going down, starts
sending TCN BPDUs out of its root port. It does so every Hello_Interval
seconds (configured locally, not learned from the root bridge) and until the
upstream bridge sends a BPDU with TCN Acknowledge bit set
-> Every bridge that receives and acknowledges a TCN BPDU on its
designated port starts sending TCN BPDU on its root port, until it is in turn
acknowledged. This process continues upstream until it reaches the root
bridge.
-> When the root bridge receives and acknowledges the TC BPDU, it sets
TCN flag in all outgoing Configuration BPDUs sent downstream. The flag
will be set for the duration of Max_Age+Forward_Time seconds.
-> Every bridge that hears Configuration BPDU with the Topology Change
(TC) flag set reduces MAC address learning table aging time from the
default interval (300 seconds) to Forward_Time seconds. This facilitates
quick information aging and new MAC address learning.
BackBone Fast:
----------------
A-----B
| |
| |
C-----D
A is the root and port connecting D to B is the root port and port connecting to C is in blocking state.
If the link connecting C and A goes down then C declares itself as a root and starts sending BPDU's
When D receives inferior BPDU's then it creates a RLQ(Root Link Query) BPDU's out of root ports and alternate ports.
It contains :
-> Query Bridge ID
-> The Bridge ID of what querying bridge considers the current Root Bridge.
** Every bridge that receives the RLQ, checks the Root Bridge ID in the
query and performs either of the following:
-> If this Root Bridge ID matches the current root information stored
locally, the bridge relays the RLQ upstream, across its root port.
o If the bridge receiving the RLQ is the root bridge, it floods a positive
RLQ response out of ALL its designated (downstream) ports. In our
example, this is the case, and “A” immediately responds
->If the bridge receiving the RLQ has different root bridge information
other than one found in RLQ, it immediately responds with a
negative RLQ, flooded out of all designated (downstream) ports.
-> RLQ responses are flooded by every bridge downstream out of all
designated ports. Only the bridge that finds it to be the originator of the
RLQ will not flood the responses further.
-> When the originating bridge receives a negative response on any
upstream port, it immediately invalidates the information stored with this
port, and moves it to the Listening state, starting BPDU exchange. If the
RLQ response was positive, the information stored with the local root port
is considered to be valid. The bridge waits for responses on all upstream
ports. If all responses were negative, the querying bridge declares loss
of connectivity to the old root. In this case, the local bridge declares itself
as the new root bridge and starts listening to the inferior information
received on previously blocked port. This starts new root bridge election
bypassing the Max_Age timeout needed to expire old root bridge
information.
-> If at least one RLQ response was positive, the querying bridge knows
that it still has healthy path to the current root. The bridge then unblocks
the port that received the original inferior BPDU and moves this port to
Listening state. This allows the bridge to start sending information about
the current root to the bridge that thinks it lost connection to the root
bridge.
In our example, when C crashes, it starts sending inferior information to D. D will
receive inferior BPDU from C and respond by sending RLQ BPDU to B. The
information will be propagated upstream to A, which will respond back to B and
finally D will learn that the path via B is working. After this, D will unblock its port
connected to C and make it designated, allowing for BPDUs to flow down to C
and letting C to learn the new path to the root quicker.
RSTP Sync Process:
=============
Topology changes are handled slightly different from STP. First, the goal of
RSTP is fast re-convergence. Since ports are assumed to transition to forwarding
relatively fast, simply increasing MAC address aging speed is not enough. Thus,
when a topology change is detected, RSTP instructs the bridge to flush all MAC
address table entries. With Ethernet, this process results in unconstrained
flooding until the moment MAC addresses are re-learned. The bridge detecting a
topology change sets the TC (Topology Change) bit in all outgoing BPDUs and
starts sending BPDUs with the TC bit set upstream through the root port as well.
This marking lasts for TCWhile=2xHelloTime seconds and allows the detecting
bridge the start the flooding process.
Every bridge that receives a BPDU with TC bit set, should receive it on either
root port (coming from upstream) or designated port (coming from downstream).
The receiving bridge performs the following:
-> Flushes all MAC addresses associated with all ports with except to the
port where the TC BPDU was received
-> Repeats the flooding procedure by starting TCWhile timer and setting the
TC bit for all BPDUs sent upstream or downstream. The receiving port is
excluded from flooding, in order to ensure flooding procedure termination.
There is no need to flush MAC addresses on the port receiving the TC BPDUs as
the downstream section will only originate a TC BPDU if a “Link Up” event was
detected. Thus, the downstream section could only potentially learn additional
MAC addresses, but not lose any of the existing.
Optimization:
--------------
* only a link going into forwarding state causes the topology change event.
* Links going down do not result in any changes, as loss of connectivity does not provide new paths in the topology
* edge links (PortFast links) don’t create any topology changes, even if they become forwarding.
* no TCN BPDUs are ever flooded out of the edge ports, as there is assumed to be no bridges connected downstream.
No comments:
Post a Comment