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

A Juniper router has the ability to use any operational routing table as the multicast RPFtable. 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 routingknowledge for it to appear in the output.

e.g

The administrators of two AS networks have decided to use theinet.2 routing table for RPF checks. The first step in this process is copying the local routesinto this table by using a rib-group. Much like a routing policy, the rib-group is given a namein 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

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

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.

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

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?

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

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.