On Thu, Jun 30, 2005 at 07:56:37PM +0200, Ivo Vachkov wrote:
> > How? The hashes from the packet won't match the hashes in the table.
> > Because in the table, there would be addrsss/mask entries which are not
> > identical to the actual values in the packets.
> 
> Masks will be used. Just like it works now.

How will the hash be computed, then?

> > 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
> > dest-address criterion.
> 
> 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.

> > As the daemons (at least zebra/quagga) are modeled according to Cisco, it
> > would be interesting to know how Cisco does it.
> 
> Hmm, I'm not aware Zebra/Quagga to do any policy routing ... 

And Cisco?

Bye	Pavel