RSTP/MSTP Part - IV SVLAN Demarcation of services and RSTP MESH topology

Night 02:00 AM
Day: Tuesday

A Call comes suddenly from one person.

" Sir  I had a RSTP ring, I created a new traffic link on the same ring. I did this to ensure another service flow is to be created for a different customer. However just on creating the same link my existing service went down."

Prima facie, when a transport guy hears such a call then it seems very wierd to him. I mean how can a different traffic go down when you just create a seperate link on your topology. For a person who is dealing with transport and for a person who is actually doing transport operations, such a statement is wierd.

However, let us not forget something that Provider Bridge has some different traits from the conventional transport. Not that these are very very out of the world but then as I had discussed in my earlier blog post unlike the TDM where a Trail or a Cross connect is the service Element in the case of Provider Bridge the Trail or Cross connect in the TDM is NOT the service element, it is only the INFRASTRUCTURE. The actual service element is the VPN. So the isolation of services is not done by the means of trail but it is done by the means of SVLAN.

Now let us understand what this guy had done. So we go back to the figure that was there before. A service between A and B that is already created.

There is already a traffic flowing from from Point A to Point B which is located in Client No -2. Now there is one more customer that is taking handoff from Client No 3 and this is a different customer.

So what was the first step done by the guy of the transport.

Now just see what happens when he is doing this.  He feels he will put this new set of  customer on a seperate Link between the root and the client -3 forgetting that the RSTP topology is already converged and the service of customer -1 is already running in this topology. But he decides ignoring all these to create another trail in the topology and this is what happens to the RSTP after he creates the new link.

Now RSTP is bound by its inherent rules, for n number of paths to the root bridge there will be n-1 paths in the blocking state. So in this case the Blocking path is re-calculated. Now you have the Path between Client -1 and Client -2 as blocking and Client-3 and Client 4 as blocking. However the new link that is created from Root to Client -3 is in forwarding mode.

RSTP has done its job but what about the service? The VPNs were actually  built round the ring and are still there. So for the traffic from Point A to Point B, where the VPNs are there they encounter two Blocking paths. This is shown in the figure below.

This is making the whole service go down for Service -1 and that is why my friend called me.

So is this a fault????     NO

Is this a configuration ERROR????? YES

So what should have been the Ideal way to configure the service number -2 in this case, without hampering any traffic?

To this we should again go to the previous posts where the service demarcation is done by the means of SVLAN.

As you can see in this figure you have diffent VPN for different Services in teh same topology and seperated by seperate SVLANs. The SVLAN or the service Vlan actually Seperates the services in a way that there is no Cross talk between different services. Of course they share the same infrastructure.

Each service can be Rate limited to its BW CAP by means of Policy and then both the VPN services can be delivered on teh same infrastructure.  Like this multiple services can be delivered.

This results to a proper ring optimization and good control of the traffic.


But does that mean that you cannot have Multiple topologies in the RSTP configuration?

Is it always that RSTP should always be in the form of a RING?

The answer is NO...

RULE NO 5: YOU CAN SIMULATE MULTIPLE ALTERNATE LINES OF DELIVERY WITH THE RSTP HOWEVER CARE HAS TO BE TAKEN THAT THE SERVICE IS ALSO ACCORDINGLY MAPPED.

So then let us see how the service mapping of Service - 1 between A and B should have been in the topology when another Link is actually present between the Root and the Client -3 considering the same topology convergences that happened before.

If we see at this figure and consider the VPN creations for Service -1 which is between A and B the changes are seen at location Root and Client -3.

In the Root where earlier you had only two WAN ports added you are now adding all the three WAN Ports.

And in Client 3 instead of making a transit VPN with two WAN ports we are not making Transit VPN with 3 WAN ports.

This will result in double failure protection also as now we have two alternate paths as opposed to one, however the most important thing is that the service has to be in accordance.

Same rules and infrastructure applies also for Service from X to Y.

The main thing to remember is that RSTP is an algorithm that is dependant on the topology creation so if RSTP is to be chosen then the Services have to be traced out according to the topology.

It is just like the case that in a linear equation if you have two variables and only one reference equation then you will not be able to solve it. Hence you need to keep one part Variable and one part in reference to it.

In the event you are using RSTP

1. The RSTP algorithm takes care of the topology transitions in the case of failure. ( So this is the variable and varrying part in your network).

2. The service should include all the WAN ports that are part of the RSTP topology. ( This should be the constant part).

In any dynamic algorithm that relies on Topology transitions (OSPF/ERP/IS-IS/BGP) the service is always consisting of the fact that the routing has to have possibilities of all the WAN.

So is the case in RSTP.

My advice to my transmission Fraternity:

1. Once you make the service as per the topology then things are very perfect.
2. Need not create new topologies for new services, because you are actually doing an imbalance to the equation.
3. If you do need to provide alternate paths then make sure that the Ports are also mapped accordingly in the path.

 HAVE A SUPERB WEEKEND AHEAD.........

Cheers....

Kalyan

Coming up next:

How does Switching take place in RSTP 

RSTP/MSTP Part-III How to create Services in the RSTP Topology

