L2 VPN vs L3 tunnel: five checks before you bridge a site

You bridge a site because a tool insists it must sit on the same network, and three weeks later you are reading switch logs at two in the morning. That kind of hunch decides far too many Ethernet-over-IP links. Only one difference really matters here: whether whole frames travel end to end, or only IP packets do. Run the five checks below in sequence, and stop at the first one that fails.

Check what the application actually puts on the wire

Before any product name enters the discussion, capture a minute of the traffic that has to cross the link: tcpdump -i eth0 -nn -e 'not ip'. The -e flag prints the link-layer header, which is exactly the part a routed tunnel discards. If the capture stays empty, your application speaks IP and an L3 tunnel carries it unchanged. If frames do appear, note the EtherType, because 0x0806 is ARP, 0x88cc is LLDP, and a vendor value usually means a discovery protocol with no IP fallback. That is the point where an ordinary tun interface stops being enough.

Repeat the capture on the far side as well. A frame that only exists inside one host's virtual switch is no reason to stretch a broadcast domain across a WAN.

Check whether discovery has to cross the link

A routed tunnel has no shared segment, so nothing addressed to a group reaches the other end. ARP, DHCP broadcasts, mDNS on 224.0.0.251, SSDP and NetBIOS name queries all assume a link that several hosts can hear at once.

Ask which of those the application genuinely depends on, and whether a proxy already exists for it. DHCP relay, mDNS reflection and static ARP entries each remove one dependency, and each of them is another service to run and monitor. When two or three remain, bridging is the honest answer.

Check what the extra header costs you

Frames need somewhere to live, so everything you send gets a second header stack wrapped around it. In a VXLAN overlay that means an outer IP header, a UDP header and an 8-byte VXLAN header, which pushes a full-size 1,500-byte payload past the path MTU of an ordinary 1,500-byte internet link. OpenVPN in tap mode adds its own overhead in the same direction. Without a lower MTU on the inner side you get a link that answers pings and stalls on the first large transfer.

The bill does not stop at header bytes. Broadcast and multicast that a switch handles in hardware now ride the WAN, and every bridged site inherits the same address plan, DHCP scope and duplicate-address behaviour. That makes the link considerably harder to audit than a routed pool with one prefix per site.

Do the arithmetic before you choose. A busy segment replicated to three sites can move more broadcast traffic than the file transfers it was built to carry.

Check which kind of L2 VPN you are being offered

The term itself is ambiguous, and the ambiguity decides who carries your traffic. Sometimes it describes the payload: Ethernet frames inside IP, sent over the internet like any other tunnel, as VXLAN, ZeroTier and OpenVPN tap mode do. Sometimes it describes a purchased service: a carrier Ethernet circuit or an MPLS pseudowire that joins two sites inside one provider network.

Both hand you a segment, so the application cannot tell them apart, but the operational difference is large. An overlay leaves you responsible for MTU, encryption and the underlying path. A carrier service takes those over and charges for them, and it will not route your frames across the public internet at all. Which one you want depends on whether the two sites share an operator or merely share a company.

Check the cheaper workaround before you bridge

Most requests for a bridged link come from one broken lookup, not from a protocol that truly needs frames. Push the resolver and the search domain over the routed tunnel first: dhcp-option DNS 10.8.0.1 together with dhcp-option DOMAIN internal.example in an OpenVPN server configuration settles a surprising number of them. A local forwarder on the remote side does the same job without moving any broadcast traffic.

If one legacy tool still fails, put that tool behind a proxy or a jump host on the destination segment. A single TCP forwarder is cheaper to operate than a bridged WAN.

Close the decision in order: does the traffic carry a non-IP EtherType, does discovery have to cross, can the MTU absorb the extra headers, is a provider circuit actually available, and did the routed workaround fail for a reason you can name? A no at any step ends the argument in favour of the tunnel you already have. File the capture and the EtherType list with the change record, because the next person will ask the same question and will not want to repeat the measurement.