Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
Hello Marcin, the situation you described by changing the network card is one example of the bad behavior. The second one is for example when you have device without storage which generates DUID on boot from the MAC address. when you configure kea to assign static IPv6 address using DUID-LL, it assigns the provided static IPv6 address in the reservation, but stores full DUID into the lease file. Thereafter if the devide reboots, the DUID gets different and the thinks this is different device and provides the new IPv6 address from the pool. Marek Sent with Proton Mail secure email. On Monday, December 23rd, 2024 at 9: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 > > [email protected] 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
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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
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
desi
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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
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 fil
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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 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:
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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 adde
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
Hi,
From what you have provided, it appears that the static ip should have
been renewed for the printer. There could be things in your
configuration that influence this, however. Could you provide your
configuration file?
Thank you,
Darren Ankney
On Sun, Dec 22, 2024 at 8:26 PM fbcadmin via Kea-users
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] (0x)
> 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] (0x)
> 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
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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
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 any
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
Hello
The reservations for 2 of the 3 KVM's have been there since we
switched over to KEA.
thank you for looking and responding to this.
On 12/23/24 01:44, Marek Greško 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
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]
(0x)
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] (0x)
*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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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
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
Re: [Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT issue
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
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] (0x)
> 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] (0x)
> 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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
