Pseudowire Up but 1500-Byte Frames Disappear
A carrier provides an LDP-signalled VPWS between PE1 and PE2. Both PEs show VC ID 200 up with local and remote labels assigned. The customer CE interfaces are 1500-byte MTU, and the core links support 9216 bytes. Small pings pass, but ping 1500 with the DF bit set fails. The CE-to-CE BGP session flapses when it sends full updates, and large file transfers stall while small transactions work. On PE1, show interface shows physical MTU 1500 and MPLS MTU 1500. On PE2, physical MTU is 1500 and MPLS MTU is 1508. The pseudowire is configured with mtu 1500 on PE1 and mtu 1508 on PE2. The team plans to increase the CE MTU to 9000 to match the core. You must explain the failure and judge whether that plan is correct.
1. Why do small pings pass while 1500-byte frames fail, even though the pseudowire reports up?
Read the worked answer
The pseudowire control plane can be up while the data plane cannot carry the customer's maximum frame size. A 1500-byte CE frame needs additional MPLS label stack bytes on the PE-to-core link. If PE1's MPLS MTU is 1500, adding even one 4-byte label exceeds the allowed MPLS payload size. PE1 may drop the frame or fail to forward it; because this is Layer 2, it cannot rely on IP fragmentation. Small pings fit under the limit and pass, which makes the pseudowire look healthy. The mismatch between PE1 and PE2 pseudowire MTU also signals that the two ends do not agree on the maximum payload. The VC being up only proves label exchange and basic PW status, not that the data plane supports the required frame size.
2. What would you check and change on the PEs, and why is increasing the CE MTU to 9000 the wrong fix?
Read the worked answer
Check show mpls l2transport vc 200 detail on both PEs for the pseudowire MTU, control-word, and status. Check the physical and MPLS MTU on the access and core interfaces with show interface and show mpls interfaces. The PE must be able to receive a 1500-byte CE frame and add the label stack, so the MPLS MTU should be at least the physical MTU plus the maximum label stack, for example 1508. Align the pseudowire MTU on both ends to the customer contract, usually 1500, and make sure the core path supports the resulting encapsulated size. Increasing the CE MTU to 9000 does not help: the CE still sends 1500-byte frames unless applications change, and a larger CE MTU can create bigger frames that the PE cannot encapsulate. The fix belongs at the PE MPLS and pseudowire MTU, not at the CE.
3. What verification would prove the fix without disrupting the customer?
Read the worked answer
After aligning the MTUs, run a DF-bit ping at 1500 bytes from CE to CE and confirm it succeeds. Check show mpls l2transport vc 200 detail for matching MTU values and a stable PW status. Use interface counters and show mpls forwarding-table to confirm that labeled frames are being forwarded rather than dropped. Generate a large TCP transfer or a BGP update and confirm that the session remains stable. If possible, capture on the PE-core link and verify the labeled frame size is within the MPLS MTU. A controlled maintenance window is still advisable, but the verification can be done with a test VC or a temporary secondary pseudowire before changing the production VC.