Junos OS

Expand all | Collapse all

why use inet.2 rather than inet.0 for RPF?

  • 1.  why use inet.2 rather than inet.0 for RPF?

    Posted 01-18-2009 13:15

    Could you provide an example of when I would want/need to use inet.2 rather than inet.0 for RPF?

     

    Thx!!!!



  • 2.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 01-18-2009 23:22

    Hi

    A Juniper router has the ability to use any operational routing table as the multicast RPF
    table. The only real requirement is that the selected table contain IP unicast routing information.
    However, the JUNOS software has set aside the inet.2 routing table for RPF usage, most administrators use this table in place of inet.0

     The inet.2 routing table already exists on the router, so we only need to populate it with routing
    knowledge for it to appear in the output.

     e.g 

    The administrators of  two AS networks have decided to use the
    inet.2 routing table for RPF checks. The first step in this process is copying the local routes
    into this table by using a rib-group. Much like a routing policy, the rib-group is given a name
    in the configuration and is supplied the tables into which the routes should be placed. The dubai router currently has a rib-group called populate-inet2, which contains an import-rib statement. The rib-group lists both inet.0 and inet.2 as tables where it can place routing information. The configuration currently appears as so:
    user@dubai> show configuration routing-options

     

    interface-routes {
    rib-group inet populate-inet2;
    }
    rib-groups {
    populate-inet2 {
    import-rib [ inet.0 inet.2 ];
    }
    autonomous-system 65001

     

    user@dubai> show route 10.x.x.x terse table inet.2

     

    (You can also concern with JNCIS study guide page 433 to 437) 🙂

     

    Thanx

    Fahad



  • 3.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 01-19-2009 06:08

    Cool! That a great explanation but if you don't mind let me ask you this: why would you go through all this extra work if RPF can be performed with inet.0?


    Thanks Fahad!



  • 4.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 01-20-2009 22:39

    A lot of folks don't bother to go through this "pain" and just keep everything in inet.0 - this makes things easier to understand too.

    It's all about choice I guess.



  • 5.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 08-26-2009 07:42

    I'm a bit late on this reply but if you have an mpls network where multicast traffic isn't supported ove LSP tunnels, then this is where

    you will need to force RPF to use a separate topology other then inet.0.  Inet.2 will contain your native IGP/Interface routes which then RPF could operate. 



  • 6.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 08-26-2009 07:51

    Nothing is in inet.2 native except as earlier stated MBGP routes. If you want something in there you need to use rib groups to "copy" data there, for eaxmple IGP routes and directly connected networks.

     

    So if you need RPF check and unicast is handled by MPLS and multicast is native... dont I still tell PIM tell what table I do RPF checks? So if I kept IGP routes and interface routes in inet.0 as Sean stated, wont that be enough? Or is it the case that the source and RPC path is only reachbale via a LSP? And then I am still confused why it would help to have IGP and interfaces in inet.2? Wouldnt it make sense to copy whatever data to inet.0 as well ass inet.2 for RPF? 

    Help 🙂



  • 7.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 01-06-2011 11:00

    What I meant in my original post is that native mcast will never use lsp hence you have tell pim to use inet.2.  What I didn't mention was the specifics that you have to of course dump your interface/igp/bgp routes into inet.2 also.



  • 8.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 12-18-2018 19:20

    some times we need different data flow path between unicast and mulicast 



  • 9.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 01-20-2009 10:31

    In short, it allows the operator to have a control-plane for multicast, that is independent of the normal unicast routing table.  Here are some specific examples.

     

    If multicast routes are exchanged via MBGP (AF1/SAFI 2) or multi-topology IS-IS, they are placed in inet.2 by default

     

    Using inet.2 also allows for rib-group import policies.  If, for example, you wanted to filter the routes that get installed in inet.2.

     

    Some networks use traffic-engineering or have the igp configured for shortcuts.  In that case, you have LSP next-hops installed inet.2.  These are not valid for RPF check.  The alternative, is to have the IGP install the routes with non-MPLS next-hops into inet.2 table.

     

    Regards,

    Ben



  • 10.  RE: why use inet.2 rather than inet.0 for RPF?

    Posted 04-09-2020 12:46

    Also, you can use inet.2 if you want your multicast traffic take a different path than the unicast in the network.
    Use inet.2 if you must have a separated topology for multicast. It required RIB groups

    Capture.PNG