Re: per-FIB socket binding

From: Paul Vixie <paul_at_redbarn.org>
Date: Fri, 27 Dec 2024 08:48:48 UTC
On Tuesday, December 24, 2024 3:34:45 AM UTC Santiago Martinez wrote:
> Hi,
> here’s another user of fibs. Each of our servers have multiple fibs and
> jails with fibs. I like the proposed.
> Santi

Cool. Read on.

On Tuesday, December 24, 2024 5:06:32 AM UTC Jamie Landeg-Jones wrote:
> Paul Vixie <paul@redbarn.org> wrote:
> > ...
> I like that. I isolate 5 seperate networks by assigning a fib to each
> interface, and was initially surprised that I had to jump through ipfw
> hoops to get it to work properly, in fact at the end of my ipfw rules for
> these interfaces, just to guarantee no leaking, ...
> 
> So, yes, I agree that it's crocky, and your proposal is how I originally
> expected it to work, and indeed, I can so no reason for it not to work that
> way, but am prepared to be enlightened if anyone else has an opinion on
> this.
> 
> Jamie

Groovy. See attached patch. This is just for TCP since I have no way to test SCTP and I 
think UDP will have to be handled at the application layer. There are two one line changes 
here.

First, save the FIB number from the SYN in the syncache. This FIB number was in the 
incoming m_pkthdr so I didn't need to change any function signatures. Note that if the 
listener socket has a non-zero FIB number it will be used instead of the interface FIB 
number -- it's more specific and likely to be right.

Second, when the initial ACK arrives and it's time for the connection to exit from the 
syncache and to become a socket, restore the original FIB number and apply it to the 
cloned socket, which will already have inherited its FIB number from the listener socket.

This works here. The diff is for a 14.2 kernel but is likely backward-portable. I'd very much 
like to hear anybody's experience with this patch, or commentary on its approach and/or 
advisability.

-- 
Paul Vixie