Junos OS

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

Thx!!!!

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

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!

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.

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. 

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 🙂

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.

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

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

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