[Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
fbcadmin
fbcadmin at fantinibakery.com
Mon Dec 23 11:13:00 UTC 2024
Hello,
here are the lease details
# VLAN25
{
"id": 15,
"subnet": "10.1.25.0/24",
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "10.1.25.1"
}
],
..
{
"hostname": "p132.fantinibakery.com",
"ip-address": "10.1.25.132",
"hw-address": "b4:22:00:26:35:b5"
},
if more info is needed let me know.
thanks for helping on this.
On 12/23/24 03:19, Marcin Siodelski wrote:
> Marek,
> Kea implements a lease conflict resolution mechanism described here:
> https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#conflicts-in-dhcpv4-reservations.
> This mechanism deals with situations when the requesting client has a
> lease and it gets the reservation for another one, or the client gets
> a lease and later a reservation, but another client is using this new
> reservation.
>
> If a client has a lease for an address but an administrator creates a
> reservation for another address for this client, the client will be
> allocated the reservation if there is nobody else using this address.
> If there is another client using this address the client having a
> reservation cannot be allocated this address until the other client
> releases it or the lease expires for this other client. The other
> client should stop using this address as soon as it tries to renew
> because the server would send DHCPNAK to the client currently using
> the lease and the client will get another address doing the 4-way
> exchange. The lease the client was using is now free for allocation
> for the client having the reservation. The client having the
> reservation gets the reserved lease when it retries (renews).
>
> I am not sure what you exactly mean by referring to the "major design
> flaw in Kea" using the lease file precedence. There are indeed cases
> when the lease file has a precedence but that's when the lease cannot
> be allocated to the client because it is used by another client. I
> guess you could have a situation when you replace network card in the
> device now appearing as another client and you'd want Kea to reuse the
> client lease without conflict resolution described above. However,
> DHCP server has no means to determine whether the request comes from
> the same or different device. It merely sees MAC address. If nothing
> else you can always delete the lease manually.
>
> As for the problem described by fbcadmin, it does seem like something
> has changed in the server configuration. The server sees the lease
> allocated toMAC: [hwtype=1 b4:22:00:26:35:b5] / client_id:
> [01:b4:22:00:26:35:b5] which is the same as the reservation, but the
> server doesn't think this lease belongs to this client. There are a
> couple of possible reasons for it:
>
> - match-client-id settings have changed,
> - subnet-id has changed for the subnet where this client is connected
> (so the subnet-id in the lease is different),
> - client-classes have changed in the subnet where this client is
> connected and the client no longer matches the classes,
>
> It would be useful to see the lease details for 10.1.25.132. We could
> compare the subnet-id at least to see if it matches. If the lease is
> not renewed, it should eventually expire and be allocated to the
> client that has a reservation. As a workaround, you should be able to
> delete this lease. However, to make sure we know what is going on,
> existing lease details would be helpful.
>
> Marcin Siodelski
> ISC
>
>
> On 23.12.2024 07:44, Marek Greško via Kea-users wrote:
>> Hello,
>>
>> I suspect, you just hit major design flaw of the kea. It is storing
>> the reservation into the lease file and the lease has precedence when
>> responding to the client. So if your client asked for a ip address
>> and received some from the pool and you added the reservation after
>> that, you will always get the ip address from the lease. Is not this
>> your issue also?
>>
>> Marek
>>
>> On Monday, December 23rd, 2024 at 2:26, fbcadmin via Kea-users
>> <kea-users at lists.isc.org> wrote:
>>>
>>> Hello
>>>
>>> we have some hosts setup with reservations , which are instead
>>> getting a pool address.
>>>
>>>
>>> this printer which should have 10.1.25.132 but got 10.1.25.183 .
>>> this printer and another get used overnight so we had to temporarily
>>> change the IP address at the cups print server . *
>>> *
>>>
>>>
>>> In the mean time we'll look at the programming on some of our
>>> recently replaced managed switches. I suspect pvid is incorrect on
>>> some ports or dhcp relay setting... I had been working on network
>>> security settings - like limiting which vlans are accessible from
>>> some downstream switches..
>>>
>>> in addition we use proxmox to manage our virtual machines. all
>>> debian KVM's which used dhcp-client had wrong addresses . windows
>>> are okay. LXC's are okay. a lot of testing and debugging was done.
>>> details are at
>>> https://forum.proxmox.com/threads/dhcp-issue-with-kvm-lxc-does-not-have-the-issue.159440/#post-731975
>>>
>>> here is some debugging info for a host that has this reservation.
>>> *If anyone has I suggestion on where to look to solve the issue I am
>>> all ears*! [ except the next 7 hours for sleep.]
>>>
>>> {
>>> "hostname": "p132.fantinibakery.com",
>>> "ip-address": "10.1.25.132",
>>> "hw-address": "*b4:22:00:26:35:b5*"
>>> },
>>>
>>>
>>>
>>> sudo tcpdump -i eth0 port 67 or port 68 -e -n -vv
>>>
>>> 10.1.25.132 p132.fantinibakery.com p132
>>> the following s/b p132:
>>>
>>> 18:55:34 ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1
>>> b4:22:00:26:35:b5], cid=[01:b4:22:00:26:35:b5], tid=0x1237:
>>> conflicting reservation for address 10.1.25.132 with existing lease
>>> Address: 10.1.25.132
>>> Valid life: 604800
>>> Cltt: 1734607378
>>> Hardware addr: *b4:22:00:26:35:b5*
>>> Client id: 01:b4:22:00:26:35:b5
>>> Subnet ID: 17
>>> Pool ID: 0
>>> State: default
>>> Relay ID: (none)
>>> Remote ID: (none)
>>>
>>> 19:02:21.603380 1c:34:da:f4:05:0e > bc:24:11:e2:1d:b8, ethertype
>>> IPv4 (0x0800), length 355: (tos 0x0, ttl 64, id 59862, offset 0,
>>> flags [DF], pro
>>> to UDP (17), length 341)
>>> 10.1.3.202.67 > 10.1.3.15.67: [udp sum ok] BOOTP/DHCP, Request from
>>> *b4:22:00:26:35:b5*, length 313, hops 1, xid 0xdc07, Flags [none]
>>> (0x0000)
>>> Gateway-IP 10.1.25.9
>>> Client-Ethernet-Address b4:22:00:26:35:b5
>>> Vendor-rfc1048 Extensions
>>> Magic Cookie 0x63825363
>>> DHCP-Message (53), length 1: Discover
>>> Client-ID (61), length 7: ether b4:22:00:26:35:b5
>>> Hostname (12), length 15: "BRNB422002635B5"
>>> Parameter-Request (55), length 11:
>>> Domain-Name-Server (6), Default-Gateway (3), Subnet-Mask (1),
>>> Domain-Name (15)
>>> TFTP (66), BF (67), BS (13), Netbios-Name-Server (44)
>>> Time-Zone (2), NTP (42), Hostname (12)
>>> Agent-Information (82), length 28:
>>> Circuit-ID SubOption 1, length 6: bond19
>>> Remote-ID SubOption 2, length 18: 1c:34:da:f4:05:00^J
>>>
>>>
>>> 19:02:21.604284 bc:24:11:e2:1d:b8 > 1c:34:da:f4:05:0e, ethertype
>>> IPv4 (0x0800), length 418: (tos 0x10, ttl 128, id 0, offset 0, flags
>>> [DF], proto
>>> UDP (17), length 404)
>>> 10.1.3.15.67 > 10.1.25.9.67: [udp sum ok] BOOTP/DHCP, Reply, length
>>> 376, hops 1, xid 0xdc07, Flags [none] (0x0000)
>>> *Your-IP 10.1.25.183 *
>>> Gateway-IP 10.1.25.9
>>> Client-Ethernet-Address b4:22:00:26:35:b5
>>> Vendor-rfc1048 Extensions
>>> Magic Cookie 0x63825363
>>> DHCP-Message (53), length 1: Offer
>>> Subnet-Mask (1), length 4: 255.255.255.0
>>> Time-Zone (2), length 4: -5
>>> Default-Gateway (3), length 4: 10.1.25.1
>>> Domain-Name-Server (6), length 12: 127.0.0.1,10.1.3.41,10.1.3.40
>>> Hostname (12), length 22: "p132.fantinibakery.com"
>>> Domain-Name (15), length 17: "fantinibakery.com"
>>> NTP (42), length 4: 10.1.0.2
>>> Lease-Time (51), length 4: 604800
>>> Server-ID (54), length 4: 10.1.3.15
>>> Client-ID (61), length 7: ether b4:22:00:26:35:b5
>>> Agent-Information (82), length 28:
>>> Circuit-ID SubOption 1, length 6: bond19
>>> Remote-ID SubOption 2, length 18: 1c:34:da:f4:05:00^J
>>>
>>
>>
>
More information about the Kea-users
mailing list