Migrating to Internet-in-a-VRF Without Breaking Your Tier-1 Backbone

Getting your Trinity Audio player ready...

On a service provider backbone, that database is the Global Routing Table (GRT).

Today, most backbones force two completely different trust domains to live in the same house. The GRT holds well over a million untrusted public internet prefixes right alongside the operator’s most critical infrastructure, its loopbacks, link addresses and control-plane endpoints.

Because they share a table, reachability is inherent. The only thing keeping the internet from probing the service provider’s core is its infrastructure ACL. Tens of thousands of lines, synced across every router, forever. One wrong line exposes the core and no alarm goes off.

This architecture leaves service providers with three critical problems:

• A massive attack surface: The operator’s core sits in the same table as public routes and gains absolutely nothing from being there.
• Network-wide blast radius: A route leak or a bad config lands in the one table every router reads, hitting the whole network at once.
• Implicit policy boundaries: The line between where the internet ends and the operator’s network begins is spread across thousands of ACL lines, a nightmare to prove to an auditor and the exact opposite of what zero-trust and compliance frameworks demand.

Internet-in-a-VRF (IaV) fixes all three by design. The infrastructure isn’t actively blocked from the internet. It is simply removed from the table the internet uses. There is nothing to reach. By enforcing this structural separation, the VRF edge becomes a clean, enforceable control point. Operator misconfiguration stops being a security event.

Sounds simple, right? The goal is simple. The journey is not.

The Migration Challenge

The fix is straightforward. Give the internet its own table. It moves into a dedicated VRF with its own route distinguisher (RD), route targets (RT) and policy. The GRT goes back to doing one job, managing the operator’s own infrastructure. The GRT holds a few thousand entries. The Internet VRF holds over a million. It uses the same total memory, just separated into two secure containers.

Anyone building a greenfield network would do this on day one. But large-scale service providers are dealing with massive brownfield networks that are already carrying live traffic.

The benefits of IaV only arrive the moment the internet completely leaves the GRT. Running both tables in parallel doubles memory and delivers nothing. Half-way is not half-secure.

This means a network-wide change is needed, but it cannot happen everywhere at once. Nobody converts a national backbone overnight. Converting hundreds of edge routers across dozens of sites takes months, leaving the network in a prolonged “half-migrated” state.

In that limbo state, some edge routers keep the internet in a VRF while others still use the GRT. Every link between them is up and every router can still reach every other router. What breaks is less obvious. The two groups have started describing internet routes in entirely different formats, and neither side can read what the other sends.

• The legacy PE advertises internet prefixes as IPv4 unicast (no RD, no RT, no VPN label). The migrated PE installs this into its GRT, which is now infrastructure-only, stranding the route.
• The migrated PE advertises VPNv4 with an RD, RT and a VPN label. The legacy PE has no VRF importing that RT, so the route is discarded.

Forwarding breaks at the transport layer, too. They need a translator, something to attach the RD, RT and label going one way and strip them coming back.

Why “Option A” Fails at Tier-1 Scale

When tackling this translation problem, the industry default is usually Option A (from RFC 4364). It involves building a stitching node with a foot in both worlds (GRT on one side, Internet VRF on the other) joined by a physical cable. You run BGP across it and re-advertise everything both ways.

Because the routes cross a BGP boundary, the stitching node rewrites itself as the next hop. While Option A is great for a pilot or a single region, it fundamentally breaks down across a national Tier-1 backbone:

• It becomes a permanent data-path chokepoint. Every packet between the legacy and migrated halves must cross this physical cable. Traffic volumes change wildly during migration, making it impossible to accurately size the link.
• Massive hardware bloat. It requires a fleet of new, expensive routers. Each box must hold the internet table twice (once for each side). Every region needs one, plus a redundant partner, purely to survive the migration.
• Suboptimal routing (tromboning). Every route points to the stitch box, destroying ECMP and hot-potato routing. If two PEs are in Frankfurt but the stitch box is in Madrid, traffic trombones from Frankfurt to Madrid and back.
• Broken transport layer. The transport label is stripped and re-imposed at the box, breaking end-to-end LSPs, traffic engineering and SRv6 paths.
• A new failure domain. Taking the temporary bridge out requires another maintenance window, meaning this “temporary” choke point often becomes a permanent liability.

None of this is theoretical for us. We have worked through this list with operators running backbones of exactly this size. These operators are also moving toward an open, converged, SRv6-ready core and Option A works against all of it. So we went looking for a better answer, one built for networks of that size.

DriveNets AFX Is the Elegant Solution

Look at what the Option A box is really doing:

1. It translates routes between the two halves. (The job we actually need).
2. It forwards packets between them. (A job that only exists because the translator was built out of a router with a cable in it).

DriveNets AFX (Address Family Translator, X just sounds cooler) keeps the first job and deletes the second. It is an address-family translation function within DriveNets Network Operating System (DNOS) that acts as a boundary route reflector. A classic route reflector lives inside one address family. It cannot bridge unicast and VPN planes. AFX bridges that exact gap. It peers with the unicast plane on one side (IPv4/IPv6 unicast) and the VPN plane on the other (VPNv4/VPNv6).

Because AFX relies entirely on standard BGP with no proprietary extensions, it seamlessly connects the legacy unicast world to the secured VPN world. Translation runs automatically in both directions, entirely in the control plane:

