Routing

We currently run our core routing in a separate routing instance. This is multiple transits and IXPs across 5 routers.

Is there any disadvantage to using a routing instance over inet.0? Juniper's documentation and AI seem to suggest not but it is difficult to get an explicit answer to that effect. We have Cisco engineers who have concerns this impacts BGP route convergence time as it would on Cisco routers.

Does anyone know of any Juniper documentation to clarify any advantages or disadvantages of routing performance in a VRF?

Our Internet/DFZ is in an MPLS VRF since 2011. Happy with that. Make use of the various MPLS LDPoRSVP / BGP_PIC / fast rerouting / rLFA stuff (MX routers).

Hello Craig

We are running our overlay network in inet.0 with separate routing instances for internet, voice, and additional services.  We ran into an issue on the ACX platform, not supporting flow-monitoring for the interfaces that reside under a non-default routing-instance.  This is tracked under RLI59340. last target release was 25.2R1-EVO

We were not able to gather flow data for customer internet traffic, because it was not in the default routing-instance.  We worked around this by gathering the flow data from other routers in the network. 

Storing Internet routes in a VRF has been a common practice among mobile operators since the introduction of 3G, where a clear separation of the internal IP routing context and the Internet (at the GI/SGi reference point) became a must. Having in mind that at that point in time most mobile carriers adopted MPLS L3 VPNs, using a separate VRF for Internet was somehow "natural" to them. Also, bear in mind that mobile Core & Edge networks (3G/4G/5G) always assume a separate entity for public Internet routing (peering & transit), which is usually referred to as Internet GateWay  (IGW), where Internet routes are stored in the default context  (inet.0), while in the mobile core they are in a VRF. IGW there typically acts as a "CE" with respect to the mobile core network which acts as a "PE". Implementations differ, though.

OTOH, storing Internet routes in the default routing context (inet.0) has been the way of doing it amongst traditional ISP/telcos, simply because in the time when they started their business there was no MPLS and there was only one routing context on the routers available - the default one (sometimes also wrongly called "GRT").

So nowadays, it's  a matter of choice, combined with the legacy and what we call technical debt.

From my broad experience, I would be able to summarize pros and cons of using a VRF for Internet routes

Advantages

• Routing security - having in mind that inet.0 is then used for IGP, this nicely isolates your IGP and label signaling  (LDP / RSVP / BGP-LU / SR)  from internal attacks in a substantial manner. And if your network uses inet.0 for management too, this is one additional reason to isolate Internet routes.
• Flexible route leaking - you can export any Internet prefix by simply tagging it with a proper RT community and it will land in the VRF having that RT on import. Much easier and clearer for your Ops teams, than having to deal with rib-groups headaches and - even worse - import-rib policies.
• Settlement free peering isolation - for networks participating in settlement-free peering arrangements it's usually necessary to limit yourself to advertising your own networks and networks of your direct BGP customers only to your external parties. Isolating those routes in a separate VRF, with the use of proper RT tagging, allows you to create a separate compartment for exposing your network to your external parties and, hence, disallowing them to smuggle their traffic through your network by setting a static default route on their side (which happened in the past, even among big players in the market, unfortunately).

Disadvantages and Caveats

• Increased RAM usage on the routers and RRs - VPNv4 prefixes stored in bgp.l3vpn.0 are 96-bit long, as opposed to IPv4 prefixes stored in inet.0 that are 3 times shorter (32-bit). With VPNv6 vs IPv6 this ratio is also significant - bgp.l3vpn-inet6.0 are 192-bit long (8 bytes RD + 16 bytes IPv6 address) compared to 128 bites of pure IPv6 prefixes. This clearly requires more RAM on your Routing Engine, but with the NG-REs being capable of storing ~30M routes this might not be such a huge issue. However ...
• Take care of RD formats - if your network uses RD Type 1 (IP:nnn - e.g. 1.2.3.4:567) and that IP address is the lo0.0 IP address of your router, you may end up in multiple copies of your full Internet routing table on your RR. Therefore, using RD Type 0 (ASN:nnn - e.g. 64509:567) is a better option in that case, ensuring that only one copy of the Internet routing table is being maintained in your network.
• Best Path Selection vs RD format - again, RD Type 1 will create multiple copies of the Internet routing table, leaving to the PE routers to select the best path, because the RRs will not be able to compare apples-to-oranges (e.g. 1.1.1.1:999:5.5.0.0/16 and 2.2.2.2.999:5.5.0.0/16 are treated by the RR as two different prefixes, while 64500:999:5.5.0.0/16 received from multiple PE routers / RR clients, are treated as one same prefix, where BGP best path selection applies). Sometimes, using RD Type 1 may be an advantage, though - it delegates the choice of the best path to the PE, as opposed to the RD Type 0 case where this choice is made by the RR. Beware of this caveat.
• After-failure convergence - if your RR serves all VPNv4 routes (Internet included), when IBGP sessions towards the RR reset (e.g. if you transition the router to the ASBR mode), your VPN customers might have to wait until the full Internet routing table loads. However, using  Constrained Route Distribution (RFC4684) - i.e. RT filtering can help you implement multi-plane RRs, clearly separating your RR sets for Internet VRF and other (non-Internet) VPN routes.

All in all, A.D. 2025 there are no real cons of storing Internet routes into a VRF. YMMV.