On 29/01/2019 15:18, Zhengjing Jim Yang wrote:
> Hi,
>
>
>
> Here is some additional information why I tested DHCPD v4.4.1 building
> with --enable-use-sockets option.
>
>
>
> When the server is running with DHCPD v4.4.1 building WITHOUT using
> --enable-use-sockets option,
>
> from the tcpdump results and the dhcp logs listed below, we can find
> that the client 10.155.129.193 sent one DHCPREQUEST to the dhcp-server
> (10.0.0.249),
>
> but the dhcp-server replied with three DHCPACKs to the client (one
> DHCPACK via each interface).
>
>
>
> Note: there are three IP service addresses bonded to one NIC on this
> dhcp-server.
>
>
>
> sudo tcpdump -n -tttt -i bond0 port 67 and port 68
>
>
>
> --- tcpdump results ---
>
> 2019-01-29 09:51:28.594948 IP 10.155.129.193.bootpc > 10.0.0.249.bootps:
> BOOTP/DHCP, Request from 80:ce:aa:aa:aa:aa, length 300
>
> 2019-01-29 09:51:28.595959 IP 10.0.0.249.bootps > 10.155.129.193.bootpc:
> BOOTP/DHCP, Reply, length 300
>
> 2019-01-29 09:51:28.596320 IP 10.0.0.249.bootps > 10.155.129.193.bootpc:
> BOOTP/DHCP, Reply, length 300
>
> 2019-01-29 09:51:28.596722 IP 10.0.0.249.bootps > 10.155.129.193.bootpc:
> BOOTP/DHCP, Reply, length 300
>
>
>
> --- the corresponding dhcp log lines ----
>
> Jan 29 09:51:28 dhcp-server dhcpd: DHCPREQUEST for 10.155.129.193 from
> 80:ce:aa:aa:aa:aa (client host name) via bond0:2
>
> Jan 29 09:51:28 dhcp-server dhcpd: DHCPACK on 10.155.129.193 to
> 80:ce:aa:aa:aa:aa (client host name) via bond0:2
>
> Jan 29 09:51:28 dhcp-server dhcpd: DHCPREQUEST for 10.155.129.193 from
> 80:ce:aa:aa:aa:aa (client host name) via bond0:1
>
> Jan 29 09:51:28 dhcp-server dhcpd: DHCPACK on 10.155.129.193 to
> 80:ce:aa:aa:aa:aa (client host name) via bond0:1
>
> Jan 29 09:51:28 dhcp-server dhcpd: DHCPREQUEST for 10.155.129.193 from
> 80:ce:aa:aa:aa:aa (client host name) via bond0
>
> Jan 29 09:51:28 dhcp-server dhcpd: DHCPACK on 10.155.129.193 to
> 80:ce:aa:aa:aa:aa (client host name) via bond0
>
>
>
> When the server was running with DHCPD v4.3.5 with the same
> configuration, I did not see this kind of behavior (1 client request, 3
> server replies sent from each interface).
>
>
>
> As I reported yesterday, the DHCPD v4.4.1 failed to start when building
> with --enable-use-sockets option.
>
>
>
> I also tested running the DHCPD v4.3.5 when building with
> --enable-use-sockets option. It started up successfully using the same
> configuration file.
>
>
>
> Is this a bug?
>
>
>
> Thank you for your time.
>
>
>
> Jim
>
> *From: *Zhengjing Yang <
[hidden email]>
> *Date: *Monday, January 28, 2019 at 3:42 PM
> *To: *Users of ISC DHCP <
[hidden email]>
> *Subject: *dhcpd v4.4.1 failed to start when built with
> --enable-use-sockets option
>
>
>
> Hi,
>
>
>
> I have some issue with dhcpd v4.4.1 when building it with
> --enable-use-sockets option.
>
> The binary was built successfully on Red Hat Enterprise Linux 6.
>
>
>
> $ ./configure --enable-use-sockets
>
> $ make
>
> $ make install
>
>
>
> When I tried to start up the server, it failed to start with the
> following errors in the logs below.
>
>
>
> The same configuration works for dhcpd v4.3.5 with the same build option.
>
> The same configuration also works for dhcpd v4.4.1 when built without
> using --enable-use-sockets option.
>
>
>
> Did I miss something?
>
>
>
> Thank you for your time.
>
>
>
> Jim
>
>
>
> ----Log ----
>
>
>
> Jan 28 14:47:46 test1 dhcpd: Wrote 0 class decls to leases file.
>
> Jan 28 14:47:46 test1 dhcpd: Wrote 0 deleted host decls to leases file.
>
> Jan 28 14:47:46 test1 dhcpd: Wrote 0 new dynamic host decls to leases file.
>
> Jan 28 14:47:47 test1 dhcpd: Wrote 1233 leases to leases file.
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same subnet:
> bond0 bond0:1
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same shared
> network: bond0 bond0:1
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same subnet:
> bond0 bond0:2
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same shared
> network: bond0 bond0:2
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same subnet:
> bond0 bond0:3
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same shared
> network: bond0 bond0:3
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same subnet:
> bond0 bond0:4
>
> Jan 28 14:47:47 test1 dhcpd: Multiple interfaces match the same shared
> network: bond0 bond0:4
>
> Jan 28 14:47:47 test1 dhcpd: setsockopt: SO_BINDTODEVICE: No such device
>
> Jan 28 14:47:47 test1 dhcpd:
>
> Jan 28 14:47:47 test1 dhcpd: If you think you have received this message
> due to a bug rather
>
> Jan 28 14:47:47 test1 dhcpd: than a configuration issue please read the
> section on submitting
>
> Jan 28 14:47:47 test1 dhcpd: bugs on either our web page at www.isc.org
> or in the README file
>
> Jan 28 14:47:47 test1 dhcpd: before submitting a bug. These pages
> explain the proper
>
> Jan 28 14:47:47 test1 dhcpd: process and the information we find helpful
> for debugging.
>
> Jan 28 14:47:47 test1 dhcpd:
>
> Jan 28 14:47:47 test1 dhcpd: exiting.
>
>
>
>> uname -a
>
> Linux 2.6.32-754.6.3.el6.x86_64 #1 SMP Tue Sep 18 10:29:08 EDT 2018
> x86_64 x86_64 x86_64 GNU/Linux
>
>
>
>>ifconfig
>
> bond0 Link encap:Ethernet HWaddr aa:bb:cc:dd:ee:ff
>
> inet addr:10.0.1.20 Bcast:10.0.1.63 Mask:255.255.255.192
>
>
>
> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>
> RX packets:899836753 errors:0 dropped:0 overruns:0 frame:0
>
> TX packets:668845942 errors:0 dropped:0 overruns:0 carrier:0
>
> collisions:0 txqueuelen:0
>
> ...
>
>
>
> bond0:1 Link encap:Ethernet HWaddr aa:bb:cc:dd:ee:ff
>
> inet addr:10.0.1.21 Bcast:10.0.1.63 Mask:255.255.255.192
>
> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>
>
>
> bond0:2 Link encap:Ethernet HWaddr aa:bb:cc:dd:ee:ff
>
> inet addr:10.0.1.22 Bcast:10.0.1.63 Mask:255.255.255.192
>
> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>
>
>
> bond0:3 Link encap:Ethernet HWaddr aa:bb:cc:dd:ee:ff
>
> inet addr:10.0.1.23 Bcast:10.0.1.63 Mask:255.255.255.192
>
> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>
>
>
>
>
> # dhcp configuration:
>
> local-address 10.0.1.21;
>
> server-identifier 10.0.1.21;
>
> pid-file-name "/opt/dhcp/var/dhcpd.pid";
>
> lease-file-name "/opt/dhcp/etc/dhcpd.leases";
>
> ddns-update-style none;
>
> option ntp-servers 10.0.1.50
>
> default-lease-time 3600;
>
> max-lease-time 3600;
>
> deny bootp;
>
> authoritative;
>
> ping-check true;
>
> omapi-port 1000;
>
> omapi-key omapi-key;
>
>
>
> failover peer "test" {
>
> primary;
>
> address 10.0.1.21;
>
> port 647;
>
> peer address 10.0.2.21;
>
> peer port 847;
>
> max-response-delay 60;
>
> max-unacked-updates 10;
>
> mclt 900;
>
> split 128;
>
> load balance max seconds 3;
>
> }
>
>
>
> subnet 10.0.1.0 netmask 255.255.255.192 {
>
> option routers 10.0.1.1;
>
> }
>
Answering belatedly as a similar question arose recently and the
explanation might be helpful to others encountering the same or similar
problems when upgrading to versions of ISC DHCP that use the newer
interface discovery logic.
When ISC DHCP is started with no interfaces listed on the command line,
it will attempt to discover and listen on all running interfaces. (This
is convenient, but it might not be what you want in all situations).
But significantly, if you're depending on discovery versus specifying
the interfaces explicitly, be aware that the interface discovery logic
was changed in 4.3.6 to use getifaddrs().
This allows the server to see VLANs which the old code did not do
properly. This also means it will now see multiple addresses per
interface such as aliases. In the configuration shown above, servers
prior to 4.3.6 will only see bond0 while beginning with 4.3.6, they will
see bond0, bond0:1, bond0:2 etc.
This explains why, when you start a 4.4.1 server, compiled without
--enable-use-sockets, in your configuration, without explicitly
specifying to listen upon only bond0 via the command line, the server
starts. However it is now listening on bond0 *as well as* on all the
aliases because it can now 'see' them - which it couldn't do on the
older version of dhcpd. This means that client packets that are
broadcast on that subnet are seen on ALL of those interfaces. So one
DHCPDISCOVER becomes many - hence the multiple responses.
You also tried to run dhcpd compiled with --enable-use-sockets. With
this mode of operation, the socket initialization code attempts to set
the SO_BINDTODEVICE socket option via a call to setsocktopt. This call
fails with an error of "no such device" when invoked on aliases. The
server code treats this as a fatal error and exits.
Thus when you start a 4.4.1 server, compiled with --enable-use-sockets,
in your configuration, without explicitly specifying only bond0 via the
command line, the server falls down when it attempt to call setsockopt
on bond0:1.
Whether or not you choose to compile with --enable-use-sockets, we
suggest you specify only bond0 (and any other actual interfaces you want
the server to listen on explicitly) on the command line invocation, such
as this:
dhcpd <options> bond0
The end result should be the behavior you had before.
Hoping that this helps!
Cathy
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
