Hi, here’s another user of fibs. Each of our servers have multiple fibs and jails with fibs. I like the proposed. Santi
> On 23 Dec 2024, at 16:46, Paul Vixie <p...@redbarn.org> wrote: > > > On Monday, December 23, 2024 7:23:35 PM UTC Bjoern A. Zeeb wrote: > > On Sat, 21 Dec 2024, Bjoern A. Zeeb wrote: > > >> Any thoughts/comments? > > > > > > That all said with your opt-in approach if the code itself doesn't bring > > > too many new complications I'd be happy with it (assuming FIBs still > > > have a use case). > > > > Seems there's plenty people using multi-FIB in various scenarios still, > > which is good to know. > > > > Go for it. > > i've been thinking along these lines for a few years now, since my vm server > is multi-fib. each interface has a fib, mostly zero. for incoming TCP SYNs, > i'd like to carry that fib# into the resulting PCB so that that fib's routing > table and especially its default route will be used for that connection. yes, > i can do that with ipfw, and am in fact doing so now. however, that's crocky. > i think defaulting to the interface FIB for connections created and > maintained by the kernel should always happen -- not opt-in, not opt-out, > just always. is it worth me sending a patch that does this or would it be > considered controversial? > > (making this happen for UDP is also interesting but is a separate matter > since those servers already have to maintain socket-per-interface in order to > get their source addresses to match the client's destination address.) > > -- > Paul Vixie
