N4N051: MPLS Fundamentals

Today's episode is sponsored by Meetr, delivering a complete network as a service offering, wired, wireless, and cellular in a unified solution, find out more at metr.com slash n4n.

That's n the number 4n.

Welcome to NS4 Networking, the podcast where we take networking fundamentals and make them slightly more understandable.

My name is Holly Metlitsky, and with me is co-host Ethan Banks.

Follow us on LinkedIn and join the Packet Pushers Community Slack group at PacketPushers.net slash community.

Today's topic is MPLS, as in multi-protocol label switching.

And it's one of those foundational technologies that power service provider networks and enterprise brands all over the world.

As someone who's mostly been in the enterprise space, I haven't really encountered MPLS directly,

so I thought, what better way to learn than making Ethan and our guests teach me.

To help us break it down, we've invited James Bansley to join the conversation.

James is a network tech, with deep experience in service provider technologies, and he's here to help make MPLS approachable. Welcome James.

So to kick things off, why don't you tell us a little bit about who you are and what you do.

Sure, thanks for the intro as well. Now I feel like I really got live up to that intro as well.

So the pressure is on, yeah, so my name is James. Thanks a lot for having me on the show.

I just want to stay on the recording as well. Huge Packet Pushers fan, left the whole podcast network, been listening for a long time.

So keep up the great work. I want that to be on record.

Thank you.

And thank you for saying that and for giving back by sharing your knowledge in this area.

James, I have not run MPLS and anger. So my knowledge of MPLS is theoretical from any study I had to do with certs and lab work I've done and so on.

And so I appreciate you coming to since you got the hands on your MPLS to have a more real world discussion than Ethan would be able to come up with on his own.

Well, I hope I live up to who live up to the expectations.

So Holly asked, is she introduced me? Yes, I said I'm James.

So yeah, I mean, I have been working with MPLS. I've been I've been in networking for nearly 20 years, about 19, about 19 years and about the last 15 years have been spent with MPLS.

So I've been working with it in all shapes and sizes as well. So for people who there's anyone listening who has MPLS experience, it might I have worked with things like LDP RSVP.

Nowadays, I work with segment routing and been doing stuff like inter a MPLS and this kind of stuff.

Seemless MPLS. So all different shapes and sizes and, you know, permutations of it and yeah, all the all the baggage that goes with it right endless tack cases late night troubleshooting sessions and everything else.

All the fun of being in networking.

I think let's let's start from the very beginning because often I find that when we look at different types of protocols, understanding what's spurred a creation of it really helps to understand fundamentally like why we need it.

So perhaps you can walk us through a little bit of exactly that what's the creation of MPLS and really I'd like to know why we need it because it pops up, but I've been I've managed to avoid it.

Sure. Okay. This is a few things to understand why we need MPLS. We need to do a little walk down memory lane and this predates me right.

So I said I've been in networking for nearly 20 years, but we're going back more like 30 plus years to get.

So this when I use the phrase we I mean the royal we the industry as a whole right. So we so we had a bunch of problems back in the days.

Well, one of them, for example, is we didn't have the fast a six that we have in devices today. So we have a six in high high end routers and switches.

Yeah, which can do millions of lookups for IP packets or ethernet frames per second and back then which didn't have that that kind of didn't have high a six a lot of software driven stuff just software running on a regular CPU.

And doing IP lookups for is very expensive in terms of computing time. So there's a few things that we do there was at the time a drive to speed this up to do faster lookups.

Also to reduce the size of the routing table. So we'll come on to it a bit later when we get to kind of what MPLS header looks like, but it's significantly smaller than IP.

And the we have routing tables now on devices that store roots for IP.

Those routing tables today are very large back then they were much smaller but despite the fact that they were much smaller back then they were still large relative to the amount of memory we had.

So kind of an MPLS uses something called a label table, which is much smaller than IP table. So we've got kind of faster lookups we've got less memory.

And then we also want to do some other interesting things. We want to be able to do things. So I said my background as service provider.

And you said you hadn't come across MPLS so much.

Yeah.

And I think one of the reasons for that is and this is one of the major use cases of MPLS is I operate a network as a service provider and I want to sell connectivity to people all over the place.

I have my one physical network and I want to share that with as many customers as I can to get more revenue from my one network.

If you run an enterprise network, you probably you are your own customer and you run it just for you and for nobody else kind of thing.

It's your private network.

And this is a major major point of MPLS is I want to be able to put some layer of abstraction in.

Let me reuse my physical network from many different customers who got all different purposes and types of requirements.

So I can we can go a bit further down memory lane.

Right.

So because the to understand the structure of MPLS, you kind of have to understand the problems we had back then.

So kind of way back when we had something called circuit switching.

So for people listening with more gray hairs than non gray hairs.

We are going way back.

Okay.

All right, all right.

Yeah, way back to search.

We had time division multiplexing and people don't really need to know what that means.

But essentially what it meant was if we had a very simple topology, let's say we've got North East Southwest.

We've got a compass and a packets or compass four points on a compass and we've got one point in the middle that's going to join them up.

Now packet comes into the west and it needs to get across to the east.

And so in circuit switching, we would just say, okay, if the packet comes into interface one on the on the west.

That goes to the north.

If it comes into interface two, it goes to the east.

And if it comes into interface three, we're going to the south.

And that was it.

Circuit switching did not look at the IP address or where the traffic was going to.

So the destination MAC address or destination is IP.

We just looked at what we would call a mux.

We just look at the port that it came in on, which circuit does this relate to and off it went.

So it's kind of this dumb system and a very expensive system because what that means is you have circuits switching.

You have a permanent connection.

So from east.

So from like west going up to north or from west to east or from west out as that.

You've made permanent path across your network.

The traffic only goes one way across that path.

And you and you cannot change it.

I mean, you can, but it's not, it's not easy, right?

It's very replugging wires in to pull it off.

Exactly.

It's a very, very static rigid system.

So then we, okay, how can we, how can we, the Royal, we, how can we improve on this?

So we had virtual switching.

So virtual circuit switching, which you don't have to be quite so great to be familiar with ATM.

So that's a kind of virtual circuit switching.

I mean, pretty great.

But no quite as great.

Yeah.

I'm trying to be polite.

But so virtual circuits switching.

I can make this more flexible.

Rather than packet comes in interface and we just send it across the network.

Let's look at the destination IP address, for example.

And then decide which circuit we're going to put it on to go across the network.

So there's a bit to the device where the packet comes in at the edge of the network is like looking at the IP header.

Okay.

The destination for this is where we're there.

