[Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
fbcadmin
fbcadmin at fantinibakery.com
Mon Dec 23 12:37:36 UTC 2024
Hello Darren
So we'll just let the issue run its course and put fixed IP's as
needed. Generally these days we put a fixed IP to switches, printers,
servers etc. This helped us find the 5% that did not have fixed IP's.
Thanks again for all the help.
Merry Christmas or Happy Holidays!
PS: This is the time of year when network upgrades and fine tuning are
usually done in order to get kicked in the head. I mean who does not do
network upgrades at year end?
On 12/23/24 07:13, Darren Ankney wrote:
> Hi,
>
> The lease commands hook is documented here:
> https://kea.readthedocs.io/en/kea-2.6.1/arm/hooks.html#libdhcp-lease-cmds-so-lease-commands-for-easier-lease-management
>
> However, you may not want to just delete a bunch of leases that have
> the wrong subnet ID ... especially dynamic ones. If there is no lease
> for a dynamic ip address, Kea might assign that same IP to a new
> client. The situation should resolve itself over time as leases expire
> (Kea shouldn't be able to update the lease and should fail to renew
> because of the ID mismatch (someone correct me if I am wrong)).
> Perhaps you could deal with these conflicts as they come up instead of
> creating potentially a worse problem with potential duplicate address
> assignments?
>
> Thank you,
> Darren Ankney
>
> On Mon, Dec 23, 2024 at 7:02 AM fbcadmin via Kea-users
> <kea-users at lists.isc.org> wrote:
>> I see , thanks for the info.
>>
>> I use ONA [ OpenNetAdmin IP Address Management (IPAM) system ] to
>> manage our IP info.
>>
>>
>> I had deleted a couple of subnets/vlans .
>>
>> When there are changes to network or hosts, a file is sent to kea-dhcp
>> and I convert with keama to kea-dhcp4.conf .
>>
>> So deleting a couple of subnets caused some of the ID's to be changed.
>>
>> So I will no longer delete or add subnets using ONA. [ eventually I'll
>> use Stork for maintaining network and hosts etc ].
>>
>> --
>>
>> Could you point me to docs or examples to do ' lease_cmds hook library
>> to remove stale leases and leave the current subnet id' ?
>>
>>
>> Thank you for the Help!
>>
>> On 12/23/24 06:31, Marcin Siodelski wrote:
>>> Hello,
>>> You have sent subnet configuration, not lease details. But, that's
>>> also helpful.
>>>
>>> The log you sent before says that the conflicting lease is in the
>>> subnet with "id": 17. The subnet configuration you have sent now shows
>>> that the subnet "id" where the client is connected is 15. This
>>> mismatch is suposedly the primary reason for the issue. The subnet id
>>> should be kept stable during subnet reconfiguration to avoid conflicts
>>> between already allocated leases and the server configuration. Note
>>> that the server records the subnet id in the lease database when it
>>> allocates a lease. I suspect that if you assign "id": 17 to the subnet
>>> "10.1.25.0/24" in the configuration it should eliminate the conflict.
>>> However, if the server allocated new leases in this subnet (with "id"
>>> 15), changing the subnet id to 17 could create conflicts for other
>>> leases.
>>>
>>> The easiest way to deal with this situation could be using lease_cmds
>>> hook library to remove stale leases and leave the current subnet id.
>>> For the future, it is highly recommended to not change the subnet
>>> identifiers during reconfiguration.
>>>
>>> Marcin
>>>
>>> On 23.12.2024 12:13, fbcadmin via Kea-users wrote:
>>>> 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
>>>>>>>
>>>>>>
>> --
>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>
>> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>>
>> Kea-users mailing list
>> Kea-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
More information about the Kea-users
mailing list