VeloCloud SD-WAN and Partner Gateways Part 3: Taming the Default Route at the NNI

29 May 2026 VeloCloudArista

Parts 1 and 2 established the architecture and walked through the onboarding sequence. We ended with a warning: the temporary default route (0/0) injected into the MPLS VRF during onboarding must not be left in place indefinitely, and it must never be allowed to leak across the NNI into the Partner Gateway.

This part explains why, in detail. It covers the failure modes a leaked default route causes, how to filter it at the NNI using BGP policy, what the VeloCloud best practice for default route handling actually is, and how to validate that your NNI filters are working.

Why a 0/0 from the MPLS Is Dangerous at the PG

The Partner Gateway runs two distinct routing tables:

  • Underlay routing table: routes learned from the NNI BGP peering, used to reach MPLS sites and to forward returning traffic back across the NNI. This is standard IP routing.
  • Overlay routing table: routes learned from the SD-WAN control plane (VCO), representing the SD-WAN fabric. The PG uses this to forward traffic within the overlay.

These two tables are logically separate. The PG keeps underlay and overlay routing isolated by design. But the underlay routing table still matters — it is used for the PG’s own control-plane reachability, for VCMP tunnel source/destination resolution, and (depending on the PG implementation) for any traffic that needs to be forwarded natively rather than via the overlay.

If the MPLS injects a 0/0 into the NNI BGP session, the PG installs it in its underlay routing table. Now the PG has a default route pointing back into the MPLS fabric. This creates several failure modes:

Failure Mode 1 — Routing Loops

The PG is supposed to be an internet exit point for SD-WAN traffic. It has its own internet link. When branch internet traffic arrives over VCMP, the PG decapsulates it and needs to route it to the internet. If the underlay routing table has a 0/0 pointing toward the MPLS (via the NNI), and the PG’s internet link is down or not preferred for some reason, the PG may forward internet-destined traffic back across the NNI into the MPLS fabric.

The MPLS fabric now receives internet-destined traffic from the PG. What does the MPLS do with it? It looks up its routing table. If the MPLS VRF still has a 0/0 pointing to the carrier’s internet gateway, the traffic might reach the internet via a completely unintended path. If the MPLS VRF has no default route, the traffic is dropped. Either way, the intended SD-WAN internet exit path is broken.

In the worst case, the MPLS internet gateway also has a route back toward the PG, and you get a forwarding loop between the MPLS and the PG — each forwarding packets to the other indefinitely until TTL expires.

Failure Mode 2 — Asymmetric Routing

Even if a loop doesn’t form, a 0/0 from the MPLS can cause asymmetric routing — outbound traffic leaving via the PG’s internet link, return traffic arriving via the MPLS and the carrier’s internet gateway. This breaks stateful inspection (firewalls, NAT), causes TCP session failures, and is extremely difficult to diagnose because the two paths may work independently but fail in combination.

Failure Mode 3 — Blackholing

If the carrier’s internet gateway (the next-hop of the MPLS 0/0) is not reachable from the PG’s perspective, traffic following that default route gets blackholed silently. Internet traffic from SD-WAN branches works when the PG routes it via its own internet link, but fails for any traffic that inadvertently follows the leaked MPLS default.

Failure Mode 4 — Management Plane Disruption

The PG itself needs to reach the VCO and other VeloCloud infrastructure. This management traffic goes over the internet. If the PG’s underlay default route points toward the MPLS rather than the PG’s own internet link, VCO connectivity from the PG may break — the PG’s management sessions try to reach the internet via the MPLS, which may or may not reach the internet, and may introduce latency or asymmetry that kills the TCP sessions. A PG that loses VCO connectivity cannot update its overlay routing table or enforce policy.

The NNI BGP Filter — Blocking 0/0 Inbound

The fix is straightforward: configure an inbound BGP prefix filter on the NNI session that explicitly denies 0/0. The filter sits on the Partner Gateway’s NNI-facing BGP neighbour configuration and drops 0/0 from the MPLS before it is installed in the underlay routing table.

This is not a matter of hoping the carrier won’t advertise 0/0. It is a hard filter that ensures 0/0 cannot be installed regardless of what the carrier sends.

Here is what this looks like in practice. The exact syntax varies by the PG’s underlying OS, but the logic is universal.

Example: Cisco IOS-XE Style (Common on Carrier PE / Route Reflectors)

