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