Underlay Design

Introduction

This is the first page in the Connectivity layer on purpose. Before comparing MPLS, broadband, DIA, cellular or satellite, it’s worth asking a more basic question: what does this site actually need from its network, and why?

Most bad connectivity decisions aren’t technology mistakes. They’re decisions made in the wrong order: a technology gets picked (often because it’s what the last site used, or what a vendor is pushing) before anyone has written down what the site actually requires. The result is either overspend (MPLS everywhere, including sites that would be fine on broadband) or underspend (a critical site on best-effort internet because “the other stores are fine on it”).

The rest of the Connectivity layer covers individual technologies in depth. This page covers how to decide between them, and how those decisions add up to an underlay design for the whole organisation, not just one site.

Private ≠ encrypted. This distinction runs through every connectivity technology on this site, not just MPLS. A private or isolated network keeps your traffic separate from other traffic; it does not, by itself, protect the content of that traffic. Confidentiality is a separate decision, made with encryption, not with the choice of transport. Each technology page covers where this applies to it specifically.

Design drivers

These are the questions that should actually decide the technology, in roughly the order they’re worth asking:

• Reliability requirements. What does an hour of downtime at this site cost, in revenue, safety or reputation? A till system and a marketing office do not have the same answer.
• Bandwidth needs. Both today and in twelve to twenty-four months. Video, cloud backup and SaaS usage grow faster than most bandwidth planning assumes.
• Application sensitivity. Does anything at this site care about latency and jitter specifically, not just raw throughput? Voice, video, terminal sessions and industrial control traffic behave very differently from a file download.
• Cost constraints. Both the connectivity budget itself and what it’s being compared against. A technology that’s “too expensive” in isolation may be cheap next to the cost of the outage it prevents.
• Geographic availability. What’s actually installable at this address, on what timeline, from which providers. This constrains the decision more often than any other factor, and it’s the one people check last.
• Regulatory requirements. Data sovereignty, sector rules or contractual obligations that require or rule out specific connectivity models. See Security & compliance considerations on individual technology pages, and the Compliance layer for the frameworks themselves.

No technology wins on all six. The point of asking in order is that reliability and application sensitivity should narrow the field before cost and availability decide within it, not the other way around.

Traffic architecture: backhauling vs local breakout

Once a site is connected, the next design question is what its traffic actually touches on the way to its destination.

Backhauling routes a site’s traffic to a central location, usually a data centre or headquarters, before it goes anywhere else, including to the internet. This used to be the default: it centralised security and internet breakout when running a firewall at every site wasn’t practical. The trade-off is added latency for anything the site could have reached directly, which is most obviously felt with today’s cloud and SaaS traffic. See the backhauling diagram on the MPLS page for what this looks like in practice, and “cloud and SaaS traffic taking the scenic route” as a specific example of the cost.

Local breakout sends internet and cloud-bound traffic straight out from the site itself, instead of via the hub. It’s faster for that traffic, but it means security enforcement has to happen locally too, whether that’s a local firewall, a cloud-delivered security service, or both.

Neither is universally correct:

• Backhaul when the site has no independent security stack, when the traffic in question genuinely needs to go via the hub or data centre anyway (an internal application, for instance), or when a compliance requirement calls for centralised inspection.
• Break out locally when the traffic is destined for the internet or SaaS, cloud-delivered security is in place to cover it, and the latency saved is worth the additional moving part.

Most real designs do both: backhaul what belongs at the hub, break out locally what doesn’t, and use the overlay (see Hybrid considerations below) to make that split a policy decision rather than a wiring decision.

Site classification

Not every site deserves the same connectivity, and treating them all the same is one of the most common sources of both overspend and risk. A simple three-tier classification covers most organisations:

Tier	Examples	Typical connectivity approach
Critical sites	Head office, primary data centre, manufacturing plants, sites carrying payment or safety-critical traffic	Justify the cost of guaranteed performance: MPLS, dedicated internet access, or dual diverse circuits with an SLA behind them
Standard sites	Typical branches, retail stores, regional offices	Usually the best cost-to-performance fit: broadband or DIA, often dual-ISP, with SD-WAN steering traffic and providing resilience
Temporary / pop-up sites	Seasonal retail, events, rapid-deployment or disaster-recovery sites	Fast to deploy over anything that doesn’t need a truck roll: cellular (4G/5G), sometimes satellite where cellular coverage is poor

