From nobody Fri Sep 19 19:59:03 2025 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 4cT3HX61p0z67WXy for ; Fri, 19 Sep 2025 19:59:20 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cT3HX4R2hz3QnD for ; Fri, 19 Sep 2025 19:59:20 +0000 (UTC) (envelope-from leeb@ratnaling.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-71d71bcac45so17659527b3.0 for ; Fri, 19 Sep 2025 12:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20230601.gappssmtp.com; s=20230601; t=1758311958; x=1758916758; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YnPxFCgcX1gq/YDQctiX4a3J5RgoxJTVuXdmpjRvx2M=; b=2Kuut017LEdSm/4Y2/yoE+R0+GRFDqMHvz8bsrUHnMaoJBEmGOInTP2ZUJc5rNofL8 q3+uCtFsnxz1EQIaC6NgiIySL7L8zZi17DYdSZ8pEboBeYgbyOZVRTDJVY7l/gllhxV9 OiVjN5zjYh4192JM2WQ7mHlE5OP7XQvS4K3mGSa/9ubrj/DTwS3ibzDmCaQ/SyQcLrM5 YBdzcROPOUrm0GEM3IxFCM1zPtogGlSDEYMf0oiouoKXT3rQQgXQnq+ujnE2/+4TR8zQ eO13LWhQBwh9RXp0bVJGJDwFdfpiaRb6wl1WYOZOTYav1lzWsjtKcRRyotf/8MXFjFE1 WSLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758311958; x=1758916758; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YnPxFCgcX1gq/YDQctiX4a3J5RgoxJTVuXdmpjRvx2M=; b=Pt/eIiyxC/VhbiRdLxrqq7DqMJYL/qZtil3J7ylcEwi994LnRbbXWJ4Zpg2Chu8vo8 fF3YSHI0JWr1Nb8JixvroGz/ubkXktX+JjozYE9B5l0ik9WduuRS2Vq5qdv+ROLkTUCp sa1UX2OyIwN76CBBfc8LSHCuds8eiD6yhidfp7/S4iz0EPgMFJoYUA5NTklzSH+9BQda vLNb1qm9PT54jXdWpLqY8ByPXEnFiFSzXufL6m2A/gG3bqRvmajeV2S8kw7EM1ZytCtE EO2uHC4gn9cqcfu/M9wbwX8qMBOMkOr66EbPt4nw/7Vde/2LOPGlE5IMXtwGMYmhgXLw AITA== X-Forwarded-Encrypted: i=1; AJvYcCUxd437pCi5e4gOspodEhlLY49MccR6Bo/swi1B6+aTxLFB8W75Ed89W12YqCflv5OXFZsYTu2P1Bxw9g==@freebsd.org X-Gm-Message-State: AOJu0YyXmq6+XNX+f/IIJt7SlWVpkYUdmaKUbMzU9fdrV9swcdzGZ6Mj CxXS+pq4GEDiI4ohq7e47oz7Ua6uV3OrTXCHzy8pb//6SMBwB0EDg6pryOlDkPX1Fabnx8kAZLY Tu2TK9NGwXxCU/qPR8/Nd9uQEPA42r2F/JQzFuP80GXyJT9BMkiLW X-Gm-Gg: ASbGnctpCEl5O6fLNso4DNFYiSzZ0ZHPenlngW1Y+sbvNJlXNXFkGC7DGFYhalqV4RZ 41EP3RksqDnev2grC2me0rZ5SQIf0yNhdiXFGx6yh0IcGsPle59sv8Qm3KfsnhxZjEHU98zCexO r5PnnqPuektz2xS36vATcAboWXwQevIb3LALU2UYHyWziaXKCiNLmPZdjPzdbi8Z0pHgx97+OUm Z8PLCzoJ43VQDrp2gX4Px1ZSYoqXr0rVK20SAijO+3C+2bdz2VM9jPC4X059iP6ofZ6Cycd1xi5 aOoSn6Bkvk/3sQVEZ/Xeqq0FOSI= X-Google-Smtp-Source: AGHT+IFJrF5OZmtiOQRlFbgohC8MZKu6ROyhEdKH+v/qZd+I9MhZfo7y//y/Za6sqZWXKmEcJoFNdRQ5SJNjZfJUQVU= X-Received: by 2002:a05:690c:890:b0:723:9700:716d with SMTP id 00721157ae682-73d3f5e13d1mr39847647b3.54.1758311958199; Fri, 19 Sep 2025 12:59:18 -0700 (PDT) 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 References: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org> <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name> In-Reply-To: <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name> From: Lee Brown Date: Fri, 19 Sep 2025 12:59:03 -0700 X-Gm-Features: AS18NWC8qoA190HblO1XIhZCFjRCctiOH46al6I8my3dxtm7J61tL7X0O8pkHY0 Message-ID: Subject: Re: DHCP on multi-homed host, some thoughts To: Roy Marples Cc: avg@freebsd.org, freebsd-net@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ac5224063f2ce746" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cT3HX4R2hz3QnD --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 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 * > 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 or DHCPFIB? > 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
I use /etc/dhclient-enter-hooks and /etc/dhclient-exit hoo= ks 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,=C2=A0or multiple FIB's, etc..

On Fri, = Sep 19, 2025 at 12:19=E2=80=AFPM Roy Marples <roy@marples.name> wrote:
You could look into using dhcpcd from ports which solved = this multihome issue years ago.

Each interface aut= omatically get a metric based on type and index. This is override able, low= est wins.
For any competing setup, lowest takes precedence and se= amlessly 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 pos= sible and some people
have it (according to the Internet). I am also t= rying 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 netwo= rks are
likely to be completely unaware of each other.

The hos= t itself may be a router providing internet access to another local
net= work via another interface (or even multiple networks + interfaces). But <= br>that's not important.

Some things provided via DHCP are per= interface, but others are per host
("global"). Each interfa= ce 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. <= br>
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 interf= ace, the interface
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, witho= ut any
extra settings, then there is an obvious problem. A winner woul= d depend on
random things like which interface gets link first, which D= HCP sever is more
responsive, etc. And a random winner is not always w= hat is desired.

As far as I know, there is no way to set any prior= ity or anything like that.
I found only two solutions used by other peo= ple, both not ideal.

One solution is to start dhclient-s "man= ually" (i.e., outside of rc.conf
declarative configuration) via so= mething like rc.local. This way we can control
which interface gets co= nfigured first.

The other approach is to create a dhclient.conf co= nfiguration for the
"secondary" interface(s) which would igno= re the "global" options (routers, name
servers, etc). This w= ay the "primary" interface would be the only one that gets
an= d sets the global configuration while all interfaces get their individual I= P
configuration.

The latter approach is "less intrusive&q= uot; (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 t= he
secondary interface (either explicitly in dhclient.conf or by dhclie= nt-script's
strategy). And those options may come handy if we want= to dynamically flip (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 config= uration.
I think that it could just add configurations from all interfa= ces and let
resolvconf(8) deal with that. And an administrator would h= ave control over 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 o= n domain, etc.

Regarding routing, these days we can have multiple = FIBs, so instead of
discarding "secondary" routing informatio= n we could use it to configure a
non-default FIB.

Initially, I= wanted to start working on some changes to dhclient-script to
implemen= t 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) the= n that alone would achieve the goals:
- the secondary dhclient would be= considered a winner because it's the only one
to set the default r= oute 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 c= all resolvconf.

I wonder if it would be a good idea to run dhclien= t under setfib if an interface
is configured with DHCP/DHCPSYNC "v= irtual" option and real ifconfig 'fib' option.
Or would th= at clash with some other uses / intentions?
Then maybe we could add ano= ther virtual option like FIB<X> or DHCPFIB<X>?
Or, probably= even better, some thing like dhclient_fib_IF=3DX?
Akin to background_d= hclient, for example.

The standard dhclient_fib option is, obvious= ly, of no use because it would put
all dhclient-s into the same FIB.
--
Andriy Gapon



=

--000000000000ac5224063f2ce746--