Thursday, April 25, 2013

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..... 

No comments:

Post a Comment