You need to go on circuit number one.

Well, the destination is down here.

So it needs to go on circuit number two.

So some bit more flexibility here in virtual circuit switching.

Also with stuff like ATM, we would actually put an ATM header on top of the packet.

And the headers got the virtual circuit identifier on it.

And this would be used to carry the packet along this, this circuit along the network.

So we were going way back.

I know.

But this gave us just a tiny bit more flexibility that the device that received the packet

is now looking at the destination IP address, putting a new header on the packet.

And the devices along the path are looking at that new header to see where the packet needs to go.

So we could also go in different directions.

We've got some more flexibility, but still not great.

And then eventually we get the packet switching, which is what we have today.

Every device along the path speaks IP understands IP or if it's a layer two network,

every device understands ethernet.

So if it's a layer three network, an IP packet comes in at the edge.

Edge device is looking at the IP header, looking at his routing table.

Okay, this device needs to go to north or needs to go to east or south.

So he forwards it to the middle device.

The middle device does the same look up in his IP table.

Oh, this is a packet for north.

So he sends it out or it's a packet for east.

So he sends it to the right.

So every device is now looking at the packet he receives

and looking in his routing table and deciding where this needs to go.

So this is now like what we call per hop behavior, per hop forwarding.

And this is like the ultimate inflexibility because every device is fully aware of where this packet needs to go

and can make his make its decision on his own.

And then that's the model that we've been talking through on this show thus far.

Where 50 something shows in at this point.

And that's really what we've been talking about.

Holly, I think we've mentioned circuit switching and so on,

at least in passing, you know, somewhere along the way.

But we move to packet switching and how that goes.

And that's that model and how routers do look up.

So we've done some shows on that.

That's what we've evolved to as the model.

You just describe James where it's a per hop behavior.

We haven't gotten into an abstraction above that really.

Other than we've done some discussions of tunneling.

But we've still kind of had that in the discussion of per hop behavior,

still in how things change.

So yeah, well, I think we're we're with you so far.

Okay, yes, well, that brings us hopefully up to today.

And then, okay, but there were some problems with this IP forwarding and this per hop behavior.

This is actually problematic.

So what I said earlier is I'm a service provider.

And I've got my one physical network.

And I want to reuse it for all my different customers.

So if we say customer one, he has an office in East and West.

And customer two has gone office in North and South.

So one's going horizontal one's going vertical.

Now, if those customers use the same IP addresses,

like these private IPs inside their offices.

And these the same IP addresses.

The customer number one, he sends a packet into the West.

I looked at West doesn't IP look up.

Okay, that needs to go to the East.

So he sends it to kind of to the to the point in the middle.

But he gets the point in the middle.

Oh, wait a minute.

Customer two score this IP addressing and customer one's got the IP addressing.

Now, what do I do?

I have the say this doesn't work.

Which is super common.

You're going to have, you know, Ethan's network will use 10 dot something

in Holly's network.

I'll also use 10 dot something.

So James, a service provider network is like,

how do I distinguish between these two networks that are sharing the same address space?

But in fact, our different networks.

Exactly.

So you can't have things like overlapping address space between your customers.

Which, you know, these days, IP version six and private addressing is more prevalent.

But we also were talking back in a time when it was pure IP version four.

And we can't be giving everyone public IPs for everything.

We haven't got enough IP addresses.

So clashing or overlapping, I private IP space is prolific.

And it creates another set of problems,

which is that every device in the network needs to know all the routes.

So if I've got my, I've got my four compass points.

And the one that's in the middle, linking them all up, he has to know all the routes

to know where the traffic goes that he receives.

So this is scales very poorly, basically.

Yeah.

Every device has to have all the routes for all my customers.

Yeah.

Is if you're a service provider of any size,

you'll have hundreds of thousands or millions of routes to be dealing with.

And that if that were the scenario.

Yeah, exactly.

And also it's the same for layer two as well.

So if people want layer two connections, it is less common,

but it also happens that people have clashing or overlapping MAC addresses too.

So same problem.

You can't just have one giant MAC table.

That's supposed to be true, but in practical terms,

it ends up being that way.

Yeah.

Yeah.

So that's kind of where we get to, right?

Is this we have these a few problems to do with the size of the routing table.

The time it takes to do the lookups in the routing tables.

Yeah.

We don't have fast devices.

And then also I've got this overlapping address space.

And I also don't want the headache of managing address space for my customers.

That would be terrible.

So I need some way to abstract all of that and be able to just to forward traffic

across my network.

And for my my devices along the path,

do not have to know where the file desk to know all the IPs of my customers.

They just need to know, OK, it needs to go to the east.

I'll forward this traffic to east.

That's all I need to know.

Nothing more, nothing less.

And also we did our little walk down memory lane with circuit switching

and then virtual circuit switching and then coming on to packet switching.

The other thing is the industry went through this transition period

where we're migrating from one technology to another.

If you run a packet switch network and I have an older customer

who uses virtual circuit switching,

how can I provide him connectivity over my packet switch network?

It says also MPLS also gives us the possibility

to transport protocols or technologies that my routers don't understand.

So I basically encapsulate the customer's traffic

because I don't actually understand in an MPLS label

and then I can carry it across my network and I don't care.

So that's also quite a nice feature.

Not that you're doing much of that today, but back in the day.

Yes, thankfully it is very rare to encounter such things.

But if you read back through the early RFCs and stuff,

those were some of the features that were going in.

So just to clarify.

So we've got MPLS, you've got a label, right?

And now we're saying, we don't really care about IP as much.

We just have to know, OK, we see the label.

We know, for example, what customers are associated with that label

and we can just forward the packet in that general direction?

That's kind of basically the high level concept.

Yeah, we can dig into it a bit more.

But that's basically the high level concept.

Yeah, we just ignore whatever we don't ignore it.

But the first device on the edge of the network

receives something from the customer.

This first device has to be aware of.

So if it's Ethernet, it has to speak layer two

or if it's IP has to do understand layer three.

And he has to work out based on this IP address.

What's the correct label I need?

And everything else along the network

is only looking at the label.

So then all the rest of my network is ignorant of what is inside.

So, OK, so this is an important concept then.

In an MPLS network, my edge routers know a lot of things

about both my customers and my MPLS labels.

But in the middle of my network as a service provider network,

I know my routers know about MPLS labels.

And that's it.

They don't really know much about the customers themselves.

Yes, that's a really fundamental and like common design case

service provider networks.

Your edge devices tend to be low scale, but high features.

So they understand layer two and layer three.

And then they understand IP version four and IP version six.