The classification is a starting point, not a formula. A “standard” retail store that also processes card payments may need a critical-site-grade path for that traffic specifically, while the rest of the site’s traffic stays on standard connectivity. Classify by what the site actually does and what it risks, not by its category on an org chart.

Hybrid considerations

Very few organisations run one connectivity technology everywhere, and fewer still should. A realistic estate usually mixes MPLS at the sites that justify it, broadband or DIA at most others, and cellular as backup nearly everywhere. This is not a compromise; it’s the correct design once sites are classified honestly.

Running multiple transport types in parallel used to mean routing complexity: multiple links per site, manual failover, and separate policies per circuit type. SD-WAN’s main practical contribution is making that manageable. It treats each underlay transport, MPLS, broadband, DIA, cellular, as an input, and applies one policy layer on top: steering traffic by application and by the real-time quality of each path, failing over automatically, and giving one place to see and manage all of it, instead of one per circuit type.

That’s also why “underlay” and “overlay” are worth keeping separate in your head, and why they’re two different layers on this site. The underlay technologies on this page decide what physical paths exist into a site. SD-WAN, the first topic in the SD-WAN & Network Architecture layer, decides how traffic is steered across whichever underlay paths are present. Getting the underlay classification right (this page) matters just as much with SD-WAN in place as without it: SD-WAN can steer traffic intelligently across the transports it’s given, but it can’t manufacture a guarantee that none of those transports actually offer.

Migration approach

Moving a site, or an entire estate, from one connectivity model to another is where good underlay theory meets contract terms, installation lead times and the fact that the business doesn’t stop while you migrate. A few principles that hold up in practice:

• Migrate by site tier, not all at once. Standard and temporary sites are lower-risk places to prove a new model before touching critical sites.
• Run both in parallel before cutting over. Install the new circuit, validate it under real load, and only then retire the old one. This costs more for a short overlap period and avoids a hard cutover with no way back.
• Prove it, don’t promise it. “Broadband and SD-WAN should perform comparably to MPLS at this site” is a hypothesis, not a decision. Pilot it, measure it against the site’s actual design drivers, and only then decide.
• Let contract end dates set the pace, not the reverse. Trying to exit MPLS contracts early is usually more expensive than the saving being chased. Sequence the migration around renewal dates where possible.
• Expect the routing, not the technology, to be the hard part. The physical cutover is usually the easy step. Redistributing routes between old and new paths, keeping policy consistent across both, and not breaking anything mid-migration is where the real work is.

MPLS’s own “Selective MPLS retention alongside other transports” use case is a worked example of this: MPLS kept only where it earned its place, other transports introduced elsewhere, and the decision to fully retire it left open per site rather than forced.

Connectivity comparison table

A single reference table across every Connectivity-layer technology, so the trade-offs can be compared side by side rather than re-derived on each page. It will fill in as each technology’s own page is written; for now, MPLS is populated and the rest point back to their (currently planned) pages.

Dimension	MPLS	Broadband / DIA	4G / 5G	Satellite
Typical cost per Mbps	High	Pending — topic not yet written	Pending — topic not yet written	Pending — topic not yet written
Deployment lead time	Weeks to months	Pending — topic not yet written	Pending — topic not yet written	Pending — topic not yet written
Performance guarantee (SLA)	Yes, contractual	Pending — topic not yet written	Pending — topic not yet written	Pending — topic not yet written
Native QoS	Yes, carrier-managed	Pending — topic not yet written	Pending — topic not yet written	Pending — topic not yet written
Privacy characteristics	Private path, not encrypted	Pending — topic not yet written	Pending — topic not yet written	Pending — topic not yet written
Typical fit	Critical sites, OT, guaranteed-performance workloads	Pending — topic not yet written	Pending — topic not yet written	Pending — topic not yet written

[REVIEW: fill in Broadband/DIA, 4G/5G and Satellite columns once those pages are written, and check the MPLS column against the figures used on the MPLS page itself.]

Related topics

• MPLS: the first technology page this design thinking feeds into.
• SD-WAN concepts: how the overlay steers traffic across whatever underlays this page helps you choose (coming soon).
• Underlay vs overlay: the conceptual distinction behind the Hybrid considerations section above (coming soon).