• Into the VPN: AFX adds the RD, sets the RT and attaches the MPLS VPN label.
• Out of the VPN: AFX strips the RD and RT. For IPv6 heading toward labelled-unicast peers, it uses an implicit or explicit null label so forwarding resolves correctly.

What are the advantages of DriveNets AFX?

AFX touches the control plane, not the data path.

Because AFX preserves the next hop, traffic flows directly to the real exit router. AFX makes no best-path decisions of its own. It translates every path, keeping ECMP and multipath completely intact.

• No chokepoints. No more sizing cables, traffic tromboning and label discontinuities.
• No fleet to buy: In most deployments, AFX replaces an existing route reflector rather than adding to your footprint. Even when new nodes are deployed, they consist of a redundant pair of control-plane nodes that carry zero traffic. This means you avoid placing expensive, top-of-the-line forwarding routers in every region.
• No duplicate tables: Translation happens centrally, so no router ever has to hold the internet table twice, the fatal hardware constraint that kills most IaV projects.
• Tier-1 scale & resilience: Built on DNOS and open white-box hardware, AFX is designed to hold the full internet table across redundant route reflectors. It guarantees stability through Non-Stop Routing (NSR) and Graceful Restart, including Long-Lived Graceful Restart (LLGR), keeping the routing table stable through maintenance and failures.

Migration transparency matters, so here is how traffic behaves during the transition. During migration, each converted PE must locally leak its own routes into both the GRT and the IaV VRF. Un-migrated peers still forward traffic to it without a VPN label (resolving in the GRT), while migrated PEs reach those routes through the VRF. Keeping the local routes present in both tables guarantees reachability either way. This dual-table presence is only required for a small portion of local routes and ends entirely once the migration is complete.

Route translation between a GRT and a VRF is not new in itself, and several vendors can leak or translate routes on a PE. What we have not seen elsewhere is doing it centrally, on a route reflector, at full internet-table scale and off the data path.

Legacy vs. AFX Migration

Feature	Internet in the GRT (Legacy)	Internet-in-a-VRF with AFX
Trust domains	Internet and infrastructure share one context.	Cleanly separated into different tables.
Blast radius	A leak or attack can reach the whole network.	Contained inside the dedicated internet VRF.
Migration effort	Big-bang cutover touching every edge router.	Incremental, edge-by-edge with AFX.
Protocol	Standard BGP.	Standard BGP – no proprietary extensions.

Gradual, Safe, Reversible

The internet table does not belong in the same place as the machinery that runs your network. Agreeing on that destination was never the hard part. Surviving the migration was.

DriveNets is the change enabler for service providers. Our job is to help operators transition massive networks toward architectures that are open, converged and simpler to operate. The existing migration methods choke on a real backbone, so we built one designed around how a Tier-1 network actually runs.

AFX is the bridge that makes this transition possible. It allows Tier-1 operators to migrate at their own pace, pause at any point and roll back safely if needed. An impossible cutover becomes a controlled, scheduled evolution. Furthermore, this exact translation approach extends naturally as operators move toward SRv6, segment routing and cloud-native service edges.

Key Takeaways

• Internet-in-a-VRF improves security by separating public internet routes from critical infrastructure routes. Instead of relying on massive ACLs, it removes direct reachability and contains route leaks within a dedicated VRF.
• Migrating a Tier-1 backbone cannot happen overnight. Legacy routers advertise unicast routes while migrated routers use VPN routes, creating a prolonged transition period in which the two routing environments cannot communicate directly.
• RFC 4364 Option A translates routes by adding stitching routers to the data path. At Tier-1 scale, this creates traffic chokepoints, duplicates full internet tables, disrupts optimal routing, and introduces new hardware and failure domains.
• DriveNets AFX performs address-family translation in the control plane, converting unicast routes to VPN routes and back while preserving next hops. Traffic bypasses AFX, protecting ECMP, multipath routing, and transport continuity.
• AFX enables a gradual and reversible Internet-in-a-VRF migration. Operators can convert edge routers at their own pace, pause when needed, and maintain reachability without a big-bang cutover, chokepoints, or duplicate routing tables.

Frequently Asked Questions

How does Internet-in-a-VRF (IaV) improve Tier-1 network security over traditional GRT setups?

Internet-in-a-VRF (IaV) isolates public internet routing by moving over 1 million untrusted prefixes out of the Global Routing Table (GRT) into a dedicated VRF container. This leaves the GRT managing only a few thousand critical infrastructure endpoints, structurally eliminating direct public reachability, reducing attack surfaces, and preventing network-wide blast radius without requiring complex infrastructure ACLs.

Why is RFC 4364 Option A unsuitable for Tier-1 Internet-in-a-VRF migrations?

RFC 4364 Option A introduces physical data-path chokepoint risks, hardware bloat, and suboptimal traffic routing across Tier-1 backbones. Option A requires physical stitching routers holding duplicate 1-million-entry internet tables, rewriting next-hop addresses, breaking end-to-end SRv6 or traffic-engineering LSPs, and forcing regional traffic tromboning between sites during multi-month migration phases.

How does DriveNets AFX enable seamless Internet-in-a-VRF migration?

DriveNets AFX operates within DNOS as a control-plane boundary route reflector using standard BGP to bridge unicast and VPN planes without data-path impact. It automatically translates IPv4/IPv6 unicast routes to VPNv4/VPNv6 by adding or stripping RDs, RTs, and MPLS labels while preserving original next hops, eliminating forwarding chokepoints and hardware bloat.