Struggling with BGP VPNv4/v6 for public internet routes? Learn why this common mistake creates a routing black hole and discover three practical fixes, from the quick hack to the proper architectural solution.

BGP VPNv4/v6 for Public Internet Routes? Don’t. (But Here’s How to Fix It When Someone Does)

I still remember the 3 AM PagerDuty alert. A whole new customer PoP was dark. The monitoring showed our PE router, `pe-dal-01`, was up and receiving a full internet table from our transit provider. The customer’s CPE was peering with us just fine. We could ping from our router to theirs. But from their side? Nothing. Not a single public IP was reachable. After two hours of burning the midnight oil, we found the culprit: a well-intentioned but junior engineer had configured the BGP session with our transit provider under the `family inet-vpn` context, thinking they were being clever by keeping the “internet VRF” separate. The routes were coming in, hitting a wall, and vanishing into the ether. It’s a classic case of using the right tool for the wrong job, and it’ll get you every time.

The Root of the Problem: Apples and Oranges

Let’s get this straight. The BGP `inet` (or `ipv4-unicast`) address family and the `vpnv4` address family are fundamentally different beasts, designed for different purposes.

• `family inet` (The Global Table): This is your standard, vanilla, public internet routing. Prefixes are just prefixes (e.g., 8.8.8.0/24). It’s designed for one massive, global routing table (`inet.0` in Junos land). Simple.
• `family inet-vpn` or `vpnv4` (The L3VPN World): This is for MPLS L3VPNs. It was created to solve the problem of overlapping IP space between different customers. To do this, it bolts extra information onto each prefix:
  • Route Distinguisher (RD): A 64-bit number prepended to the IPv4 prefix to make it globally unique across the entire provider network. Customer A’s 10.0.0.0/8 is different from Customer B’s 10.0.0.0/8 because they have different RDs.
  • Route Target (RT): An extended community attribute that acts like a tag. Routers use RTs to decide which VRFs should import or export which routes. It’s the “policy” part of the puzzle.

When you configure a BGP session to accept `vpnv4` routes and you feed it standard `inet` routes from a transit provider, the router doesn’t know what to do. The incoming prefixes have no RD and no RT. The router sees the traffic, shrugs, and drops it because it has no instructions on which VRF to put it in or how to advertise it to other PE routers. You’ve successfully configured a multi-thousand-dollar packet black hole.

Fixing the Mess: Three Paths Forward

So, you’ve found yourself in this situation. Maybe you inherited it, maybe you made the mistake yourself (we’ve all been there). Here’s how to fix it, from the “get it working now” band-aid to the “do it right” architectural change.

Solution 1: The “Quick Fix” – Route Leaking

This is the classic “stitch it together” approach. It’s not pretty, but it’s fast and minimizes changes. The idea is to receive the internet routes in the correct global table (`inet.0`) and then selectively “leak” or “copy” them into the customer’s VRF.

How it works: You maintain two separate BGP configurations. One with your transit provider for `family inet`, and another for your internal `vpnv4` peering. Then, you use a mechanism like a RIB group (Junos) or `import/export map` (Cisco) to copy the routes.

Here’s a conceptual Junos example:

/* Step 1: Define the VRF */
routing-instances {
    customer-A-vrf {
        instance-type vrf;
        interface ge-0/0/1.100;
        route-distinguisher 65000:100;
        vrf-target target:65000:100;
        /* Step 3: Tell the VRF to import routes from the main table */
        vrf-import import-internet-routes-policy;
    }
}

/* Step 2: Receive internet routes normally in inet.0 */
protocols {
    bgp {
        group TRANSIT-PROVIDER {
            type external;
            peer-as 12345;
            neighbor 203.0.113.1;
        }
    }
}

/* The magic glue */
policy-options {
    policy-statement import-internet-routes-policy {
        term import-from-global {
            from {
                protocol bgp;
                /* Match routes from your global table */
                rib inet.0; 
            }
            then accept;
        }
    }
}

Darian’s Take: This is a band-aid. It works, but it gets complex fast. You’re duplicating routes in memory, and troubleshooting becomes a headache of figuring out which policy or RIB group is misconfigured. Use it to stop the bleeding, but plan for Solution 2.

Solution 2: The “Permanent Fix” – The Right Architecture

The correct way to do this is to stop trying to force internet routes into a VPN-shaped hole. Treat them as separate services. Your PE router’s primary job is to connect to the internet. Providing L3VPNs is a service it offers *on top* of that connectivity.

How it works:

1. Your BGP session with your transit provider is a standard `family inet` session into your global routing table. No VRFs involved.
2. Your customer is in their own VRF with their own `vpnv4` configuration for site-to-site connectivity.
3. To give the customer internet, you provide a default route within their VRF that points to the global table on the PE router itself. This is often done using a next-hop resolution feature or by leaking just a default route from `inet.0` into the VRF.

This keeps a clean separation of concerns. The router manages one internet table, and each customer VRF just has a “gateway of last resort” pointing to it. This is vastly more scalable and easier to manage.

Solution 3: The “Nuclear Option” – Full Internet in a VRF

Okay, so what if a customer *demands* a full internet routing table inside their own isolated VRF? Maybe they’re a managed security provider and need to apply unique policies to the entire DFZ (Default-Free Zone). In this specific, high-end scenario, you can do it, but you do it directly.

How it works: You configure the BGP session with your transit provider *inside* the customer’s VRF definition. This tells the router to build an entirely separate `inet.0` table that exists only within that routing instance (`customer-A-vrf.inet.0`).

A conceptual Cisco IOS-XR example:

router bgp 65000
 !
 vrf customer-A-vrf
  rd 65000:200
  !
  address-family ipv4 unicast
   ! This is where you import/export for L3VPN purposes
   import route-target 65000:200
   export route-target 65000:200
  !
  ! HERE is the session for the full internet table
  neighbor 203.0.113.1
   remote-as 12345
   description Full Internet Transit for Customer A
   address-family ipv4 unicast
    route-policy TRANSIT-IN in
    route-policy TRANSIT-OUT out
   !
  !
 !
!

Warning: Don’t do this lightly. You are asking your router to hold a full copy of the BGP table (900k+ routes) *per VRF*. This chews through memory (FIB/RIB) and CPU. Your hardware better be up to the task. This is a specific tool for a specific job, not a general-purpose solution.

At the end of the day, understanding the *intent* behind an address family is key. `VPNv4` is for VPNs. `inet` is for the internet. Mixing them without a clear plan is a recipe for a 3 AM outage. Choose the right architecture, keep it simple, and you’ll sleep a lot better.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions