[quagga-dev 11703] Re: [PATCH] zebra: Connected route addition shoudn't happen in MRIB

David Lamparter david at opensourcerouting.org
Thu Oct 30 12:42:15 GMT 2014


On Thu, Oct 30, 2014 at 01:36:32PM +0100, David Lamparter wrote:
> On Thu, Oct 30, 2014 at 10:04:58AM -0200, Everton Marques wrote:
> > On Thu, Oct 30, 2014 at 5:17 AM, Balaji G <balajig81 at gmail.com> wrote:
> > > On Thu, Oct 30, 2014 at 12:25 PM, David Lamparter <
> > > david at opensourcerouting.org> wrote:
> > >> On Thu, Oct 30, 2014 at 11:55:28AM +0530, Balaji G wrote:
> > >> > On Thu, Oct 30, 2014 at 10:40 AM, David Lamparter <
> > >> > david at opensourcerouting.org> wrote:
> > >> > > This patch was discussed on IRC between Balaji, Everton and me;  the
> > >> > > outcome was that Balaji would resend it with a switch to control the
> > >> > > behaviour.
> > >> > >
> > >> >
> > >> > I would send a V2 with that switch. do you want something "rib-lookup
> > >> > mrib". On executing this the connected routes and the RPF check is made
> > >> in
> > >> > the MRIB and executing "no rib-lookup mrib" would bring it back to URIB
> > >> > lookup and remove the connected routes. Would that be fine ?
> > >>
> > >> Hm, we have 3 cases:
> > >> 1. MRIB only
> > >> 2. MRIB first, then URIB
> > >> 3. URIB only
> > >>
> > >> Options 1. and 3. can be "emulated":
> > >> 1. = use 2. but install add "default unreachable" route to MRIB
> > >>      => URIB lookup never happens
> > >> 3. = use 2. but leave MRIB empty
> > >>      => empty MRIB doesn't get used
> > >>
> > >
> > > Thanks for the suggestion but i guess we can have two in terms of CLI.
> > > MRIB-URIB and URIB .
> > >
> > > MRIB-URIB Case:This would be with MBGP and Mroute enabled where the
> > > look-up happens at the MRIB first and then URIB. The connected routes would
> > > be installed in MRIB and URIB
> > > URIB Only- No MRIB and No routes get installed in MRIB including Connected
> > > Routes
> > > MRIB Only - Not sure if this is needed in CLI
> > >
> > 
> > I would like to know if there is a case for MRIB only as well.
> 
> MRIB-only is the fundamental, "pure" mode specified in RFC4601
> (throughout the document, no specific section - note that it doesn't
> refer to the unicast RIB *anywhere*)
> 
> What the draft specifies is:
> 
>    MRIB  Multicast Routing Information Base.  This is the multicast
>          topology table, which is typically derived from the unicast
>          routing table, or routing protocols such as Multiprotocol BGP
>          (MBGP) that carry multicast-specific topology information.
> 
> The way I understand this is that it suggests 2 variants:  use the
> unicast RIB, or use a completely separate MRIB.
> 
> Note that in particular there is no specification of how to mix MRIB and
> URIB, which to me means that that's not what's suggested here.
> 
> Allowing to mix URIB and MRIB is an extension to make things easier for
> the admin.  I'm not sure who came up with it, maybe it was Cisco.  It's
> not documented anywhere, and even within Cisco, there are different
> approaches to it.  The post you linked below:
> > BTW, I found this interesting reference on RPF lookup:
> > http://blog.ine.com/2011/07/31/understanding-static-multicast-routes/
> mentions this in the middle ("It seems that in all recent IOS version
> the linearly ordered match has been replaced with longest-match lookup
> across the mroute table.")
> 
> So... why MRIB-only?  Because URIB-only and MRIB-only are the easy to
> understand variants where you don't need to figure out which exact way
> of combining the URIB and MRIB the router is using.  A complicated
> mode is a good way unexpected things to happen...


Another note:  if I understand
https://www.juniper.net/documentation/en_US/junos12.3/topics/topic-map/mtr-multicast.html
correctly, then Juniper always uses only the MRIB.  But it's not written
very clearly to be honest, so it could be a misunderstanding on my end.


> (btw.  Which MRIB+URIB mixing variants exactly are you going with?  The
> old Cisco, the new Cisco, or something else?  Or more than one?)
> 
> 
> -David




More information about the Quagga-dev mailing list