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

David Lamparter equinox at opensourcerouting.org
Thu Oct 30 06:55:15 GMT 2014

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

I still think we should have a switch with all 3 options, so that the
end user can change his setup (i.e. migrate between MRIB and URIB
setups) and not need to resort to table-tweaks.

Especially, if we want to support the workflow of "first prepare new
MRIB, then start using it", then the switch for "connected into MRIB"
needs to be separate from "use MRIB/URIB for RPF".

(Also, one switch doing multiple things goes against the principle of
least surprise.)


> > This is particularly relevant in cases where the multicast RIB contains
> > a default route, such that the fallback to unicast is not triggered.
> > Such a case would result in local networks not working for RPF checks
> > because connected routes are not in the MRIB.
> >
> > (Of course, all IGPs have essentially the same problem, so we need
> > controlled RIB<>MRIB route exchange and/or MT support in OSPF & IS-IS.)

More information about the Quagga-dev mailing list