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.