From nobody Tue Dec 24 03:34:45 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YHLB03mWYz5hvNF for ; Tue, 24 Dec 2024 03:35:04 +0000 (UTC) (envelope-from sm@codenetworks.net) Received: from relayout05-q02.dominioabsoluto.net (relayout05-q02.dominioabsoluto.net [217.116.26.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YHLB01SRTz40Wt for ; Tue, 24 Dec 2024 03:35:04 +0000 (UTC) (envelope-from sm@codenetworks.net) Authentication-Results: mx1.freebsd.org; none Received: from relayout05-redir.dominioabsoluto.net (relayout05-redir.dominioabsoluto.net [217.116.26.107]) by relayout05.dominioabsoluto.net (Postfix) with ESMTP id 4YHL9w6gSqzMpDW; Tue, 24 Dec 2024 04:35:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codenetworks.net; s=domabs; t=1735011300; bh=ZbrUOMpYTp123tOyCvQgLkPlu0a2mAZEw69ibapboFs=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=ZCrnQW2Fz1uJYVosPYIFj/+vrA+WenMxPBVXOvet51V+f94ItFi5jieMJR5sTW/DM gZ0/3DyCIsQx6SIfu3cUPI7A8wmtl3VP0q0IYxMlmHmKT6UaYK68x6rHUcY09oOD/e UXgVrF9hQmPbohNvPJ5hdYZuZlcrqPCEWz6Pw/lg= Received: from smtpclient.apple (unknown [152.171.186.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sm.codenetworks.net) by relayout05-dsp.dominioabsoluto.net (Postfix) with ESMTPSA id 4YHL9v3kSQzMpDK; Tue, 24 Dec 2024 04:34:59 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-4EB0C1F2-E6B5-4BB7-BD5D-7D078539BAD4 Content-Transfer-Encoding: 7bit From: Santiago Martinez List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (1.0) Subject: Re: per-FIB socket binding Date: Tue, 24 Dec 2024 00:34:45 -0300 Message-Id: <28EF197D-0D10-449A-A3C5-8B931F31CA6C@codenetworks.net> References: <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> Cc: freebsd-net@freebsd.org In-Reply-To: <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> To: Paul Vixie X-Mailer: iPhone Mail (22C152) X-PostalOut-Country: IP: 152.171.186.178 | Country: AR X-PostalOut-Information: AntiSPAM and AntiVIRUS on relayout05 X-PostalOut-MsgID: 4YHL9v3kSQzMpDK.A6900 X-PostalOut-SpamCheck: no es spam, clean X-PostalOut-From: sm@codenetworks.net X-PostalOut-Watermark: 1735616100.67712@BCPcoY+buF8s1FYcMeA8WQ X-Spam-Status: No X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16371, ipnet:217.116.24.0/21, country:ES] X-Rspamd-Queue-Id: 4YHLB01SRTz40Wt X-Spamd-Bar: ---- --Apple-Mail-4EB0C1F2-E6B5-4BB7-BD5D-7D078539BAD4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=20 here=E2=80=99s another user of fibs. Each of our servers have multiple fibs a= nd jails with fibs.=20 I like the proposed. Santi=20 > On 23 Dec 2024, at 16:46, Paul Vixie wrote: >=20 > =EF=BB=BF > 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 bri= ng > > > 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. >=20 > i've been thinking along these lines for a few years now, since my vm serv= er is multi-fib. each interface has a fib, mostly zero. for incoming TCP SYN= s, i'd like to carry that fib# into the resulting PCB so that that fib's rou= ting 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, j= ust always. is it worth me sending a patch that does this or would it be con= sidered controversial? >=20 > (making this happen for UDP is also interesting but is a separate matter s= ince those servers already have to maintain socket-per-interface in order to= get their source addresses to match the client's destination address.) >=20 > -- > Paul Vixie --Apple-Mail-4EB0C1F2-E6B5-4BB7-BD5D-7D078539BAD4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,=  
here=E2=80=99s another user of fibs. Each of ou= r servers have multiple fibs and jails with fibs. 
I like the proposed.
Santi 


On 23 Dec 2024, a= t 16:46, Paul Vixie <paul@redbarn.org> wrote:

=EF=BB=BF

On Monday, December 23, 2024 7:23:35 PM UTC Bj= oern 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 bri= ng

>= > 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 routi= ng table and especially its default route will be used for that connection. y= es, i can do that with ipfw, and am in fact doing so now. however, that's cr= ocky. i think defaulting to the interface FIB for connections created and ma= intained 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 consid= ered controversial?


= (making this happen for UDP is also interesting but is a separate matter sin= ce those servers already have to maintain socket-per-interface in order to g= et their source addresses to match the client's destination address.)


= --

Paul= Vixie

= --Apple-Mail-4EB0C1F2-E6B5-4BB7-BD5D-7D078539BAD4--