L2TPv2 vs L2TPv3 vs GRE vs VPWS: choose by payload

Most L2TP versus GRE arguments collapse for the same reason: the names sit at different layers of the problem. Two of them describe encapsulation you configure on your own routers. One of them describes a service somebody else sells you. Begin with the payload the endpoints must carry and the comparison becomes a short list of consequences instead of a feature fight.

Payload first, protocol second

In practice the payload is one of four things: a PPP session, a raw Ethernet frame, an IP packet, or an MPLS frame handed to a provider. Each imposes different demands on addressing, broadcast handling and failure detection. Get this list wrong and no amount of encapsulation tuning will rescue the design.

Anything outside these rows is added later, such as encryption, compression or traffic shaping. Pick the row first.

L2TPv2 and L2TPv3 share a name and little else

L2TPv2 exists to carry PPP sessions across an IP network, which is why it reads like a remote access protocol rather than a generic frame transport. L2TPv3 generalizes that idea: a control connection negotiates sessions, and each session carries a defined Layer 2 connection between two IP endpoints. Same family name, different control protocol, different session model. A requirement that says only L2TP is incomplete, and a template copied from the wrong version will not even negotiate.

If you need PPP, L2TPv2 is the only realistic member of the family; if you need Ethernet frames across a routed core, you are in L2TPv3 territory.

Transport details differ in ways that surface during a firewall review. L2TPv3 can travel directly over IP protocol 115 or inside UDP, commonly on port 1701, while L2TPv2 stays on UDP 1701 with PPP inside. A policy written for one version can look entirely correct and still drop the other.

GRE is a header, not a service

GRE wraps a payload in a four-byte header with an optional key and sequence field, then hands the result to IP for delivery. It makes no claim about what the payload means, so implementations can tunnel IPv4, IPv6 or Ethernet if those protocol types are supported. Generic is not the same as universal: verify the protocol type and the fragmentation behaviour on the actual device.

The key field is what makes GRE useful when several tunnels share one pair of endpoint addresses, because the receiver demultiplexes on that value. GRE over IPv4 costs about 24 bytes before any extra options, which starts to matter on links already provisioned for 1500-byte frames. On its own GRE offers no confidentiality, so the usual pattern pairs it with IPsec and lets IPsec own the crypto boundary. That pairing works, but the MTU budget then has to cover both headers.

GRE also carries multicast and broadcast through the tunnel when the payload is Ethernet, which a plain unicast IP tunnel cannot do. That property, rather than the acronym, is usually why a design picks it.

VPWS is bought, not configured

A virtual private wire service delivers a point-to-point Layer 2 circuit across a provider's network. Your attachment circuit terminates on a provider edge device, and the pseudowire across the core belongs to the provider. The questions that matter are operational: where the demarcation sits, who owns the first and last mile, and what the provider does with oversized frames.

This is where the comparison turns. L2TPv3 and GRE are things you run end to end, so you debug them with your own credentials and your own captures. VPWS is a contract with a handoff, so an outage starts with a ticket rather than a packet capture. Neither model wins outright; they fail in different places, and the choice rests on whether you want to own the last mile.

The pseudowire label stack stays inside the provider network, so it does not change your MTU arithmetic the way a visible tunnel header does.

Pick one row and write it down

Record the decision as a single sentence with three parts: payload, encapsulation, and transport owner. Then attach the numbers that make it checkable.

For each candidate, write down the on-wire overhead, the largest frame the path accepts, and the first hop that would report an MTU problem. Confirm both endpoints support the protocol type or session type you chose, not just the marketing term on the datasheet. Decide what multiplexing would look like if a second circuit appears next year, because GRE keys and L2TPv3 session IDs are not interchangeable solutions to that problem. Then send one oversized frame and one normal frame; that pair catches most designs that looked fine on paper.

Comparing tunnels by name keeps producing arguments nobody can settle. Comparing them by payload, overhead and ownership produces a decision in an afternoon, plus the evidence needed to defend it later.