MPLS - load balancing on a Layer2 circuit EoMPLS

[sagou.brahim]

Hi all,

I'd need a help about a load balancing question in an EoMPLS environment. I'm relatively new to this technology... Here is the situation :

I've got two sites A and B with two STM-1 links between them. In each site I have a 7200 router, each one with two POS interfaces connected to the STM-1 links. Let's name the two routers R1 and R2.

I've activated OSPF routing between R1 and R2 (the two WAN subnets and the loopback adress of each router).

I've also activated MPLS on all the WAN interfaces.

Now on the LAN side of each router I want to connect a switch, and I want the switch of each site to be part of the same LAN, so I'm trying to use EoMPLS configuration (xconnect command on the LAN interfaces of the routers).

This seems to work well as the two remote sites are able to comunicate at layer 2, but my problem is that I do not know if I will have a load sharing between the two STM-1 links (when I use the command "show mpls l2transport vc detail" , I have only one WAN interface used as the output interface for that layer 2 circuit...). Is it possible to configure a layer 2 circuit to use redundant mpls paths?

Thanks in advance for your help,

brahim

[mheusing]

Hello Brahim,

EoMPLS uses two labels, the IGP label for the IPv4 address used in the "xconnect" command - call it IPDA - and a VC label negotiated through a directed LDP session between the two VC endpoints.

Loadsharing in the MPLS core for a L2 circuit uses both labels. First, load sharing is only possible, if you have two IGP routes to IPDA. Second, it depends on the CEF load sharing algorithm, what the outcome for a particular VC will be. A MPLS enabled router will load share based on the VC label for EoMPLS and as the default algorithm is "per destination", which really translates to "per VC" with EoMPLS, I would expect the observed behaviour. So all packets for a particular VC will be sent along one path. This behaviour could be modified by configuring "per packet" load sharing on the routers interfaces. However, this could lead to packet reordering - the transport delay on one interface might be longer than on the second interface, hence a packet A sent on one interface might arrive later than packet B sent afterward on the other interface. This could lead to detrimental effects for TCP sessions, voice etc. why the default is "per destination".

So you could change the behaviour by configuring per-packet CEF load sharing, but it might not be beneficial from an application point of view.

Another approach could be to use two VCs between the two sites each utilizing one STM-1, but you need to design spanning tree carefully in this case. Unless you have trunks and direct some VLANs over one VC and others over the second VC, your LAN switches - seeing two parallel links between them - will block one port and hence again no load sharing will happen.

Hope this helps! Please use the rating system.

Regards, Martin

[sagou.brahim]

Hi Martin !!

Great to hear from you again I was a student of you in a CRS-1 course in England !! :)

Thank you very much for your help the contribution was very useful.

I tested the recomendation in a lab. It is true that now, when I do a "show ip cef X.X.X.X(IPDA) detail" I have the two paths with the option "per-packet load balancing". And I see that when I launch some pings from LAN to LAN, the "current path" for the IPDA changes from a WAN interface to the other.

The only thing that still disturbs me is that in the command "show mpls l2transport vc detail" , I still see a unique ouput POS interface for that vc, but the trafic seems to be balanced with those ping tests.

I'll have to test it in production network to see if the trafic is really load balanced between the two POS interfaces. (packet reordering will not be a problem in our situation)

I'll get you informed.

Thanks again for the help,

Brahim

[sagou.brahim]

Hi,

I've made some tests and it seems that traffic is not really load balanced between the two WAN interfaces. Well it seems that in the "show mpls l2transport vc detail" command, the output interface revealed is the only one used by data trafic.

I think the FIB table is used only once, at the VC establishment. At that moment, we pick up one of the two available output interfaces, and we establish the VC.

Then, all data flow is sent over that interface initially used to build the VC. And that will not load balance the trafic..:(. The output interface will change if the first one goes down.

Well I tried to set a GRE tunnel between the two routers, and then setting the prefered path for my VCs as the tunnel interface,hoping that trafic will use the two available paths for the tunnel destination but it doesn't work for the moment(The VC doesnt't even come up).

Any ideas welcome ??

Best Regards,

Brahim

[mheusing]

Hi Brahim,

Great to hear from you again! Which platform and IOS are you using? The description I gave has some exceptions for some IOS versions and platforms and one of them might apply to your case.

Regards, Martin

[sagou.brahim]

Hi Martin,

Well, I am using in both sides a 7200 router wih NPE-G1 and IOS version 12.0(33)S with service provider feature set.

Brahim

[mheusing]

Hi Brahim,

Reading up on the load balancing, I have to correct my statement regarding "per-destination" and "per-packet" with respect to EoMPLS or AToM VCs in general. "per-packet" or "per-destination" does only apply to IP traffic. Non-IP traffic will be load balanced based on the label stack, which means a particular VC will take a particular path in a 7200. There are other platforms with different additional options, but in your case the observed behaviour is what is expected.

Sorry for the confusion maybe caused by my first post.

Regards, Martin