Request on offered address gives "unknown lease"

[Peter Rathlev]

Dear all,

We're testing some new software on a client device (a switch) and can
see that it doesn't get an IP address lease correctly. Considering the
error appeared when we started testing the new software we're convinced
it's the client's fault. Still I would like to understand what goes
wrong. The server is a v4.3.6b1 failover setup. Both servers log the
same messages, I have only included from the primary below.

We see ostensibly correct DISCOVER packets, followed but OFFERs from
the servers as usual. And then a REQUEST from the client, but one which
the server doesn't seem to like. It logs "unknown lease" even though
the IP address matches the offer.

How would one troubleshoot this? As mentioned, we're pretty sure the
client is at fault.

The server logs the following:

Oct 24 12:31:25 gauss dhcpd: DHCPDISCOVER from 00:c0:29:26:43:fa (NEXANS-00C0292643FA) via 10.230.177.2
Oct 24 12:31:25 gauss dhcpd: DHCPOFFER on 10.230.177.173 to 00:c0:29:26:43:fa (NEXANS-00C0292643FA) via 10.230.177.2
Oct 24 12:31:25 gauss dhcpd: DHCPDISCOVER from 00:c0:29:26:43:fa (NEXANS-00C0292643FA) via 10.230.177.2
Oct 24 12:31:25 gauss dhcpd: DHCPOFFER on 10.230.177.173 to 00:c0:29:26:43:fa (NEXANS-00C0292643FA) via 10.230.177.2
Oct 24 12:31:25 gauss dhcpd: DHCPDISCOVER from 00:c0:29:26:43:fa (NEXANS-00C0292643FA) via 10.230.177.3
Oct 24 12:31:25 gauss dhcpd: DHCPOFFER on 10.230.177.173 to 00:c0:29:26:43:fa (NEXANS-00C0292643FA) via 10.230.177.3
Oct 24 12:31:25 gauss dhcpd: DHCPREQUEST for 10.230.177.173 (10.83.45.30) from 00:c0:29:26:43:fa via 10.230.177.2: unknown lease 10.230.177.173.
Oct 24 12:31:25 gauss dhcpd: DHCPREQUEST for 10.230.177.173 (10.83.45.30) from 00:c0:29:26:43:fa via 10.230.177.2: unknown lease 10.230.177.173.
Oct 24 12:31:25 gauss dhcpd: DHCPREQUEST for 10.230.177.173 (10.83.45.30) from 00:c0:29:26:43:fa via 10.230.177.3: unknown lease 10.230.177.173.

Capturing the packets doesn't reveal anything that to my eye seems out
of the ordinary. Below is an example transaction -- the UDP checksum
warning on sent packets is caused by offloading.

Can anyone spot what makes the server say "unknown lease" to something
it just offered?

1) DISCOVER:

12:31:25.276152 IP (tos 0x0, ttl 251, id 31051, offset 0, flags [none], proto UDP (17), length 328)
    10.230.177.2.67 > 10.83.45.30.67: [udp sum ok] BOOTP/DHCP, Request from 00:c0:29:26:43:fa, length 300, hops 1, xid 0x534b4895, secs 4321, Flags [Broadcast] (0x8000)
      Gateway-IP 10.230.177.2
      Client-Ethernet-Address 00:c0:29:26:43:fa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Vendor-Class Option 60, length 7: "266:074"
        Client-ID Option 61, length 7: ether 00:c0:29:26:43:fa
        Hostname Option 12, length 19: "NEXANS-00C0292643FA"
        Parameter-Request Option 55, length 5: 
          Subnet-Mask, Default-Gateway, Hostname, TFTP
          BF
        END Option 255, length 0
        PAD Option 0, length 0, occurs 10

2) OFFER:

12:31:25.276399 IP (tos 0x0, ttl 64, id 60569, offset 0, flags [DF], proto UDP (17), length 355)
    10.83.45.30.67 > 10.230.177.2.67: [bad udp cksum 0xf4b9 -> 0xfaba!] BOOTP/DHCP, Reply, length 327, hops 1, xid 0x534b4895, secs 4321, Flags [Broadcast] (0x8000)
      Your-IP 10.230.177.173
      Server-IP 10.83.247.20
      Gateway-IP 10.230.177.2
      Client-Ethernet-Address 00:c0:29:26:43:fa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 10.83.45.30
        Lease-Time Option 51, length 4: 900
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 10.230.177.1
        TFTP Option 66, length 12: "10.83.12.190"
        BF Option 67, length 43: "/266:074/10.230.177/NEXANS-00C0292643FA.cfg"
        END Option 255, length 0

3) REQUESTs:

