Re: Why does dhcpd have a routers (plural) option for a subnet?

On Thu, Sep 26, 2024 at 03:29:39PM +0100, Frank Leonhardt wrote:
> On 2024-09-25 21:04, Steve Rikli wrote:
> > On Wed, Sep 25, 2024 at 08:39:39PM +0100, Frank Leonhardt wrote:
> > > Ever wondered why there's a "routers" option in dhcpd.conf? I have.
> > ...
> > Fwiw, dhcp-options(5) says:
> > 
> >     option routers ip-address [, ip-address ...];
> >          The routers option specifies a list of IP addresses for routers
> >          on the client's subnet.  Routers should be listed in order of
> >          preference.
> > 
> > That said, I've never really tried multiple address there either.  :-)
> 
> That's interesting! I was looking in man dhcpd.conf and elsewhere, but not
> this man page (which appeared in FreeBSD 4.0 - I've just checked).
> 
> This would require the host to rotate on failed gateways. I've always
> thought this was a sensible and simple idea but networking geeks said it was
> a really bad one and router standby protocols were the way to go.
> 
> So the next interesting question would be which host stacks would accept
> multiple gateways and what would they do with them?

As an experiment, I configured DHCP service in the lab to offer 2 routers
to some test VM's, using an option like this:

    option routers 172.16.0.1, 172.16.0.2;

The original config had only 172.16.0.1, and 'netstat -rn' on the VM's
reported same.

After rebooting, FreeBSD 14.1 and NetBSD 10.0 both continued to use just
the 1st router listed -- 172.16.0.1.

A Debian 12.7 VM added the 2nd router, listing both afterwards:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.0.1      0.0.0.0         UG        0 0          0 ens18
0.0.0.0         172.16.0.2      0.0.0.0         UG        0 0          0 ens18
172.16.0.0      0.0.0.0         255.255.255.0   U         0 0          0 ens18

Checking "order of preference" from the man page, I reversed the routers
list order in the DHCP offer, and rebooted the VM's; as you'd expect, the
BSD's then used the 172.16.0.2 router, and Debian likewise re-ordered the
netstat list to have 172.16.0.2 first.

AFAI can see, DHCP makes no effort to determine if either router is up or
valid, which is what I'd expect. E.g. 172.16.0.2 in my test was shutdown.

So it looks like ISC DHCP is working as advertised, and how a given host
makes use of this config is apparently OS-dependent. Seems reasonable.

If you do have multiple gateway paths out of your network, this could
provide a basic way to offer both to DHCP clients, in the absence of
other router failover mechanisms, HSRP, pf+CARP, etc. But you'd still
have to manage the DHCP routers list yourself -- not automatic.

Cheers,
sr.