And anything else you can shake a stick out.

So they understand all the different kinds of things

and they have all my customer routes on them.

But they're kind of, for example,

you have to make a trade off when you build a router.

I have these many, many features,

but a lower bandwidth or lower packet per second rate.

And then the devices that sit in the core of my network

are kind of done, we call them done devices,

feature less rather than feature rich.

They're pretty low on features, very high throughput.

All they just have sort of a much more limited feature.

So they just understand labels,

but they can do this one thing extremely fast.

So I can have lots and lots of edge devices spread out

all over the place where all my customers connect in.

And then a couple of some kind of central,

but very high speed core devices that link them all together.

It's the old, what's the old expression?

Like cheap, fast, good, pick two.

It's that kind of thing.

So you can't have edge devices on your network

that can speak 25 different protocols

and be high speed, like Android, MPL, and everything.

That's kind of the trade offer.

It's a very common service program networks.

The edge devices are complicated, low speed,

core devices, sort of less complex, very high speed.

All right, so we've got like the general idea of MPLS

and kind of where it stem from.

But I'm assuming that it wasn't always a standardized protocol.

So how did it get to the point?

Like now we talk about labels.

And I think historically,

there might have been some talks about tags

and other terminology.

How did that evolve?

Yeah, that's a good point.

So when we, air quotes,

decided to develop this technology,

the real spun out of Cisco,

the original form of this spun out of Cisco.

So Cisco had a technology that was called tag switching.

It's synonymous with label switching.

And Cisco developed a protocol that was called

tag distribution protocol, TDP.

And tag switching and TDP ended up being standardized

through the IETF as what we now call MPLS or label switching.

And the protocol then for distributing labels across the network

so that devices knew which labels to use,

which is then called the tag distribution protocol,

became label distribute and protocol.

There were two guys that worked on it, right?

Yakov Rector, who was a legend.

He, one of the guys that invented BGPs, Yakov Rector.

And Eric Rosen, who also did many MPLS things,

also early, they have a lot of the early multi-cast development.

So those were two sort of giants of their time.

Also, also doing up to MPLS.

I'm great enough in my beard James,

that when I was studying MPLS back in the day,

both TDP tag distribution protocol

and LDP label distribution protocol were presented

with that background you just described.

As Cisco, we came up with tag distribution protocol,

it's working through the IETF, we're moving towards

label distribution protocol and standardizing on that.

So that sort of been, I guess late 90s, early 2000s,

I have to go back and do some digging,

but that time frame was I recall.

Yeah, I see.

No, I've read James.

I think the first service product network I touched

was around 2015.

And we still had in iOS then tags switching commands

that kind of not long after then faded out.

I remember we were running quite an old iOS version

and after a few upgrades, the commands were gone.

That was the tail end of it.

Yeah.

I want to dive into something that I realized,

I actually don't have knowledge about,

and that's, you mentioned label distribution protocol.

So you've got MPLS, you want to run this protocol

across your network with these labels,

but I guess I never even thought about how do all

of the devices learn about all of the labels they need to know of.

So I'm assuming label distribution protocol

is the way of distributing said labels

that the network engineer has predefined.

Okay, yeah, there's two, there's two things to what you just said.

So yeah, LDP label distribution, label distribution protocol

say that after a few drinks.

That's, that is one way that labels get distributed,

but there's a step that comes before that,

which is actually allocating the labels.

Okay.

So there's a concept in MPLS that we call FECs.

It's just stands for forward equivalency path,

or forward equivalency class.

And it's a fancy way of basically saying stuff

that belongs together.

So I've got my customer, he's connected to my East

and West routers.

And so he's got an office connected to West

and an office connected to East.

And he sends me his roots from his East office

into my East router.

And my East router is going to send those roots across

to my West router.

So now any traffic that comes into West,

I've got the root.

I can do a root look up and say,

okay, I need to send that across to East

because that goes to his office over in the East.

So all the stuff that needs to go

to the same end point, the same direction

or out of the same next hop or the same interface,

anything that belongs together like that,

we call that a forward equivalence class.

So there's anything that needs to get...

You can kind of summarize it and say everything

that needs to go in the same direction.

We call that a fac.

Or can you give examples of where you buy everything

or we're talking about a bunch of different IP routes

for a customer?

Yes, yes.

If I've got my...

So for example, my customer, like I said,

he's got an office connected to in the East

and one in the West.

And let's say one in the North as well.

We've got three offices, East, Worth and North.

And all the roots they send into East,

that would kind of be one fac.

So what that means is,

if the customer sends a packet into West,

and we do a look up on the destination IP address,

and the destination IP address is one we learned

over in the East.

So it belongs to this FEC,

that we've assigned for everything in the East.

There could be, I don't know,

10 different IP prefixes that belong to that East Office.

Yes, so in the East Office, he's got one IP,

he's got like this person,

he or she has got like, say 10 different lands,

finance and HR and R&D, right,

and the guest network.

Each one has a different IP subnet,

but they're all over there in the East.

So for my service provider network,

I don't really care.

For me, they're just over on the East side.

So I will...

I can group them all together and say these things,

any traffic that needs to go to any one of these prefixes,

they all need to go to the same place,

which is this office building in the East.

So these FECs aren't...

Like, let's just say customer specific.

Let's deal with the service provider network.

It's not like one customer gets a FEC.

It's each location for each customer has their own FEC.

It could be.

It could be...

It's annoyingly, it's a bit more abstract than that.

So it could be...

It's more...

So within the network,

anything that needs to go out of, say, this interface,

interface one, we'll just call that,

we'll say that's FEC one.

And anything that needs to go out of interface two,

is FEC two.

So it's much more abstract.

It's not that it's a specific customer, for example.

It's really a way of, kind of,

saying anything that I need to send out of this interface

or towards this next top IP address, for example,

we give it this, what we call, a FEC.

You can think of it maybe, is grouping things together,

and it's just some sort of group ID.

But it's pretty abstract.

So in my case with customers, yeah, we could say,

this customer, the customer who's connected to me in the East,

yeah, all their prefixes, they get one FEC.

And if I have another customer connected to me in the East,

they would get a different FEC.

So it's quite an abstract concept

to kind of get your head around.

Yeah, so I guess if I'm understanding this correctly,

a FEC can be defined by the network engineer.

There's no like standard for, like I said,

it's not like, oh, we're going to assign,

I guess because it's a class,

I like to think of classes,

makes me think of QOS,

and those are very defined classes of what goes into this.

This is kind of like,

this is what works for my networks,

so I'm going to assign X, Y, Z to this FEC

