Who routes between your sites: Layer 2 or Layer 3 VPN?

Order a provider VPN and someone ends up owning intersite routing, whether you named that owner or not. Sign for a Layer 2 handoff and the provider delivers a pipe while your routers form the adjacency; sign for a Layer 3 service and the provider carries your prefixes inside its own routing context. Both are legitimate products with different on-call stories. Walk the order from the quote to the first acceptance test and the choice stops being abstract.

Start with the handoff form, not the topology slide

Every provider eventually sends a form that asks what it should hand you: a pseudowire, a multipoint Ethernet segment, or a routed attachment on a shared service edge. That single answer decides more than any diagram in the sales deck, because it fixes where your responsibility starts.

A point-to-point pseudowire is one circuit between two attachments, and a multipoint Ethernet service joins several sites in one broadcast domain. They look similar on a diagram and behave nothing alike once a loop or a broadcast storm is involved. Confirm which one is being quoted before you plan addressing.

Product names do not settle it. An MPLS label, a dark fibre handoff and an internet-based overlay can all be called a private network, and the framework documents treat the service model and the customer-provider split as the thing to define. Ask for the attachment semantics in writing, then read them back to your own team in plain words.

Read what arrived on the day of turn-up

On turn-up day, look at the interface you were given before you configure anything on top of it. A routed Layer 3 attachment usually appears as a port with a small point-to-point subnet or a next hop you must reach. A Layer 2 attachment appears as a link that expects frames, so your first useful command is a bridge or neighbour check rather than a route lookup.

ip -br link show
ip -br addr show
ip route show default
ip neigh show

Those four lines tell you which world you are in. A default route pointing at a provider address means the provider is routing for you. An interface with no useful layer-3 address but a populated bridge means you are expected to route, and any missing prefix is yours to fix.

A promiscuous-looking link can also mean the handoff is tagged, so confirm the VLAN agreement before blaming the circuit. Duplicated MAC addresses across a multipoint service are a design symptom, not a provider fault.

Assign one owner per object before the first prefix

Walk the object list and say the name of the team that owns each one out loud. Customer prefixes and the advertisements between sites. The adjacency or service identifier that forms the relationship with the provider edge. Who breaks loops, and who agreed to live inside one wider broadcast domain. Where the MTU ceiling sits, how failures get noticed, and how service returns. Access policy, plus any encryption the service does not include.

That list is short because it is the part that breaks during an incident. If two teams both believe they own route policy, an outage produces two conflicting changes in the same hour. If neither owns it, the first asymmetric path survives until a customer reports it.

A routed service usually gives you a BGP or static boundary, so your side needs a session state you can read: birdc show protocols or the equivalent on your router tells you whether the adjacency is up, and the counters tell you whether it is flapping during business hours only. A Layer 2 handoff gives you no such signal, which is why the customer must own an explicit reachability check instead.

Walk the failure case for one site

Write the acceptance test before the service goes live: drop one site attachment and record what each team sees. On a Layer 3 service the provider withdraws reachability for that site's prefixes, your session logs the withdrawal, and the remaining sites keep their paths. On a Layer 2 service the circuit goes down, your routing protocol notices a dead neighbour, and the same convergence depends entirely on your timers.

Restore the link and check the second half of the case, because stale state is the usual leftover. Confirm the adjacency returns, the prefixes come back with the expected attributes, and no temporary static route remains in the table from the incident.

Also test the boring failure: a single site doubling its traffic. On a routed handoff you can see per-prefix counters; on a bridged one you may only see interface throughput, which leaves you guessing which host is responsible.

What the contract does not buy

A Layer 2 or Layer 3 label says nothing about latency, a dedicated backbone, or encryption. Those are separate commitments, and availability figures do not imply any of them. Read the service agreement for what is promised and treat everything else as an assumption you should test.

If your requirement is a point-to-point attachment between two customer routers, a Layer 2 service fits without asking the provider to run your interior routing. If your requirement is many sites with distinct subnets and a small operations team, a routed service usually removes work you would otherwise own.

Neither is a default. Check device support for the encapsulation, the actual traffic relationships between sites, the redundancy model, and whether your team can operate the part it just accepted. Then write the owner names into the runbook, since that is the only part of the decision that survives staff changes.