Requesting comments on Multi-routing table usage
Ian Smith
smithi at nimnet.asn.au
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