VeloCloud SD-WAN and Partner Gateways Part 1: MPLS-Only Site Architecture

Most VeloCloud SD-WAN deployments lean on dual transport — broadband plus MPLS, or broadband plus LTE. The broadband link gives you a direct internet path; MPLS gives you a private, low-jitter backbone. But a meaningful number of enterprise sites are MPLS-only: no broadband circuit, no LTE, no direct internet breakout at the branch. Every byte, whether it’s heading to the data centre or to the internet, has to traverse the MPLS fabric.

This series is about what happens at those sites — how VeloCloud handles routing through a Partner Gateway, how you safely onboard an MPLS-only Edge, and, critically, why you must never let a default route from the MPLS underlay leak unchecked into the Partner Gateway.

What Is a Partner Gateway?

VeloCloud Gateways (VCGs) sit at the edge of the SD-WAN overlay. Every Edge device builds encrypted VCMP (VeloCloud Multipath Protocol) tunnels to one or more Gateways; those Gateways are the overlay’s exit points to the rest of the world.

There are two flavours:

• Operator Gateways — hosted by the SD-WAN operator (Arista/VMware, or an SP running VeloCloud), reachable only over the internet underlay.
• Partner Gateways — hosted by the MPLS carrier or a network services partner. They have a private peering into the MPLS fabric, which means an Edge with no internet link at all can still build VCMP tunnels, because the MPLS circuit is the underlay path to the Gateway.

Partner Gateways are what make MPLS-only deployments possible. Without one, an Edge needs at least one internet-facing transport to reach a Gateway. With one, the MPLS link becomes the underlay, and the VCMP tunnel rides across it.

The NNI — Network-to-Network Interface

The NNI is the physical and logical boundary between the MPLS carrier’s network and the Partner Gateway. Think of it as the handshake point: on one side sits the MPLS PE (Provider Edge router), on the other sits the Partner Gateway’s underlay interface.

Connectivity at the NNI is typically:

• A dedicated circuit (physical hand-off, dark fibre, or a carrier Ethernet service) between the carrier’s core and the PG host environment.
• Or a tagged VLAN presented on a shared interconnect, much like a data-centre cross-connect.

BGP runs across the NNI. This is how routes are exchanged between the MPLS fabric and the Partner Gateway:

MPLS Carrier Network
       │
       │  NNI (BGP peering)
       │
  Partner Gateway (VCG)
       │
       │  VCMP tunnels (over MPLS underlay)
       │
   Branch Edges

The BGP session at the NNI operates in the context of the customer’s MPLS VRF (or a dedicated interconnect VRF, depending on the carrier design). What each side advertises matters enormously — and we will come back to this in Part 3 when we talk about default route handling.

What the MPLS Carrier Advertises to the PG

The carrier’s PE advertises the customer’s site prefixes across the NNI — the LAN subnets sitting behind each branch PE. These are the routes that tell the Partner Gateway how to reach every site in the MPLS fabric.

For example, in a typical enterprise deployment:

PE → PG (NNI BGP):
  10.10.1.0/24   (Branch A LAN)
  10.10.2.0/24   (Branch B LAN)
  10.10.3.0/24   (Branch C LAN)
  172.16.100.0/24 (Data Centre LAN)

The PG installs these as underlay routes. When overlay traffic needs to reach one of these destinations, the PG knows how to forward it back across the NNI.

What the Partner Gateway Advertises to the MPLS

The PG advertises the SD-WAN overlay summary prefixes back toward the PE. These are typically the aggregate address ranges used by the SD-WAN fabric — not individual host routes, but summarised blocks that tell the MPLS network “send SD-WAN traffic this way.”

The PG may also advertise a default route (0/0) toward the MPLS, but only when it’s intentional — and only in the direction from PG toward the PE, to serve as the branch’s internet exit. This is the right direction for the default route. The wrong direction, as we will see, is the MPLS advertising 0/0 toward the PG.

MPLS-Only Edge Topology

An MPLS-only Edge has a single WAN link: the MPLS circuit. There is no broadband, no LTE, no out-of-band management path. The Edge’s entire connectivity to the SD-WAN overlay — and to the internet — depends on that one link.

The traffic model, once the Edge is fully onboarded, looks like this:

Branch LAN
    │
  Edge (VeloCloud)
    │  MPLS circuit (the underlay)
    │  VCMP tunnel (the overlay, encapsulated inside the MPLS path)
    │
  MPLS PE ── MPLS Core ── MPLS PE at NNI
                                │
                         Partner Gateway
                                │
                    ┌───────────┴───────────┐
                    │                       │
               Other SD-WAN sites      Internet breakout
               (via overlay)           (via PG's internet link)

The branch Edge encapsulates all its traffic in VCMP. The MPLS network simply carries this encapsulated traffic to the Partner Gateway — it has no visibility into the overlay payload. At the PG, the VCMP tunnel is terminated, and the PG makes the forwarding decision: is this traffic destined for another SD-WAN site (keep it in the overlay), or does it need to break out to the internet (send it out via the PG’s internet link)?

From the MPLS carrier’s perspective, it’s just forwarding IP packets between the branch PE and the PG. The SD-WAN intelligence — dynamic path selection, QoS, application steering — lives in the overlay.

The Onboarding Problem

Here is where things get interesting. For a VeloCloud Edge to join the SD-WAN fabric, it must first activate. Activation means:

1. The Edge powers on and obtains its WAN IP (from the MPLS PE, typically via static assignment or DHCP from the PE).
2. The Edge contacts the VeloCloud Orchestrator (VCO) — a cloud-hosted (or on-premises) management plane.
3. The VCO sends the Edge its configuration, including which Partner Gateways to build VCMP tunnels to.
4. The Edge builds its VCMP tunnels to the Partner Gateways.
5. The Edge is now “live” in the overlay.

Step 2 is the problem. The VCO is reached over the internet. An MPLS-only Edge has no internet path — except the MPLS circuit. Unless the MPLS network can route the Edge’s activation traffic to the internet somehow, the Edge can never activate.

The standard solution is to temporarily inject a default route (0/0) into the customer’s MPLS VRF for the duration of the onboarding window. The carrier routes this 0/0 to their internet gateway, giving the Edge a transient internet path via the MPLS. The Edge uses this path to reach the VCO, activate, and build its VCMP tunnels.

Once the tunnels are up, the production internet path for the branch is via the Partner Gateway — not the carrier’s internet gateway. The temporary 0/0 has served its purpose, and the question becomes: what happens to it next?

That is the subject of Part 2.

Key Concepts — Summary

Before moving on, it is worth anchoring the terminology used throughout this series:

Term	Meaning
PG / VCG	Partner Gateway / VeloCloud Gateway — the overlay exit point
NNI	Network-to-Network Interface — the BGP peering between MPLS PE and PG
Underlay	The physical transport network (MPLS fabric, internet)
Overlay	The VCMP tunnel mesh that carries SD-WAN traffic
VCO	VeloCloud Orchestrator — the management and policy plane
VCMP	VeloCloud Multipath Protocol — the encapsulation used in the overlay
VRF	Virtual Routing and Forwarding — logical routing table used to isolate customer traffic in the MPLS fabric

In Part 2, we walk through the onboarding flow step by step — what the Edge does during activation, what the MPLS needs to provide, and how the routing state changes once the VCMP tunnels come up.