because it works well for what we intend to do.

Yeah, I mean, we don't actually,

thanks to the wonders of technology,

we don't know how to assign them manually at all.

It happens automatically within my router.

So, I'll give you an example is,

so one example is,

I have two connections on this on a router.

I have two connections on a router.

And one of the connects,

so we're going to go from New York to London.

And I've got two links from New York to London.

And one of them is a very low latency link,

which is incredibly expensive,

transatlantic connectivity is extremely expensive.

So, one of those low latency,

and it takes the most direct path.

And my second link is higher latency

that takes a kind of much longer path and is cheaper.

So, I only want to put customers on my low latency path,

who are going to pay the extra cash, basically,

because they're costically affordable to have.

So, it's not something that I would kind of say,

the path one is spec one and path one is spec two.

But I can assign something,

some sort of identifier to each link.

And they kind of implicitly become two different facts.

So, for example,

traffic is coming from my first customer,

and he's a high frequency trader.

And he's paying me for low latency.

So, as his traffic comes into my router,

it will mark his traffic somehow.

I'll put a DSCP marking in there.

I will put him in a specific VLAN.

I'll put him in a different VRF.

I will put him on a special interface.

Somehow, I've identified him as being different.

And then I've got another customer.

She's connected to port number two.

She's not interested in the low latency,

but she's got huge amount of bandwidth.

You can take a longer path.

She does data transfer or something like this.

So, again, my second customer,

I'm somehow I make them unique.

Put a unique DSCP value on there.

Put them in a different VLAN.

Put them in a different interface.

There's a bunch of different ways I can do it.

And I'm linking the first customer

with this low latency path.

And the second customer with my higher latency path.

And just by kind of,

it's a very difficult concept to explain

without a diagram.

But with that,

two different paths will have two different facts.

And it's something that happens automatically in your router, right?

As long as I differentiate these things

as being two different things,

two facts will then be allocated.

Is a fact something that,

if I were to look at a router's configuration,

I would see a definition of a fact,

or is that a concept we're using

and what we're really talking about as a label definition?

Yeah.

There's nothing you can see,

unlike the CLI, for example,

to show that this is a fact.

There's a very abstract concept.

It's more how the root is working internally.

So these things,

so the root is internally,

it's allocating effects to the grain.

Okay, all these things need to go up the same interface.

So I'll just call those fact one.

And all these other things,

they all need to go up the same interface.

So I'll just group them together

and call it fact two.

And then for every fact we have,

we allocate a label.

Oh, yeah.

So I've got my root.

The labels are real thing.

Labels are real things.

So you have a label table,

where we store the labels we've allocated

and what they point to,

which in the background is the fact.

So what that means is I've got my root.

And I've got a bunch of different interfaces

that go to different places.

So if we go back to my compass topology,

north, east, south, and west,

and there's one in the middle linking them all up.

So the one in the middle,

he's got four interfaces,

one that goes north, east, south, and west.

And so the go four different places,

they do four different things.

So internally it's created four facts,

and allocated four different labels.

We'll just say one, two, three, four.

And so now any traffic that comes

into my router in the middle,

there has label one on it.

He knows he will look in his label table.

Label one was to interface one.

So he knows it needs to go over the interface one.

Any traffic that comes in with label two on it,

he just looks in his label table.

Label two, that's interface two.

And so it ships you off of interface two.

Can you have multiple labels mapped to a single thick?

For special cases you can,

yes, if you want to do some kind of very special,

we call traffic engineering.

Yes, it is possible yet.

Also for things like special kind of routing.

So there are use cases in service provider networks we have,

where we want to send traffic

not along the best path.

So if you were looking at a routing table,

and you say where's the next hop for this route,

it's have interface three.

Sometimes we don't want to actually go that way.

Because there's packet loss on the link,

or it's, it's got a higher bandwidth or a lower latency or whatever.

So we have a concept called traffic engineering and impulence,

which lets us basically send traffic

in a way that is against the default rules.

You know, it kind of counter to what you,

so we can do things that you're not supposed to do.

Let's say like that.

So that MPLS labels,

is it appropriate to talk about a label stack at this point?

Because as I understand it in the MPLS world,

you don't just have one label assigned to a packet.

You could have a stack of labels

that help guide that packet through the MPLS core.

Absolutely, yeah, yeah.

So perhaps we could talk a bit about the MPLS header,

and that would make it a bit clear.

Yeah, so we said we allocate labels or gone.

Before we get there,

before we jump into the header,

I just want to define a label.

Like what exactly is the label?

Like is a label?

Like,

because to me a label is kind of an English term for something.

Like if I'm laboring things, it's like,

oh, customer A, B and C.

Or is it like low latency customer?

It's an arbitrary set of bits that create and unique.

Like what exactly is that label?

Yeah, it's a really good question.

So a label is the latter.

It is just an ARP.

So we have a label header.

It's a header.

It's 32 bits.

So four bytes long.

It's just a very small header compared to IP and other protocols.

And there is a value in the label header.

So it's the actual, sorry, let me rephrase.

There's the MPLS header.

Part of the header is the label number.

And it's just a number.

It goes from one to about one million.

So you've got about a million possible numbers.

And that's it.

It's just a number.

And it's completely arbitrary.

So if we allocate facts for things,

so all everything that needs to go to interface one,

there's going to be effect one.

Everything that needs to go to interface two is effect two.

And we'll allocate a label for each facts.

We allocate label one.

And we allocate label two.

And that is it.

There's just this abstract label.

So it is an actual, like Ethan said, it's a thing.

It's a physical header we put on to packets.

But really, it's just a number.

And we can just, for example, with IP addresses,

these are allocated very carefully.

And we use classful subnetting to not be wasteful of IP addresses.

And there's kind of a hierarchy who will design to IPs.

Labels who just allocate the next one, the next one, the next one, the next one.

Did you've got a million in that enough?

Right.

Yeah, for most people, that's enough.

So we just allocate the next one.

If some early one becomes free, we can also go back and use that one.

We don't care what order they get allocated in or free,

don't know anything, they're just numbers.

So this is also kind of part of the beauty of MPLS,

is that it is so simple.

Very simple.

Yeah, I know it sounds confusing.

But if you compare it to IP, for example,

where you have to, like I said,

there's a hierarchical addressing screen scheme

that you have with IP addresses.

And we have to be very careful about how we allocate them

and your routing table grows if you do not aggregate your address space nicely.

If you just allocate IP addresses all over the place,

you end up with this messy routing table.

But for labels, this is not really a problem.

It's fixed.

There's one million entries.

