[quagga-dev 3604] couple questions on MRIB support

Hugo Santos hsantos at av.it.pt
Mon Aug 22 03:02:09 BST 2005


Hi,

I require some input from fellow developers and specialy from Quagga's
maintainers about two points. :-)

The first envolve the redistribute table. My approach to support MRIB
envolves adding MRIB zebra command counterparts (for instance
ZEBRA_IPV6_MCAST_ROUTE_ADD) which specify the SAFI implicitly, in this
case SAFI_MULTICAST. The redistribute table in zserv (one per client) is
flagged by type only, which means that even if i'm only interested in
MRIB entries, if this interface continues, i'll get messaged about RIB
entries as well, resulting in unnecessary communication between zebra
and the daemons. My proposal would be flagging the redistribute table by
safi as well (and possibly afi too? ripd has no interest on v6 routes,
and ripngd in v4). Anyone has something against? If only safi is
settable, this would envolve new commands ZEBRA_MCAST_REDISTRIBUTE_ADD
and DELETE, with the current ones setting AFI_UNICAST only. We could
instead have new REDISTRIBUTE_{ADD,DELETE} commands which allow setting
both afi and safi, with the current ones defaulting to v4 and v6 (if
available) and AFI_UNICAST. Input?

The second point is related to zebra_rib. Currently rib_process has no
knowledge of SAFI and acts as if every route_node fed to it is
AFI_UNICAST (well, in fact it doesn't care, which makes sense since the
tables for SAFI_MULTICAST aren't even created at the moment). This must
change obviously in order to properly flag redistribute_{add,delete} to
generate the appropriate command (unicast vs multicast) as well as to
zebra_install_kernel work properly (i.e. don't install multicast routes
into RIB). I'm guessing the only place to feed the safi is into
zebra_queue_node_t, anything against? Finally, while there is MRIB
support for v4 in Linux (only an example), there is none for IPv6, so
the routes can't be installed into the kernel (so we'll call
zebra_install_kernel for unicast only). This is a limitation that exists
right now but the MRIB entries are still useful in Quagga to be
redistributed to other daemons (via rib_process) which might be
interested in them (which is my case) and for nexthop lookups.

As always, any input is welcome.

Thanks,
Hugo Santos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20050822/8a4347f7/attachment-0001.sig>


More information about the Quagga-dev mailing list