42 comments on “RIB Group Confusion

  1. Very good article ! Indeed, I’ve seen the source/destination explanation in sooo many places and though I knew it’s not the correct one, it seems it was easier for people to understand it (or to explain it) !

  2. Hi Jeff,

    Nice article.But i don’t understand the need to import the route from one table to a custom made table.and in the case of vrf we can achieve this by extraneting the vrfs.i find this feature redundant.correct me if i am wrong.

    • I think I mention somewhere in the article that importing routes into inet.51 is just something I am doing for demonstration purposes only. It doesn’t actually do anything. One of the biggest use cases for RIB groups is getting routes into inet.2 for multicast RPF, which I am writing an article about. As for VRFs, auto-export is the more common way to do this, but RIB groups are another option. Redundant? Oh, there are a lot of redundant features in Junos, IOS, or any other vendor’s platform. At least a good understanding of the concepts will help you decode any RIB group examples you come across in documentation. Thanks!

  3. Jeff,

    by redundant i meant “options” to achieve the same results.Anyway,looking forward to the multicast use case.

  4. This is an excellently written article. I’ve been puzzled by rib-groups for sometime. I’ve also been puzzled by most *all* of Juniper’s documentation. They haven’t learned to use metaphors, or language well like the folks over on “the other side.”

    I’ll be looking for more articles!

    Ryan

    • Thanks, Ryan, and I agree. I think we are making improvements in this area, which is why I intend to focus my articles on less prominent features. As a double CCIE and former Cisco TAC employee, I have a lot of experience with the “other side”, and I am consistently impressed with the power of Junos–when I can figure it out. I hope to help both externally by continuing to post these articles, and internally by working with the business to push more human-friendly documentation. I’m a bit backlogged right now with work, but keep an eye out for a few more articles in the pipeline!

  5. nice job!!

    now i want to ask you what i have to do if i want to share vrf.inet to inet-0?
    basically is the opposite from inet.0 to vrf.inet.0…

  6. Hi Jeff,
    Thanks for the wonderful article. I am new to JunOS and was trying to implement Filter Based Routing using the EX4600 series switch. I was really amazed at how they did not have the “next-hop” option to define the action for the filters. However, the only useful option I could find was “routing-instance”. So inevitably I was dragged into this “RIB Group” related configs. Please let me know if we can discuss about this further if possible.

    Regards,
    Yash

  7. Nice and its wonderful article, specially for explanation/clarification on source & destination concept of RIBs.

    Thanks

    Muhammad Saleem

  8. Best explanation ever, Juniper should hire you as their technical writer. I have worked with many technical writers in the past, I have no idea how they got their jobs, they don’t know sh*t about technology and specific features, yet they can come out a lengthy documentation, contents seem mostly correct, but absolutely useless.

  9. How is it possible to solve such task as if i have 2 static route (e.x. 2.2.2.2/32 next-hop 100.0.0.1 and 3.3.3.3/32 next-hop 100.0.0.1) and i would like to install static route 2.2.2.2 to rib-group A and static route 3.3.3.3 to rib-group B. How i can solve this task?

    • Well, I now work for Cisco and am not doing much Juniper stuff, and I no longer have access to Juniper gear to test with. But that said, I think I pretty much cover this scenario in the article, i.e., installing static routes in RIB groups. If you don’t want the routes to appear in both RIB groups I seem to remember there being an option to filter, but I can’t recall how it works just now.

    • yup mate , it bloody took me 3 hrs but here it is .

      lab@vmx-R5# run show route 3.3.3.3/32
      3.3.3.3/32 *[Static/5] 00:02:46
      Reject
      lab@vmx-R5# run show route 2.2.2.2/32
      2.2.2.2/32 *[Static/5] 00:02:42
      Reject

      set routing-options rib-groups test02 import-rib inet.0
      set routing-options rib-groups test02 import-rib test02.inet.0
      set routing-options rib-groups test02 import-rib test03.inet.0
      set routing-options rib-groups test02 import-policy test02-03

      [edit policy-options policy-statement test02-03]
      lab@vmx-R5# show | display set
      set policy-options policy-statement test02-03 term 1 from protocol static
      set policy-options policy-statement test02-03 term 1 from protocol bgp
      set policy-options policy-statement test02-03 term 1 from protocol isis
      set policy-options policy-statement test02-03 term 1 from protocol ospf
      set policy-options policy-statement test02-03 term 1 from protocol direct
      set policy-options policy-statement test02-03 term 1 from protocol local
      set policy-options policy-statement test02-03 term 1 then next term
      set policy-options policy-statement test02-03 term 2 from protocol static
      set policy-options policy-statement test02-03 term 2 from route-filter 2.2.2.2/32 exact
      set policy-options policy-statement test02-03 term 2 to rib test02.inet.0
      set policy-options policy-statement test02-03 term 2 then accept
      set policy-options policy-statement test02-03 term 3 from route-filter 3.3.3.3/32 exact
      set policy-options policy-statement test02-03 term 3 to rib test03.inet.0
      set policy-options policy-statement test02-03 term 3 then accept
      set policy-options policy-statement test02-03 term last then reject

      lab@vmx-R5# run show route table test02.inet.0

      test02.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
      + = Active Route, – = Last Active, * = Both

      2.2.2.2/32 *[Static/5] 00:00:04
      Reject
      10.10.10.10/32 *[Direct/0] 05:35:41
      > via lo0.100

      [edit]
      lab@vmx-R5# run show route table test03.inet.0

      test03.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
      + = Active Route, – = Last Active, * = Both

      3.3.3.3/32 *[Static/5] 00:00:06
      Reject
      20.20.20.20/32 *[Direct/0] 05:35:43
      > via lo0.103

      • lab@vmx-R5# run show configuration routing-instances test02 | display set
        set routing-instances test02 instance-type virtual-router
        set routing-instances test02 interface lo0.100

        [edit]
        lab@vmx-R5# run show configuration routing-instances test03 | display set
        set routing-instances test03 instance-type virtual-router
        set routing-instances test03 interface lo0.103

        [edit]
        lab@vmx-R5# show interfaces lo0.100
        family inet {
        address 10.10.10.10/32;
        }

        [edit]
        lab@vmx-R5# show interfaces lo0.103
        family inet {
        address 20.20.20.20/32;
        }

  10. Hi Jeff,

    Thank you very much for the post. Its been very useful to me. I have actually implemented this RIB group concept before, but I didn’t have a very clear idea about it. One of the commonly used application of this route leaking feature between VRF is called FBF or filter based forwarding which is equivalent to the policy based routing feature in cisco.

    I really appreciate it.

    Thank you !

  11. Hello Jeff,

    It’s a nice post, however maybe you can help me a little bit. I would like to import all the static route from the default instance routing to another instance routing without the default route (0.0.0.0/0).

    I tried to import with some argument or delete this specific route after importing but it’s not working,..

    Thank you in advance !

    • Thanks. I’m glad this post still has life! Unfortunately I haven been gone from Juniper for a year and I’m getting rusty. I also don’t have access to the gear any more. I think you can use the static route syntax as in the article and add a policy to it, but I can’t give the details.

  12. Excellent article, many thanks to it. I have working dense with Juniper 8+ years, and rib-groups are still confusing at some cases.
    Special thanks for explanation of export-rib

  13. Excellent article on rib-groups i’ve read thus far. Can you please help who how can we filter the static routes being imported from inet.0 to routing instance(Virtual Router)? I’ve looked into almost everywhere, still out of luck.

    • Thanks. I’m afraid I can’t help. I’ve been out of Juniper for a while now and have forgotten quite a lot, and don’t have access to Junos any more.

    • I believe you can do that by putting an import policy on the rib group that takes routes from inet.0 to your routing instance. In your policy statement only allow the routes you want to block the rest.

  14. I think I’ve wrapped my head around the ‘export-rib’ use-case.

    Unlike “import-ribs” which allow us to share routes from one instance into another instance, “export-rib” is when you are wanting to share routes that reside within a non-default (user-defined) routing-instance INTO a dynamic-routing-protocol to share with neighbors.

    So say you are R1 with BGP (or whatever dynamic routing protocol) running on inet.0 over to a neighboring router.

    If R1 contains another user-defined routing-instance, say we call it ‘blue.inet.0’ with some static routes or whatever protocol (direct/static/RIP), you can export from blue.inet.0 into BGP to be shared with the neighbor.

    • Correction to my lost post:

      After further review, I was sorely mistaken.

      An export-rib is when you are exporting any route(s) from ANY routing-instance INTO a dynamic-routing-protocol to be shared with a neighbor – period.

      Thus “import-ribs” are when sharing routes from one routing-instance into another routing-instance.

      Export-ribs are when sharing routes from one routing-instance into a dynamic-routing protocol to be sent to a neighbor.

      • It really amazes me that a blog post from 2014 is still of interest in 2021. It just shows how confusing and poorly explained RIB groups are, even today. Unfortunately, since I left Juniper in 2015 and have been a management/director-type for the last five years, I really couldn’t answer that question anymore. I’d need to get my hands on some Junos gear and spend some time re-acquainting myself with my own explanation. Given that I work for Cisco now, it’s probably not where I’m going to spend my time. But best of luck to you in coming to terms with the notorious RIB Groups!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.