You can't have more, and you can have less, but you can't have any more.

So we just have this fixed table size with a million entries in it.

And you can put in each entry, whatever you want.

So James, I'm your customer.

You're my service provider.

I give you a packet.

It doesn't have an MPLS label on it.

I give it, give my packet to you.

At some point, you put an MPLS label on it.

Can you explain what my packet without an MPLS label on it?

We know what that looks like.

I give it to you.

You're going to put an MPLS label on it.

What does my packet look like that?

Our sponsor meter is a network as a service company.

And that means a meter network is a tightly integrated stack

of network hardware and operating system software delivering wired,

wireless, and cellular service.

And they deliver that gear to your premises as a service,

such that the fussy parts of network operations are handled by meter for you.

So for example, you don't have to worry about upgrading a switch

to make sure that it stays secure.

Meter's got you covered.

Plus, they monitor your network remotely, so no matter how big or small it is,

from branch office to a data center, meter can handle it.

Meter does more than ship you gear.

They also take care of everything needed to bring a site online.

Internet, wireless site survey, cabling,

that is all part of what the meter offering is.

The networking stack is going to give you all the things that you've been learning about

on in this for networking, routing, switching, wireless,

firewalling, security, cellular, intelligent power, DNS security,

VPN, SD-WAN, and there's more stuff than that offering too.

Now in fall, 2025, I did a video on the Packer Pressure's YouTube channel

showing you a meter stack, and I'm going to do an updated video in 2026.

Why?

I was at Meter's headquarters recently,

and I got to look at their new hardware and a preview of their software updates,

the things that their clients come in soon, and these guys are iterating fast.

And there's a vibe.

There was a vibe when I was there.

I felt this genuine thrill of enthusiasm from the meter folks who I was talking to.

A hundred percent.

The meter team is excited about what they are building.

So thanks the meter for sponsoring.

Go to meter.com slash n4n.

That is n the number four n to book a demo now.

That is meter M-E-T-E-R dot com slash n the number four n to book a demo.

Okay, sure.

So let's say you're going to send the packet into my west, my west router.

I keep with the same topology to make it easy.

So you're sending it into my west router.

It's got an IP address in it.

I'm going to look at the IP address.

I can say it.

And I know that this packet belongs to Ethan.

Because it came in interface one.

That's where Ethan's connected.

So I know it belongs to you.

So I'm going to have a look at what routes do I know for Ethan specific.

In the same holly's got her own private network.

So I'm going to look at my routine table for Ethan.

I know Ethan routes.

Because you may have overlapping IP addresses.

So I look at my routes for Ethan only.

Aha.

I know this destination IP address.

It's connected to Ethan's office over in the east.

Okay, so I need to get it across to across your core out.

Yeah.

You know, the east bound router, let's say.

Yeah.

And now I've got a route for this prefix from Ethan and it's over in the east.

I need to get over there.

Okay, so two things need to happen.

I need to get the packet across the network to the east.

And then when it gets to the east, my east router.

And my east router needs to know which customer descended to because I've got many customers connected there.

So there's two things I need to to tasks.

I need to accomplish, let's say.

So I need to push two labels on one label that's going to get my packet across the network to the east router.

And a second label that's going to tell that east router.

This is for Ethan.

And you know, not for holly.

Don't send some private data that belongs to Ethan to holly.

That would be bad.

So I'm going to, so what happens is I have to do, first I do a routing look up.

I say, okay, this IP address belongs to Ethan.

And I've learned it from the router over in the east.

How do I get to east?

Second look up.

So I have to do another look up.

How do I get to the router in the east?

Aha, he's over there.

I have to send it to the router in the middle of my campus.

I have to send it to that router, which is interface five, whatever it is.

That is you need to provide a path via labels to get through your core.

So that it comes in, gets into the middle of your network and then comes out the other side on the east.

So I got to get from edge to edge through the core.

That's exactly correct.

Yeah.

So this tie this back to what holly asked earlier about label distribution protocol.

So before I had any customers, I've just built my network.

I've got my four routers around the edge and one in the core.

And all my routers have got an IP address.

It doesn't matter what it is, but they've all got an IP address.

And so to use holly's example early of label distribution protocol, or we just call it LDP.

So this is when each router will allocate a label for its own IP address.

And then share that with the other routers in the network.

And LDP is one way we can do that.

We can use LDP.

For each router to say, this is the label you use to get to my IP address.

And LDP is one way RSVP is another way segment routines the other way.

That's kind of a more advanced thing.

But I have a method of first allocating labels to the IPs of the routers themselves and distributing the labels.

So the packet that came into my West router from from Ethan.

Okay, it needs to get across to East.

So how do I get to East?

Ah, I've got this label 10.

Label 10 will get me across to East.

But also when it gets there, I need to East needs to know that this is for Ethan and not for holly.

So when my East router learned the IP prefix from Ethan and sent and he advertised across to West router,

he said, this is an IP address that I learned from Ethan and I've allocated label 20.

So my West router knows, okay, I need label 10 to get across to East and I need label 20 to say this is Ethan.

So I'll push two labels onto the header stack.

First is the key word there push.

That's a specific MPLS operation, right?

Yes, correct, yeah.

So I'll come back to that in a second.

But I'm going to create this header stack of two labels.

First one is 10, second one is 20.

I send my packet to the gut to the router in the middle.

He looks at the first label and says, 10.

Ah, yeah, that's the label allocated to the IP address of the router in East.

So it needs to go East.

So he just forwards it on East, he's just looking at that label.

Every router along the path is just looking at a table.

10, what does that mean?

Ah, East, okay.

So they just keep passing it along towards the East until eventually it gets to the East.

And he says, 10.

Ah, that's for me, okay.

Remove that label.

What's next?

20.

Ah, ha.

That means inside here is an IP packet for Ethan.

So he then throws that label away and sends that sense of packet to Ethan.

Because I don't want to receive a packet from you that's got MPLS labels in it.

I don't know what to do with those.

So you're going to remove them before handing me that packet again.

So it looks to me like I had a direct connection from West East.

It's just an IP packet from me as the consumer of your service provider network.

I don't know that anything MPLS happened.

I don't have to configure a router for MPLS.

I don't know.

You just handled it all for me as a service provider.

Yeah, that's correct.

Yes, and for you, it should be fully transparent.

So I want to like bring in our conversation about tunneling way back when.

Because I think that was another conversation that.

That I'd.

Confuse me, telling confuse me initially.

But like this just sounds like let's say in your core network,

you've got these MPLS tags that know the routers in your network.

Those are kind of tunnels that have a specific MPLS tag.

