A Junos Logical Tunnel Is Two Attachments, Not One Link

Inside the router, an lt- interface looks exactly like a cable, and that impression causes most of the confusion. It is not one link but two attachments: each end belongs to a service, each end has its own encapsulation, and the pair only forwards when both services are correctly joined. Work the five steps below in order, and treat a clean commit as the beginning of the verification rather than the end of the work. Each step leaves a record the next engineer can check without repeating the investigation.

Step 1: write the attachment worksheet

Before touching configuration, draw what should join what. One side terminates a point-to-point Layer 2 circuit, the other side joins a VPLS instance, and the logical tunnel sits between them carrying frames from one to the other. Name both services explicitly, because a point-to-point circuit, a VPLS instance and an EVPN-VXLAN interconnect are not interchangeable just because each can be described as stitching.

Record the unit numbers on both ends and which service each belongs to. That sheet is the only artefact that will still be correct after three changes and a rollback.

Step 2: pin the peer units and the encapsulation

The two units must live on the same logical tunnel interface and point at each other, and a unit can have exactly one peer. Juniper's logical-tunnel documentation states both constraints along with the supported encapsulations and the platform resources the interface consumes. Verify those against the installed hardware and release rather than against a lab example from a different line card. A peer unit referenced across two different lt interfaces commits cleanly and forwards nothing.

Then choose the encapsulation that matches the service on each end. A sketch of the pair looks like this:

set interfaces lt-0/0/0 unit 0 encapsulation vlan-ccc
set interfaces lt-0/0/0 unit 0 peer-unit 1
set interfaces lt-0/0/0 unit 1 encapsulation vlan-vpls
set interfaces lt-0/0/0 unit 1 peer-unit 0

Copying Ethernet-CCC and Ethernet-VPLS keywords into a VLAN service without reconciling tagging is the other common way to produce a pair that comes up and forwards nothing.

Step 3: attach each end to its own service

Each unit belongs to a service definition, and the service has to actually include it. For supported MX Layer 2 arrangements the documentation calls out bridge-domain or VPLS membership as the thing that makes forwarding bidirectional, which means a correct peer pair with an unmembered unit is a pair of endpoints talking to nothing. Add the membership in the same commit as the units, so the two can never disagree.

Set up the pseudowire signalling and the instance membership as part of the same change, because the far end of the circuit is what gives the VPLS side something to learn from.

Step 4: budget resources and frame size

An internal link still consumes forwarding resources. The documentation lists platform bandwidth implications for logical tunnels, so check them instead of assuming internal means free.

Align the service MTU and the tagging model across both attachments and the remote pseudowire. Do not copy a sample MTU value without establishing which headers the relevant setting counts, because an internal hop that silently shrinks the budget will fail exactly where user traffic is largest.

Step 5: verify forwarding, then look for loops

Send traffic in both directions and inspect the service state, not just the interface state. show interfaces lt-0/0/0 tells you the pair is administratively up, and show vpls connections tells you whether the instance has a connection to learn over. Neither one proves that a frame entered on one service left on the other, so test that explicitly. Send from a host on one side to a host on the other, with the service state visible while the traffic runs.

Finally, check whether another physical or logical path already joins the same Ethernet domain. Adding this attachment can change flooding behaviour and create a loop that did not exist before, and the symptom will appear somewhere else entirely. Plan the redundancy you intend rather than discovering an unsupervised Layer 2 path during an incident.