deny duplicates doesn't work? (using to handle pxeclients)
Brian J. Murrell
brian at interlinx.bc.ca
Fri Oct 25 16:46:15 UTC 2013
I am using Internet Systems Consortium DHCP Server 4.1.1-P1 on CentOS 6.4
I'm experiencing the previously discussed problem of hosts that boot
using PXE requesting two different leases because the PXE DHCP request
has a client identifier in it but the Linux DHCP request doesn't have
one in it.
Given that I do have host declarations for all of my hosts in my
dhcpd.conf such as:
host node-19vm1 {
hardware ethernet 52:54:00:19:D9:01;
filename "/pxelinux.0";
next-server 10.14.80.6;
option subnet-mask 255.255.248.0;
option host-name="node-19vm1";
ddns-updates on;
ddns-hostname "node-19vm1";
ddns-domainname "foo.example.com";
}
I thought I could take care of this problem with a global:
deny duplicates;
at the top of my dhcpd.conf.
I don't think the feature is working though. Given a boot of an example
machine, node-19vm1, this is what dhcpd reported:
Oct 25 12:08:29 mgmt1 dhcpd: DHCPDISCOVER from 52:54:00:19:d9:01 via eth0:1
Oct 25 12:08:30 mgmt1 dhcpd: DHCPOFFER on 10.14.81.42 to
52:54:00:19:d9:01 via eth0:1
Oct 25 12:08:30 mgmt1 dhcpd: DHCPDISCOVER from 52:54:00:19:d9:01 via eth0:1
Oct 25 12:08:30 mgmt1 dhcpd: DHCPOFFER on 10.14.81.42 to
52:54:00:19:d9:01 via eth0:1
Oct 25 12:08:30 mgmt1 dhcpd: DHCPDISCOVER from 52:54:00:19:d9:01 via eth0
Oct 25 12:08:30 mgmt1 dhcpd: DHCPOFFER on 10.14.81.42 to
52:54:00:19:d9:01 via eth0
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#55492: updating zone
'foo.example.com/IN': update unsuccessful: node-19vm1.foo.example.com:
'name not in use' prerequisite not satisfied (YXDOMAIN)
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#48157: updating zone
'foo.example.com/IN': deleting rrset at 'node-19vm1.foo.example.com' A
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#48157: updating zone
'foo.example.com/IN': adding an RR at 'node-19vm1.foo.example.com' A
Oct 25 12:08:32 mgmt1 dhcpd: Added new forward map from
node-19vm1.foo.example.com to 10.14.81.42
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#34461: updating zone
'81.14.10.in-addr.arpa/IN': deleting rrset at '42.81.14.10.in-addr.arpa' PTR
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#34461: updating zone
'81.14.10.in-addr.arpa/IN': adding an RR at '42.81.14.10.in-addr.arpa' PTR
Oct 25 12:08:32 mgmt1 dhcpd: added reverse map from
42.81.14.10.in-addr.arpa. to node-19vm1.foo.example.com
Oct 25 12:08:32 mgmt1 dhcpd: DHCPREQUEST for 10.14.81.42 (10.14.80.6)
from 52:54:00:19:d9:01 via eth0:1
Oct 25 12:08:32 mgmt1 dhcpd: DHCPACK on 10.14.81.42 to 52:54:00:19:d9:01
via eth0:1
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#42903: updating zone
'foo.example.com/IN': update unsuccessful: node-19vm1.foo.example.com:
'name not in use' prerequisite not satisfied (YXDOMAIN)
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#44208: updating zone
'foo.example.com/IN': deleting rrset at 'node-19vm1.foo.example.com' A
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#44208: updating zone
'foo.example.com/IN': adding an RR at 'node-19vm1.foo.example.com' A
Oct 25 12:08:32 mgmt1 dhcpd: Added new forward map from
node-19vm1.foo.example.com to 10.14.81.42
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#42583: updating zone
'81.14.10.in-addr.arpa/IN': deleting rrset at '42.81.14.10.in-addr.arpa' PTR
Oct 25 12:08:32 mgmt1 named[5823]: client 127.0.0.1#42583: updating zone
'81.14.10.in-addr.arpa/IN': adding an RR at '42.81.14.10.in-addr.arpa' PTR
Oct 25 12:08:32 mgmt1 dhcpd: added reverse map from
42.81.14.10.in-addr.arpa. to node-19vm1.foo.example.com
Oct 25 12:08:32 mgmt1 dhcpd: DHCPREQUEST for 10.14.81.42 (10.14.80.6)
from 52:54:00:19:d9:01 via eth0
Oct 25 12:08:32 mgmt1 dhcpd: DHCPACK on 10.14.81.42 to 52:54:00:19:d9:01
via eth0
Oct 25 12:08:33 mgmt1 xinetd[1613]: START: tftp pid=26820 from=10.14.81.42
Oct 25 12:08:33 mgmt1 in.tftpd[26821]: RRQ from 10.14.81.42 filename
/pxelinux.0
Oct 25 12:08:33 mgmt1 in.tftpd[26822]: RRQ from 10.14.81.42 filename
/pxelinux.cfg/83db70ee-f13f-144d-7a4b-592f50325d01
Oct 25 12:08:33 mgmt1 in.tftpd[26823]: RRQ from 10.14.81.42 filename
/pxelinux.cfg/01-52-54-00-19-d9-01
Oct 25 12:08:49 mgmt1 named[5823]: client 127.0.0.1#59861: updating zone
'foo.example.com/IN': update unsuccessful: node-19vm1.foo.example.com:
'name not in use' prerequisite not satisfied (YXDOMAIN)
Oct 25 12:08:49 mgmt1 named[5823]: client 127.0.0.1#56785: updating zone
'foo.example.com/IN': update unsuccessful:
node-19vm1.foo.example.com/TXT: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)
Oct 25 12:08:49 mgmt1 dhcpd: Forward map from node-19vm1.foo.example.com
to 10.14.81.44 FAILED: Has an address record but no DHCID, not mine.
Oct 25 12:08:49 mgmt1 dhcpd: DHCPREQUEST for 10.14.81.44 from
52:54:00:19:d9:01 via eth0:1
Oct 25 12:08:49 mgmt1 dhcpd: DHCPACK on 10.14.81.44 to 52:54:00:19:d9:01
via eth0:1
Oct 25 12:08:49 mgmt1 named[5823]: client 127.0.0.1#42565: updating zone
'foo.example.com/IN': update unsuccessful: node-19vm1.foo.example.com:
'name not in use' prerequisite not satisfied (YXDOMAIN)
Oct 25 12:08:49 mgmt1 named[5823]: client 127.0.0.1#35651: updating zone
'foo.example.com/IN': update unsuccessful:
node-19vm1.foo.example.com/TXT: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)
Oct 25 12:08:49 mgmt1 dhcpd: Forward map from node-19vm1.foo.example.com
to 10.14.81.44 FAILED: Has an address record but no DHCID, not mine.
Oct 25 12:08:49 mgmt1 dhcpd: DHCPREQUEST for 10.14.81.44 from
52:54:00:19:d9:01 via eth0
Oct 25 12:08:49 mgmt1 dhcpd: DHCPACK on 10.14.81.44 to 52:54:00:19:d9:01
via eth0
PXE requested a lease first and got 10.14.81.42 and then at 12:08:49 the
O/S PXE booted requested a specific lease: 10.14.81.44. Shouldn't that
second request have caused the 10.14.81.42 lease to be discarded?
Stopping and starting dhcpd shows the following two leases for that mac
address:
lease 10.14.81.42 {
starts 5 2013/10/25 16:08:32;
ends 5 2013/10/25 22:08:32;
tstp 5 2013/10/25 22:08:32;
cltt 5 2013/10/25 16:08:32;
binding state active;
next binding state free;
hardware ethernet 52:54:00:19:d9:01;
uid "\001RT\000\031\331\001";
set vendorclass = "PXEClient:Arch:00000:UNDI:002001";
set ddns-fwd-name = "node-19vm1.foo.example.com";
set ddns-txt = "3100d50217e933c168082cba8fa0e623c0";
set ddns-rev-name = "42.81.14.10.in-addr.arpa.";
}
lease 10.14.81.44 {
starts 5 2013/10/25 16:08:49;
ends 5 2013/10/25 22:08:49;
tstp 5 2013/10/25 22:08:49;
cltt 5 2013/10/25 16:08:49;
binding state active;
next binding state free;
hardware ethernet 52:54:00:19:d9:01;
set vendorclass = "anaconda-Linux 2.6.32-358.el6.x86_64 x86_64";
}
Which means they are both still valid (active) right? Shouldn't the
first lease have been discarded by the request that resulted in the
second lease?
Additionally, at discard time which should have been at Oct 25 12:08:49
when 10.14.81.44 was requested, I would have expected the DDNS records
to have been removed, making way for the new ones to be installed.
Clearly they were not.
All of that said, I am aware of the previously suggested solution to
just give PXE leases a short duration but that doesn't work with DDNS,
assuming you want your nodes to have a name in DNS while they are booted
in the PXE session. Here's why.
Let's say at exactly 1:00:00, a PXE client gets a lease using a CID and
let's say it's a 60 second lease. At 1:00:00 DDNS records are populated
for the name of the client. The client pxeboots quickly and within 45
seconds the booted operating system requests it's lease (without a CID)
so that's at 1:00:45. The problem is that an attempt to create DDNS
records for the new lease will fail because the lease handed out at
1:00:00 still has it's RRs in DNS and they will be there for 15 more
seconds.
So 15 seconds pass and at the end of the 60 second PXE lease the DDNS
records are removed. But since the lease attained at 1:00:45 (which
failed to install DDNS records due to prerequisite failures) is a 24
hour lease, there will be nothing prodding the installation of DDNS
records for the new lease for 12 more hours (well, 11h, 59m, 15s
technically) when the client requests a renewal. So that's 12h where
there are no DNS records for this host. It could be even worse with
longer leases.
Shortening the PXE leases could work but you'd have to shorten them to a
very small time. Basically they'd have to be guaranteed to expire in
the time between PXE getting a lease and the operating system getting a
lease which according to the above two leases is only 17 seconds. A 15,
or even 10 second lease just seems crazy.
So "duplicate deny" (assuming a discarded lease gets it's DDNS records
removed -- which I would think it should) is the better way to go to
solve this problem. Well that or having the O/S send a lease request
with a CID matching PXE but that's out of scope for this situation as I
have no control over the clients -- and really, the CID could be
anything. Making the O/S of each machine send a lease with a CID that
matches it's PXE is not really a scalable solution.
Thoughts?
b.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20131025/68164c63/attachment.bin>
More information about the dhcp-users
mailing list