Why your L2VPN ignores the RSVP-TE LSP you just built

Two engineers can leave the same maintenance window convinced the new path is in service, and both be wrong for different reasons. One built the LSP and assumed the service would follow. The other left the service alone and assumed nothing changed. A pseudowire only ever uses the transport that its peer address resolves to at that moment, so the real question is what that resolution currently produces, and the two designs answer it differently.

One label names a service, the other moves a packet

A pseudowire label, signalled by targeted LDP as described in RFC 4447, tells the receiving provider edge which attachment circuit should receive the frame. It says nothing about how the frame got there. The label underneath it belongs to the transport, and that stack is built by whatever advertised reachability for the peer loopback, whether LDP, RSVP-TE or a segment-routed path. Because different protocols signal the two layers, one can be healthy while the other is stale. That separation is the entire source of the confusion.

Worth saying plainly: the pseudowire does not choose the LSP. It hands a frame to the transport, and the transport decides from the destination address it was given.

This is also why a clean ping across the new LSP proves so little. The LSP can be up, labelled, and carrying other services while your pseudowire still resolves through a different next hop. Until you read the binding, those two facts are unrelated.

Option A: pin the pseudowire to a chosen transport

Pinning means making the service's transport resolution deterministic. Depending on the platform, that takes the shape of a tunnel-selection policy, an explicit transport endpoint on the service, or a route policy that rewrites the next hop for the peer address. All three do the same thing underneath: they force the resolution of one destination onto a specific LSP. That is what makes the result auditable afterwards.

The cost is scope. A policy matching on a peer address affects every service pointed at that peer, not only the pseudowire you had in mind.

Fallback deserves a decision before the change window, not during it. If the pinned LSP drops, you either let the service ride another approved path or you let it stop. A policy that quietly falls back onto a path violating a latency or disjointness constraint has converted a clean outage into something much harder to explain to anyone.

Option B: let the IGP pick and watch what happens

Leaving the service alone is a legitimate design, and often the better one. The pseudowire follows the same resolution as any other traffic to the peer loopback, so it inherits IGP convergence, prefix suppression and whatever redundancy the core already offers. Fewer policies mean fewer places for a stale match to hide. The trade is that you no longer control which path the service takes, only that some path exists.

Equal-cost multipath sharpens that trade more than it first appears. Hashing is per flow, so two conversations inside one pseudowire can leave on different outer labels.

Read the installed forwarding before you trust either

Start with the peer address rather than the service. On Junos, show route 203.0.113.1 detail prints the selected next hop and the label operation, and show route table mpls.0 maps the incoming label to that operation. On IOS XR, show mpls l2transport vc 100 detail gives the pseudowire state together with the imposed stack.

Confirm the LSP the transport actually uses, not the one your design document names. traceroute mpls ipv4 203.0.113.1/32 on IOS XR walks the label-switched path and lists the labels and outgoing interfaces along it, which is the closest thing to watching the path yourself. Then repeat the exercise from the far provider edge, because the return direction resolves independently and asymmetry is common after a partial policy rollout. A path that is right one way and wrong the other is worse than one that is uniformly wrong, since half your tests will pass.

Keep the evidence with the service record: peer address, next hop, outer label, and the date you checked. Route policies age badly, and nobody remembers which one was in force two quarters ago.

Choose by failure mode, not by preference

Pinning suits services with a constraint the IGP cannot express, and teams that can maintain the policy through every change. Leaving it to the IGP suits services that must survive any single failure without a human in the loop.

The deciding question is what a wrong path costs you. If a service on the wrong LSP merely performs a little worse, let the IGP decide and spend the effort on monitoring. If a wrong path breaks a contract, an audit finding or a disjointness requirement, pin it and write the fallback down. Then test the fallback, because an untested fallback is an assumption rather than a plan. Either way, re-read the installed binding after any change to the core, and treat a pseudowire that came up as evidence of nothing except that signalling works.