Requesting comments on Multi-routing table usage

Ian Smith smithi at
Thu Jul 17 17:54:54 UTC 2008

On Thu, 17 Jul 2008, Julian Elischer wrote:
 > The current code in -current will add a new interface to all
 > FIBs.

Consider yanking/reinserting cardbus NICs as one source of fun.

 > So for example when you add a gre interface irt shows up everywhere.
 > This behaviour is probbaly correct for the base NICs on the system 
 > when you boot, but it is probably wrong in other cases.
 > For example, when mpd makes tunnels it probably
 > (but not always) wants to add that set of routes into one
 > FIB. Similarly for other apps that can create tunnels.
 > What is needed is a way to allow the caller to somehow
 > specify the behaviour wanted whenever new interfaces are added.
 > various things crossed my minds..

I'm of two minds myself .. but you seem to have lots more :)

 > -------------
 > Maybe real hardware shoudl go everywhere and virtual should go to
 > the FIB of the creator
 > Maybe P2P interfaces should not go everywhere.
 > Maybe a sysctl can be used to 'flip' teh mode from "everywhere"
 > to "specific fib" after boot has completed. (I have code for this but 
 > it's not the perfect solution).

Yes in addition to 'setfib N command' it would be likely useful to have
a more global 'setfibto' type command, so you could run whole scripts or
shells in a known fib context, to which scripts etc could be oblivious?

Tuning by sysctl/s would seem most useful, at least for development?

 > Maybe ifconfig can set a new flag somewhere somehow.
 > Maybe a process can set a flag for itself saying what its mode is..
 > ----------
 > The trouble is that there is not an "always correct" answer.
 > some people may want to see a tunnel turn up on all FIBs
 > and others may not.

It's the options that drive ya crazy .. but being able to set/tune the
forwarding context - one fib, all fibs, or a set of fibs? - may allow
flexibility in view of the large set of maybes you (so far) mentioned.

Just some popcorn from the peanut gallery ..

cheers, Ian

More information about the freebsd-net mailing list