Junos L2VPN: get the customer attachment contract right first

Before you touch a pseudowire, follow one customer frame into the PE and see where it is supposed to land. The physical port classifies it into a logical unit, that unit carries an encapsulation, and the unit is bound to a service. Three separate decisions, three separate ways to get it wrong. Most cases escalated as a signalling fault are actually a frame classified into a unit nobody configured for that service. So start at the attachment and work outward.

Write the frame contract down

Record the contract before choosing any configuration: untagged, one service tag, or a stack. Add the MTU the customer will send and the tag treatment expected in each direction, because those are negotiated properties rather than local preferences. A unit number is only an identifier, and it says nothing about which frames the interface will accept.

Write it in the service note rather than in a ticket comment. The person debugging this in six months will read the note. They will not read the ticket.

Match the encapsulation to the contract

A single-tagged service typically uses a VLAN circuit encapsulation such as vlan-ccc, while untagged frames need the plain Ethernet circuit form and a stack needs the extended variant that understands two tags. On a platform supporting per-unit service encapsulation, one physical interface can host several at once, which is convenient and is also how a frame ends up in the wrong unit. Where the guide for your platform calls for family ccc, configure it as part of the complete attachment rather than bolting it onto a routed interface. The encapsulation guide lists which attachment types impose which requirements.

Do not add one family statement to every interface as a precaution. The configuration that makes one circuit work can make the next one accept frames its customer never sends.

Bind the attachment to the right service

A BGP-signaled Layer 2 VPN, an LDP-signaled circuit and the other supported services each have their own interface-binding and signalling configuration, and they are not interchangeable. Mixing the attachment style of one with the signalling of another produces a circuit that reports a peer and never carries a frame.

Compare the far end against the near end rather than reviewing either in isolation: peer address, service identifier, encapsulation agreement, control-word expectation and size budget. The MPLS underlay can be perfectly healthy while the attachment is missing or classified elsewhere, which is why an underlay-only test proves nothing here.

Verify with the frame, not the status

Read the local interface counters while the customer sends traffic, then read the service state, then confirm that the frame that arrives is the frame that was agreed, including its tag. A repaired attachment delivers that frame; a status change on its own is not evidence of anything.

Where you are authorized to capture, look at the frame in both directions. Tag asymmetry is easy to miss in a status view and obvious in a capture. That asymmetry also explains complaints that work in one direction and fail in the other.

Then write it down

Record four values in the service note: contract, encapsulation, unit and service binding. Those four are what a new engineer needs and what a configuration review rarely spells out.

When the circuit breaks in six months, that note is the difference between a fifteen-minute fix and re-deriving the whole design from a running configuration. Add the date you last verified it, so the note also says how stale it is.