Lessons (10, study in order)

Lesson 1 · What problem does MPLS actually solve

Beginner · about 8 min

Goal: Get straight on why we bother stacking a label on top of IP — otherwise everything after this is rote memorization.

The pain point of plain IP forwarding

An ordinary router receives an IP packet and has to look up the destination address in the routing table with a longest-prefix match.
That table can have hundreds of thousands of entries with prefixes of every length (/8, /16, /24…), and it's redone at every single hop.
On top of that, every router in the backbone has to carry the entire network's routes — that stops scaling once the network gets big.

MPLS's idea: look it up once, at the entrance

MPLS takes a different approach:
① At the network's entrance, look up the IP routing table once and compress the result into a 20-bit number — the label.
② Every hop in between only looks at this fixed-length number and does an exact match (a hash/index lookup, done in one shot) — it never touches the IP header again.
③ At the network's exit, strip the label off and hand back a plain IP packet.

That's why MPLS is often called a layer-2.5 protocol: it sits between layer 2 (Ethernet) and layer 3 (IP).

What this actually buys you

· The P devices in the middle don't need the full routing table — they only need to know how to swap labels, which lets the backbone scale up a lot.
· The forwarding path is decoupled from the IP shortest path → that's what makes MPLS TE (traffic engineering) possible: you can force detours and reserve bandwidth.
· Labels can be nested (a multi-layer label stack) → that's what makes MPLS VPN possible, so overlapping customer address ranges never collide.
· A backup label path can be pre-staged for failures → FRR gives you 50ms-class rerouting.

One honest addition: the old pitch of "forwarding faster than IP" isn't really the point on today's hardware anymore — MPLS's real value today is VPN and traffic engineering.

Try it: take a look at the circuit used in the walkthrough

Go to the packet simulation page. You'll see the real circuit used for this whole course:
Beijing → Seoul → Tokyo → San Francisco (a transoceanic TE tunnel on a backbone network).

Four devices in a chain, with PE (ingress / egress) at both ends and two P devices (label-swap only) in the middle.

For now just look at the two labels on the card on the right: cost 30 and 1 Gbps reserved.
★ The "1 Gbps reserved" one is the key point — it's something LDP simply cannot do, and it's the number-one reason this scenario has to use RSVP-TE. Lesson 8 goes into it.

Don't click "Start walkthrough" yet — finish the concepts in this lesson first.

Key takeaways

• MPLS = look up IP once at the entrance + look only at labels in the middle + strip the label at the exit
• A label is a fixed-length 20-bit number, matched exactly
• MPLS is a layer-2.5 protocol, sitting between Ethernet and IP
• MPLS's core value today is VPN and traffic engineering, not "speed"

Lesson 2 · Building your first LSP: push → swap → pop

Beginner · about 15 min

Goal: Build an LSP with your own hands and see exactly which device does PUSH / SWAP / POP.

Meet the three roles first

There are only three kinds of roles on an LSP (Label Switched Path):

· Ingress LER (the entry point): the only device that does PUSH. This is the device people mean when they ask "how does the MPLS entry point work." It's also the only device on the whole path that still has to look up the IP routing table.
· Transit LSR (a device in the middle): only does SWAP, replacing the top label with the next one. It never looks at the IP header at all.
· Egress LER (the exit point): does POP, stripping the label so the packet turns back into plain IP.

Rule of thumb: the edge attaches labels, the core swaps them.

Try it: walk through the 5 data-forwarding steps

