Introduction to MPLS

Lessons Discussion
186

Hello David

When purchasing consumer grade connections (i.e. DSL, cable, fixed 5G etc…) that you can get for your home or small business, the primary variable that affects the cost is indeed the speed. In most cases it is the only variable!

For enterprise-grade connections which include technologies such as MPLS, there are many more variables involved that will affect the price. Speed is still a fundamental parameter, so if all else remains equal, yes a higher speed will cost more.

Other parameters that play a significant role in the cost of enterprise grade connections include:

  • Connection type - fiber or microwave links will typically cost more than copper, Wi-Fi/WiMax, or mobile network connections.
  • Asynchronous or Synchronous - Asynchronous links (slow upload fast download) are typically cheaper than synchronous links (equal upload and download speed).
  • SLAs - Enterprise-grade links usually include different levels of service and response times for dealing with faults and support requests. Each SLA level has a different cost.

So when it comes to MPLS and other enterprise-grade technologies, speed does play a role in the cost, but so do other parameters that are important to such implementations.

I hope this has been helpful!

Laz

187

Hello,

Please have you posted any lesson about Seamless MPLS here, could you mention it please, if no could you share some resources about this topic or any information please.

Regards.

188

Hello Ahmedlmad

Currently there is no lesson on seamless MPLS, however, you can find some information at this NetworkLessons note. You can also read up on Cisco’s documentation about the topic here:

If you would like to see a lesson on NetworkLessons about this topic, you can always visit the Member Ideas page here:

There you can make your suggestions for new topics. You may find that others have suggested similar topics, and you can add your voice to theirs.

I hope this has been helpful!

Laz

189

Hi Laz.

I have a quick questions that is more directed towards you.

When it comes to MPLS, ever since my CCNA studies, I was taught how it works from the customer’s/enterprises’ perspective.

The goal is to connect your customers and their sites together and allow them to communicate. We accomplish this by configuring an MPLS infrastructure, labeling, MP-BGP, VRFs, and the import and export of routes into the relevant VRFs.

However, from the service provider perspective, are there any other use cases for MPLS? If no customers connect to the infrastructure, can it still be used for anything? If possible, do you have any specific examples from what you’ve encountered?

We use MPLS at my work (a medium-sized ISP). No customers connect to it but we still use it for L2 and L3 VPNs and I am still struggling to understand why we use it despite asking quite a lot :smiley:

Thank you
David

190

Hello David

When it comes to studying MPLS in the context of CCNA/CCNP and similar certifications, the most common setup is indeed the one where you have the MPLS network interconnecting the remote sites of customers. This is typically done using various technologies and techniques, including VPNv4, VRFs, MP-BGP, and so on.

Although this approach is excellent for starting to learn MPLS as a technology, MPLS networks are not limited to serving just this scenario. Service providers use MPLS extensively for their own internal infrastructure, even when no external customers are connected. Think of the service provider itself as its own most important customer. Your medium-sized ISP uses MPLS to build a scalable, segmented, and resilient network for its internal services and operations.

In this sense, just like you would create VRFs to keep different enterprise customers separate, your ISP does the same for its own internal services. These can include a Management VRF, a voice/video VRF, a corporate IT VRF and several production services VRFs for things like DNS, RADIUS/AAA, email, monitoring systems etc… The logic is the same, but the services being served are different.

Indeed, some ISPs, like the one that serves my office, for example, deliver L3VPNs for simple internet connectivity, as well as telephony. From my perspective, in my office, I don’t see the MPLS at all, since I have the CE device, but internally, I am provided with Internet and voice services, each one using a different set of parameters/traffic engineering based on the type of service. So it’s not just an interconnection of remote sites, but a resilient underlay that carries multiple services of various types.

So MPLS isn’t just about customer VPNs. It’s a foundational architecture for building scalable, segmented, and engineered networks. The same benefits you’d provide to external customers (isolation, traffic engineering, QoS, fast convergence) are equally valuable, and often more critical, for a service provider’s own operations. Does that make sense?

I hope this has been helpful!

Laz

191

Hello Laz!

The reason why an ISP could use MPLS to provide internet connectivity is because you have the benefit of a BGP-free core and you don’t need every single router to maintain a huge routing table with milions of routes?

And when it comes to traffic engineering, is there anything that MPLS can accomplish that simple BGP cannot do?

Thank you

David

192

Hello David

Yes, that’s one of the big reasons ISPs run MPLS. In this way, you keep BGP (and the full Internet table) off the transit and core P routers. Only the edge PE routers need to have the “knowledge” of the BGP routes on the Internet. P routers just run the IGP and a label protocol (LDP/RSVP or Segment Routing), and they swap labels without ever looking at the Internet prefixes.

