Date: Fri, 19 Sep 2025 12:59:03 -0700 From: Lee Brown <leeb@ratnaling.org> To: Roy Marples <roy@marples.name> Cc: avg@freebsd.org, freebsd-net@freebsd.org Subject: Re: DHCP on multi-homed host, some thoughts Message-ID: <CAFPNf5-UF7zm4xK77d43nh4sOvu0xjdmhcOmnK86Etq_irxt9w@mail.gmail.com> In-Reply-To: <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name> References: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org> <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000ac5224063f2ce746 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I use /etc/dhclient-enter-hooks and /etc/dhclient-exit hooks to override functions in dhclient-script. That way I can control which interface updates /etc/resolv.conf and/or default routes even in FIB's that are not associated directly with the interface if I want, or multiple FIB's, etc.. On Fri, Sep 19, 2025 at 12:19=E2=80=AFPM Roy Marples <roy@marples.name> wro= te: > You could look into using dhcpcd from ports which solved this multihome > issue years ago. > > Each interface automatically get a metric based on type and index. This i= s > override able, lowest wins. > For any competing setup, lowest takes precedence and seamlessly changes > when the interface goes down or loses a lease. > > Roy > > > > ---- On Fri, 19 Sep 2025 20:13:45 +0100 *Andriy Gapon <avg@FreeBSD.org>* > wrote ---- > > > > Admittedly not a very common configuration, but still possible and some > people > have it (according to the Internet). I am also trying to set up such a > configuration for "reasons". > > In the simplest form, there are two network interfaces connected to two > different networks. Each network has its own DHCP server, its own router = / > gateway to the wider Internet, its own DNS server(s), etc. The networks > are > likely to be completely unaware of each other. > > The host itself may be a router providing internet access to another loca= l > network via another interface (or even multiple networks + interfaces). > But > that's not important. > > Some things provided via DHCP are per interface, but others are per host > ("global"). Each interface can get its own IP address, that's fine. > But, for example, which gateway to select for the default route? > > Dealing with those "global" things is the main issue in such a setup. > > What do we have now? > Specifically, with dhclient that's a part of the base. > > Essentially, it has a winner takes it all approach. > That's implemented in the default dhclient-script and the gist of the > logic is > in is_default_interface() function. Whichever interface is first to get a > lease > with a router wins. dhclient-script would set the default route to the > router > and as long as the default route goes through the interface, the interfac= e > remains the winner (for subsequent updates). > > So, the winner gets to set the default route. > The winner also gets to set the resolver configuration (using > resolvconf(8), by > default). > Losers can only configure their interface, other information is lost. > > If DHCP is simply configured for multiple interfaces via rc.conf, without > any > extra settings, then there is an obvious problem. A winner would depend o= n > random things like which interface gets link first, which DHCP sever is > more > responsive, etc. And a random winner is not always what is desired. > > As far as I know, there is no way to set any priority or anything like > that. > I found only two solutions used by other people, both not ideal. > > One solution is to start dhclient-s "manually" (i.e., outside of rc.conf > declarative configuration) via something like rc.local. This way we can > control > which interface gets configured first. > > The other approach is to create a dhclient.conf configuration for the > "secondary" interface(s) which would ignore the "global" options (routers= , > name > servers, etc). This way the "primary" interface would be the only one tha= t > gets > and sets the global configuration while all interfaces get their > individual IP > configuration. > > The latter approach is "less intrusive" (more declarative), but it has a > flaw > that if the selected primary network is down then there would be no > default > route at all. > > Both solutions still have the issue of discarding the global options from > the > secondary interface (either explicitly in dhclient.conf or by > dhclient-script's > strategy). And those options may come handy if we want to dynamically fli= p > (and > as seamlessly as possible) between interfaces based on some events / > criteria. > > It's especially interesting that dhclient uses the power of resolvconf(8) > (unless forced to update /etc/resolv.conf directly) but still takes only > the > winner's configuration. > I think that it could just add configurations from all interfaces and let > resolvconf(8) deal with that. And an administrator would have control ove= r > how > multiple configurations are merged via resolvconf.conf. Especially, if a > local > resolver (like unbound, for instance) is used. E.g., it would be possible > to > use different name servers based on domain, etc. > > Regarding routing, these days we can have multiple FIBs, so instead of > discarding "secondary" routing information we could use it to configure a > non-default FIB. > > Initially, I wanted to start working on some changes to dhclient-script t= o > implement those ideas. But then it occurred to me that it would easier to > get > what I want by changes external to dhclient. > > If there was a way to run a secondary dhclient with a non-default FIB > (e.g., via > setfib) then that alone would achieve the goals: > - the secondary dhclient would be considered a winner because it's the > only one > to set the default route of the FIB; > - so, it would obviously set the default route in the FIB; > - and because the dhclient is considered a winner, it would also call > resolvconf. > > I wonder if it would be a good idea to run dhclient under setfib if an > interface > is configured with DHCP/DHCPSYNC "virtual" option and real ifconfig 'fib' > option. > Or would that clash with some other uses / intentions? > Then maybe we could add another virtual option like FIB<X> or DHCPFIB<X>? > Or, probably even better, some thing like dhclient_fib_IF=3DX? > Akin to background_dhclient, for example. > > The standard dhclient_fib option is, obviously, of no use because it woul= d > put > all dhclient-s into the same FIB. > > -- > Andriy Gapon > > > > > --000000000000ac5224063f2ce746 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I use /etc/dhclient-enter-hooks and /etc/dhclient-exit hoo= ks to override functions in dhclient-script.<div><br></div><div>That way I = can control which interface updates /etc/resolv.conf and/or default routes = even in FIB's that are not associated directly with the interface if I = want,=C2=A0or multiple FIB's, etc..</div></div><br><div class=3D"gmail_= quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, = Sep 19, 2025 at 12:19=E2=80=AFPM Roy Marples <<a href=3D"mailto:roy@marp= les.name">roy@marples.name</a>> wrote:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex"><u></u><div><div style=3D"font-family:Verdana;fon= t-size:11pt"><div>You could look into using dhcpcd from ports which solved = this multihome issue years ago.</div><div><br></div><div>Each interface aut= omatically get a metric based on type and index. This is override able, low= est wins.</div><div>For any competing setup, lowest takes precedence and se= amlessly changes when the interface goes down or loses a lease.<br></div><d= iv><br></div><div id=3D"m_1377890562645764481signatureElementId" style=3D"d= isplay:block"><div>Roy</div></div><div><br></div><div><div><br><br></div><d= iv>---- On Fri, 19 Sep 2025 20:13:45 +0100 <b>Andriy Gapon <avg@FreeBSD.= org></b> wrote ----<br></div><div><br></div><blockquote style=3D"margin:= 0px"><div><br><br>Admittedly not a very common configuration, but still pos= sible and some people <br>have it (according to the Internet). I am also t= rying to set up such a <br>configuration for "reasons". <br> <br>= In the simplest form, there are two network interfaces connected to two <br= >different networks. Each network has its own DHCP server, its own router = / <br>gateway to the wider Internet, its own DNS server(s), etc. The netwo= rks are <br>likely to be completely unaware of each other. <br> <br>The hos= t itself may be a router providing internet access to another local <br>net= work via another interface (or even multiple networks + interfaces). But <= br>that's not important. <br> <br>Some things provided via DHCP are per= interface, but others are per host <br>("global"). Each interfa= ce can get its own IP address, that's fine. <br>But, for example, which= gateway to select for the default route? <br> <br>Dealing with those "= ;global" things is the main issue in such a setup. <br> <br>What do we= have now? <br>Specifically, with dhclient that's a part of the base. <= br> <br>Essentially, it has a winner takes it all approach. <br>That's = implemented in the default dhclient-script and the gist of the logic is <br= >in is_default_interface() function. Whichever interface is first to get a= lease <br>with a router wins. dhclient-script would set the default route= to the router <br>and as long as the default route goes through the interf= ace, the interface <br>remains the winner (for subsequent updates). <br> <b= r>So, the winner gets to set the default route. <br>The winner also gets to= set the resolver configuration (using resolvconf(8), by <br>default). <br>= Losers can only configure their interface, other information is lost. <br> = <br>If DHCP is simply configured for multiple interfaces via rc.conf, witho= ut any <br>extra settings, then there is an obvious problem. A winner woul= d depend on <br>random things like which interface gets link first, which D= HCP sever is more <br>responsive, etc. And a random winner is not always w= hat is desired. <br> <br>As far as I know, there is no way to set any prior= ity or anything like that. <br>I found only two solutions used by other peo= ple, both not ideal. <br> <br>One solution is to start dhclient-s "man= ually" (i.e., outside of rc.conf <br>declarative configuration) via so= mething like rc.local. This way we can control <br>which interface gets co= nfigured first. <br> <br>The other approach is to create a dhclient.conf co= nfiguration for the <br>"secondary" interface(s) which would igno= re the "global" options (routers, name <br>servers, etc). This w= ay the "primary" interface would be the only one that gets <br>an= d sets the global configuration while all interfaces get their individual I= P <br>configuration. <br> <br>The latter approach is "less intrusive&q= uot; (more declarative), but it has a flaw <br>that if the selected primary= network is down then there would be no default <br>route at all. <br> <br>= Both solutions still have the issue of discarding the global options from t= he <br>secondary interface (either explicitly in dhclient.conf or by dhclie= nt-script's <br>strategy). And those options may come handy if we want= to dynamically flip (and <br>as seamlessly as possible) between interfaces= based on some events / criteria. <br> <br>It's especially interesting = that dhclient uses the power of resolvconf(8) <br>(unless forced to update = /etc/resolv.conf directly) but still takes only the <br>winner's config= uration. <br>I think that it could just add configurations from all interfa= ces and let <br>resolvconf(8) deal with that. And an administrator would h= ave control over how <br>multiple configurations are merged via resolvconf.= conf. Especially, if a local <br>resolver (like unbound, for instance) is = used. E.g., it would be possible to <br>use different name servers based o= n domain, etc. <br> <br>Regarding routing, these days we can have multiple = FIBs, so instead of <br>discarding "secondary" routing informatio= n we could use it to configure a <br>non-default FIB. <br> <br>Initially, I= wanted to start working on some changes to dhclient-script to <br>implemen= t those ideas. But then it occurred to me that it would easier to get <br>= what I want by changes external to dhclient. <br> <br>If there was a way to= run a secondary dhclient with a non-default FIB (e.g., via <br>setfib) the= n that alone would achieve the goals: <br>- the secondary dhclient would be= considered a winner because it's the only one <br>to set the default r= oute of the FIB; <br>- so, it would obviously set the default route in the = FIB; <br>- and because the dhclient is considered a winner, it would also c= all resolvconf. <br> <br>I wonder if it would be a good idea to run dhclien= t under setfib if an interface <br>is configured with DHCP/DHCPSYNC "v= irtual" option and real ifconfig 'fib' option. <br>Or would th= at clash with some other uses / intentions? <br>Then maybe we could add ano= ther virtual option like FIB<X> or DHCPFIB<X>? <br>Or, probably= even better, some thing like dhclient_fib_IF=3DX? <br>Akin to background_d= hclient, for example. <br> <br>The standard dhclient_fib option is, obvious= ly, of no use because it would put <br>all dhclient-s into the same FIB. <b= r> <br>-- <br>Andriy Gapon <br> <br> <br></div></blockquote></div><div><br>= </div></div><br></div></blockquote></div> --000000000000ac5224063f2ce746--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPNf5-UF7zm4xK77d43nh4sOvu0xjdmhcOmnK86Etq_irxt9w>