Hello,
A note here. fbcadmin sent the dhcp configuration and there is
already an id 17 subnet so changing the id of 10.1.25.0/24 subnet
should not be done unless it is first confirm that there are no leases
from this subnet:
# VLAN37
{
"id": 17,
"subnet": "10.1.37.0/24",
"option-data": [
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "10.1.37.1"
}
],
/// default-valid-lifetime moved from an internal pool scope
"valid-lifetime": 604800,
/// max-valid-lifetime moved from an internal pool scope
"max-valid-lifetime": 604800,
"pools": [
{
"pool": "10.1.37.203 - 10.1.37.249"
}
]
},
Thank you,
Darren Ankney
On Mon, Dec 23, 2024 at 6:32 AM Marcin Siodelski <mar...@isc.org> 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@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
--
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
