The Multiprotocol Label Switching (MPLS) protocol boasts a lot of flexibility. But when you hear about MPLS, you'll most likely hear carriers touting it as a WAN service that's the "new" frame relay.
In fact, my organization bought into this and has been loving it ever since. We replaced our 70-location frame-relay network with MPLS at every site.
MPLS is a relatively new technology, so let's review what it is and how it works. We'll use my organization's use of MPLS for our example.
How does MPLS differ from frame relay?
Let's start by reviewing a tried-and-true network protocol and WAN service—frame relay. When using frame relay, you configure Layer 2 on your router, ending up with a WAN network with a connection to a central cloud.
Through that cloud, you have connections (permanent virtual circuits or PVCs) to whichever remote sites you've requested and are paying for. If you have a fully meshed network (where every site has a connection to every other site), you pay for every one of those PVCs, which can easily become quite expensive.
One of the biggest benefits offered by MPLS is that you don't have to worry about PVCs—nor do you have to pay for them. The pricing structure of a MPLS circuit is similar to an Internet circuit; you just pay for the access loop as well as a connection fee. Once connected, you have a fully meshed IP network between all remote sites.
Keep in mind that MPLS circuits are not Internet circuits. While these circuits usually ride the same backbone as the carrier's Internet traffic, they aren't public circuits, and they have a private IP address structure.
In addition, it's important to remember that different carriers use MPLS in different ways. For example, when using AT&T solutions, you actually run the MPLS protocol on the router and label (i.e., tag) every packet that goes out to the network.
Conversely, at Sprint, the vendor my organization uses, you don't actually run MPLS on the router. Instead, Sprint runs MPLS in the network cloud.
Another huge benefit of MPLS is that you get to use the full port speed of your circuits. So, there are no more committed information rates (CIRs) and no more forward explicit congestion notifications (FECNs) or backward explicit congestion notification (BECNs). Just like Internet service, if you buy a 1024-K Internet circuit, you get to use 1024 K of bandwidth, both ingress and egress.
How do you route MPLS?
So, after setting up MPLS, you have this fully meshed network between all remote sites. That's great, but how do you route between all of these sites?
You do so with a routing protocol. You can use either static routes (not a preferable choice when you have more than a few sites) or a dynamic routing protocol such as EIGRP, OSPF, or BGP. With a dynamic routing protocol in place, every site can learn about the LANs at every other site, and you have a fully meshed and converged network.
Of course, there's usually a catch. In this case, it's that your MPLS provider involvement in the process is essential. As I mentioned, this is an all-IP network, which means that—unlike when using frame relay—some other Layer 2 protocol isn't encapsulating your IP packets.
With frame relay, the provider's frame-relay switches swap the frame packets based on data link connection identifier (DLCI) numbers. The switches don't look at the IP information, nor do they need to.
But this isn't the case with MPLS. The switches look at the IP source and destination of the packets because their IP routers are critical IP routers on your network. That means they must participate in whatever routing protocol you choose. Because, if they're routing packets for you, they must have your routes.
So, when using the Sprint MPLS network, Sprint's Cisco routers talk to my company's Cisco routers and exchange routes (when using dynamic routing). But, even if you're using static routing, the Sprint routers must have every LAN on your network in their routing tables.
Working with MPLS
Let's say that you have an MPLS network, and you're running Open Shortest Path First (OSPF) as your dynamic routing protocol. All sites have access to every other site. At the central site, you have an Internet circuit.
One day, you decide that you want a remote site to be able to access the Internet through the central site's Internet circuit. That means you must put in a default route, which basically sends any destination not specifically found in the routing table to the specified next-hop router.
In the case of a frame-relay network, this would be easy to do. On the remote router, you would enter your default route, as shown below:
ip route 0.0.0.0 0.0.0.0 xx.xx.xx.xx
The xx.xx.xx.xx route is the IP address of your central router's frame-relay interface. From here, assuming DNS was in place, everything should work. The remote routers would go to the central router, and the central router would connect to the Internet, bring the traffic back, and deliver it to the remote routers. All routing is working.
In the case of MPLS, however, this approach won't work. If you put the same default route on the remote router, the IP address of the next-hop router is not the same because the carrier's router is in the middle. When using MPLS, it's no longer just your company running the network—you must take the carrier and its routers into account.
Think of the provider's router as the "big" router in the cloud. All of your routers connect to its router, and you're routing the traffic together.
Who's responsible for routing MPLS traffic?
If you make changes to the routing protocol, you may need to request that the provider reconfigure its routing protocol. In most cases, however, you can just add a new LAN subnet without informing them at all, and the dynamic routing protocol does its job. Or, if you want to do this without involving the carrier, you could distribute a default route through the dynamic routing protocol and—assuming the carrier doesn't have any filters—the remote routers should be able to access the Internet using this default route.
Another option is to use the static route mentioned above. However, the next-hop router would be the carrier's router in the cloud, and the provider would have to configure a static route to point to your central router (to complete the connection).
When working with MPLS, it's vital that you remember that both your organization and your carrier are responsible for the routing of MPLS traffic. Some may view this is a drawback to using MPLS, but it has worked very well for my organization.
The fully meshed features, full bandwidth, and simple configuration of MPLS are advantages of making the move to MPLS. In my opinion, carrier-based MPLS service is a huge improvement over the old frame-relay network, and the transition is well worth it.
What's your take on MPLS service? Have you used it before? Weigh in with your opinion on this article's discussion.
Miss a column?
Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.
Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!
David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.