This is a reply to the second of two of Julian's recent messages. On Friday, March 14, 2025 4:45:48 AM UTC Julian Elischer wrote: > On 2/21/25 8:35 AM, Paul Vixie wrote: > > On Thursday, February 20, 2025 4:47:41 PM UTC Mark Johnston wrote: > >> On Tue, Feb 18, 2025 at 05:16:07AM +0000, Paul Vixie wrote: > >>> this is the second fibnum patch, ... > >> > >> The high-level changes seem to be: > >> - If a TCP listening socket's FIB is 0, then the FIB of incoming > >> > >> connections matched to that socket will be the FIB of the interface on > >> which the initial SYN was received. > > for outgoing connections it makes sense to allow the sender to force a > fib regardless of the interface's default fib. (it is after all just a > default (possibly I didn't document that well)).
ok, that's doable. fibnum2 changes bind() to make the interface FIB be the socket's FIB, but overriding this with the process FIB (if nonzero) makes sense to me. > ... > > For incoming connection requests, what exactly does a fib mean? Since > fibs are an outgoing thing.. You could just force the interface's fib > onto the session or you could have one associated with the process > applied to it. Or you could declare the whole idea void. path asymmetry by which a connection comes to an interface having a FIB but all outbound data sent via that connection has fib 0 means: we aren't actually multihoming. the fib 0 default route for example may have a very different way of getting back to the initiator. it may also have firewall rules, or pass through low-performance networks meant for command and control rather than service. > I think the order of evaluation would be Process FIB highest priority, > followed by interface FIB. I do remember I was thinking about a fib > value of -1 being "no fib.. I'm a pushover, do with me what you > want". but I never really followed that through. we're using fib 0 for that today, and it works. i'll add your process-first priority scheme in what i suppose will be called "fibnum3". > >> The handling of the second point seems incomplete: it doesn't update the > >> FIB number stored in the socket itself. Gleb and I talked a bit about > >> eliminating that field entirely so that there's only one source of > >> truth, and I think we'll eventually do that, but in the meantime, > >> in_pcbbind() needs to update so_fibnum as well. > > I can't remember much of what I did this for. It was um..17 years > ago? anyhow I wouldn't have made two copies of something unless there > was some case where you wanted them to be different, but of course > that case may not exist any more.. > > Where is the other copy? inp->inp_inc.inc_fibnum. -- Paul Vixie
