Date: Fri, 27 Dec 2024 08:48:48 +0000 From: Paul Vixie <paul@redbarn.org> To: Santiago Martinez <sm@codenetworks.net>, Jamie Landeg-Jones <jamie@catflap.org> Cc: freebsd-net@freebsd.org Subject: Re: per-FIB socket binding Message-ID: <38589000.XM6RcZxFsP@dhcp-151.access.rits.tisf.net> In-Reply-To: <28EF197D-0D10-449A-A3C5-8B931F31CA6C@codenetworks.net> References: <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <28EF197D-0D10-449A-A3C5-8B931F31CA6C@codenetworks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --nextPart2734174.Isy0gbHreE Content-Type: multipart/alternative; boundary="nextPart1970228.IobQ9Gjlxr" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1970228.IobQ9Gjlxr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, December 24, 2024 3:34:45 AM UTC Santiago Martinez wrote: > Hi, > here=E2=80=99s another user of fibs. Each of our servers have multiple fi= bs 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, ... >=20 > 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 th= at > way, but am prepared to be enlightened if anyone else has an opinion on > this. >=20 > Jamie Groovy. See attached patch. This is just for TCP since I have no way to tes= t SCTP and I=20 think UDP will have to be handled at the application layer. There are two o= ne line changes=20 here. =46irst, save the FIB number from the SYN in the syncache. This FIB number = was in the=20 incoming m_pkthdr so I didn't need to change any function signatures. Note = that if the=20 listener socket has a non-zero FIB number it will be used instead of the in= terface FIB=20 number -- it's more specific and likely to be right. Second, when the initial ACK arrives and it's time for the connection to ex= it from the=20 syncache and to become a socket, restore the original FIB number and apply = it to the=20 cloned socket, which will already have inherited its FIB number from the li= stener socket. This works here. The diff is for a 14.2 kernel but is likely backward-porta= ble. I'd very much=20 like to hear anybody's experience with this patch, or commentary on its app= roach and/or=20 advisability. =2D-=20 Paul Vixie --nextPart1970228.IobQ9Gjlxr Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8"> </head> <body><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">On Tuesday, December 24, 2024 3:34:45 AM UTC Santiago Martinez wrote:</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Hi,</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; here=E2=80=99s another user of fibs. Each of our servers have multiple fi= bs and</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; jails with fibs. I like the proposed.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Santi</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">Cool. Read on.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">On Tuesday, December 24, 2024 5:06:32 AM UTC Jamie Landeg-Jones wrote:</= p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Paul Vixie <paul@redbarn.org> wrote:</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > ...</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; I like that. I isolate 5 seperate networks by assigning a fib to each</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; interface, and was initially surprised that I had to jump through ipfw</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; hoops to get it to work properly, in fact at the end of my ipfw rules for= </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; these interfaces, just to guarantee no leaking, ...</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; So, yes, I agree that it's crocky, and your proposal is how I originally<= /p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; expected it to work, and indeed, I can so no reason for it not to work th= at</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; way, but am prepared to be enlightened if anyone else has an opinion on</= p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; this.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Jamie</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">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.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">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 signa= tures. Note that if the listener socket has a non-zero FIB number it will b= e used instead of the interface FIB number -- it's more specific and likely= to be right.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">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 nu= mber and apply it to the cloned socket, which will already have inherited i= ts FIB number from the listener socket.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">This works here. The diff is for a 14.2 kernel but is likely backward-po= rtable. I'd very much like to hear anybody's experience with this patch, or= commentary on its approach and/or advisability.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">-- </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Pau= l Vixie</p> </body> </html> --nextPart1970228.IobQ9Gjlxr-- --nextPart2734174.Isy0gbHreE Content-Disposition: attachment; filename="fibnum.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="x-UTF_8J"; name="fibnum.diff" diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index 83f85a50e..0e030f24f 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -1057,7 +1057,7 @@ tcp_input_with_port(struct mbuf **mp, int *offp, int proto, uint16_t port) } inc.inc_fport = th->th_sport; inc.inc_lport = th->th_dport; - inc.inc_fibnum = so->so_fibnum; + inc.inc_fibnum = so->so_fibnum || m->m_pkthdr.fibnum; /* * Check for an existing connection attempt in syncache if diff --git a/sys/netinet/tcp_syncache.c b/sys/netinet/tcp_syncache.c index 15244a61d..a50648fa5 100644 --- a/sys/netinet/tcp_syncache.c +++ b/sys/netinet/tcp_syncache.c @@ -805,6 +805,7 @@ syncache_socket(struct syncache *sc, struct socket *lso, struct mbuf *m) */ if ((so = solisten_clone(lso)) == NULL) goto allocfail; + so->so_fibnum = sc->sc_inc.inc_fibnum; #ifdef MAC mac_socketpeer_set_from_mbuf(m, so); #endif --nextPart2734174.Isy0gbHreE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38589000.XM6RcZxFsP>