case studies
FULL VIEW / INTERNET
IN VRF or MPLS L3VPN
Full Internet table inside a VRF on Junos MPLS L3VPN
Customer Story
Every network engineer has an opinion on this one. The Internet routing table belongs in the global table, inet.0 on Junos, the way networks have been built for thirty years. Or it belongs inside a VRF, treated as just another L3VPN service. Both camps are convinced they are right, and both are right in the correct context.
We have deployed it both ways across different customers. This post covers the reasoning, with the strongest example being one of our larger ISP customers where we migrated the network to MPLS and L3VPN and made the deliberate decision to move the full Internet table inside a VRF.
Engineering
Client: Non Disclosure
Industry: Service Provider
Services: Professional Network Services
Technologies: IP, MPLS, Juniper, Junos, BGP, L3VPN
The network and the trigger
The customer operates six edge routers, all Juniper MX480, terminating five eBGP full-view transit sessions plus several IX peerings. The chassis went through multiple upgrade cycles over the years: SCBs first, then Routing Engines, then line cards. The platform was ready for whatever design we chose.
The migration to MPLS and L3VPN was not driven by engineering preference. It was driven by the product roadmap: business customers started asking for dedicated routing tables, shared EVPL services, and Internet access delivered inside their VPNs. Once L3VPN becomes the service framework, the question follows naturally: does the Internet stay in inet.0, or does it become one more VRF?
The case for the global table
Before explaining our choice, the honest arguments for keeping Internet in inet.0.
First, if the network has no MPLS or any other tunneling layer, there is no decision to make. L3VPN requires a transport tunnel. Without one, the global table is your only option. This also brings a structural consequence: with hop-by-hop IP forwarding, every router in the path between the customer and the edge must be able to resolve Internet destinations. In practice that means a full table on every transit router, or a default route pointing toward the edge with the limitations that brings. A BGP-free core only becomes possible once you have MPLS, regardless of where the Internet table lives.
Second, simplicity. Bringing a full table operational in inet.0 is the path every engineer already knows. eBGP session up, policies applied, done. No route distinguishers, no targets, no VPN label decisions. For a smaller network without an L3VPN product portfolio, this simplicity is worth more than any flexibility argument.
The case for the VRF, and why we chose it
The deciding factor for us was route leaking.
With the Internet in inet.0 on Junos, every leak between the global table and a customer VRF means rib-groups. A rib-group is defined locally, per router. If ten routers need the leaked routes, you configure and maintain the leak on ten routers. The configuration looks like this:
set routing-instances INTERNET instance-type vrf
set routing-instances INTERNET route-distinguisher 65000:100
set routing-instances INTERNET vrf-target export target:65000:100
set routing-instances INTERNET vrf-table-label
set policy-options policy-statement CUST-A-IMPORT term INET from community RT-INTERNET
set policy-options policy-statement CUST-A-IMPORT term INET then acceptMultiply that by every VRF that needs Internet routes and every router that hosts those VRFs, and you have configuration sprawl that grows with the business.
With the Internet inside a VRF, leaking is native to the L3VPN control plane. The Internet VRF exports its routes with a route-target, and any customer VRF that needs Internet access simply imports that target:
set routing-instances INTERNET instance-type vrf
set routing-instances INTERNET route-distinguisher 65000:100
set routing-instances INTERNET vrf-target export target:65000:100
set routing-instances INTERNET vrf-table-label
set policy-options policy-statement CUST-A-IMPORT term INET from community RT-INTERNET
set policy-options policy-statement CUST-A-IMPORT term INET then accept One policy decision, distributed by BGP to every PE automatically. Selling Internet access inside a VPN becomes an import statement, not a project. When the product team asks for a new service combination, the answer is a route-target, not a maintenance window on six routers.
The cost: memory, and how to contain it
The trade is not free, and pretending otherwise would be dishonest.
The same prefix inside a VRF carries more state than in inet.0. Every VPN route is held in bgp.l3vpn.0 with the route distinguisher prepended to the NLRI, plus route-target extended communities, and then copied into the VRF table after import. With unique RDs per PE, route reflectors and PEs can hold multiple copies of the same Internet prefix. At a full table north of one million IPv4 routes, this is Routing Engine memory you budget for at design time. On the MX480s in this network, the earlier RE upgrades made this a non-issue, but it must be a conscious line item in capacity planning.
On the forwarding plane, two mechanisms contain the cost.
vrf-table-label allocates a single MPLS label per VRF instead of per prefix or per next-hop, with an IP lookup at the egress PE. For an Internet VRF this collapses the label space dramatically.
Chained composite next-hops do the same for next-hop state. Routes with different destinations share forwarding next-hop entries when the next-hop is the same, and the VPN label is held at the ingress PFE rather than multiplying rewrite strings at egress. Juniper recommends enabling it for L3VPN deployments approaching one million routes, and it improves convergence as well, since a next-hop change updates shared structures instead of rewriting state per prefix:
set routing-options forwarding-table chained-composite-next-hop ingress l3vpn
One operational warning: enabling or removing chained-composite-next-hop on the MX resets BGP sessions. This belongs in the migration design, not as a tuning change on a production PE carrying a full table.
What actually broke
After cutover, the problem was not memory and not convergence. It was the router itself, and it broke in two waves.
The root cause was the same for everything: the interfaces used as the source for the router’s own services moved into the VRF together with the Internet. The services themselves, configured at the system level, still expected to resolve and source traffic through the global table. The moment the source interfaces became VRF members, that assumption broke.
The first wave was immediate and loud. DNS resolution and NTP went down right away. The routers kept forwarding customer traffic perfectly while quietly losing their own clocks and name resolution.
The second wave was silent. A few days after the migration, we realized that flow export had stopped working as well, along with several other services tied to the same source interfaces. The flow records were being generated, but the export could no longer reach the collector. Nothing alarmed, and no error surfaced anywhere anyone was watching. The gap only became visible when someone opened the flow analyzer and found days of missing data. Flow telemetry is exactly the kind of service nobody checks until they need it, which makes it the most dangerous category in this type of migration.
There are two ways to fix this class of problem on Junos. The first is to bind each service to the routing instance explicitly, since most system services support a routing-instance option for exactly this scenario. The second is to restore reachability from the global table by pointing a default into the Internet VRF:
set routing-options static route 0.0.0.0/0 next-table INTERNET.inet.0Keep in mind that Junos does not allow mutual next-table references between two tables, so the return path needs a different mechanism.
The broader lesson: before migration, inventory every service that sources from an interface you are about to move into the VRF, and split the list into services that fail loudly and services that fail silently. DNS, NTP, RADIUS, TACACS+ will announce themselves within minutes. Flow export, syslog, SNMP traps, and streaming telemetry will not. For the silent category, verify each one explicitly after cutover instead of waiting for the absence of data to become visible on its own.
The decision framework
MPLS present but no L3VPN service portfolio and none planned: global table. The simplicity is worth it, and the BGP-free core works either way.
MPLS present and L3VPN services are the product: Internet inside a VRF. The route-target import model turns service combinations into policy statements, the memory cost is contained with vrf-table-label and chained composite next-hops, and the operational gotchas are predictable if you inventory the management plane before cutover.
We have run both designs in production. The right answer is not a religion. It is a function of what the network sells.
be our next success story!
Drop us a line! We care for your Business and are here to answer your questions 24/7