DHCP issues 1

[Leslie Rhorer]

On 6/1/2022 2:22 PM, Gregory Sloop wrote:
>
> I probably (almost certainly) don't have the time to address all your 
> issues - and I didn't see the initial post....
>
> ...But some details would perhaps help.
>
> What OS/Distro, and version? (debian, cent os, ubuntu etc, / 20.04, 
> 21.10 etc)
>
> Did you install the distro packages for dhcpd, or compile your own? 
> (or something else)
>
> What version of dhcpd?
>
     That is all in the initial post from the 24th.  I will re-post some 
parts of it.


     Debian Bullseye, installed from distro, isc-dhcpd-4.4.1


     Here is the functional declaration of dhcpd.conf on the secondary 
(malfunctioning) server:

ddns-update-style none;
default-lease-time 3600;
max-lease-time 7200;
authoritative;
log-facility local7;
failover peer "dhcp-failover" {
     address 192.168.1.51;
     port 647;
     peer address 192.168.1.50;
     peer port 647;
     max-response-delay 30;
     max-unacked-updates 10;
     load balance max seconds 3;
     split 0;
     mclt 3600;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
     filename "pxelinux.0";
     next-server 192.168.1.50;
     option routers 192.168.1.1;
     option domain-name "att.net";
     option domain-name-servers 8.8.8.8, 68.94.156.9, 68.94.157.9;
            pool {
                    failover peer "dhcp-failover";
                    range 192.168.1.220 192.168.1.240;
            }
}

include "/etc/dhcp/dhcpd.static";

> If you only answer some things - those above are the most important.
>
> ---
>
> You mention "secondary" server. Does this mean just a second server 
> (serving it's own ip block[s]), or a load-balanced/peer set of servers?
>
> Running load-balancing/peer servers is quite a bit more complicated. 
> (Lots of moving parts to go wrong, in weird ways, unanticipated corner 
> cases etc.)
>
     Load balancing, but the issues are only on the secondary peer.
>
> You say it's "working" - but how do you know it's working?
>

     It is servicing DHCP requests, and there are no errors in the log 
file.  The issues are the same whether the primary server is up and 
running or disabled.

> But I think getting the basics of what you've done and intend to do is 
> a good place to start.
>
> -Greg
>
>
>             I posted previously about the issues I am having.  Nothing
>     I tried, including completely purging and reinstalling
>     isc-dhcp-server, would get DHCP to work on my secondary server, so
>     I completely wiped the server and reloaded the OS.  The server is
>     mostly working now, but there are still some annoying issues.
>     Stopping, starting, and restarting the server don't quite work
>     properly.
>
>
>             1. Systemd reports a spurious error when starting the
>     server from a clean slate.
>
>
>       isc-dhcp-server.service - LSB: DHCP server
>           Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
>           Active: failed (Result: exit-code) since Wed 2022-06-01
>     13:21:26 CDT; 1min 10s ago
>             Docs: man:systemd-sysv-generator(8)
>          Process: 19134 ExecStart=/etc/init.d/isc-dhcp-server start
>     (code=exited, status=1/FAILURE)
>            Tasks: 4 (limit: 4461)
>           Memory: 4.8M
>              CPU: 124ms
>           CGroup: /system.slice/isc-dhcp-server.service
>       /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf enp11s0
>
>
>     Jun 01 13:21:24 Backup dhcpd[19159]:
>     Jun 01 13:21:24 Backup dhcpd[19159]: exiting.
>     Jun 01 13:21:26 Backup isc-dhcp-server[19134]: Starting ISC DHCPv6
>     server: dhcpd6check syslog for diagnostics. ...
>     Jun 01 13:21:26 Backup isc-dhcp-server[19164]:  failed!
>     Jun 01 13:21:26 Backup isc-dhcp-server[19165]:  failed!
>
>
>             It doesn't say what the error is, but the exit code is 1.
>     This causes the system to think the server has failed to start,
>     but it does load and remains in memory.  It seem to be working
>     pretty well.  Is there some way to get the server to report a bit
>     more in the way of diagnostics, perhaps in the log, or even just
>     stderr?  Obviously, this isn't a show stopper, but it is a bit
>     annoying, and it is possible there is something a bit more
>     insidious going on.
>
>
>             I tried running the server from the CL with the -d option,
>     but it doesn't produce any output.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220601/c1b5ee78/attachment.htm>