Skip site navigation (1)Skip section navigation (2)
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&#39;s that are not associated directly with the interface if I =
want,=C2=A0or multiple FIB&#39;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 &lt;<a href=3D"mailto:roy@marp=
les.name">roy@marples.name</a>&gt; 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 &lt;avg@FreeBSD.=
org&gt;</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 &quot;reasons&quot;. <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&#39;s not important. <br> <br>Some things provided via DHCP are per=
 interface, but others are per host <br>(&quot;global&quot;).  Each interfa=
ce can get its own IP address, that&#39;s fine. <br>But, for example, which=
 gateway to select for the default route? <br> <br>Dealing with those &quot=
;global&quot; things is the main issue in such a setup. <br> <br>What do we=
 have now? <br>Specifically, with dhclient that&#39;s a part of the base. <=
br> <br>Essentially, it has a winner takes it all approach. <br>That&#39;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 &quot;man=
ually&quot; (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>&quot;secondary&quot; interface(s) which would igno=
re the &quot;global&quot; options (routers, name <br>servers, etc).  This w=
ay the &quot;primary&quot; 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 &quot;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&#39;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&#39;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&#39;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 &quot;secondary&quot; 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&#39;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 &quot;v=
irtual&quot; option and real ifconfig &#39;fib&#39; option. <br>Or would th=
at clash with some other uses / intentions? <br>Then maybe we could add ano=
ther virtual option like FIB&lt;X&gt; or DHCPFIB&lt;X&gt;? <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>