Ask an engineer how much to add for MPLS and you will hear a number, usually thirty, delivered with confidence. The number is not wrong so much as unmoored: it depends entirely on what the starting figure counts and what the provider edge actually transmits. On an Ethernet pseudowire the assumptions are visible, and once you write them down, the arithmetic replaces the folklore.

Three different things are being measured under one name. There is the customer's IP packet, the Ethernet frame carried across the pseudowire, and the provider's own outer link framing. A budget that mixes them produces a value no device field expects.

One worked budget with every assumption stated

Take a customer IP packet of 1500 bytes, an ordinary Ethernet header carried across the pseudowire without the customer FCS, no VLAN tag retained, a two-entry label stack, and a four-byte control word. The carried Ethernet header adds 14, retained tags add nothing, the two label entries add 8 because each entry is 4 bytes, and the control word adds 4. That gives 1526 bytes of MPLS-encapsulated packet.

Read the result carefully. It excludes the provider link's outer Ethernet header and its FCS, and it is an example rather than a constant to type into any field labelled MTU. Two labels is an assumption too: the real stack may carry a transport label, a service label and occasionally more, and each entry costs the same 4 bytes.

What actually crosses the pseudowire

RFC 4448 defines how Ethernet frames travel inside MPLS, and in its ordinary model the customer preamble and FCS are stripped at ingress and regenerated at egress. That is why the FCS does not appear in the budget above. VLAN handling depends on the service mode: a mode that preserves customer tags adds their bytes back, and a mode that maps them does not. Additional preservation or extra encapsulation has to be counted on top.

The control word is part of the arithmetic whenever it is used. RFC 8469 recommends it for Ethernet pseudowires, so an older text describing it as optional is not evidence that your path leaves it out. Confirm the actual service mode with the provider instead of inferring it from a diagram.

Compare the number with the right field

Now hold the required encapsulated size next to every relevant link, and next to the vendor's definition of the limit you are configuring. Some fields describe an IP packet, others describe a frame or another encapsulation boundary. Two numbers can look identical and describe different capacities, which is how a configuration that appears to fit produces drops in production.

This is also why copying a value between unrelated platforms is risky. The name of the field is the specification, not the decimal number you remember from another vendor's console.

Ping payloads are not MTU values

An IPv4 ping payload is not an IP MTU. The IP header and the ICMP header consume bytes too, so a payload size that succeeds corresponds to a larger packet on the wire. A probe that passes at one size also says nothing about a service using a different VLAN mode or a deeper label stack. The test measures one path, one size and one payload shape, and the service can vary all three.

Worse, a ping can succeed while large frames fail, because the probe exercised a path and a size that the real traffic never uses. Treat it as one data point about reachability, not as a layer-2 service specification.

When the frame does not fit

If oversized frames cannot be carried and no supported fragmentation or reassembly mechanism is in place, they get dropped, usually without a clean error at either end. Applications then show timeouts on bulk transfers while interactive sessions stay healthy, which sends people looking at firewalls and routes instead of byte counts.

Resolve the actual budget with the provider: service mode, tag handling, label depth, control word, and the exact limit your device enforces. Write the assumptions next to the number, because the next engineer will otherwise inherit the thirty-byte rule and a mystery.

Winndannde jowitiiɗe heen