Subject: Re: Policy Routing
To: Ivo Vachkov <email@example.com>
From: Vincent Jardin <firstname.lastname@example.org>
Date: 07/01/2005 00:07:16
>>>>Also, if you embed all the criteria in one routing table, how will you
>>>>learn dynamic routing daemons (ospfd et al.) to add the
>>>>source/protocol/TOS fields you need to the transient entries that they
>>>>create in the FIB? Because now routing daemons know only about the
>>>This is Quagga/Zebra developers problem :) Btw - since they support
>>>Linux multiple routing tables it should be no harm to support NetBSD's
>>>way ... it's just another #ifdef :)
>>But how they should it? The Linux way with multiple routing tables seem
>>straightforward to support, but I don't see how the OSPFD configuration
>>would look with your scheme.
It is not 100% exact. Some modifications are required in order to have
the support of many kernel FIB with Quagga. In fact, this patch was
already done a long time ago on FreeBSD 4 thanks to a setsockopt on the
routing socket in order to associate the routing table to a specific
index, and the interfaces to the same index. Then, when you start the
zebra daemon, you have to provide the FIB index.
It is described by:
However, even if this paper starts many zebra daemon, it is easy to
modify Quagga in order to have a single zebra daemon which supports many
RIB: one RIB for each VPN id.