Why a Junos L2VPN shows a label but forwards nothing

Customer reports arrive saying the L2VPN connection is Up, the attachment is up, and no frame crosses. The status lights are honest; the frame is being classified into a service that has no usable forwarding state at the far end. In a BGP-signaled point-to-point L2VPN the first decision belongs to the attachment rather than to a route lookup. The customer frame arrives on a logical interface, and that interface names the connection and therefore the remote site. Everything after that is label-forwarding state built out of what the peers advertised.

The frame never does a route lookup

Signalling prepared the state; per-packet processing is a label lookup on a connection that was already selected. Asking why a route is missing is therefore the wrong question, and it hides the two values that matter: the attachment's connection and the service label it uses.

That also explains the asymmetry in effort. Configuration review tells you what should have been installed, while the connection view tells you what was actually derived, and only the second one survives a label-block mismatch.

Two labels, two directions

Each PE allocates a label block locally, advertises its base and size, and its peers add an offset to derive the label for a particular site. Allocations are therefore locally significant: two PEs can use different bases and different block sizes for the same service. Read the connection from both ends before changing anything. A block that was sized one label too small looks exactly like a connection that never installs.

show l2vpn connections instance CUST-A extensive

In that output the incoming label is the one this PE allocated and told its peer to use, while the outgoing label is the peer's allocation that this PE pushes. Reading the two backwards is the classic mistake, and it sends you hunting for a value that was never supposed to appear on this side. The connection reference documents the fields beside the labels, including site, status and block information.

What the label lookup proves

Once you have the incoming value, the local lookup is one command:

show route label 160042

That output should show an l2vpn entry with a next hop, and the label operation tells you whether the frame is pushed, swapped or popped before it leaves. If it shows nothing, the service state was never installed even though the connection displays Up, and the discrepancy lives in signalling rather than in transport.

Follow one frame

A single packet pushed into the attachment settles more than any configuration review. The service label route should point at the transport LSP toward the remote PE, and the two labels should correspond to the values the peer reported. When transport is healthy and the service label is wrong, the frame reaches the correct router and is discarded there, which is why the far end's counters look empty while the near end's look busy.

Check the attachment encapsulation, the control-word setting and the MTU at the same time, because those are negotiated properties rather than per-hop behaviour.

Keep the service models apart

VPLS learns MAC addresses and EVPN advertises endpoints, while a point-to-point L2VPN does neither, so their frame-selection procedures are not interchangeable despite riding the same BGP and MPLS infrastructure. Lifting a troubleshooting step from one model into another produces confident conclusions with no basis.

For a missing path, record both peers' connection status, the attachment, both label directions, the encapsulation, the control-word setting and the MTU. That record connects what was advertised to what the forwarding plane actually does, which is the only link that matters, and it is also what the next engineer will ask for.