MPLS, an acronym thrown around my field, some understand it and others just say it to look smarter than they really are. Either way, very few people will ever touch the actual configuration on the service provider (SP) side and will only interface from a CE (Customer Equipment) side. I will give a very brief overview of the three most common types and their generic terms.

  • L3VPN MPLS Private IP – This is a layer 3 solution where you are given a private, RFC1918 address, to peer with SP PE (Provider Equipment). Most of the time you’ll want to peer with OSPF, if available, or more likely BGP, to exchange routes between sites
  • L3VPN MPLS Public IP – Same as above with public IP addresses provided by either the SP or if you happen to own your own block; however, the latter has considerable design attributed to it and most don’t resort to this option. You’re likely to find more L3VPN MPLS with private IP
  • L2VPN VPLS – This service, very popular with people who can manage their own infrastructure responsibly, creates a WAN solution which appears as if all your offices are on one big ole VLAN/broadcast domain. In this scenario you can connect at layer 2 and span your broadcast domain or, like most implementations you’ll see, connect using a layer 3 interface and peer with a dynamic routing protocol like OSPF.

There are lots of design considerations to be taken into account when building your MPLS cloud, each with it’s own little issues and “kinks” to iron out; however, DO NOT choose loosely. Building a fully meshed MPLS requires considerable thought about how your network works today and how you plan on running it in the future. Take it from my experience in having to migrate a global network from a L3VPN solution with 60+ static routes to a VPLS based solution using OSPF, the road to get there is painful and frustrating.


Comments are closed.