If you are configuring the filter on the MPLS PE side (preventing advertisement of 0/0 toward the PG):

ip prefix-list BLOCK-DEFAULT seq 5 deny 0.0.0.0/0
ip prefix-list BLOCK-DEFAULT seq 10 permit 0.0.0.0/0 le 32

route-map TO-PARTNER-GATEWAY permit 10
 match ip address prefix-list BLOCK-DEFAULT

router bgp 65001
 neighbor 198.51.100.1 remote-as 65100
 neighbor 198.51.100.1 route-map TO-PARTNER-GATEWAY out

If you are configuring the filter on the PG side (preventing installation of 0/0 received from the MPLS):

ip prefix-list DENY-DEFAULT-FROM-MPLS seq 5 deny 0.0.0.0/0
ip prefix-list DENY-DEFAULT-FROM-MPLS seq 10 permit 0.0.0.0/0 le 32

route-map FROM-MPLS-NNI permit 10
 match ip address prefix-list DENY-DEFAULT-FROM-MPLS

router bgp 65100
 neighbor 198.51.100.2 remote-as 65001
 neighbor 198.51.100.2 route-map FROM-MPLS-NNI in

The inbound filter on the PG is the belt-and-braces defence. Even if the carrier makes a configuration mistake and advertises 0/0, the PG will not install it.

Example: Junos Style

On a Junos-based PE or PG:

policy-options {
    prefix-list DEFAULT-ROUTE {
        0.0.0.0/0;
    }
    policy-statement BLOCK-DEFAULT-FROM-MPLS {
        term deny-default {
            from {
                prefix-list DEFAULT-ROUTE;
            }
            then reject;
        }
        term permit-rest {
            then accept;
        }
    }
}

protocols {
    bgp {
        group NNI-TO-PARTNER-GW {
            neighbor 198.51.100.1 {
                import BLOCK-DEFAULT-FROM-MPLS;
            }
        }
    }
}

The import policy applies to routes received from the neighbour — exactly the inbound filter we need.

Best Practice: The Right Direction for Default Routes

VeloCloud’s best practice model for default route handling at the NNI is clear:

The default route (0/0) is a PG-to-MPLS advertisement, not an MPLS-to-PG advertisement.

The PG advertises 0/0 toward the MPLS. This tells branch PEs: “send your internet traffic to me.” Branch Edges receive this default via the overlay (not the underlay), encapsulate internet traffic in VCMP, and send it to the PG. The PG is the internet exit.

The MPLS should never advertise 0/0 toward the PG. The PG does not need a default pointing into the MPLS — it has its own internet link for outbound traffic, and it reaches MPLS sites via specific prefixes learned from the NNI BGP session.

Correct:

  Partner Gateway ──── 0/0 ────► MPLS (toward branches)
                                  (PG is the internet exit for branches)

  MPLS ──── specific prefixes ──► Partner Gateway
            (10.10.1.0/24, etc.)  (PG knows how to reach MPLS sites)

Incorrect:

  Partner Gateway ◄─── 0/0 ──── MPLS
                                  (creates routing loops, asymmetry)

What the PG Should Receive from the NNI

The NNI inbound filter on the PG should permit only the customer’s specific site prefixes — the actual LAN ranges used in the MPLS fabric. A well-designed NNI filter might look like:

Permit:
  10.10.0.0/16 le 24    (customer site LAN ranges)
  172.16.0.0/12 le 24   (data centre ranges)
  [any other known customer prefixes]

Deny:
  0.0.0.0/0             (explicit: no default)
  [RFC 1918 ranges not used by the customer]
  [bogon prefixes]

The “permit specific, deny everything else” approach is cleaner than “permit everything, deny 0/0.” It limits what the MPLS can inject into the PG’s routing table to exactly what is expected, and nothing more.

What the PG Should Advertise Toward the MPLS (NNI Outbound)

Outbound from the PG toward the MPLS, the filter should control what the branches see as reachable via the PG. Typically:

Permit:
  0.0.0.0/0             (default route: internet exit via PG)
  [SD-WAN overlay aggregates, if the MPLS needs to reach non-MPLS SD-WAN sites]

