Normalize VLAN Tags at the Pseudowire Endpoints: A Runbook

Define the frame each customer edge should receive before you touch the pseudowire. In the simple case, CE A sends one service-delimiting tag and CE B expects untagged frames, and the provider edge is where that difference is resolved. The tag is local policy rather than part of the customer's Ethernet contract, and the pseudowire carries the agreed frame rather than the original one. Write both directions down before any configuration.

Write the frame contract first

The forward direction removes a tag and the reverse direction adds it back. If you only write one of them, you will test a working path in one direction and call the circuit healthy.

Keep the contract short enough to paste into the change ticket: which edge sends tagged, which expects untagged, and which tag value is service-delimiting.

Agree on the pseudowire mode

RFC 4448 distinguishes raw and tagged pseudowire modes and describes how service-delimiting tags are handled. Raw mode can still carry tags that belong to the customer frame, so the distinction is about a tag's service role rather than the mere presence of an 802.1Q header. Reading the mode as tagged versus untagged is the most common way to mis-scope this work. Agree the mode with the peer before you decide which operations you need.

Then check the actual pseudowire type and the peer parameters. A local VLAN attachment and a remote port attachment need a supported interworking arrangement, and two local rewrite statements do not prove that the advertised circuit types agree.

If the control-word and MTU expectations differ, you have a negotiation problem that no rewrite will fix. Confirm both from the peer's running configuration rather than from the design document.

Apply the local tag operations

Juniper's VLAN CCC rewrite guide documents pop, push and swap operations with platform-specific restrictions. For an already configured compatible tagged unit, the illustrative direction is input-vlan-map pop on ingress and output-vlan-map push on egress. Those lines illustrate operations, not a complete interface or circuit configuration. Confirm the exact platform and release instead of applying one device family's example everywhere.

The unit's supported VLAN and encapsulation settings still have to define the intended tag and classification. A rewrite statement on a unit that classifies the wrong frames moves the problem rather than fixing it.

Preserve any inner customer tags the service requires. For stacked tags, establish which outer tag you are manipulating before you remove anything.

Budget the size, not just the tags

Include retained tags, the actual MPLS stack and the control word in the size budget. RFC 8469 recommends a control word for Ethernet pseudowires, and that recommendation changes the frame budget whether or not your platform enables it by default. Reconcile an MTU mismatch rather than suppressing its warning as the repair. A suppressed warning is a scheduled outage with the date filed off.

Check the same budget on both provider edges, because one side adding a tag and the other adding a control word is enough to break a payload that was previously fine.

If the numbers disagree, change the plan rather than the logging level.

Accept it frame by frame

For acceptance, inspect the expected frame at each customer attachment in both directions. Then exercise the application and control traffic the service actually needs under the approved test plan, because a ping proves far less than a tagged frame arriving intact. Record the ingress and egress frame contract with the circuit's configuration. That record is what makes the next change reviewable.

Keep the mode, the tag operations, the MTU budget and the test result in one place, since they only make sense together. Splitting them across three tickets guarantees that the next engineer rediscovers the same constraint.

The circuit is done when both directions match the contract you wrote at the start, not when the first direction passes.