My Dear Friends of the Transmission Fraternity,

The last two posts about RSTP were actually how the functioning of RSTP happens, how there is a convergence happening, Root bridge etc. These properties and configurations of RSTP were actually related to the fact that there is a creation of a RSTP domain. However, what we have not understood in these entire thing is that how are services created in this domain and how is the traffic actually flowing inside the RSTP ring.

Knowing how to create the RSTP ring is just the start of the process. Actually the Data planning requires three major planning aspect and especially in scenarios like RSTP.

1. Topology planning (Covered in Parts I and II)
2. Service Planning and Alternate route Planning ( Is being covered in this section)
3. QoS planning and Service prioritization. ( Will be covered later as we learn about QoS).

RULE No 4: THE CREATION OF SERVICE IN A RSTP NETWORK SHOULD TAKE CARE OF THE ENTIRE RING CONVERGENCE:

Remember one thing over here that RSTP is a property that is closely associated with a topology. So how RSTP will behave is actually decided by the topology and not by the service. The service has to be planned on this ring taking a cue or taking a basis from how the RSTP is actually behaving.

To understand the creation of service let us first take the case of the topology of RSTP that we are taking into consideration for these services.

As you can see in the picture that there is a topology of RSTP , well defined, and we want to send the traffic from Point A to Point - B. We want to send in a way to satisfy the following things.

1. The traffic is able to cater well from A to B.
2. Whenever there is a ring failure in the active section there will be a switch of Path and there will be a proper re-routing of traffic without any kind of loops.
3. At no point of time there should be flooding in the network.

While this kind of traffic is being provisioned there will be the following panic points raised by the people who are actually just shifted from transmission and doing these kinds of configurations.

PANIC No: 1   My traffic is not flowing inspite of the fact "I HAVE CREATED TRAILS and VPN"

Hmm!!!!! let us see what exactly happens in a case like this. The customer, typically a tx guy, calls up and says, I have created "RSTP Trails" and then also traffic is not passing. What do we see exactly in a scenario like this.

The VPNs are created in the following fashion in the L2 modules.

As you can see in this figure that there is VPN created by the VPN has only been created in Point A and Point B. The Client -1 bridge is an intermediate node which doesn't have a VPN at all. The traffic now actually comes from Point A and enters the link between Root and Client -1 and then it enters Client -1. However, since Client -1 has no VPN created the packet actually drops over there.

Hence there is not end to end traffic.

The preconceived notion of the TX engineer is "I have already created the RSTP ring so why should there  be creation of VPNs".... HA HA HA.

Actually the thing that needs to be understood is as follows, while RSTP is taking care of your topology convergence the traffic switching and routing is taken care by VPN. So without VPN routing at every point there cannot be flow of traffic. 

Just like you need Pass Through Cross connects at intermediate points, you also need the VPN Transit at the intermediate switching points.

Now after this rectification is done there is one more problem that is faced by the TX engineer eventually. They come out with the following panic statement.

PANIC NO:2"I have flow of traffic fine, but my traffic is not switching on the removal of a link"

Hmm serious problems raised by the TX NNOC to the TX support and well most of the time this is what happens.

Please see the figure below to understand how the VPNS are created.

No prize for  guessing what the mistake in this configuration is. No doubt about the fact that under no failure scenarios the traffic will flow fine from Point -A to Point - B Via the Client -1 but when there is a failure in the link between the Root bridge and Client -1 then there will be traffic drop.

Most of the Transmission Engineers think that at this time RSTP should take its course.....Well my dear friends, remember what I told before, RSTP is a loop avoidance mechanism and not the protection. RSTP can catalyze a protection response faster but not be the protection itself. Let's see one thing, in a SNCP kind of scenario if you don't provision the other side of the Path then will a Protection take place????? The answer is No... So there is an inevitable requirement to actually make the VPN round through the ring.

First of all let us understand how the problem is occurring in this case with a series of Pictures.

As seen in this figure there is a link failure in the link between Root Bridge to Client -1.

Now over here the blocking link actually comes to forwarding. So as to say that the RSTP convergence has happened.

However, since in the other path there is no VPN created The traffic is actually no reaching the other point through the other path.

So now it is clear that the VPN has to be replicated round the full ring for the proper running of the services. The figure below actually shows how to have services done in the RSTP network.

The figure above is the real way to create the service in the RSTP ring. The Ethernet service is actually routed through both the ways, just like a SNCP Trail which has dual PTPs at drop locations and pass-through at every location, main or alternate.

In such a case the loop avoidance is done by the help of the blocking link. See initially when there is a broadcast the traffic will flow through both sides but the Blocking link will prevent replication and flooding of the traffic.


Some points to remember in the service kinds.
 
1. The service is always a E-LAN instance.
2. There is always MAC learning enabled as the drop points always have to make a decision between two or more paths based on MAC learning of the destination equipment.
3. The intermediate services for just the pass through can be done with Mac learning disabled.


Coming up Next::::

RSTP in MESH.... And service kinds..... 

RSTP / MSTP PART-II Selecting the Optimal Blocking port

Dear Friends of my transmission fraternity,

