MPLS: Triangle with Redundant Paths

The scenario

R1, R2 and R3 are joined in a triangle. Host-A (10.0.1.10) is behind R1. Behind R3 are Host-B, a web server on 10.0.5.0/24, and Host-C on 10.0.6.0/24. R1 reaches Host-C with an ordinary static route over the direct link, 10.0.6.0/24 via 10.0.13.2: one hop to R3. For Host-B, R1's route 10.0.5.0/24 points at R2 (10.0.12.2) and has LSP te-via-R2 bound to it, so R1 pushes label 16001. R2 swaps it for 16002 toward R3, and R3 pops it and delivers to Host-B. R2 has no route to 10.0.5.0/24, so without the label it could not forward that traffic. Replies from both hosts to 10.0.1.0/24 use R3's LSP to-R1: R3 pushes 16010 over the direct link and R1 pops it. No router runs OSPF; every route and label is static.

What you will work out

See an LSP carry traffic along a path that plain IP forwarding could not use, and learn why a static LSP neither follows route changes nor fails over by itself.

Why this matters

Being able to send chosen traffic along a path other than the shortest one is the reason many operators run MPLS traffic engineering: to fill spare capacity, keep latency-sensitive traffic on particular links, or keep a backup path ready. The same lab shows the cost of doing it statically: every router on the path must agree on the labels, and a failure is not repaired unless something like RSVP-TE with fast reroute is there to do it.

Running it

MPLS: Triangle with Redundant Paths opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.