Go to the packet simulation page, click "Start walkthrough", then click "Next" all the way to step 9 (the first 8 steps are the signaling that builds the tunnel — that's lesson 3).

Steps 9–12 are the whole journey of one packet from Beijing to San Francisco:
· Step 9, Beijing: PUSH — push on label 2001
· Step 10, Seoul: SWAP — 2001 becomes 3001
· Step 11, Tokyo: POP — the label gets popped (penultimate hop, PHP)
· Step 12, San Francisco: what arrives is already plain IP

Focus on the "on receipt → on send" label-stack comparison shown under each step.

Read the label chain

The "forwarding table once it's built" card on the right side of the walkthrough page — read it top to bottom:

Beijing        [in=none    PUSH  out=2001]
Seoul          [in=2001    SWAP  out=3001]
Tokyo          [in=3001    POP   out=none]
San Francisco  [in=none    IP forward     ]

How to read it:
· Beijing has no incoming label — it receives an ordinary IP packet, which never had one to begin with.
· Beijing's outgoing label, 2001, was assigned and advertised to it by Seoul — Beijing didn't just make it up.
· ★ The outgoing label on one row = the incoming label on the next row. Break that chain and the packet never arrives.
· San Francisco receives a plain IP packet (Tokyo popped the label early), and only looks up the IP routing table once.

⚠️ Don't be fooled by how neat 2001 / 3001 look — in a real network these values are essentially arbitrary. Each device just picks a number from its own local label space. They line up this cleanly here purely to make the lesson easier to follow.

Try it: walk through again, watching only the stack

Back on the walkthrough page, use the step list on the right to jump straight to step 9, then click forward one step at a time.
Ignore everything else this time — watch only the "on receipt → on send" label stack:
empty → [2001] → [3001] → empty.

The packet is an MPLS packet only for those two middle hops; it's plain IP both before entering and after leaving the tunnel — the IP packet at each end of the tunnel is identical, just wrapped in a label in between.

Key takeaways

• PUSH only happens at the ingress, SWAP in the middle, POP at the egress (or the penultimate hop)
• The ingress is the only device that still looks up the IP routing table
• A device's outgoing label = the value assigned and advertised to it by its downstream neighbor

Lesson 3 · Who assigns the label? (the easiest thing to get backwards)

Beginner · about 12 min

Goal: Burn "downstream assigns, upstream is told" into your head.

First, define upstream and downstream

Look at it from the direction the data flows: whatever the packet reaches first is upstream, whatever it reaches later is downstream.
On the flow PE1 → P1 → P2 → PE2, from P1's point of view: PE1 is upstream, P2 is downstream.

⚠️ Note: upstream/downstream are relative to a specific LSP / FEC. The same pair of neighbors can have the relationship flipped on a different, reverse LSP.

The iron rule: labels are assigned downstream, advertised upstream

Why downstream?
Because a label means "please attach this number when you send to me, so one lookup tells me how to forward it."
Only the side receiving the packet knows which number in its own table is free and which number maps to which path. So the receiver (downstream) has to be the one to decide.

Corollaries (favorites in exams and interviews):
· A device's incoming label is one it assigned itself, then advertised upstream.
· A device's outgoing label is a gift handed down from downstream — it has no say in it.
· So label assignment happens in reverse, starting at the egress and working back to the ingress.

Try it: ★ the heart of this lesson — walk through the 4 Resv steps

Go to the packet simulation page, use the step list on the right to jump straight to step 5, then click forward to step 8.
These 4 steps are the RSVP-TE Resv message, exactly where labels actually get handed out:

· Step 5, San Francisco (the egress): assigns first, gives out label 3 (implicit null)
· Step 6, Tokyo: assigns 3001, tells upstream Seoul "attach 3001 when you send to me from now on"
· Step 7, Seoul: assigns 2001, tells Beijing
· Step 8, Beijing: receives 2001, tunnel is UP

★ At every step, look at the LABEL object highlighted in red — that's exactly "the label I'm assigning to my upstream neighbor."

Then compare the two directions:
· Assigning labels: San Francisco → Tokyo → Seoul → Beijing　backwards
· Forwarding data: Beijing → Seoul → Tokyo → San Francisco　forwards

These two directions being opposite is the one thing this lesson wants you to remember.

While we're at it, the three dimensions of LDP

The real-world protocol that does this job is called LDP (Label Distribution Protocol). It has three sets of modes:

· Label distribution: DU (Downstream Unsolicited — sends without being asked) / DoD (Downstream on Demand — sends only when asked). Ethernet defaults to DU.
· Label retention: liberal (keeps every neighbor's advertised label — faster switchover, more memory) / conservative (keeps only the current next hop's — less memory, slower switchover). Liberal is the default.
· Label control: ordered (only advertises upstream after downstream has advertised to it, so it only announces once the path is confirmed end-to-end) / independent (can advertise on its own right away). Ordered is the default.

Vendors' default combination is basically always: DU + liberal + ordered.

Key takeaways

• Labels are assigned downstream and advertised upstream — if you forget, think "the label is for me to use, so of course I decide"
• Incoming label = assigned by yourself; outgoing label = given by downstream
• The direction of label assignment is opposite to the direction of data forwarding
• LDP defaults: Downstream Unsolicited + liberal retention + ordered control

Lesson 4 · Reading the three tables: FTN / LFIB / LIB

Beginner · about 10 min

Goal: You can only troubleshoot once you can read the tables.

FTN — only the ingress has one

FTN = FEC To NHLFE. It answers the question:
"An ordinary IP packet needs to enter the tunnel — which label do I push, and which interface does it go out?"

So its input is an IP prefix, and its output is a PUSH label + outgoing interface + next hop.
Only the ingress needs this table, because it's the only device facing unlabeled packets.

LFIB — every MPLS device has one

LFIB = Label Forwarding Information Base, often split into two parts, ILM + NHLFE:
· ILM (Incoming Label Map): incoming label → what to do about it
· NHLFE (Next Hop Label Forwarding Entry): the concrete action (SWAP/POP + outgoing label + outgoing interface + next hop)

It answers the question: "I got label X, what do I do?"
It's looked up by fixed-length exact match — that's the reason MPLS forwarding is fast.

⚠️ Key point: the incoming label is this table's primary key. So on any given device, one incoming label can only map to one LSP.

LIB — the label "advertisement ledger"

LIB = Label Information Base, and it records advertisement relationships, not forwarding actions:
"I advertised label A to upstream neighbor X", "downstream neighbor Y advertised label B to me."

What's in the LIB isn't necessarily all in active use. For example, under liberal retention you'll have several neighbors' labels stored, but only the one for the current best next hop gets pushed down into the LFIB to actually forward with.
LIB is the control plane, LFIB is the data plane.

Try it: do a "label chain" against the table

Go to the packet simulation page and look at the "forwarding table once it's built" card on the right. Four devices, four rows — the first row is labeled FTN, the other three LFIB — matching exactly the two tables above.

Chain it starting from the first row:
① Beijing's row is FTN: to reach 4.4.4.4/32 → PUSH 2001. Remember 2001.
② Seoul's row is LFIB: its incoming label is exactly 2001 — it matches. Its outgoing label is 3001.
③ Tokyo's row: incoming label 3001 — matches again. The action is POP, no outgoing label (penultimate-hop popping — the tunnel ends here).

★ This "the outgoing label on one row = the incoming label on the next" chain-check is exactly the standard move for troubleshooting on real hardware, hop by hop with display mpls lsp — wherever the chain breaks is where the problem is.

Key takeaways

• FTN: IP prefix → PUSH label (only the ingress has one)
• LFIB = ILM + NHLFE: incoming label → action + outgoing label (every MPLS device has one)
• LIB: the label advertisement ledger, control plane
• The incoming label is the LFIB's primary key — it can't repeat on the same device

Lesson 5 · Three ways to handle the egress: PHP / explicit null / an ordinary label

Advanced · about 12 min

Goal: Understand implicit null label 3 and explicit null label 0 — a favorite interview question.

PHP: letting the penultimate hop pop the label

PHP = Penultimate Hop Popping.

The egress advertises implicit null label 3 (Implicit NULL) upstream, meaning:
"Pop the label yourself and just hand me the plain IP packet."

So the penultimate hop's action switches from SWAP to POP, the egress receives a plain IP packet, and only has to look up the IP table once.
Benefit: the egress skips one of its two lookups ("pop the label + look up IP"), which is lighter on the CPU/ASIC. This is the vendor default behavior.

⚠️ Very important: label 3 never appears in an actual packet — it's purely a signal used in LDP advertisements. A lot of people assume the packet itself carries a 3; that's wrong.

Explicit null label 0: for keeping the QoS priority

PHP has a side effect: since the label is popped early, the EXP field (3 bits, carrying QoS priority) in the MPLS header goes with it.
If the egress still needs to schedule by priority, have it advertise explicit null label 0 (IPv4 Explicit NULL) instead:

· The penultimate hop does a SWAP, changing the label to 0;
· When the packet reaches the egress it's still an MPLS packet (label value 0, no forwarding meaning, purely a placeholder);
· The egress itself does the POP, reads the EXP, then forwards.

The cost is one extra table lookup at the egress.

An ordinary label: the most intuitive for teaching

The egress assigns a normal label (say, 1027), the penultimate hop does a normal SWAP, and the egress itself does the POP.
This isn't the default on real hardware, but it's the most useful setup while learning — you can watch the label change at every single hop, instead of losing a step to early PHP popping.

Try it: see exactly how PHP is implemented in the walkthrough

The tunnel used in the walkthrough runs PHP. Go to the packet simulation page and look at three spots to string together "how PHP actually happens":

① Step 5 (San Francisco replies with Resv): the LABEL object in the packet is 3 (implicit null).
　　That's PHP's switch — the egress already said, during signaling, "don't attach a label, just give me the IP packet."

② Step 11 (Tokyo, the penultimate hop): the action is POP, not SWAP.
　　Because its LFIB lookup shows the outgoing label is the implicit null, so it just pops the label right there.

③ Step 12 (San Francisco): what it receives is already a plain IP packet, so it looks up the IP routing table once.

★ Put it together: one label value (3) at signaling time buys you one fewer table lookup at data time.
If it used an ordinary label instead, step 11 would be a SWAP, the pop would be pushed to step 12, and the egress would have to do two lookups.

Key takeaways

• Implicit null label 3 = the PHP signal — only ever appears in advertisements, never in a packet
• Explicit null label 0 = a real label 0 riding in the packet, there to keep the EXP priority
• PHP is the vendor default, and it exists so the egress does one fewer lookup

Lesson 6 · An LSP is one-way (the #1 beginner trap)

Beginner · about 6 min

Goal: Get straight on why "I configured it and it still won't ping."

An LSP only goes in one direction

Every hop on an LSP is "receive label X → swap it for Y → send out some interface."
That rule is inherently directional: a reverse-direction packet would have a completely different label and outgoing interface, and simply doesn't fit the rule.

So an LSP from PE1 → PE2 cannot carry traffic from PE2 → PE1.

The classic reason for "it won't ping"

A student finishes configuring an LSP, it won't ping, and then starts doubting everything.
The real reason is usually: the outbound direction has an LSP, but the return direction has none at all (or the return path took ordinary IP routing and got dropped by a device along the way).

The fix: build one LSP in each direction. Their label values will necessarily be completely different, since they're two entirely independent assignment processes.

Try it: verify in the walkthrough that it really is one-way

Go to the packet simulation page, look at the forwarding table on the right, and ask yourself just one question:

Can this table forward a packet going "San Francisco → Beijing"?

Walk through it and you'll see it can't:
· Beijing's row is FTN (IP → label), and only handles packets entering the tunnel at Beijing
· In Seoul's and Tokyo's LFIB, every outgoing interface points toward San Francisco
· San Francisco's row has no incoming label at all — it's only ever an endpoint, never a starting point

★ These four table rows, as a whole, only serve one direction. To carry bidirectional traffic you'd have to run the full RSVP-TE process again and build a San Francisco → Beijing tunnel, and that tunnel's label values have nothing to do with this one — because it's a completely separate, independent assignment process.

Key takeaways

• An LSP is one-way — bidirectional traffic needs two of them
• The label values on the two directions have nothing to do with each other; each is assigned independently
• "I configured it and it won't ping" — the first thing to suspect is a missing reverse LSP

Lesson 7 · Design your own labels + common failure modes

Troubleshooting · about 20 min

Goal: Level up from "I can read it" to "I can design it myself," and meet four high-frequency failure classes.

Try it: design one yourself first, then check the answer

Don't look at the walkthrough page yet. Grab a piece of paper and design your own set of labels for this tunnel:

Beijing         in=____  action=____  out=____
Seoul           in=____  action=____  out=____
Tokyo           in=____  action=____  out=____
San Francisco   in=____  action=____  out=____

Once you've filled it in, go to the packet simulation page and compare against the forwarding table on the right. Check yourself on four things:
① Is Beijing's incoming label empty? (it receives an IP packet, which never had one)
② Does the outgoing label on each row equal the incoming label on the next row? (is the label chain unbroken?)
③ Are the label values you picked all ≥ 16? (0–15 are reserved, unusable)
④ Is Tokyo's (the penultimate hop's) action POP? (because this tunnel has PHP on)

★ Any specific number you fill in is fine (as long as it's ≥16 and doesn't repeat on the same device) — what has to be right is the chain, not the values. That's the single most important sentence in this lesson.

The four rules of designing labels

① The ingress has no incoming label — it receives a plain IP packet.
② The egress has no outgoing label — it's the end of the tunnel.
③ Upstream's outgoing label == downstream's incoming label — the most important rule, and the easiest to get wrong.
④ An incoming label can't repeat on the same device — it's the LFIB's primary key.

Also: label values range 16–1048575; 0–15 are reserved and unusable for real traffic; by convention static LSPs use 16–1023, dynamic protocols use 1024 and up.

Four high-frequency failure classes

① A broken label chain (the most common)
Upstream's outgoing label ≠ downstream's incoming label. Symptom: interfaces up, IP routing table completely healthy, but traffic doesn't go through.
The packet misses the LFIB lookup at the downstream hop and is silently dropped — there may not even be a log entry.
Troubleshooting: starting from the ingress, do a hop-by-hop "label chain-check."

② A device in the middle doesn't have MPLS enabled
No LFIB, so labeled packets are dropped outright. On real hardware, check with display mpls interface.

③ A reserved label got used
Someone entered 0–15. The device may reject the config outright, or behave strangely.

④ Only a one-way LSP was built
See lesson 6.

Try it: break the label chain on paper and reason through the fallout

Go to the packet simulation page, look at the forwarding table, then run a thought experiment —
suppose Seoul's row got its outgoing label misconfigured as 3009 (instead of 3001):

① Beijing still PUSHes 2001 as usual and sends to Seoul　→ fine
② Seoul's LFIB lookup hits, SWAPs to 3009, sends to Tokyo　→ still looks fine
③ Tokyo receives 3009 and looks it up in its LFIB — it only has an entry for 3001, no match → the packet is dropped outright

★ The nastiest part of this failure:
· IGP is completely healthy, and the IP routing underneath ping works fine too
· The first two hops report no error at all — the problem only shows up at the third hop
· The packet is silently dropped, with no alert of any kind

The symptom is exactly that classic line: "routing looks completely fine, but traffic just doesn't go through."
There's exactly one way to troubleshoot it: go hop by hop along the LSP with display mpls lsp, checking whether "the previous hop's Out Label" equals "this hop's In Label" — whichever hop the chain breaks at is where the fault is.

Key takeaways

• Upstream's outgoing label = downstream's incoming label — the first thing to check when troubleshooting
• A broken label chain looks like "routing is fine but traffic doesn't go through" — the packet is silently dropped
• 0–15 are reserved labels, unusable for real traffic
• Real-hardware commands: display mpls lsp / show mpls forwarding-table

Lesson 8 · Explicit paths and an intro to traffic engineering (TE)

Advanced · about 15 min

Goal: Understand why MPLS can "not take the shortest path" — a capability nothing else has replaced to this day.

The problem: IP routing only ever takes the shortest path

In a traditional IP network, the routing protocol computes the shortest path, and all the traffic piles onto that one path.
Even if there's an idle backup path sitting right next to it, it goes unused — because IP forwarding makes independent, hop-by-hop decisions. You can't tell one device "send this traffic the long way around" — the next hop will just compute its own shortest path again anyway.

MPLS's solution: the path is locked in at the entrance

By the time an LSP is established, the path has already been strung together, hop by hop, via labels.
Once a packet is labeled, it can only follow that string of labels — devices in the middle have no say in it; they just swap labels according to their LFIB.

So all you have to do is specify a non-shortest path when building the LSP, and the traffic really will take the detour.
An LSP with a specified path like this is called an ER-LSP (Explicit Route LSP), established via the RSVP-TE protocol.

Try it: ★ go back and look at that contrast from lesson 1

Go to the packet simulation page and look at the two objects in the packet at step 1 (Beijing sends Path) — they each correspond to one thing RSVP-TE can do that LDP cannot:

① SENDER_TSPEC: reserving 1 Gbps
Along the way, every single hop has to genuinely set aside 1 Gbps; wherever a hop can't, it replies with PathErr and the tunnel simply fails to come up.
LDP has no concept of bandwidth at all — it only cares whether "a path exists," never whether "that path still has capacity left." So if a critical service needs guaranteed bandwidth, RSVP-TE is the only option. This is the hardest difference between the two.

② ERO: the path is nailed down in the config
It literally says "must pass through Seoul, then Tokyo, in that order."
⚠️ To be honest: the walkthrough's topology is a straight chain with no alternate route, so this path also happens to be the IGP shortest path — the ERO here isn't for taking a detour.
Its job is to nail the path down: later, if IGP cost changes or a new link gets added, this tunnel won't drift with it. An LDP LSP follows the IGP — when IGP changes, so does the LSP.

★ And if the topology genuinely had a shorter alternate route (say, a submarine cable running straight from Beijing to Tokyo), the ERO could make the tunnel deliberately avoid it — that's RSVP-TE's more famous use case, usually for a very practical reason: that cable is short on capacity, under maintenance, or its capacity is reserved for a different path.
Points ① (bandwidth) and ② (nailing the path down) above are both visible in this exact topology; the detour case needs a topology that actually has an alternate route to demonstrate.

★ While you're there, take a look at the card showing "which device each of these commands is typed on" — explicit-path and interface Tunnel1 are only configured on Beijing; Seoul and Tokyo don't have a single line of tunnel configuration on them. Adding a TE tunnel only touches one device.

What real-world TE also does

· Bandwidth reservation: declare that an LSP needs 100M when it's built, devices along the path keep the books, and if there isn't enough it switches to a different path (computed via CSPF).
· Affinity attributes / link coloring: tag links with colors and require an LSP to only use links of a certain color (e.g. to avoid a submarine cable).
· FRR (Fast ReRoute): pre-compute a backup path and pre-install its labels, so a failure on the main path switches over locally within 50ms, without waiting for IGP convergence.
· SR-TE: the modern approach today is Segment Routing, which encodes the entire path directly into the packet via a label stack, so devices in the middle don't need to maintain per-tunnel state — this is the MPLS data plane paired with a brand-new control plane.

Key takeaways

• MPLS can take detours because the path is already strung together by labels at the entrance — devices in the middle have no say
• An LSP with a specified path is called an ER-LSP, established via RSVP-TE
• TE's core capabilities: explicit paths + bandwidth reservation + FRR fast reroute

Lesson 9 · MPLS VPN and the two-layer label stack

Advanced · about 20 min

Goal: Understand why two customers can both use 192.168.1.0/24 and never collide.

The problem: overlapping addresses

Customer A and Customer B both use 192.168.1.0/24. The carrier has to provide interconnect for both of them over the same backbone at the same time.
If both customers' routes were dumped into the same routing table, they'd collide outright.

The first layer of isolation: VRF

The PE builds a separate routing-table instance for each customer, called a VRF (VPN Routing and Forwarding; Huawei calls it a vpn-instance).
Customer A's routes go into VRF-A, Customer B's into VRF-B — the two tables are physically isolated, so overlapping addresses don't interfere with each other.
A RD (Route Distinguisher) prefixes routes to make them globally unique, and an RT (Route Target) controls which VRFs a route gets imported into.

The second layer: a two-layer label stack

Packets carry two layers of labels across the backbone:

· Outer layer = the public label (assigned by LDP): gets the packet from the ingress PE to the egress PE. Backbone P devices only ever look at this layer — they know nothing about the customer VPN at all, which is exactly why P devices don't need to carry customer routes.
· Inner layer = the VPN label (advertised by the egress PE via MP-BGP): tells the egress PE "this packet belongs to which VRF / which private route."

The forwarding process:
① Ingress PE: looks up the VRF routing table → PUSH the inner VPN label → PUSH the outer public label.
② Transit P: only SWAPs the outer layer; it never even looks at the inner one.
③ Penultimate hop: POPs the outer layer (PHP).
④ Egress PE: sees the inner label → locates the matching VRF → POPs it → looks up the private route inside that VRF → sends to the CE.

Try it: imagine the walkthrough's tunnel carrying a VPN

The Beijing → San Francisco tunnel on the walkthrough page carries a single-layer label stack the whole way (the public label).
Now suppose it needs to carry a customer's VPN traffic — the stack becomes two layers. Work through it yourself:

Beijing        PUSH inner 1050 (VPN) + PUSH outer 2001 (public)  stack=[2001, 1050]
Seoul          SWAP outer only                                   stack=[3001, 1050]
Tokyo          POP outer (PHP, penultimate hop)                   stack=[1050]
San Francisco  read inner 1050 → find VRF → POP → look up private route   stack=[]

Line it up against the single-layer stack on the walkthrough page and three things become clear:
① The outer label changes exactly the same way as in the walkthrough — 2001 → 3001 → popped. The public label's job is purely "get it to which PE" — it has nothing to do with who the customer is.
② The inner label, 1050, never changes the whole way through. Seoul and Tokyo never even look at it — that's exactly what "a P device needs to know zero customer routes" means.
③ Only San Francisco reads the inner label, using it to decide "which customer's VRF does this packet belong to."

★ So MPLS VPN's scalability comes down to this division of labor: the backbone only cares where it's going; only the edge cares whose it is.

While we're at it, the S bit

How does a device know which layer in the label stack is the last one? Via the S bit (Bottom of Stack, 1 bit) in the MPLS header:
the innermost label has S=1, every other layer has S=0. Once a device reads S=1, it knows the IP header comes right after.

Key takeaways

• The outer public label handles "which PE to deliver to," the inner VPN label handles "which customer it belongs to"
• P devices only ever look at the outer layer, so they need zero customer routes
• VRF isolates routing tables, RD makes routes globally unique, RT controls which routes get imported where
• S=1 means this is the bottom label, and the IP header follows right after

Lesson 10 · The MPLS header, bit by bit, plus the two TTL modes

Advanced · about 10 min

Goal: Thoroughly understand what's packed into those 32 bits.

32 bits per layer, and you can stack several

A label-stack entry is exactly 4 bytes:
· Label (20 bits) the label value, range 0–1048575
· EXP / TC (3 bits) QoS priority, usually mapped from IP's DSCP
· S (1 bit) bottom-of-stack flag, 1 on the innermost layer
· TTL (8 bits) time to live, decremented by 1 at each hop

On Ethernet, EtherType 0x8847 marks unicast MPLS, 0x8848 marks multicast.
Head to the "packet structure" page for a visualized bit diagram.

TTL's Uniform mode

· When the ingress does PUSH, it decrements the IP TTL by 1 and copies it into the MPLS TTL;
· Every LSR decrements the MPLS TTL;
· When the egress does POP, it writes the MPLS TTL back into the IP TTL.

Result: a user's traceroute can see every hop of the backbone. Convenient for debugging, but it exposes the internal topology.
This lab's simulation uses this mode.

TTL's Pipe mode

· When the ingress does PUSH, it sets the MPLS TTL straight to 255, ignoring the IP TTL;
· When the egress does POP, it does not write the MPLS TTL back — it just decrements the IP TTL by 1.

Result: to the user, the entire backbone looks like just one hop; traceroute can't see any internal devices.
Carriers use this almost universally — it both hides the topology and makes the path the customer sees look "cleaner."

Why MPLS needs its own TTL at all

Because MPLS forwarding never looks at the IP header, the IP TTL can't help. If a label is misconfigured into a loop (say A's outgoing label points back to B, and B's points back to A),
without an MPLS TTL the packet would circulate forever. With it, it gets dropped after at most 255 hops.

Incidentally: it's exactly because the MPLS TTL decrements at every hop and triggers an ICMP reply that traceroute works at all inside an MPLS network.

Key takeaways

• Label 20 + EXP 3 + S 1 + TTL 8 = 32 bits
• EtherType 0x8847 = unicast MPLS
• Uniform mode exposes every hop; Pipe mode hides the whole backbone as one hop
• The MPLS TTL exists to prevent loops, since MPLS forwarding never looks at the IP TTL