MPLS VPN or IPsec overlay: three contracts to settle

Three promises sit inside a single wide-area quote, and buying one does not buy the others. Someone forwards your packets, someone keeps your routing separate from every other customer, and someone decides whether the payload is readable in transit. Those promises can belong to different parties and still describe one workable design. Separating them is the decision; choosing a technology name is not.

Three promises inside one wide-area quote

The first promise is transport: which sites connect, over which access circuits, and who forwards packets between them. The second is routing: which prefixes may reach each other, who approves a change, and how your traffic stays apart from another tenant. The third is protection: what is encrypted, between which endpoints, and who holds the keys. Ask for each in writing, because each answer lives in a different document.

A provider quote tends to price the first, assume the second and leave the third to you. That is not dishonesty; the three are sold by different teams. It becomes a problem when a design review finds that the security team assumed encryption and the network team assumed the carrier handled it. Splitting the sentence into three costs an hour and prevents that meeting.

A label describes forwarding, not the service at the demarcation

Multiprotocol label switching says how a packet travels inside a provider network. It does not say what the customer plugs into, or what the customer exchanges with the provider edge. A provider can build a routed IP VPN on MPLS, or a Layer 2 service with an entirely different attachment model, and both may reach you as an "MPLS connection".

The IETF provider-provisioned VPN terminology defines the vocabulary for exactly this: the customer edge, the provider edge, and the service models built between them. Use it when a quote blurs the layers, and ask what the handoff physically is.

A routed service hands you a routing relationship with the provider edge, so adding a prefix becomes a change request in two organisations. A Layer 2 handoff carries your own routing and moves the operational burden to your side. Neither is better in the abstract; the answer follows from how often your topology changes and who you want answering at three in the morning.

Encryption is a promise you cannot delegate by accident

Private transport does not make a payload unreadable. Provider separation keeps tenants apart operationally; it is not a statement about who can inspect bytes on the path. If the requirement is that the carrier cannot read the traffic, that requirement needs a mechanism you control, and IPsec is the usual one.

IPsec runs over private transport as readily as over internet access, so "MPLS or IPsec" is a false choice whenever you need managed reachability and your own trust boundary at once. Decide where the tunnel terminates, because a tunnel ending on a router leaves the segment behind that router in cleartext. Then decide who administers each peer, since a key held by a third party is not a boundary you own.

Give every promise a name and a measured edge

Write one line per promise with an owner and a boundary that can be measured. An access circuit's availability belongs to its supplier, backbone latency belongs to the provider, and tunnel liveness belongs to whoever runs the endpoints. A single end-to-end number that nobody measures is a number nobody owes you.

A service level agreement comes from the contract and its scope, not from the letters in a technology name. IPsec does not require best-effort internet transport, and MPLS does not carry a latency guarantee by itself; both depend on the underlay and the endpoints you choose.

Test the path you drew, including its failure

A private transport with a generous interface can still fail once an overlay adds headers, and the symptom is a session that establishes and then stalls on large responses. Test the usable size instead of reasoning about it, and write down the largest packet that passes end to end. Do that before you argue about bandwidth, because a path that drops large packets looks like an application problem. The number belongs in the design document next to the MTU of every access circuit.

ping -M do -s 1400 -c 3 <vpn-gateway>
traceroute -n <vpn-gateway>

Those commands come from a Linux host at one site; other platforms spell the same test differently. If a site needs a smaller value, that is a design constraint to record, not a fault to report. The same discipline applies to throughput, because encryption costs processing and the endpoint becomes part of the capacity calculation.

Draw two diagrams before signing: the normal path with every owner labelled, and the failure path with the same labels. The second exposes designs that look redundant on paper and depend on one device in practice. When an outage arrives, that drawing is what turns a confusing morning into a short triage.