In the previous blog post I had given the first two rules about how to provision when the RSTP is used as a major loop avoidance mechanism. However, I probably forgot to mention one very important thing in the earlier post.

I said "RSTP is not a protection mechanism it is more for loop avoidance" then how is protection achieved in a Layer 2 circuit?

Answer is a Layer -2 circuit is created when a VPN is formed and a VPN is nothing but a kind of a cross connect that you have in the SDH. However we cannot directly co-relate a VPN with a cross connect because in a cross connect the PTP and the CTP are all hard wired however in a VPN the process is different. There may be two or more than two connectivity points in a VPN and these are bound by something called as a vFIB or Virtual Forwarding Information base. The frame makes a decision on the egress port based on the Mac Table learning and if it is not able to make a decision, well it is flood. So a VPN has two modes, Flooding mode (When addresses are not known) and Forwarding mode (when addresses are known).

So if you already have more than one egress points in a VPN then be sure that the protection is already imbibed, so a VPN would first follow the MAC table and if a path fails then it takes the path that is actually present in the flooding mode. However the basic problem is the point when more than one path is active. Then in flooding state the traffic may be flooded to all the ports and then there may be a condition of loop.

It is to avoid this loop and streamline the protection that RSTP is used.

So when there is a failure the blocking path is unblocked and the traffic is seamlessly switched to the alternate path.

There are also elements like flushing involved in this to actually push the traffic to the alternate path however, this will be covered later.

Rule No: 3  Selecting the optimum blocking path for the RSTP topology

Continuing with the set of rules let us understand that the RSTP also selects the blocking path by the means of

a) Path Cost.
b) Port Priority.
c) Designated Port Number  (Ref Wiki Article on RSTP).

While a novice would actually let the protocol let do this activity and select the blocking port by itself an expert planner would actually exploit this mechanism and influence the selection of the blocking port. Remember one thing while planning of network is done for maximum reliability it also involves an element that when the active and the contingency are both available then there will be more and more stress on the effective utilization of dual bandwidth.

So as to the fact that when the ring is up we can have a dual BW utilization.

Attached is a picture of a mis-planned RSTP ring with respect to path cost and blocking link.

Now what is really wrong in this setup?

First of all the Root Bridge is not planned, which makes all the sanctity of Rule -1 as void. Secondly the traffic is from hub to spokes, and if the right side link is always blocking then in ideal condition there will be a problem in the sense that you will always have 100Mb/s of traffic in the Idle times also. So as to say that when the ring is intact you will only have 100 Mb/s of traffic flowing and no gain in the same ring.

The picture below will explain it.

So as you can see that when the ring is intact the maximum possible BW interchange between the Hub and the spokes are only 100 Mb/s. In a data planning scenario this is like a very novice planning. An efficient planner will not do this, never.

So what is the right way of going ahead? How can we actually ensure that we have a more controlled instance of the RSTP to our benefit.

So friends, let us understand the nuances of creating the blocking link to our benefit. If we see the example above then it is very clear that you have 4 spoke locations in the entire setup and the best possible location of having the blocking link is the link between the second and the third spoke.

To do this we need to understand that which is the factor of  blocking port that is actually in our hands.

1. Designated Bridge Port........ No.
2. Port Priority....... May be but when you have more number of ports in hand it is better not to touch that.
3. Path Cost..... Yes.

The path cost is something that is in our hands and so if we make the path cost of the segment between the second and the third link to be highest then there is most probability that the link would be the blocking link.

Also we keep in mind that the other links' path cost are kept at a much lower side. Because remember the basic statement of RSTP.

"For N number of paths to the root bridge from a bridge N-1 Paths would be in a blocking state"

So the computation of the paths is done taking the sum of all the cost of the segment that is coming from the root to the expected bridge.

Look at the picture below.

 



The picture explains the following.

> First of all the root bridge is selected as the HUB.  So both the egress ports and all the ports are in actually forwarding state.

> Then the link in-between the second and the third  bridge is assigned the highest path cost. This makes the link as the blocking link.

However, let us understand how optimal is that. For this look at the next picture.

Now as you can see that there is a double usage of the same 100 Mb/s infrastructure. This is happening due to optimally planning the RSTP blocking path. This means that in the ideal scenario where there is no ring cut there will be double the BW available for all the sites. Efficient planning like this will actually lead to more use of EIR ( Extra Information Rate) which can be sold at BE prices.

Thus this kind of planning either saves revenue in a traffic sparse area by conserving resources or generates more revenue in a traffic opulent region by actually investing less resources.


In the next part we will study how to construct services in the RSTP configuration. Lot many parts to go.

Till then some tips.

1. Understand the requirement of BW per pop rather than taking the holistic picture.
2. Compute what will be the total requirement of BW and carefully place the blocking link.
3. Try to divide the RSTP ring in a pattern where efficient division of BW can happen, this is not technology, this is basic mathematics which you and I all have studied and you don't need a crash course for it.
4. Listen to the requirement of customer.... Because if he wants to kill a mosquito do not bring a tank.


And happy planning and provisioning.

Cheers!!!!!

Kalyan...

RSTP / MSTP how to use them and how they are mis-used. (PART-1)

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.