Junos
Reply
Juniper Employee
ahsoka
Posts: 26
Registered: ‎01-09-2009
0

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

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

 

Thx!!!!

Contributor
Fahad
Posts: 13
Registered: ‎07-22-2008
0

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

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) :smileyhappy:

 

Thanx

Fahad

Juniper Employee
ahsoka
Posts: 26
Registered: ‎01-09-2009

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

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!

Recognized Expert
benb
Posts: 205
Registered: ‎11-05-2007

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.

 

Regards,

Ben

Trusted Contributor
S_Clarke
Posts: 20
Registered: ‎12-04-2008
0

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

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.

Visitor
kupo
Posts: 4
Registered: ‎04-07-2009
0

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

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. 

Trusted Contributor
Posts: 54
Registered: ‎08-03-2009
0

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? 

Help :smileyhappy:

//Patrik
JNCIS-M, JNCIS-ES
System Engineer
Juniper Networks
Visitor
kupo
Posts: 4
Registered: ‎04-07-2009
0

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.

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.