They know about each other.

Doesn't matter what goes on in between.

It just knows.

Tag 10 or label 10.

It's got to get to 10 on the other side.

Great.

So in the edge, you've now got say kind of more tunnels,

but you take off the outer label because that was the internal core.

Let's say edge to edge rooting.

And now it's customer base.

And now it's okay.

Well, you've gotten to your east router.

For example, now you need to get to your customer.

That's the next label.

So it's.

Kind of just a tunneling protocol.

But I don't know if everybody calls MPLS tunneling.

But that's basically it.

Right.

So there are two phrases that we use MPLS.

So the label that gets the packet across the network

to the other router.

We call our transport label.

Transports the traffic across the network to wherever needs to go.

The label that said then this is for Ethan.

We call that service label.

Exactly.

Because that's when I provided a service to Ethan,

which is connectivity from west to east.

So there's two labels one on top of the other.

The first one is the transport label across my network.

The second one is the service label,

which identifies my customer.

And now the encapsulation is done by the whole MPLS header,

which includes all of these labels.

Exactly right.

So we have an MPLS header.

So in the header, you've got the label value.

It's 10, 20, 30, 40, 50, whatever it is.

You've got the what some people call the EXP value.

It's basically a cross-value, a cross-marking.

So some people call it traffic class.

Some people call it EXP.

So there's the label number.

There's a cross-marking.

Then there's two more fields.

There's one called bottom of stack.

And that's just a flag that's just on or off.

And the bottom of stack bit means this is the last label.

There are no more labels beyond this point.

Beyond this point is the customer data.

So in the case with Ethan's network,

I put two labels on.

The first one is 10, the transport label.

And 20 is the service label.

And that's the last label.

So there we set the bottom of stack bit.

And the other field in the MPLS header is the time to lift field.

But you also have an IP route in IP headers.

And that's to stop routing loops.

Stop my packets going round and round and round by mistake.

So you've got this.

So you only like de-incaptulate the packet once you hit that bottom of stack bit.

Which makes sense.

That it's not like multiple encapsulations.

It's just on the MPLS header.

Each router is going to look and be like,

OK, I've read a tag.

Is this the last one?

No, it's not.

Keep going as an MPLS packet.

Exactly.

Yeah.

So there's a philosophical conversation.

You can probably have about like,

what's the difference between tunneling and encapsulation?

Like, we probably need to have a few more drinks before we get into that.

Yeah.

So there's arguments about EZMPLS tunneling.

There was a whole packet process show that goes way, way back over a decade, I think,

where we argued, I don't remember if we came to a firm, firm conclusion.

Well, that's why I'm like comparing it to tunneling.

But if you don't think it's tunneling, great.

If you do, great.

Well, James, is it reasonable to talk about an MPLS tunnel?

Is that a term you guys use?

It is a very everyday term that people use.

It's a tunnel.

So I built a tunnel for Ethan from West to East.

It's very everyday terminology, yeah.

We would call it a tunnel.

Which, to me, it's a tunnel because you're building a, that you mentioned in the beginning,

it's an abstraction layer.

And that's the whole point of tunneling is to create an abstraction layer where other devices

on the network don't need to know what's happening inside the packet.

They just need to understand that outer header.

Exactly.

So there's like some pros and cons to it.

So I said earlier that MPLS is kind of simple.

I mean, what I meant is really in terms of like the header is very basic.

Yeah.

There are four fields.

The main field, which is the label, which is just, it's just a number.

I think that it's pretty basic.

Can't get, can't get much more basic than that.

It has no, for example, MPLS has no field that says what comes next.

So in an ethernet header, you have an ether type field.

And it says inside the ethernet is IP version four or IP version six or whatever.

And in IP, you have a protocol number that says after this IP version four header comes a TCP.

And in TCP, we use the port number.

So if it's port four for three, we use that to indicate that it's HTTP traffic.

MPLS has no such header, no such field in its header.

So there's like pros and cons to the simplicity of this.

So one major con is not having a field that says what comes next,

but instead relying on this bottom of stack flag.

Because what that means is any device is that need to look beyond the label stack,

have no idea what comes next.

So an example of that is not the, what we call the ingress device,

where the packet came in and not the egress device,

at the other end of my network, or at least, but the device is in the middle along the path.

All my core routers along the middle.

If I have two core routers, and I've got four links between them,

and I want to load bands traffic across all four links.

The way the load balancing normally works is I would look at something inside the packet

that would differentiate it from some other packet.

So all the packets that have got destination IP address 123 will go on the first link,

and all the packets with destination 234 will go on the second link, and so on and so on.

But if the packet has got MPLS header on it, when I look at it,

they've all got the same label.

All the traffic going from east to west or west east will just got the same label number.

There's nothing to load bands on.

And my router, and there's nothing that says what comes after my label.

So there's no way for my router to know, okay, what comes next?

Is it IP version four or IP version six, or is it ethernet?

To do this load balancing.

So there are like trade offs, let's say like that with the, with the simplicity of the MPLS header.

Okay, but you asked about, you asked about, I said pushing labels on.

You mentioned pushing and I felt it was worth talking about those MPLS operators

because when you study it, those are terms that have meaning.

Yes, there's a lot of fundamental terms to understanding MPLS.

So I said in our example, packet comes into my west router,

you do a lookup, an IP lookup side where the packet needs to go,

and we push some labels on. So it means we actually add some MPLS headers

onto the existing header stack.

And then we send the traffic out of my interface across the call.

Let's just pause there for one second.

Okay, so push is an MPLS operation.

And you mentioned we've been talking about the MPLS header.

We've talked in this show a lot about layer two versus layer three.

We followed the OSI model because that's just commonly the way everyone talks about it.

MPLS isn't a layer two or a layer three header.

I've heard it described as layer two and a half.

Do you have thoughts on that, James?

Yeah, it's...

So the OSI model is a really good way to get your head around all the different layers we have,

which things fit into which layer and how they interact with each other.

But it's obviously, there's no such thing as one size fits all.

And so MPLS is one of those things where...

So you send some IP traffic to me.

So this is layer three traffic.

The link from my Westrooter going towards my call.

It is an Ethernet link.

So as I send the information out of this link towards the call, there'll be an Ethernet header,

which is layer two.

Not my Ethernet header, but yours again.

I send you...

All you care about is the IP part of what I sent you.

So I will have an Ethernet header because I've got Ethernet link between my two devices.

I've got an Ethernet header.

And, you know, you...

Just before your IP header.

So after my Ethernet header, but before your IP one, I've got my MPLS labels.