12:31:25.287800 IP (tos 0x0, ttl 251, id 31059, offset 0, flags [none], proto UDP (17), length 330)
    10.230.177.2.67 > 10.83.45.30.67: [udp sum ok] BOOTP/DHCP, Request from 00:c0:29:26:43:fa, length 302, hops 1, xid 0x534b4895, secs 4321, Flags [Broadcast] (0x8000)
      Client-IP 255.255.255.255
      Gateway-IP 10.230.177.2
      Client-Ethernet-Address 00:c0:29:26:43:fa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Vendor-Class Option 60, length 7: "266:074"
        Client-ID Option 61, length 7: ether 00:c0:29:26:43:fa
        Requested-IP Option 50, length 4: 10.230.177.173
        Server-ID Option 54, length 4: 10.83.45.30
        Hostname Option 12, length 19: "NEXANS-00C0292643FA"
        Parameter-Request Option 55, length 5: 
          Subnet-Mask, Default-Gateway, Hostname, TFTP
          BF
        END Option 255, length 0

12:31:25.287842 IP (tos 0x0, ttl 251, id 31060, offset 0, flags [none], proto UDP (17), length 330)
    10.230.177.2.67 > 10.83.45.30.67: [udp sum ok] BOOTP/DHCP, Request from 00:c0:29:26:43:fa, length 302, hops 1, xid 0x534b4895, secs 4321, Flags [Broadcast] (0x8000)
      Client-IP 255.255.255.255
      Gateway-IP 10.230.177.2
      Client-Ethernet-Address 00:c0:29:26:43:fa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Vendor-Class Option 60, length 7: "266:074"
        Client-ID Option 61, length 7: ether 00:c0:29:26:43:fa
        Requested-IP Option 50, length 4: 10.230.177.173
        Server-ID Option 54, length 4: 10.83.45.30
        Hostname Option 12, length 19: "NEXANS-00C0292643FA"
        Parameter-Request Option 55, length 5: 
          Subnet-Mask, Default-Gateway, Hostname, TFTP
          BF
        END Option 255, length 0

12:31:25.288727 IP (tos 0x0, ttl 249, id 11221, offset 0, flags [none], proto UDP (17), length 330)
    10.230.177.3.67 > 10.83.45.30.67: [udp sum ok] BOOTP/DHCP, Request from 00:c0:29:26:43:fa, length 302, hops 1, xid 0x534b4895, secs 4321, Flags [Broadcast] (0x8000)
      Client-IP 255.255.255.255
      Gateway-IP 10.230.177.3
      Client-Ethernet-Address 00:c0:29:26:43:fa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Vendor-Class Option 60, length 7: "266:074"
        Client-ID Option 61, length 7: ether 00:c0:29:26:43:fa
        Requested-IP Option 50, length 4: 10.230.177.173
        Server-ID Option 54, length 4: 10.83.45.30
        Hostname Option 12, length 19: "NEXANS-00C0292643FA"
        Parameter-Request Option 55, length 5: 
          Subnet-Mask, Default-Gateway, Hostname, TFTP
          BF
        END Option 255, length 0

We tried clearing the leases (omitting them from the pool altogether
and restarting) but saw the exact same error on new addresses.

Thank you in advance for any clues. :-)

--
Peter Rathlev

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

On Tue, 2017-10-24 at 13:10 +0200, Peter Rathlev wrote:
> We're testing some new software on a client device (a switch) and can
> see that it doesn't get an IP address lease correctly. Considering
> the error appeared when we started testing the new software we're
> convinced it's the client's fault.

Bonus info: When we move the switch to a network served by a Windows
DHCP server (not sure exactly what version, but probably Windows Server
2012) the switch accepts a lease.

The switch doesn't log anything, it seems to just see an unanswered
request.

And to the perceptive: Yes, I copy+pasted some wrong packets, one of
them is from a different relay than the other. The contents are the
same though. (There are two Cisco L3 switch relays and two servers.)

- -
Peter

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[perl-list]

I don't know what caused that in our case, but I did see this once when our primary DHCP server died. The secondary was struggling handing out leases having not enough addresses to hand out and so on. I saw some messages similar to yours in the logs:

"Oct 24 12:31:25 gauss dhcpd: DHCPREQUEST for 10.230.177.173 (10.83.45.30) from 00:c0:29:26:43:fa via 10.230.177.3: unknown lease 10.230.177.173."

Specifically the unknown lease and noticed the address in parens that isn't usually there (unless that packet was meant for the other server in the  failover pair).

In my case, the address in parens was the secondary that was still up.  I never found out what the deal was as these were production and we needed them to work.  We disabled failover and everything then worked fine.  

Was a bear to get the servers back in to failover later, but that is another story.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

On Tue, 2017-10-24 at 13:10 +0200, Peter Rathlev wrote:
> We're testing some new software on a client device (a switch) and can
> see that it doesn't get an IP address lease correctly.
...

I tried capturing a request from an older device and am seeing a clear
difference. Specifically the newer (not functioning) software fills out
the "Client-IP" (ciaddr) field with 255.255.255.25 where the old does
not, i.e. leaves it at all zeros.

As I read RFC2131 any client requesting a fresh lease (not renewing)
should never fill out ciaddr. In this case it uses 255.255.255.255,
which is clearly invalid, but it's still wrong.

This means we have something to go to the vendor with.

Assuming this is the reason dhcpd doesn't answer the request, is there
a handle to make it accept packets with wrong ciaddr, just to make sure
this is the actual and only error?

--
Peter Rathlev

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users