Deny:
  [anything else — the PG's management prefixes, etc., should not leak into the MPLS]

The 0/0 advertised by the PG into the MPLS is installed in the branch PE VRF routing tables. It tells the PE: “for any unknown destination, send traffic toward the PG.” This is how internet traffic from the branch PE itself (not the Edge — think PE-originated management traffic if any) would reach the internet. More commonly, this 0/0 is what the Edge sees in the MPLS routing table and uses as a last-resort path — but as we discussed in Part 2, the Edge in production routes internet traffic via the overlay, not natively via the MPLS underlay.

Handling the Transition Period

There is a window during onboarding when the correct filters may not yet be in place — because the carrier is providing a temporary 0/0, and the NNI BGP session may not be active yet (since the PG won’t have the NNI configured until the site is being provisioned).

The safest sequencing:

  1. Configure NNI BGP filters before bringing up the NNI BGP session. Apply the inbound filter that blocks 0/0 on the PG side before the BGP session is established with the carrier. This way, even if the carrier has already injected 0/0 into the VRF, the PG never installs it.
  2. Validate the filters are active by checking the PG’s BGP received routes versus installed routes. You should see 0/0 in the “received” table (if the carrier is advertising it) but not in the “accepted/installed” table.
  3. Remove the carrier’s 0/0 from the MPLS VRF after the Edge is onboarded and validated (see Part 2’s recommended onboarding window).

Validating Your NNI Filters

After configuring the filters, verify them explicitly. Do not assume they are working:

On the PG (or the equivalent route reflector / looking glass):

# Cisco IOS-XE
show bgp ipv4 unicast neighbor 198.51.100.2 received-routes | include 0.0.0.0
show bgp ipv4 unicast neighbor 198.51.100.2 routes | include 0.0.0.0

The first command shows what the neighbour has advertised. The second shows what has been accepted and installed. If the filter is working, 0.0.0.0/0 appears in received-routes but not in routes.

Check the underlay routing table on the PG:

show ip route 0.0.0.0

If this returns a route learned from the NNI neighbour, your filter is not working. If it returns the PG’s own internet default (from the PG’s upstream ISP), you are good.

On the MPLS PE (NNI side):

show bgp vpnv4 unicast vrf CUSTOMER-A neighbors 198.51.100.1 advertised-routes | include 0.0.0.0

This confirms whether the PE is advertising 0/0 toward the PG. Even if your PG filter is correct, it is good practice to confirm the PE is not sending it — belt and braces.

A Common Misconception: “The Edge Will Handle It”

A misconception that occasionally surfaces is that the Edge’s routing intelligence will protect against a leaked default route at the PG. The argument goes: the Edge applies SD-WAN policy, so even if the underlay routing at the PG is wrong, the overlay will route correctly.

This is only partially true. The Edge’s policy engine controls overlay traffic — traffic inside the VCMP tunnel. But the PG’s underlay routing affects what happens after the tunnel is terminated. If the PG has a bad underlay default route, traffic that exits the overlay at the PG can be forwarded incorrectly before the Edge’s policy has any further influence. The Edge cannot save you from a routing loop at the PG — it has already handed the packet off.

Summary: The NNI Rules

To close out this series, here are the NNI rules that should be treated as non-negotiable on every VeloCloud Partner Gateway deployment:

Rule 1: Block 0/0 inbound from the MPLS at the NNI — always. Apply an explicit inbound BGP prefix filter on the PG’s NNI BGP neighbour that denies 0/0. Configure this before the BGP session comes up.

Rule 2: Permit only known customer prefixes inbound. Use a positive permit list for the specific IP ranges used in the MPLS fabric. Do not use a catch-all permit.

Rule 3: The PG advertises 0/0 toward the MPLS, not the other way around. The PG is the internet exit. The default route flows from PG toward branches, not from MPLS toward PG.

Rule 4: Withdraw the carrier’s temporary 0/0 after onboarding is complete. Do not leave the onboarding default route in the MPLS VRF indefinitely. Validate that traffic flows correctly without it, then remove it.

Rule 5: Validate your filters explicitly. Check received-routes versus installed routes. Check the PG’s underlay routing table. Do not assume the filters are working because they were configured.

Rule 6: Apply filters on both sides. The PG should filter inbound from the MPLS. The MPLS PE should also filter outbound toward the PG. Belt and braces — one filter may be misconfigured, miscommunicated, or overridden during a carrier maintenance window.

Following these rules gives you a clean separation between the MPLS underlay and the SD-WAN overlay, predictable internet routing, and a PG that is immune to the most common class of underlay routing accidents.