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

David Lamparter equinox at opensourcerouting.org
Thu Oct 30 12:36:32 GMT 2014


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...

(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