Requesting comments on Multi-routing table usage

[Julian Elischer]

Julian Elischer wrote:
> Ian Smith wrote:
>> 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?
> 
> that's already possible with setfib..
> setfib N sh script is going to do that..
> 
> The issue I have is with the routes that are added to routing tables
> when an interface is added.. It's a specific instance that is tricky
> because it's a side effect rather than a directly requested action.
> 
> what some people have asked to do is have multiple tunnels to the same 
> place but have different routing tables specify different tunnels to get 
> to that place..
> 
> e.g.
> 
> gre0   1.1.1.1 2.2.2.2
> gre1   3.3.3.3 2.2.2.2
> gre2   4.4.4.4 2.2.2.2
> 
> where in fib 0 the route to 2.2.2.2 is via gre0
> and in fib1 it is via gre1
> and in fib2 it is via gre2
> then you can use setfib in ipfw and pf to use different tunnels to get
> selected traffic to 2.2.2.2..
> 
> This is what is being asked for, but you can only add the
> interfaces like that if ifconfig only effects differnet FIBS for each
> interface.

hmmm that makes me think that maybe an ifconfig command to associate
a FIB with an interface might do the trick...
if it's not associated with a FIB it get to all of them, but if
you have previously associated it wit a FIB, then only that FIB is
affected.

That may just be a good enough answer.

> 
> 
> 
>>
>> 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
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"