The benefits include scalability, stability, faster convergence, and service flexibility, allowing the core to carry multiple data types with different requirements.

And that’s where the traffic engineering bit comes in. BGP is excellent for policy and egress selection, especially at AS boundaries using communities, local-pref, MED, and AS prepending, and within an AS it can prefer one exit over another. But BGP by itself does not give you deterministic, in‑core path control or resource guarantees. MPLS TE does.

Specifically, examples of what MPLS TE can provide that BGP alone cannot include:

  • Set explicit paths, forcing traffic to follow a specific sequence of nodes that is independent of the IGP shortest path.
  • Use constraint‑based routing by computing paths that satisfy specific constraints, including bandwidth reservations, affinities/colors, latency, and others.
  • Fast Reroute protects against link and node failures without waiting for global reconvergence, achieving sub‑50 ms response times.
  • Class- and type‑based engineering can steer different classes/VRFs over different paths.

These are just some of the TE capabilities of MPLS that are above and beyond what simple BGP could provide you with.

I hope this has been helpful!

Laz

193

Hello, everyone.

I have a few questions regarding SP architectures.

When it comes to Unified MPLS, a Cisco doc says this:

The purpose of Unified MPLS is all about scaling. In order to scale an MPLS network, where there are different types of patforms and services in parts of the network, it makes sense to split the network into different areas. A typical design introduces a hierarchy that has a core in the center with aggregation on the side

Is the Access/Aggregation/Core design only used when talking about unified MPLS or can it be used when talking about the SP’s architecture in general? For example, we don’t run unified MPLS at work but we still use the terms such as Edge/Core, and so on.

obrázok
obrázok987×523 59.2 KB

In this scenario, the MPLS ABR isn’t exactly like an OSPF ABR, right? The terms are the same but in MPLS, it just means that this router sits at the edge of the IGP/LDP domain (or an IGP island if I may call it that)

And one final question, do the IGP domains need to be designed in a way where each aggregation layer (and core) runs its own IGP?

So for example Aggreg1 will run OSPF1, Aggreg2 will run OSPF2, Core will run OSPF3. My question is, can these mix? Can I include, say 1 router from the core layer in the same IGP that is in the Aggreg layer?

From what I understand, that is the “typical” design but we can of course change/mix things or add more IGP domains, if we have such requirements.

That’s all, thank you :slight_smile:

David

194

Hello David

This hierarchy and the terminology used comprise a general architectural approach that is used regardless of whether you deploy MPLS, Unified MPLS, or any other technology. These are general design and organizational terms, not MPLS-specific features. Unified MPLS is simply a control plane scaling strategy that can be used on top of such a hierarchy.

Yes, that is correct. The OSPF ABR operates in a very specific manner that is defined in an RFC (2328). In the context of the MPLS hierarchy you shared, the ABR is a more general term used to describe the role of the device on the boundary between multiple IGP/LDP “islands”. It’s not defined in any RFCs.

No, this is not a requirement or an obligation. You can mix it up if you like. You may be running the same OSPF process, for example, on all routers, but a different area in the core, and different areas on the aggregation portions. You could separate the OSPF processes completely if you like, or you can choose to have some aggregation areas share the same process as the core, while others do not.

However, best practice dictates that you avoid unnecessarily extending IGP domains across boundaries just because you can. You should only split IGP domains when scale issues demand it, or when it architecturally makes sense (when you merge two networks for example).

I hope this has been helpful!

Laz

195

Hello Laz.

Thanks again for your help!

David

1 Like
196

Looks like the IP addresses on the config does not match with the ones on the diagram, no big deal but it can cause some confusion :slightly_smiling_face:

197

Hello Dan

Thank you so much for mentioning this. It’s always helpful when users point out such discrepancies. I scanned over the lab, but I was unable to find the specific error. Can you point it out to us so we can correct it? Thanks!

Laz

198

Hello, everyone.

I understand that one of the original driving factors behind MPLS’s invention was to speed up packet forwarding due to IP lookups being too harsh on old routers.

However, as hardware evolves, modern MPLS offers little to no performance on Cisco devices as CEF can route packets much faster than old routers ever could.

So the primary factor behind implementing MPLS is to provide some kind of service/application - Traffic Engineering, L2 VPNs, L3 VPNs, BGP-free core and so on.

To go back a little, I also understand that by using MPLS with IP, we can extend the possibilities of what we can transport. Adding labels to the packet enables us to carry other protocols than just IP similarly to what was previously possible only with Frame Relay or ATM Layer 2 network back then, correct? So another benefit was that it could carry all sorts of protocols over a common MPLS infrastructure.

