Routing

 View Only
last person joined: yesterday 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
Back to discussions
Expand all | Collapse all

Global Routing Table in a VRF

  • 1.  Global Routing Table in a VRF

    Posted 04-09-2025 04:51

    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?



    ------------------------------
    CRAIG MOSCARDINI
    ------------------------------


  • 2.  RE: Global Routing Table in a VRF

    Posted 04-10-2025 10:26

    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).



    ------------------------------
    Olivier Benghozi
    ------------------------------

    Original Message


  • 3.  RE: Global Routing Table in a VRF

    Posted 04-11-2025 13:47

    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. 



    ------------------------------
    JAMES SERBOUSEK
    ------------------------------

    Original Message


  • 4.  RE: Global Routing Table in a VRF

    Posted 05-02-2025 07:32

    Thank you everyone for the input. It seems clear as expected this is more of a personal preference issue than a technical limitation. It has however been useful to see some of the pros and cons that other people have experienced with the different setups.



    ------------------------------
    CRAIG MOSCARDINI
    ------------------------------

    Original Message


  • 5.  RE: Global Routing Table in a VRF

    Posted 05-05-2025 09:32

    The only real pain I have noticed is that some show commands don't work the way you expect them to, if they work at all.  The specific example I have right now is "show route advertising/receive-protocol for any VRF that is NOT inet.0.



    ------------------------------
    CRAIG DALRYMPLE
    ------------------------------

    Original Message


  • 6.  RE: Global Routing Table in a VRF

    Posted 05-06-2025 04:20

    I live with multiple routing instances with VPNv4 and EVPN families all day every day and haven't found any commands that don't work

    For example:

    > show route receive-protocol bgp <neighbour> table <vrf>.inet.0

    <vrf>.inet.0: 9403 destinations, 18360 routes (8141 active, 1 holddown, 2020 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    @ <prefix>                <nexthop>                    140        65161 65462 65139 65143 65486 I
                              <nexthop>                    140        65161 65462 65139 65143 65486 I
      <prefix>                <nexthop>                    100        I
    ...

    Does this syntax not work for you?

    Scott



    ------------------------------
    SCOTT AITKEN
    ------------------------------

    Original Message


  • 7.  RE: Global Routing Table in a VRF

    Posted 05-06-2025 10:16

    It does for BGP, but that appears to be working because BGP is configured on the default routing instance.  In my case, I am stopped at the <protocol> part of the command, likely because OSPF is NOT configured on the default instance.

    cdalrymple@CMC-SW-Spine-1> show route receive-protocol bgp 10.111.111.1 table CHS.inet.0

    CHS.inet.0: 487 destinations, 784 routes (487 active, 0 holddown, 0 hidden)

    {master}
    cdalrymple@CMC-SW-Spine-1>

    cdalrymple@CMC-SW-Spine-1> show route receive-protocol ospf
                                                           ^
    syntax error, expecting <attribute-name>, <flag-value>, or <attribute-value>.
    cdalrymple@CMC-SW-Spine-1> show route receive-protocol ?
    Possible completions:
      bgp                  Border Gateway Protocol
      msdp                 Multicast Source Discovery Protocol
      pim                  Protocol Independent Multicast
      rip                  Routing Information Protocol
      ripng                Routing Information Protocol for IPv6
    {master}
    cdalrymple@CMC-SW-Spine-1> show route receive-protocol

    I should also mention that our shop insists on using Mist Wired Assurance, so the problem here could be with how that tool sets up global level routing.



    ------------------------------
    CRAIG DALRYMPLE
    ------------------------------

    Original Message


  • 8.  RE: Global Routing Table in a VRF

    Posted 05-06-2025 14:08

    OSPF doesn't send or receive routes so receive/advertising-protocol for OSPF won't work on any table.

    The routers flood LSAs in the area. You'll also notice IS-IS is missing from the list for the same reason.

    You most likely want to be poking about in the OSPF database where the commands take an instance VRFNameoption.

    So if you wanted to see what LSAs another router in the area is originating then:

    show ospf database advertising-router <OSPF RID of some other router> instance YourVRF

    To see what what routes OSPF came up with when solving SPF for the area then you can just check RIB for the protocol:

    show route protocol ospf table YouVRF.inet.0



    ------------------------------
    STUART RIDSDALE
    ------------------------------

    Original Message


  • 9.  RE: Global Routing Table in a VRF

    Posted 05-07-2025 02:38
    Edited by Sheetanshu 05-07-2025 04:06

    Hi Craig,

    As discussed in the thread you raised (thread link), the receive-protocol command is not valid for OSPF, regardless of the routing instance configuration.

    Mist Wired Assurance does not restrict the use of show commands on the switches.

    Regards



    ------------------------------
    Sheetanshu Shekhar
    ------------------------------

    Original Message


  • 10.  RE: Global Routing Table in a VRF

    Posted 05-07-2025 09:06

    I never meant to insinuate that it didn't.  My point was that MWA may not be configuring a global OSPF instance, which makes sense as it is not needed in this use case.  

    Stuart Ridsdale nailed my issue -- well sort of. After many years of working in a BGP only shop I am having to remind myself of some of the differences between OSPF and just about everything else. You can't look for something that doesn't happen.



    ------------------------------
    CRAIG DALRYMPLE
    ------------------------------

    Original Message


  • 11.  RE: Global Routing Table in a VRF

    Posted 04-14-2025 05:48

    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.



    ------------------------------
    Berislav Todorovic
    ------------------------------

    Original Message