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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