However, in the modern world, would we really be transporting anything other than IPv4, IPv6, and Ethernet? I can’t imagine using any other technologies.

So is it correct to say that the reasons behind MPLS’s invention were:

  • Faster IP Lookups
  • Being able to carry all sorts of protocols over a common MPLS infrastructure, which included Ethernet, HDLC, PPP, IPv4, IPv6, ATM, etc
  • Being able to have a BGP-free core (I found this in an old Tag Distribution protocol RFC)

My question is, I’ve read that another major factor for inventing MPLS was to integrate IP over ATM.

I understand that ATM served as a WAN technology that used its own addressing, fields, and so on. So we needed devices that would speak ATM and also devices that would speak IP, it wasn’t all unified.

So with MPLS, the ATM switches were programmed to run an IP IGP and LDP? This is a part that confuses me a little bit. What exactly did MPLS/IP handle and what did ATM handle? How did this integration work?

It’s probably not an important question as ATM is pretty much dead these days :smiley:

Thank you!
David

199

Hello David

MPLS is an old technology, with RFC 3031 being published in January of 2001. The technology was created for something specific, but as needs evolved, so did the technology itself. Let me just touch on some of the points you mentioned:

You’re right that the original drivers behind MPLS included faster IP lookups (label swaps vs. IP longest-prefix-match), the ability to carry diverse protocols over a unified infrastructure, and creating a BGP-free core. However, the RFC actually lists five distinct advantages of MPLS, and raw forwarding speed is only one, and it is actually the least enduring. The deeper architectural drivers were about unifying IP routing with existing ATM/Frame Relay infrastructure, classifying packets at the ingress, and keeping complex forwarding logic at the network edge rather than in the core.

Concerning most of your description about the development of MPLS, you’re basically spot on. In modern deployments, MPLS carries IPv4, IPv6, and Ethernet almost exclusively. The “multiprotocol” name is still valid, but somewhat less important today. As you suggest, what MPLS actually delivers in practice includes L3 VPNs (BGP/MPLS VPN for IP traffic separation per customer), L2 VPNs (EoMPLS, VPLS for Ethernet services), BGP-free core (P routers only need IGP, not full customer routes), and Traffic Engineering (RSVP-TE to steer traffic based on bandwidth and policy, not just IGP metrics)…and none of these benefits depend primarily on lookup speed. They depend on MPLS as a Layer 2.5 tunneling and classification mechanism.

In fact, on Cisco devices, MPLS requires CEF, and the LFIB (Label Forwarding Information Base) runs at line-rate speeds just like IP forwarding. So they’ve come full circle from originally being competitors to becoming complementary technologies.

Now this is the interesting bit. MPLS was designed to accommodate ATM operation! ATM switches could use the same IP routing protocols (OSPF, IS-IS) as edge routers and learn the network topology just like any IP router. But instead of using proprietary ATM signaling (PNNI), they used LDP to exchange label bindings over IP. The clever part: The MPLS label was encoded in the ATM VPI/VCI field.

The result is that no packet-level routing lookups happened inside the ATM core, just label swaps. This was revolutionary for the time: you got the speed advantages of ATM switching combined with the intelligence of IP routing, all unified under one control plane.

Now the practical reason behind this design is this: Major ISPs (like UUnet and MCI if those names ring a bell :bell: ) had built backbones with IP routers at the edges and ATM switches in the middle. MPLS (originally Cisco’s “Tag Switching”) was designed to enable those two technologies to work together under unified IP control, competing with proprietary solutions. Legacy ATM switches were not originally IP routers, but MPLS allowed suitably upgraded ATM switches to participate as LSRs, while preserving the ATM-style cell switching in the data plane: the ingress router requested labels chain-style, and each ATM-LSR allocated a VPI/VCI on demand.

Now, these VPI/VCI labels have left some historical fingerprints on MPLS and LDP design. Modern MPLS runs over Ethernet using a label header directly without any VPI/VCI mappings. A lot of LDP’s complexity (label allocation modes, per-interface label spaces, etc.) is legacy from accommodating ATM’s hardware constraints.

Indeed, ATM is essentially dead today, but understanding how MPLS unified the IP and ATM control planes provides insight into MPLS architecture and why it is designed as it is.

I hope this has been helpful!

Laz

200

Any plans to teach segment routing?

201

Hello Philip

The content of NetworkLessons primarily focuses on Cisco’s certification and exam series. Segment routing, for the time being, is not part of any of Cisco’s mainstream certification exams. Now, having said that, you can always make a suggestion to @ReneMolenaar about the content and future lesson ideas at the following Lesson Ideas page:

There you can make your suggestion, and you may find that others have made similar suggestions, and you can add your voice to theirs.

I hope this has been helpful!

Laz