Venturing into MPLS Network

Unanswered Question
Feb 7th, 2006
User Badges:

Hi all, it is just my curiousity that ended up with a small discussion like this. Here's about it...

My company has a main client which have tonnes of remote sites connecting to both their HQ and Disaster Recovery Centre. Some of the remote sites still running on frame-relay, while other is purely leased-line. There's a few question I wish I can clear up as follows:

i. When the client have frame-relay device, what we do is create a tunnel and route all the frame-relay traffic over. Is there any advantage if we change it over to MPLS?

ii. Even if comparing to leased-line services, what kind of advantages I can expect if our cliet migrate over to leased-line?

iii. If one customer is running purely on frame-relay connectivity, any difficulties will arise when they want to switch over to MPLS network?

I still never has any hands on experience on the MPLS, that's why need to gather some info in the first place, I'm currently have a glance through those MPLS guides and configuration examples, but I knew that perhaps in real-life network, things may differs, in the meanwhile I'm studying through it, hope to gather some precious opinions. Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (3 ratings)
mheusinger Tue, 02/07/2006 - 06:46
User Badges:
  • Green, 3000 points or more


Ai) it really depends on your communication. MPLS VPNs deliver any-to-any connectivity. In case you implement VoIP this could be a real pro, because in hub-and-spoke the delay is definately larger.

Another argument would be scalability and complexity of the solution. In your case you could end up with hundreds of tunnels ... compared to simple IP access to a MPLS VPN.

Aii) MPLS L3VPNs can be more cost effective, because you just need the local loop and not long distance least lines. On the other hand non-IP traffic is much simpler to transport over least line than over MPLS VPN (i.e. in GRE or the like).

Aiii) The main obstacle in a migration path from FR to MPLS VPN I would see is in IP routing. It will be modified because of MBGP and redistribution. So you need to be extremely careful not to produce routing loops during migration, especially when operating FR and MPLS VPN in parallel. Using proper filters and migration steps this can be done, but as I said: with care.

Hope this helps! Please rate all posts.

Regards, Martin

networknoobs Tue, 02/07/2006 - 19:44
User Badges:

Thanks and appreciate your reply, however I'm not too clear about the answer regarding my third question, nevermind, let me find some times to dig more details on the issue...

mheusinger Wed, 02/08/2006 - 00:41
User Badges:
  • Green, 3000 points or more


Regarding answer iii: What you have to use inside the MPLS cloud is MBGP to route the customer prefixes. In your LAN however you will have an IGP like EIGRP. This means you need mutual redistribution between MBGP and your IGP. So a routing loop can occur once you have at least two pathes. An Example:

N1-CE1 - PE1 - PE2 - CE2

with: CE1 - PE1 using RIP, CE2 - PE2 using RIP, PE1 - PE2 using MBGP and a FR PVC between CE1 - CE2 using RIP

This would be the case when you migrate from FR to MPLS VPN and do not shut down FR the very moment you activate the MPLS links.

What can happen in this scenario is: CE1 is announcing Network N1 through RIP to CE2 directly over the FR PVC and also to PE1. PE1 will redistribute N1 into MBGP, send the prefix to PE2, which will redistribute N1 into RIP and send the update to CE2.

Now depending on implementation and metrics this will result in all traffic flowing over FR or MPLS (when adjusting metrics). No major problem yet.

The problem might occur once CE1 looses network N1. It will send an update directly to CE2 and to PE1 and a race condition exists. CE2 will still have one valid path to N1 learned from PE2 and announce this one to CE1, which will announce it to PE1 and then PE2, CE2, CE1 again and so on.

This is an intermittend or even persistent routing loop, depending on what you have done with hop count during redistribution.

By designing your overall routing solution carefully you can avoid this scenario.

Hope this helps! Please rate all posts.

Regards, Martin

networknoobs Thu, 02/09/2006 - 03:26
User Badges:


You're superb in helping newbies like me. Very clear explanation yet made it easy to understand. Appreciate your reply very much. Thanks.

I'm currently into more details and shall post again if any question arises in this helpful place. Regards

mheusinger Fri, 02/10/2006 - 00:52
User Badges:
  • Green, 3000 points or more


Thanks for the compliments!

Just one more remark: The routing loop possibilities also have to be taken into account when designing backup solutions "around the cloud".

In case you implement dial backup with dynamic routing f.e. directly to the data center, you can also create a routing loop. At the time when the backup line is operational and the main connectivity through MPLS is reestablished you also have two pathes and could experience the problems described in the previous post.

Regards, Martin


This Discussion