VeloCloud SD-WAN and Partner Gateways Part 2: Onboarding an MPLS-Only Edge

29 May 2026 VeloCloudArista

In Part 1 we established the architecture: an MPLS-only branch Edge, a Partner Gateway sitting at the edge of the MPLS fabric, and an NNI BGP peering between them. We ended on the onboarding problem — the Edge needs to reach the VeloCloud Orchestrator over the internet to activate, but it has no internet link.

This part walks through the onboarding sequence in detail: what the carrier must do, what the Edge does, and how the routing state looks before, during, and after activation.

The Two Routing States

It helps to think clearly about two distinct phases:

Phase 1 — Onboarding: The Edge has no VCMP tunnels yet. It needs an internet path to reach the VCO. The MPLS provides this transiently via an injected default route. This phase ends the moment the Edge’s VCMP tunnels come up.

Phase 2 — Production: VCMP tunnels are live. Internet access flows through the Partner Gateway. The branch no longer depends on the carrier’s internet path. The temporary default route should either be withdrawn or — critically — blocked from leaking back into the PG.

Phase 1: Onboarding

Step 1 — The Carrier Injects a Temporary Default Route

Before the Edge is shipped to site, the carrier makes a change in the customer’s MPLS VRF: they inject a 0/0 toward their internet gateway. This might be done via:

A static route on the PE, redistributed into the VRF routing table.
A BGP conditional advertisement, activated when the site comes online.
A VRF import policy that pulls in a default from the carrier’s internet-facing VRF.

The effect is the same: the branch PE now has a route to 0/0, pointing toward the carrier’s internet gateway. Any traffic from the branch that doesn’t match a more specific prefix will follow this path.

Branch PE routing table (VRF: CUSTOMER-A) during onboarding:
  10.10.1.0/24   connected   (branch LAN)
  10.10.2.0/24   via MPLS    (other branch)
  10.10.3.0/24   via MPLS    (data centre)
  0.0.0.0/0      via MPLS    → Carrier Internet GW   ← temporary

Step 2 — The Edge Powers On

The Edge boots, obtains its WAN IP from the PE (static or DHCP), and begins activation. It sends an HTTPS request to the VCO’s activation endpoint. On MPLS-only deployments, VeloCloud typically uses the Orchestrator’s FQDN (e.g. vco.velocloud.net or a customer-specific hostname).

The Edge resolves the FQDN via DNS — which also needs to work. If the MPLS PE is acting as a DHCP server for the Edge’s WAN interface, it should hand out working DNS resolvers. If DNS resolution fails, activation fails. This is a common early stumbling block on MPLS-only sites: the PE DHCP scope has no DNS servers configured, or the DNS servers are only reachable via the corporate LAN, not from the WAN interface subnet.

With DNS working and the 0/0 in place, the Edge’s activation traffic leaves the branch PE, rides the MPLS fabric to the carrier’s internet gateway, and from there reaches the VCO over the public internet.

Step 3 — VCO Pushes Configuration

Once the Edge authenticates with the VCO (using its activation key or certificate), the VCO pushes the full Edge configuration:

Business policies and QoS rules.
The list of Partner Gateways the Edge should build VCMP tunnels to.
Profile settings including WAN link configuration.

The VCO identifies this Edge as MPLS-only and associates it with the correct profile — one that has the Partner Gateway assigned as the primary (and only) Gateway.

Step 4 — VCMP Tunnels Come Up

With the configuration applied, the Edge initiates VCMP tunnel establishment to the Partner Gateway. For MPLS-only Edges, this traffic flows:

Edge → MPLS WAN link → MPLS PE → MPLS Core → PE at NNI → Partner Gateway

The VCMP tunnel is UDP-based (default port 2426). The Edge sends VCMP handshake packets toward the PG’s underlay IP address. The PG responds, and the tunnel is established.

At this point the Edge has a live overlay path to the Partner Gateway. The SD-WAN fabric is operational for this site.

Phase 2: Production Routing

How Internet Traffic Flows Post-Onboarding

Once the VCMP tunnel is up, internet-bound traffic from the branch follows this path:

Branch host
    │
  Edge (LAN interface)
    │  Edge applies business policy: internet traffic → PG
    │
  VCMP tunnel (over MPLS underlay)
    │
  MPLS Core
    │
  Partner Gateway
    │
  PG's internet breakout link
    │
  Internet

The Edge never sends internet traffic natively onto the MPLS link. It always encapsulates it inside VCMP first. The MPLS network is simply a transport layer — it carries the VCMP-encapsulated packets to the PG without inspecting the payload.

At the PG, the VCMP encapsulation is stripped, and the PG makes the routing decision. Internet traffic gets NAT’d (or routed, depending on design) out the PG’s internet interface.

The Edge No Longer Needs the Temporary Default Route — For Data

