[Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
fbcadmin
fbcadmin at fantinibakery.com
Mon Dec 23 12:01:59 UTC 2024
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
>>>>>
>>>>
>>>>
>>>
>
More information about the Kea-users
mailing list