I've shoved them in there between layer two and layer three.

I've just crowbar them in.

You see.

So some people call it a layer 2.5 header.

Some people also call it a shim header because I kind of shimmed this extra information in between layer two and layer three.

Which, that to me makes sense why some people might say it's not really a tunnel because you've got your Ethernet header kind of on the outside, not your MPLS header.

Yeah.

So I've got an Ethernet header so that my two routers can stay to each other.

As they go along each hop in my network, I need an Ethernet header to go between the hops.

Then I've got my MPLS labels.

And so also on this tunnel versus encapsulation type conversation.

My first device puts, pushes these labels on.

He's going to send it into the core.

The next device receives this...

There's got these two labels on here.

And he may have to then do something.

There are other operations.

So we said push labels on.

When the packet gets to the very end of the network, call it popping, removing the labels again.

There's two other operations.

The first one is a swap.

So we've got push and we've got pop.

The third operation is what we call swap.

And so what that swap comes into play where a label stack comes into a router.

And it's label 10.

It needs to go out of interface 25.

But I just swap it before I send it out.

The next guy in the path expects label 50.

So I receive label 10, but the next guy for the same purpose, he uses a different label number.

So labels can be allocated.

You can use the same labels across all your devices, but you can also allocate labels uniquely.

So if your device is used different labels for the same things, then as the packets travel across the network,

so one device receives something with label 10,

okay, I need to send it to the east, but he expects it to be label 20.

I don't have to swap this 10 for a 20.

So you have to swap operation going on.

Because the way in which we do label allocation now is it's a long story, but there are different ways you can allocate labels dynamically, statically, and with controllers and this kind of stuff.

So you can have the same labels everywhere or every device can use his own labels.

It quickly gets complicated.

But the going back, okay, so we've got these different operations, but if you receive an IP packet,

you add, you pushing those MPLS labels, where are they sitting then?

Let's say IP is full IP throughout the whole network.

Yeah, so where are you pushing them in like the stack?

So the very first device is going to receive the very first device is going to receive a packet.

So I've gone ethernet interface facing ethernet, and I've got an IP address configured on there.

So the packet that I get from him is going to have an ethernet header with my MAC addresses, the destination.

So it comes in and it's got an IP header, but the destination is somewhere over in another office, on the other part of the country.

And it's my job to get it there.

So it comes in with an ethernet header and an IP version four header, let's say.

So I look at the destination MAC address.

Is this for me?

Yes, it is.

I'll take this.

Now let's look at the IP address.

I'll do my IP look up.

I've got I've got this route, but it belongs.

It's connected way across the other side of the country on the eastern side of the country.

So I need to get across there.

So now I'm going to say, okay, if I need to get it to east, I do my label look up and say, okay, I need to put label 10 on here to get it all across my network.

And specifically when it gets there, it belongs to Ethan.

So Ethan's stuff is label 20.

So it's well like to push label 20 on as well.

So I've got my IP version four header.

I've got my two labels underneath.

Okay.

Which let's say ether interface two is the one that faces east.

So I'm going to send it out of interface two on my router towards my call router.

And that's an ethernet link.

So I've got to have a ethernet frame with my source MAC address.

This is my router in the west.

And the destination MAC address is my call router at the other end of that link.

So as the frame goes out of the link, I've got an ethernet frame with source and destination MAC.

I've got two labels on top.

One is my transport label that will get this all the way across the network.

One is my service label that then identifies which customer it's for.

And then on top of that, I've got Ethan's IP version four packet.

So you've got it.

So that's the kind of, I don't want to scare people off, but that's the kind of the basic premise

because we have devices that will push four or five six labels on a time for different purposes

because you need this special routing.

I guess that makes sense why you kind of call it 2.5 because you're pushing these labels

like in a sandwich.

They're going to be in between.

They're never going to be as a outer header encapsulating like an entire frame,

an entire packet because obviously you need to transport those packets of frames across your network

using either IP or ethernet.

So your label is just shoved into the sandwich.

So that, you know, the next guy know the next router knows where that label needs to be going,

but it still understands that oh, it's an ethernet frame or it's to get to that destination MAC.

I don't like this, but I understand it now.

It definitely, it definitely is a bit of a mind bending thing.

You need to get your head around.

Like I said, it's very different to what people normally do.

And that kind of agitates people.

But like I said, it's very much so.

Yeah, if you can somehow get your head around this very different way of doing things.

Like I said, it's actually much, much simpler.

It's just labels, which is just a number.

Every device is just looking in a big list.

Do I have this number?

Yes.

Okay.

And what do I have to do sending out of interface five?

Right.

And kind of finally go.

I think I've been wrapped my head around this part of it.

But then my next question would obviously be, well, we don't have hardware limitations

anymore.

We've got fancy A6.

We've got, you know, route tables that can, you know, store as much as you would like.

So do we need MPLS?

Or can I just, you know, skip over and continue on my networking journey?

I think it's a no.

But.

Yeah.

It's a really good question, actually.

So, you know, why do we need it?

Because all the things I said earlier, like circuit switching is gone.

Virtual circuit switching is basically gone.

Rooting tables, like you said, are huge.

We can start.

Yeah.

So the network I work on, we have like 10 million routes in our routing table.

The A6 that we deploy can do billions of packets a second.

So that's a really valid question.

So despite being kind of frustrating to think about the MPLS forwarding paradigm in your

head, this level of abstraction really opens up some new use cases that didn't exist.

So before we had those use cases, we, the Royal, we had those use cases back in the past that led to the creation of MPLS.

And in the meantime, you know, and like you said, those use cases have more or less gone away.

In the meantime, we've come up with a bunch more because because we've got this technology that lets us create a layer of abstraction here.

What else can we do with it?

That's kind of what the industry has been thinking for the past 30 years.

Well, what else can we do with this stuff?

So this is less to all sorts of magical things.

So I said to you earlier, I think it's very difficult to explain in simple terms because these are some very, very advanced topics.

But for example, I have, I'll give you a use case that we have in my day to day job.

So I have a ring, the topology I have as a ring is a circle of a root is in a circle.

And traffic comes into the ring at some point.

It's coming in at nine o'clock. So it's got 12 root is in a clock.

Traffic is coming in at nine o'clock.

And it needs to go around the ring to three o'clock.

And traffic is happily going, this is as clockwise around the ring from nine.

It goes up and around the three.

And when the traffic, when this link is nearly full, it's 90% full, something like this.

I want to start because this is the shortest path.

Right. Let's say this is the shortest path.

Yeah.

