Contrail SD-WAN Deep Dive Part 2: E-Hub, P-Hub, and the Anatomy of a Hub-and-Spoke Overlay

Part 1 covered CSO’s orchestration model and its two CPE families. This post is the one this arc has been building toward: the hub-and-spoke routing architecture itself, and specifically the two hub device roles that shaped everything about how traffic actually moved through a Contrail SD-WAN deployment.

Two hubs, two different jobs

CSO’s documentation distinguishes between two hub device types, and the distinction is architectural, not just naming:

Enterprise hub device. A special role that a spoke-class device — an SRX1500, SRX4100, or SRX4200 in Juniper’s supported list — could be promoted into, deployed as the anchor for a single enterprise’s own dynamic-mesh topology. It’s customer-owned, dedicated to one tenant, and typically sits at a data centre or head office, terminating the tunnels that the enterprise’s other sites build toward it. Think of it as a spoke device with a hub job bolted on: same hardware family, elevated role, single-tenant scope.

Provider hub device. A shared device the service provider hosts in its own infrastructure, acting as a point of presence for multiple customers simultaneously. This is the device that makes CSO’s service-provider DNA visible in the topology diagram: one physical (or virtualized) hub, carrying traffic for many tenants, with per-tenant isolation enforced through virtual routing and forwarding (VRF) instances rather than dedicated hardware per customer.

Informally, engineers who worked with CSO shorthanded these as E-Hub and P-Hub — enterprise hub and provider hub — and that shorthand is doing real work: it’s the fastest way to ask “whose hub is this, and how many tenants share it?” in a design conversation.

Hub-and-spoke: the provider hub model

In the hub-and-spoke deployment topology, spoke CPE devices — SRX or NFX, per Part 1 — connect across two or more WAN links to a provider hub device, and not directly to each other. Because of this, all site-to-site traffic transits the hub: a flow from Branch A to Branch B doesn’t take a direct tunnel between the two spokes, it rides Branch A → P-Hub → Branch B, even if a direct path between the two branches would have been shorter or cheaper. By default, internet-bound traffic from a spoke follows the same rule — it too routes through the provider hub rather than breaking out locally, unless the deployment is explicitly configured for local internet breakout at the spoke.

That’s the trade CSO’s hub-and-spoke model makes explicit: centralization of routing, policy enforcement, and (for a service provider) billing and visibility, at the cost of every flow taking an extra hop through a shared chokepoint. For a managed service provider, this is often exactly the trade they want — the provider hub is where they enforce policy, apply security inspection, and meter usage across every tenant sharing that hub, using VRF instances to keep one customer’s routes and traffic invisible to the next.

VRF-based multi-tenancy at the P-Hub

The provider hub’s multi-tenant model runs on VRF instances — one (or more) per tenant, giving each customer’s routing table, and by extension their traffic, logical separation from every other tenant sharing the same physical hub device. This is standard MPLS-VPN-style thinking applied to an SD-WAN overlay rather than a Layer 3 VPN backbone, which makes sense given Contrail’s SDN/NFV ancestry — VRF-based tenant isolation is exactly the kind of primitive that control plane was built to orchestrate at scale for service providers in the first place.

The operational cost of this model shows up as the tenant count grows. Every new customer onboarded to a shared provider hub is a new VRF to provision, a new set of route leaking or route-target policies to get right if that tenant needs any shared services, and a new blast radius to reason about if the hub itself has a problem. None of this is unusual for a service-provider MPLS-VPN practice — but it’s a meaningfully heavier operational model than the “each customer gets their own simple centralized controller view” pitch that Viptela and VeloCloud were selling to enterprise buyers in the same period.

Dynamic mesh: the enterprise hub model

The alternative topology, dynamic mesh, is architecturally simpler and single-tenant by construction. Each spoke builds a direct tunnel to every other site it needs to reach, rather than routing everything through a hub, with the enterprise hub device serving as the anchor point — typically the device that also carries internet breakout and connects out to data-centre resources, but not a mandatory transit point for every spoke-to-spoke flow the way the provider hub is.

This is the topology an enterprise self-managing its own CSO deployment was more likely to run, and it maps much more closely to how Viptela or VeloCloud customers thought about their own overlays: one organization, one topology, no VRF-per-tenant bookkeeping. The E-Hub, in this model, is doing a narrower job than the P-Hub — anchoring the mesh and typically handling DC/internet egress, rather than being the mandatory transit point for every flow in the network.

Where the complexity actually bit

The genuine operational friction in Contrail’s routing model wasn’t the existence of two hub types — that’s a reasonable design choice, and plenty of vendors distinguish MSP-hosted hubs from customer-owned ones. The friction was in how much day-to-day design and troubleshooting work assumed familiarity with VRF-based service-provider routing concepts, on a platform being sold, at least in part, to enterprise IT teams who weren’t necessarily coming from an MPLS-VPN background. A network engineer used to Viptela’s OMP-based centralized policy model, or VeloCloud’s business-policy abstraction, had a shallower conceptual on-ramp than one asked to reason about VRF route leaking, hub-selection policy, and provider-hub-versus-enterprise-hub topology choice on day one.

That’s not a claim that the architecture was wrong — for the MSP audience CSO was genuinely built for, VRF-based multi-tenancy on a shared provider hub is the correct tool. It’s a claim about audience mismatch: the same routing model that made CSO a coherent MSP SD-WAN platform made it a heavier lift for the straightforward enterprise deployments that made up the bulk of the market’s growth in this era. The next post in this series closes out the Contrail arc with what that mismatch meant competitively, and the specific rationale Juniper gave for moving on to Session Smart Routing.