This is an important nuance. Once the overlay is up, the Edge does not need the carrier’s temporary 0/0 for user data traffic. Internet traffic goes via the VCMP tunnel and exits at the PG. The carrier’s internet gateway is not in the data path.

The Edge does still need the underlay path to the PG for the VCMP tunnel itself. But that’s not 0/0 — it’s a specific route to the PG’s underlay IP address, which is reachable within the MPLS fabric via the carrier’s normal MPLS routing (not via the internet at all).

However, the Edge continues to use the underlay for one other purpose: reaching the VCO for ongoing management traffic (heartbeats, config updates, telemetry). By default, VCO management traffic also travels over the overlay — through the VCMP tunnel to the PG, and then from the PG to the internet. So the carrier’s internet gateway path becomes redundant for this too.

What Should Happen to the Temporary Default Route?

Once the Edge is fully onboarded and its VCMP tunnels are stable, the carrier’s temporary 0/0 in the MPLS VRF should be removed. It has served its purpose. Leaving it in place creates unnecessary risk:

If the VCMP tunnel drops (PG maintenance, MPLS instability), the Edge might use the carrier’s internet gateway as a fallback internet path. This is usually undesirable — it bypasses the SD-WAN policy engine entirely, and the traffic is unencrypted from the MPLS perspective.
The 0/0 exists in the MPLS VRF routing table. If the NNI BGP session is not properly filtered, it could leak across the NNI into the Partner Gateway. We will explore exactly why this is catastrophic in Part 3.

The Recommended Onboarding Window

In practice, carriers and SD-WAN deployment teams often leave the temporary 0/0 in place until the site has been validated and signed off. A reasonable process:

Carrier injects 0/0 into the MPLS VRF for the site.
Edge is shipped, installed, and activates.
Deployment team validates: tunnels up, traffic flowing, applications working.
Carrier withdraws the 0/0 from the MPLS VRF.
Traffic is confirmed still flowing correctly (now entirely via VCMP tunnel / PG internet breakout).

This validation step — confirming traffic still works after the 0/0 is removed — is one that gets skipped surprisingly often. It should never be skipped, because it is the test that proves the production routing model is sound.

A Routing State Comparison

Here is how the branch PE’s routing table (in the customer VRF) looks at each phase:

During Onboarding:

0.0.0.0/0      via MPLS  → Carrier Internet GW   (temporary)
10.10.1.0/24   connected
10.10.2.0/24   via MPLS  → Remote branch PE
10.10.3.0/24   via MPLS  → Data centre PE

Production (Post-Onboarding, 0/0 Withdrawn):

10.10.1.0/24   connected
10.10.2.0/24   via MPLS  → Remote branch PE
10.10.3.0/24   via MPLS  → Data centre PE
[no default route]

Notice there is no default route in the MPLS VRF in production. The branch PE has no route for unknown destinations. This is intentional. Internet traffic never hits the MPLS routing table — it’s caught at the Edge, encapsulated in VCMP, and sent through the tunnel. The MPLS only ever sees VCMP tunnel packets destined for the PG’s underlay IP, which is a known host route within the MPLS fabric.

What About the PG Side?

During production, the Partner Gateway’s underlay routing table has a different picture. The PG receives the customer’s site prefixes via NNI BGP from the carrier — the known LAN ranges for each branch. It does not receive a 0/0 from the MPLS (or if it does, it must be filtered). The PG has its own internet link and uses that for internet breakout.

The PG may advertise a 0/0 toward the MPLS (to serve as the default for branches that need internet via the overlay), but the direction matters: PG → MPLS is fine, MPLS → PG is not.

This directionality — and the NNI filters that enforce it — is the focus of Part 3.

Common Pitfalls During Onboarding

DNS not working from the WAN subnet: The PE DHCP scope for the Edge’s WAN interface must include reachable DNS servers. If DNS fails, VCO resolution fails, and the Edge sits in activation limbo indefinitely.

VCO FQDN not pre-configured: If using Zero Touch Provisioning (ZTP), the Edge needs to resolve ztp.velocloud.net (or a redirect DNS entry if the customer uses a private VCO). Confirm this is resolvable from the MPLS WAN address before the Edge is shipped.

Firewall on the MPLS blocking UDP 2426: Some carriers run stateful inspection in the MPLS core. VCMP is UDP and does not look like standard traffic. UDP 2426 must be permitted from the branch PE subnet to the PG’s underlay IP address. Also ensure ICMP is not blocked — the Edge uses ICMP probes for path quality measurement.

The 0/0 is never removed: This is the most consequential pitfall, and the one that sets up the routing disaster described in Part 3. If the temporary default route is left in the MPLS VRF indefinitely, it becomes a live risk — and if NNI filtering is absent or misconfigured, it will eventually cause a problem.

In Part 3 we turn to the NNI itself — the BGP filters that must be in place, why a 0/0 leaking from the MPLS into the Partner Gateway is dangerous, and what the VeloCloud-recommended approach to default route handling looks like in practice.