Traffic comes into the nine o'clock.

We do an IP look up.

The next hop is 10 and his next hop is 11 and so on.

Because that's the, they've got, there's the shortest path around.

So when I get to 90% full, what I want to do is start sending some of the traffic,

but not all of the traffic, the other way around the clock.

So I want this, this kind of what we would call like surgical precision level of traffic steering.

Okay, so 90% of my traffic is going clockwise.

That's, that's enough. I don't want to go anymore.

So I'm going to start sending just 10% the other way around.

So what I can do is allocate labels.

From my devices, the bottom, the go, the other way, the brand, the bottom half of the ring.

So anti-clockwise around the ring.

And allocate labels for all those hops.

And then what I can do is, traffic comes into router number nine.

I'll send it down to number eight.

And if number eight had done an IP look up, you would just send it back up again.

Because that's the shortest path.

But I sent him a label.

And it's the label to reach five.

So he just keeps forwarding it downwards towards five.

When it gets to five, he pops the label off as another label, which goes to three.

So he forwards the industry.

So I can use the, but can build the label stack and force the traffic.

A, you know, the non-best path around the network.

And so for example, this gives rise to a nice use case where I can start doing traffic sharing

along my non-best path.

What?

So you need to push those labels.

What is making the decision to push the label to direct the traffic in the opposite direction?

Now, that is a very complicated question.

Yes, it is.

Yeah, that's at least an hour.

But we can summarize it probably because that does mean this gets into really advanced use cases of MPLS.

So there's different ways you can do it, right?

The, let's say the worst case scenario is you just hard code that on all your ruges.

You can, you can write it out in config and just hard code everywhere.

That's kind of the worst case scenario.

Probably the sexiest scenario is we have what we call a controller.

So some device that sits elsewhere in the network is monitoring the link utilization,

knows about all the paths.

More correct dynamically on the fly in real time.

Tell all the devices, like speak to them all in real time, allocate a label,

and tell them to start low balancing traffic across these two different paths.

And a PCE path computation element and PCEP path computation.

Yeah, so P steps one way to do it.

Another, you can also distribute.

So this is what called segment routing policy.

You can also distribute it actually via BGP as well.

So you can actually inject policy over BGP into the network.

And that is.

We're really talking about methods that step outside traditional routing protocols

that lean into shortest path in doing some kind of traffic engineering.

We're doing some kind of computation on things that are beyond what we would do

with the typical routing protocol to make a forwarding decision based on these other things.

Capacity.

Economics, I've heard is one James where it's really expensive for me to send traffic across this thing,

like in dollars.

And I don't want to use that during this time of day or for this particular customer,

whatever it might be.

And so for the sake of the dollars, I want to push packets across this other link instead.

And, you know, PSAPU said is one way to do that in a sub end in BGP.

But you can make these policy decisions that are above what a traditional routing protocol does

with normal, plain old shortest path and then make that forwarding decision based on time of day

changing traffic conditions and reconfigure the network and the forwarding paradigm to match

what you needed to look like at any given point in time.

But man, yeah, it's complicated.

There's a lot going on.

Yeah, yeah.

The opportunities or the possibilities are really endless.

I think the key takeaway is that basically what we're getting from MPLS is if we were doing IP routing,

every device in the network does a look up and makes its own decision.

And the key factor here we're talking about with MPLS is that the first device at the start of the path

pushes a set of labels on and that dictates the path across all the rest of the network.

And that's kind of a key aspect that gives us the flexibility to do all these weird and wonderful things

is that we, at the ingress point, we push a label stack on and we take away from the other devices

possibility to make any other decisions.

The label stack we push on at the ingress is dictated the path across the rest of the network

so that way we can do all these counterproductive things or counterintuitive things.

Very productive, but counterintuitive.

Yeah, yeah.

It's been a long day.

I was going to say I have so many questions and I think there's so much more to discuss on MPLS,

but I think maybe we call it a day for that and we see what follow-ups we get

and on a future episode we can dive into all of these methods and traffic steering

and everything else that's swimming around in my head.

I guess in short, MPLS, in my own words, it is just you pushing labels

in a sandwich fashion instead of kind of a wrap of a pack of a frame

and you can have a label stack, they are swapped and popped and moved around

and eventually it gets to where it needs to go based on the label and not based on the IP address

in summary, right?

This is Holly, I don't want to.

MPLS has had some big, thick, whacking books on the topic that get into a James

which is just alluding to with the end.

There are huge books that have been written about the applications,

the network applications that run on top of MPLS because of this weird and wonderful

forwarding paradigm that MPLS gives us and why it survives today is because server

providers like Regainsworks can offer their customers a bunch of weird and wonderful services

that if you just lean into IP and shortest path forwarding, you can't do.

But you can with MPLS.

Yeah.

Something just popped into my head which is we missed probably the one question we should have answered.

What does MPLS, what does that mean?

I think I might have mentioned the intro but that is true.

We haven't mentioned it again since but a multi-protocol label switching.

Yeah, sorry.

I think that's cleaner, right?

Multi-protocols.

Yes.

We can forward anything.

We don't need to know about it.

We use labels to switch it.

It's typically going to be IP but it doesn't have to be IP.

Yeah.

So that's the MPLS multi-protocol label switching.

Now you've got the whole idea.

Which I actually had never thought about why it's called multi-protocols.

Like this is the acronym.

This is what it stands for.

Continuing with my day added to the rest of the acronyms that live in my head.

But it's very descriptive actually once you learn anything about MPLS.

Yeah, we use label switching to get multiple protocols across the network.

Easy as that.

Yeah.

Well, there we go.

What a great way to wrap it up.

That brings us to the end of today's episode on MPLS.

Big thank you.

James Vancey for joining us and the whole thing has to make MPLS a little bit more understandable.

I think we really appreciate you sharing your insight and experience.

Where can our listeners connect with you if they wish to ask some further questions?

Always happy to answer questions.

I think the only place I'm really active is LinkedIn.

So if you look up my name on LinkedIn, I'm there with us on Brero on.

Perfect.

Well, listeners of this episode helped clarify some things on MPLS for you.

Consider sharing it with your colleagues or friends who's working on the same concepts as zero.

And if you want to continue the conversation or share your well actually send them to

packerpushers.net slash follow up.

We love to hear your thoughts and questions.

You can also send them as a voice note to n4n voicemail at packerpushers.net.

We'll play it back in future episodes and we'd love to include your voice in that.

You can also find Ethan and I on LinkedIn and that packerpushers community slack.

And of course, just remember that networking isn't hard.

Other people figured it out so you can do.