Question about leases
Darren
perl-list at network1.net
Mon Apr 17 16:07:36 UTC 2006
David,
This problem is actually a bit "stranger" than just these lease
entries. Let me show you some sample output (keep in mind, many other
clients are functioning properly on this network):
first the version question
primary:
# dhcpd -v
Internet Systems Consortium DHCP Server V3.0.3
secondary:
# dhcpd -v
Internet Systems Consortium DHCP Server V3.0.3
second, this client cannot obtain an IP address to begin with.
Here are some very interesting (strange?) entries from the logfile:
primary server:
Apr 14 17:42:42 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:42 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:42:44 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:44 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:42:48 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:48 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:42:57 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:57 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:43:13 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:43:13 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:46:28 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:46:28 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:50:48 patriot-1 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:50:48 patriot-1 dhcpd: DHCPOFFER on 69.63.5.88 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
secondary server:
Apr 14 17:42:42 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:42 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:42:44 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:44 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:42:48 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:48 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:42:57 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:42:57 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:43:13 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:43:13 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:46:28 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:46:28 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
Apr 14 17:50:48 patriot-2 dhcpd: DHCPDISCOVER from 00:40:05:b2:70:ac
(DI-614+) via 216.51.227.1
Apr 14 17:50:48 patriot-2 dhcpd: DHCPOFFER on 216.51.139.130 to
00:40:05:b2:70:ac (DI-614+) via 216.51.227.1
As you can see, the two servers are even offering the Dlink 614+ two
different IP Addresses. According to the ISP, a packet sniff shows that
the offer packets are reaching the client and are being ignored for some
reason.
A packet sniff at the server end seems to show that the two discover
packets are identical at the protocol layer.
Very perplexing.
David W. Hankins wrote:
>On Mon, Apr 17, 2006 at 09:46:47AM -0400, Darren wrote:
>
>
>>We have v.3.0.3 of ISC DHCP in a failover setup.
>>
>>
>
>Are you sure one of them isn't running 3.0.2?
>
> Changes since 3.0.2
>
>- A bug was repaired where failover servers would let stale client identifiers
> persist on leases that were reallocated to new clients not sending an id.
>
>
>
>>Between the two servers, all fields match, save the following:
>>
>> primary secondary
>> tstp 5 2006/04/14 19:34:55; tstp 3 2006/04/12 21:49:54;
>>
>>
>
>TSTP is Time Sent To Peer. These are likely to mismatch. It's set
>depending on the server's state at that given moment. It's not set
>when an update is received from a peer and acked (it's rather useless
>to set it, and the mismatches here help us 'breadcrumb' multiple lease
>db entries into a picture of what happened).
>
>
>
>> client-hostname "DI-614+";
>>
>>
>
>I can't remember if this is synced via the failover channel. I
>suspect it isn't. It has (happily) been a few months since I
>have last delved into server/failover.c. I know it's possible to
>sync this via failover, I just don't think we do that today.
>
>So I don't think that's a bug.
>
>
>
>> uid "\001\000\024l\227\001\243";
>>
>>
>
>That's a bug I thought we fixed in 3.0.3.
>
>
>
>>Any idea why this would be? A relay agent forwards the discover
>>messages to the two servers, so they should be exactly the same, should
>>they not?
>>
>>
>
>The output depends on the input. What information each server was
>acting upon at the time they made the change (which may be different
>if the other server is sending failover protocol binding updates in
>between messages).
>
>The uid thing is a clear bug however. It's curious that it is
>persisting on your secondary. When the primary sends a binding
>update to indicate the new ownership of the lease, it should be
>moved to active state, and the uid stripped.
>
>And the secondary certainly should not be NAKing a REQUEST for this
>lease as it is in the free state (it just can't serve that request
>with an ACK since it can only touch active and backup leases). It
>should only NAK requests for active leases that have a uid binding.
>
>That's how the bug manifested in 3.0.2 and prior.
>
>
>
More information about the dhcp-users
mailing list