Dear Friends of my Transmission Fraternity,
First of all I would like to apologize to my transport fraternity for being so late in posting a new topic. Actually these days was very busy and was actually searching for the right topic to actually start this chain of posts. Many of my friends have now evolved from being a pure TDM guy to a person who has a good hand ont he TDM as well as Ethernet technologies.
However, like every new person the newly evolved people also have a tendency to go overboard and get carried away. Just like babies, who take the first successful step and then get carried away and take further steps which are ostentatious in nature. The result, a fall, a stumble or even worse getting hurt.
My today's topic is dealing with one such stumbles that newly evolved people have. But before I start please note one thing and one thing very seriously. Technology is something that always changes and evolves, so carrying a baggage of so called "Experience" in your head would actually not help. Learning technology should be understood with the fact that every day you are a fresher.
The word "Experience" is good to understand what were your mistakes in past and what "Should NOT be done" however what SHOULD be done is governed by serious rules of technical understanding and YOUR and only YOUR SKILL........
Today we are going to talk about RSTP/MSTP in the network of Layer-2. Understand that RSTP/MSTP should be only used when you are having a Layer-2 emulation. When the Ethernet is only needed to be encapsulated in SDH and sent from one point to another then the Layer-2 should not be mixed with it.
As I have mentioned in the previous blog the EoS trail is just an infrastructure and not an entity that decides the flow of the traffic. The actual decision of traffic flow is taken by the VPN or the EVC.
Misconceptions about RSTP:
1. RSTP is a protection mechanism in Layer-2.
2. RSTP should alwaysbe used in L2 implementations.
Facts:
1. RSTP is a loop avoidance mechanism when Ethernet rings are formed.
2. RSTP is not mandatory, it should be used and judiciously enough for L2 simulations. Better off to be used when the number of NEs are less.
While I am not explaining what is RSTP because you can really find this in the link below.
RSTP Explained properly in Wikipedia
We should be clearly understanding when to use RSTP and most important when not to enable RSTP.
RULE -1: USE RSTP ONLY IN SMALLER DOMAINS
The rule is very simple. Remember RSTP is a data plane protocol and has a lot of exchanges of BPDUs from one to another. So unnecessary loading of more and more elements in the RSTP domain may create and is infact creating problems in many networks. The best example is to create smaller domains of RSTP.
In the case these domains need to be interconnected wth each other this should be done in two ways.
1. By means of Trunk trails where RSTP is disabled.
2. By means of Layer -3 segmentation.
As you can see in the picture that various domains or rings of RSTP are actually segregated by interconnections of RSTP disabled links. If the traffic was to travel from a NE in ring -1 to a NE in Ring 2 then it actually would have the RSTP loop Prevention in the ring and then would travel the gateway links.
The gateway links can be protected by means of Layer-1 protection or ASTN. If these links are that between two routing elements then they are actually running the OSPF or a simple CIDR alternate routes.
What happens if you enable the RSTP on these links?????
Well, a mistake that all my tranmission friends do, and yes pay heavily for it and also ring the guts out of the support centres.
Understand that RSTP is a topology based protocol. If this is enabled throughout then you will not have multiple domains of RSTP but a single converged domain of RSTP. Hence there would be only one root bridge in this entire setup. And this may be any one. The BPDU flow path is now much more complex than simple ring paths and this makes making flows and VPNs more difficult and trouble shooting even more difficult.
This also results into more overloading of the CPU of the NEs which result to NEs being stuck and NEs being mis managed and traffic going hay wires. In short....Total .... Sheer....MESS......
Of course, this also lets your boss and your management think; "TDM waalon ko ye manage karna aayega ya nahin"....
So my transmission fraternity, please do not do this mistake and understand the intricacies.
RULE NO: 2 SELECT A PROPER ROOT BRIDGE
If you read very carefully the document of RSTP then you will understand that it is the selection of Root Bridge that happens first. Letting a protocol actually select the root bridge is the work of a nerd fresh pass out, who lets the system actually control him. A clever planner and a true transport "ENGINEER" and not a "FREAKING ONE MONTH COURSEWARE" will actually call his own shots and plan the root bridge in the right manner.
So interpret the document carefully of the protocol. The purpose of the Root Bridge is actually to guide the entire process of the network. So the root bridge should always preferably be the aggregation point of the Network. Most of the transmission networks are of Aggregate and collector/access kinds so in this it is very easy to locate as to which is an aggregator and which is an access.
The true engineer would actually lower the bridge priority of the aggregation node an then would keep the priorities of the other access nodes at par. Also he would keep the bridge priority of the alternate node that would become bridge at the second lowest figure so that if the root bridge fails that NE and only that NE becomes the alternate root bridge.
This system gives him good control over the network and then it also enables him to have better trouble shooting and more towards a self healing network.
I am putting two pictures over here. One of this is Right way and one of this is the wrong way. Let us see the wrong way first.
The next picture is the right way of configuring the RSTP ring. Which truly a transport engineer does.
What happens if you do not follow this rule????
Hmm, there can be many excuse not following this rule. eg
1. Why should I not stick to default? Well, default password for windows is also no password and even that is asked to change.
2. My guidelines from planning says not to change default values??? I wished your guidelines also repaired your faults when they occured and trouble shot themselves. But unfortunately they don't do that.
3. I will have to maintain a table? If you are sensible enough you will know for sure what is the aggregation node. So you won't need to maintain a table.
The bottom line is that when you yourself give the bridge priorities then the root bridge and alternates are sure shot ones. So even if there are any replacements in the rings then these replacements do not change the overall computation of the RSTP.
This means that we will actually have more control all the time, even when such replacements, removals and addition activities are done in the network. You don't need to worry about your RSTP going for New Bridge selections again and again.
Another thing is that it helps you optimize traffic. Which we will discuss in the next part.
I will post many such articles on the deadly RSTP and MSTP.... Till then my transport friends please remember the following.
1. Do not play with parameters in Data, as each and every one of them have their significance.
2. Before doing deployments keeping only default in mind just understand the technology.
Still to come in the next parts.
1. Blocking port selection.
2. Traffic optimization.
3. Flow routing in RSTP.
Have a great week ahead.
Cheers!!!!!
Kalyan.
First of all I would like to apologize to my transport fraternity for being so late in posting a new topic. Actually these days was very busy and was actually searching for the right topic to actually start this chain of posts. Many of my friends have now evolved from being a pure TDM guy to a person who has a good hand ont he TDM as well as Ethernet technologies.
However, like every new person the newly evolved people also have a tendency to go overboard and get carried away. Just like babies, who take the first successful step and then get carried away and take further steps which are ostentatious in nature. The result, a fall, a stumble or even worse getting hurt.
My today's topic is dealing with one such stumbles that newly evolved people have. But before I start please note one thing and one thing very seriously. Technology is something that always changes and evolves, so carrying a baggage of so called "Experience" in your head would actually not help. Learning technology should be understood with the fact that every day you are a fresher.
The word "Experience" is good to understand what were your mistakes in past and what "Should NOT be done" however what SHOULD be done is governed by serious rules of technical understanding and YOUR and only YOUR SKILL........
Today we are going to talk about RSTP/MSTP in the network of Layer-2. Understand that RSTP/MSTP should be only used when you are having a Layer-2 emulation. When the Ethernet is only needed to be encapsulated in SDH and sent from one point to another then the Layer-2 should not be mixed with it.
As I have mentioned in the previous blog the EoS trail is just an infrastructure and not an entity that decides the flow of the traffic. The actual decision of traffic flow is taken by the VPN or the EVC.
Misconceptions about RSTP:
1. RSTP is a protection mechanism in Layer-2.
2. RSTP should alwaysbe used in L2 implementations.
Facts:
1. RSTP is a loop avoidance mechanism when Ethernet rings are formed.
2. RSTP is not mandatory, it should be used and judiciously enough for L2 simulations. Better off to be used when the number of NEs are less.
While I am not explaining what is RSTP because you can really find this in the link below.
RSTP Explained properly in Wikipedia
We should be clearly understanding when to use RSTP and most important when not to enable RSTP.
RULE -1: USE RSTP ONLY IN SMALLER DOMAINS
The rule is very simple. Remember RSTP is a data plane protocol and has a lot of exchanges of BPDUs from one to another. So unnecessary loading of more and more elements in the RSTP domain may create and is infact creating problems in many networks. The best example is to create smaller domains of RSTP.
In the case these domains need to be interconnected wth each other this should be done in two ways.
1. By means of Trunk trails where RSTP is disabled.
2. By means of Layer -3 segmentation.
As you can see in the picture that various domains or rings of RSTP are actually segregated by interconnections of RSTP disabled links. If the traffic was to travel from a NE in ring -1 to a NE in Ring 2 then it actually would have the RSTP loop Prevention in the ring and then would travel the gateway links.
The gateway links can be protected by means of Layer-1 protection or ASTN. If these links are that between two routing elements then they are actually running the OSPF or a simple CIDR alternate routes.
What happens if you enable the RSTP on these links?????
Well, a mistake that all my tranmission friends do, and yes pay heavily for it and also ring the guts out of the support centres.
Understand that RSTP is a topology based protocol. If this is enabled throughout then you will not have multiple domains of RSTP but a single converged domain of RSTP. Hence there would be only one root bridge in this entire setup. And this may be any one. The BPDU flow path is now much more complex than simple ring paths and this makes making flows and VPNs more difficult and trouble shooting even more difficult.
This also results into more overloading of the CPU of the NEs which result to NEs being stuck and NEs being mis managed and traffic going hay wires. In short....Total .... Sheer....MESS......
Of course, this also lets your boss and your management think; "TDM waalon ko ye manage karna aayega ya nahin"....
So my transmission fraternity, please do not do this mistake and understand the intricacies.
RULE NO: 2 SELECT A PROPER ROOT BRIDGE
If you read very carefully the document of RSTP then you will understand that it is the selection of Root Bridge that happens first. Letting a protocol actually select the root bridge is the work of a nerd fresh pass out, who lets the system actually control him. A clever planner and a true transport "ENGINEER" and not a "FREAKING ONE MONTH COURSEWARE" will actually call his own shots and plan the root bridge in the right manner.
So interpret the document carefully of the protocol. The purpose of the Root Bridge is actually to guide the entire process of the network. So the root bridge should always preferably be the aggregation point of the Network. Most of the transmission networks are of Aggregate and collector/access kinds so in this it is very easy to locate as to which is an aggregator and which is an access.
The true engineer would actually lower the bridge priority of the aggregation node an then would keep the priorities of the other access nodes at par. Also he would keep the bridge priority of the alternate node that would become bridge at the second lowest figure so that if the root bridge fails that NE and only that NE becomes the alternate root bridge.
This system gives him good control over the network and then it also enables him to have better trouble shooting and more towards a self healing network.
I am putting two pictures over here. One of this is Right way and one of this is the wrong way. Let us see the wrong way first.
The next picture is the right way of configuring the RSTP ring. Which truly a transport engineer does.
What happens if you do not follow this rule????
Hmm, there can be many excuse not following this rule. eg
1. Why should I not stick to default? Well, default password for windows is also no password and even that is asked to change.
2. My guidelines from planning says not to change default values??? I wished your guidelines also repaired your faults when they occured and trouble shot themselves. But unfortunately they don't do that.
3. I will have to maintain a table? If you are sensible enough you will know for sure what is the aggregation node. So you won't need to maintain a table.
The bottom line is that when you yourself give the bridge priorities then the root bridge and alternates are sure shot ones. So even if there are any replacements in the rings then these replacements do not change the overall computation of the RSTP.
This means that we will actually have more control all the time, even when such replacements, removals and addition activities are done in the network. You don't need to worry about your RSTP going for New Bridge selections again and again.
Another thing is that it helps you optimize traffic. Which we will discuss in the next part.
I will post many such articles on the deadly RSTP and MSTP.... Till then my transport friends please remember the following.
1. Do not play with parameters in Data, as each and every one of them have their significance.
2. Before doing deployments keeping only default in mind just understand the technology.
Still to come in the next parts.
1. Blocking port selection.
2. Traffic optimization.
3. Flow routing in RSTP.
Have a great week ahead.
Cheers!!!!!
Kalyan.
Nice one - Thanks !
ReplyDeleteWas hoping to see some dedicated pointers to MSTP issues too (as heading might suggest) - hope it will come in following post.
Hi Kobi, For sure will do that. As you can see this is in parts so as we close in more we will also see the MSTP story. The best part is interacting RSTP with MSTP.
DeleteSir Thanks for sharing with us , Also requesting one detailed view on convergence timing of RSTP/MSTP , mainly MSTP.
ReplyDeleteHi Nishant, For sure I will provide that. However, please remember that use RSTP first to have loop avoidance. The convergence time is actually a de-facto phenomenon. Remember the RSTP is low in convergence because it is in a proposal and agreement mechanism. So you don't have discarded ports in RSTP but you have Alternate ports. Same in MSTP as well. However in MSTP the best part is on the basis of a service VLAN you can define the blocking path.
Delete