Re: [Kea-users] Problem using 'config-set' in API

[Veronique Lefebure]

Hi,
config-set will rewrite the whole config file. You cannot "append" a 
configuration bit. To do so you need to use the API.
Cheers,
V.

From: Kea-users  on behalf of Andrew Mulheirn 
via Kea-users 
Sent: Tuesday, March 5, 2024 10:06 AM
To: kea-users@lists.isc.org 
Cc: Andrew Mulheirn 
Subject: [Kea-users] Problem using 'config-set' in API


Hi,



I am trying to use the API and reading it seems to work fine.  However, when I 
write to it using a config-set action, it seems to stop working until I restart 
the service.  Here is an example of what I am sending in the API call.   I am 
trying to add an IP address reservation for a device connected on a particular 
switch port (using option 18):



{

"command": "config-set",

"service": [ "dhcp6" ],

"arguments":  {

"Dhcp6": {

"subnet6": [

{

"subnet": "2a00:e300:1102::/64",

"reservations": [

{

"flex-id": "'xe-0/0/4:rsw001'",

"ip-addresses": [ "2a00:e300:1102::8" ]

}

]

}

]

}

}

}





Perhaps I have misread the documentation – do I need to be sending the entire 
config in the config-set command?  Or can I add IP address reservations in an 
additive way like I am trying to do here?

Any help appreciated,



Kind regards,

Andy

Andrew Mulheirn

Senior Network Architect

M: +44 (0) 74 3654 8126 

E: andrew.mulhe...@vorboss.com 

vorboss.com 


Not sure who currently provides your internet?
Find out here and take our speed test. 


Disclaimer: This message is private and confidential. If you have received this 
message in error, please remove it from your system and notify us at 
sysad...@vorboss.net  or by telephone +44(0)20 
3582 8500. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon, this information by persons or entities other 
than the intended recipient is prohibited.   Privacy Note: Vorboss Limited may 
monitor email traffic data and also the content of email for the purposes of 
security. This email does not create or vary any contractual obligations 
between Vorboss Limited and the intended recipient.

Vorboss Limited is a limited company registered in England and Wales. 
Registered number: 05678571. Registered Office: Vorboss Limited, Broadwalk 
House, 5 Appold Street, London, EC2A 2AG, UNITED KINGDOM.
-- 
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

Re: [Kea-users] Kea 2.4.0 and duplicate host reservations not working as documented

[Veronique Lefebure]

Maybe https://gitlab.isc.org/isc-projects/kea/-/issues/2796 ?
[https://gitlab.isc.org/uploads/-/system/project/avatar/26/kea-logo-100x70.png]
"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign 
lease to reserved host) (#2796) · Issues · ISC Open Source Projects / Kea · 
GitLab
When resolving conflicts between active leases and host reservations, Kea 
relies on the client with the active lease to cooperate. When lease times are 
long, and the client...
gitlab.isc.org


From: Kea-users  on behalf of Darren Ankney 

Sent: Sunday, October 22, 2023 8:38 PM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] Kea 2.4.0 and duplicate host reservations not working 
as documented

Hi Kevin,

I thought there was already an open or closed issue about this, but I
didn't find one...

Thank you,

Darren Ankney

On Sun, Oct 22, 2023 at 10:32 AM Kevin P. Fleming
 wrote:
>
> On Sun, Oct 22, 2023, at 10:17, Darren Ankney wrote:
> > It then goes on to print details about the existing lease.  You could
> > possibly use the flex-id hook to overcome this (in certain situations
> > where there is something else to use as the identifier such as
> > circuit-id).  Alternatively, you could use the API to delete the lease
> > for 192.168.88.192 soon after granting so that it is free for your
> > other interface.  However, this could lead to strangeness should the
> > original interface try to renew (because the lease will no longer be
> > found and renewal will fail).  If it's possible, it would be best to
> > assign a separate address for each interface on the system.
>
> Thanks, at least I understand why this is happening now.
>
> I've tried other ways to address this on the client side (trying to use a 
> stable DUID or CID to have Kea think it's the same client regardless of 
> interface), but that doesn't seem to work out well either.
>
> The primary problem I'm solving here is that this client makes a lot of 
> outbound SSH connections to other machines on the network, and in order to 
> speed these up SSH persistent control channels are used. If the client 
> attempts to re-establish one of these connections after its IP address has 
> changed, SSH will just hang for quite a long time. Clearly the SSH client 
> could handle this better, but having a stable IP address is a more 
> straightforward fix.
>
> If there's no ticket open as a feature request for Kea to provide a method 
> for the existing leases to be ignored when a new REQUEST comes in, I'll 
> happily create one.
> --
> 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
-- 
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

Re: [Kea-users] multiple MACs to same IP

[Veronique Lefebure]

Hi,

On that topic, I see that [Kea-users] ip-reservations-unique and lease conflict 
(isc.org) 
did not get an answer.
Has anyone else encountered the same issue as Marc ?

Thanks,
Veronique

From: Kea-users  on behalf of Peter Davies 

Sent: Tuesday, October 10, 2023 6:47 AM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] multiple MACs to same IP

Hi -m,
You can use the "ip-reservations-unique": false,
See:
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#multiple-reservations-for-the-same-ip

/Peter

On 10/10/2023 02.41, Matt Zagrabelny via Kea-users wrote:
> Greetings,
>
> I'm migrating from ISC DHCPD to Kea.
>
> I have a laptop on my network that I want to get the same IP address
> if it is connected via wifi or if it is plugged in to hard-wired
> ethernet. This was possible in ISC DHCPD.
>
> In Kea I have database entries:
>
> # select * from hosts_human where hostname  ~ 'zirconium';
> hostname│mac_address│  ip_address
> ╪═══╪═══
>  zirconium-wlo1 │ bc:17:b8:cb:8b:94 │ 192.168.0.226
>  zirconium-eno1 │ 0c:37:96:1f:04:ef │ 192.168.0.226
> (2 rows)
>
> ..but I get errors from the server:
>
> Oct 09 19:21:07 zed kea-dhcp4[5515]: INFO  DHCP4_LEASE_ADVERT
> [hwtype=1 bc:17:b8:cb:8b:94], cid=[01:bc:17:b8:cb:8b:94],
> tid=0x2c7fc3e4: lease 192.168.0.226 will be advertised
> Oct 09 19:21:07 zed kea-dhcp4[5515]: ERROR ALLOC_ENGINE_V4_ALLOC_ERROR
> [hwtype=1 bc:17:b8:cb:8b:94], cid=[01:bc:17:b8:cb:8b:94],
> tid=0x2c7fc3e4: error during attempt to allocate an IPv4 address:
> multiple records were found in the database where only one was
> expected for query get_host_subid_addr
>
> Am I missing something to allow this particular configuration?
>
> Or is it not possible in Kea (to do what was possible in ISC DHCPD)?
>
> Thanks for any help!
>
> -m
>
--
Peter Davies
Support Engineer
Internet Systems Corporation

--
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

[Kea-users] KEA DHCPv6 on Alma8 or RHEL8 clients

[Veronique Lefebure]

Hi,

Is there anyone using KEA, for DHCPv6 clients that run OS Alma8 or Rhel8, with 
host-reservations (fixed IP addresses) ?

If yes, do you know if the clients are requesting option 39 = CLIENT_FQDN ?

Thanks,
Veronique

-- 
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

Re: [Kea-users] ARM port suggestions for HA+MT mode when Kea is serving both V4 and V6

[Veronique Lefebure]

Hi,
My experience is that you have to use different ports indeed.
Cheers,
Veronique

From: Kea-users  on behalf of Darren Ankney 

Sent: Tuesday, September 26, 2023 11:43 AM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] ARM port suggestions for HA+MT mode when Kea is 
serving both V4 and V6

Hi Kevin,

One might assume that it would be best for the v4 examples to use v4
addresses and the v6 examples to use v6 addresses regardless of port.
Looking through the ARM, I only found one example that was for Dhcp6.
However, this example did not feature any listener addresses.  It was
used to illustrate a specific setting of "parked-packet-limit"
(https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#parked-packet-limit).
I didn't re-read the entire HA section.  Perhaps it mentions the need
to use different ports or addresses between v4 and v6 (and control
agent)?

Thank you,

Darren Ankney

On Mon, Sep 25, 2023 at 5:16 PM Kevin P. Fleming
 wrote:
>
> In the before times, when HA was typically deployed using communication 
> through the Control Agent, the 'url' specified in the HA section of the DHCP4 
> and DHCP6 configs for any given peer could be the same, because that peer was 
> only running one instance of the Control Agent.
>
> In the new world, with HA+MT in place, each DHCP server needs a separate port 
> (or the same port but on a different address) in order to avoid conflicts. In 
> spite of this, the ARM suggests using port 8001 (to avoid the default of 8000 
> for the Control Agent), but doesn't address the situation where both DHCP4 
> and DHCP6 are running on each peer in the HA+MT configuration.
>
> I'm not sure whether it's better to suggest that the V4 and V6 server 'url' 
> parameters contain distinct ports, or contain distinct addresses... but one 
> of those is necessary to avoid conflicts.
> --
> 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
-- 
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

Re: [Kea-users] Possible bug with Kea DHCP Server?

[Veronique Lefebure]

Hi Chib,
Have you checked if the client is requesting the IP with the same ClientID as 
the one it was using when it first got the lease ?
Cheers,v.

From: Kea-users  on behalf of Stephen Dennis 
(Gmail) 
Sent: Monday, September 11, 2023 3:43 AM
To: kea-users@lists.isc.org 
Subject: [Kea-users] Possible bug with Kea DHCP Server?

Hi,

After a client received a lease, the client was rebooting.
It tried to ask for the same IP (Windows machine), but Kea refused with this 
error, despite the fact that Kea has a reservation for that client's MAC:
"2023-09-10 22:38:00.308 WARN  [kea-dhcp4.alloc-engine/2752.140528795599552] 
ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 xx:xx:xx:xx:xx:xx], 
cid=[01:xx:xx:xx:xx:xx:xx], tid=0xb4da0bab: conflicting reservation for address 
192.168.1.11 with existing lease Address:   192.168.1.11"

1. Why would Kea not just answer the client with the same IP already assigned 
to that client?
2. Is there no mechanism in place to deal with the case where a client reboots 
and has to resend a DHCPREQUEST during an existing lease for that client?

This, to me, looks like a bug.

Thanks,
Chib

Disclaimer:
If you are not the intended recipient of this message
 (a) you MUST NOT copy, forward, print, save, disclose or otherwise distribute, 
make use of or rely upon any of the message content,
 (b) you MUST delete it immediately and notify the Sender of the delivery error.
The Sender CANNOT guarantee that
 (a) this message has not been corrupted or altered during transmission,
 (b) this message has not been fraudulently produced by an untrusted third 
party.
The contents of this message is PRIVATE and
 (a) it MAY NOT necessarily express the views held by the Sender,
 (b) it MAY contain information that is proprietary or confidential to the 
Sender,
 (c) SHALL NOT bind the Sender to any contract or order unless explicitly 
allowed by prior written agreement or by applicable law.
-- 
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

Re: [Kea-users] got unexpected keyword "valid-lifetime" in reservations map.

[Veronique Lefebure]

I don't know. You should probably test, or get the answer of an expert.

From: Kraishak Mahtha 
Sent: Wednesday, February 22, 2023 11:19 AM
To: Veronique Lefebure 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] got unexpected keyword "valid-lifetime" in 
reservations map.

Hi Veronique,

So for a reservation entry, if we want to define a lease time that is different 
from subnet can we do as follows? i.e define only the option 
51(dhcp-lease-time) will this be efficient ?
"subnet4": [
  {
 "subnet": "4.0.0.0/16<http://4.0.0.0/16>",
 "valid-lifetime": 3600,
 "reservations": [
{
   "ip-address": "4.0.255.243",
   "hostname": "3G00034Phone",
   "valid-lifetime": 126,
   "hw-address": "aa:bb:cc:dd:ee:55",
   "option-data": [
  {
 "data": "126",
 "name": "dhcp-lease-time"
  },
  {
 "data": "4.0.0.1",
 "name": "routers"
  }
   ]
}
 ],
 "option-data": [
{
   "data": "test.com<http://test.com>",
   "name": "domain-name"
},
{
   "data": "255.255.0.0",
   "name": "subnet-mask"
    },
{
   "data": "4.0.0.1",
   "name": "routers"
}
 ],
 "pools": [
{
   "pool": "4.0.0.2-4.0.0.202"
}
 ],
 "id": 843191
  }
   ]

Thanks
Kraishak

On Wed, Feb 22, 2023 at 3:18 PM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,
If you look at https://kea.readthedocs.io/en/latest/grammar/grammar.html you 
can see that valid_life_time is not an attribute of host-reservations:


reservation_param ::= duid
 753   | reservation_client_classes
 754   | client_id_value
 755   | circuit_id_value
 756   | flex_id_value
 757   | ip_address
 758   | hw_address
 759   | hostname
 760   | option_data_list
 761   | next_server
 762   | server_hostname
 763   | boot_file_name
 764   | user_context
 765   | comment
 766   | unknown_map_entry

Cheers,
Veronique

From: Kea-users 
mailto:kea-users-boun...@lists.isc.org>> on 
behalf of Kraishak Mahtha 
mailto:kraishak@gmail.com>>
Sent: Wednesday, February 22, 2023 10:35 AM
To: kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> 
mailto:kea-users@lists.isc.org>>
Subject: [Kea-users] got unexpected keyword "valid-lifetime" in reservations 
map.

Hi All,

I am using the kea-dhcp of 2.2.0 version, I am trying to add a reservation 
entry along with a valid lifetime option value but I am facing the syntax issue 
saying "got unexpected keyword "valid-lifetime" in reservations map".

kea-dhcp4 -t kea-dhcp4.conf. --> syntax validator
Syntax check failed with:  kea-dhcp4.conf  :59.7-22: got unexpected keyword 
"valid-lifetime" in reservations map.

I took a sample example from the forums and tried as below:
"subnet4": [{
"subnet": "4.0.0.0/16<http://4.0.0.0/16>",
"valid-lifetime": 3600,
"option-data": [
{
"data": "test.com<http://test.com>",
"name": "domain-name"
},
{
"data": "255.255.0.0",
"name": "subnet-mask"
},
{
"data": "99.99.99.99",
"name": "routers"
}
],
"pools": [{
"pool": "4.0.0.2-4.0.0.202"
}],
"id": 843191
}],
 "reservations": [
{
  "hw-address": "01:23:45:67:89:ab",
  "ip-address": "4.0.0.223",
  "hostname": "example.com<http://example.com>",
  "valid-lifetime": 86400
}
  ]

I tried moving the reservation section inside the subnet but still I get the 
same, Can someone who has familiarity with reservation entries can guide me ?


Thanks in advance
Kraishak
-- 
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

Re: [Kea-users] got unexpected keyword "valid-lifetime" in reservations map.

[Veronique Lefebure]

Hi,
If you look at https://kea.readthedocs.io/en/latest/grammar/grammar.html you 
can see that valid_life_time is not an attribute of host-reservations:


reservation_param ::= duid
 753   | reservation_client_classes
 754   | client_id_value
 755   | circuit_id_value
 756   | flex_id_value
 757   | ip_address
 758   | hw_address
 759   | hostname
 760   | option_data_list
 761   | next_server
 762   | server_hostname
 763   | boot_file_name
 764   | user_context
 765   | comment
 766   | unknown_map_entry

Cheers,
Veronique

From: Kea-users  on behalf of Kraishak Mahtha 

Sent: Wednesday, February 22, 2023 10:35 AM
To: kea-users@lists.isc.org 
Subject: [Kea-users] got unexpected keyword "valid-lifetime" in reservations 
map.

Hi All,

I am using the kea-dhcp of 2.2.0 version, I am trying to add a reservation 
entry along with a valid lifetime option value but I am facing the syntax issue 
saying "got unexpected keyword "valid-lifetime" in reservations map".

kea-dhcp4 -t kea-dhcp4.conf. --> syntax validator
Syntax check failed with:  kea-dhcp4.conf  :59.7-22: got unexpected keyword 
"valid-lifetime" in reservations map.

I took a sample example from the forums and tried as below:
"subnet4": [{
"subnet": "4.0.0.0/16",
"valid-lifetime": 3600,
"option-data": [
{
"data": "test.com",
"name": "domain-name"
},
{
"data": "255.255.0.0",
"name": "subnet-mask"
},
{
"data": "99.99.99.99",
"name": "routers"
}
],
"pools": [{
"pool": "4.0.0.2-4.0.0.202"
}],
"id": 843191
}],
 "reservations": [
{
  "hw-address": "01:23:45:67:89:ab",
  "ip-address": "4.0.0.223",
  "hostname": "example.com",
  "valid-lifetime": 86400
}
  ]

I tried moving the reservation section inside the subnet but still I get the 
same, Can someone who has familiarity with reservation entries can guide me ?


Thanks in advance
Kraishak
-- 
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

Re: [Kea-users] Option 43 problems

[Veronique Lefebure]

Hi,

Reading 
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#dhcpv4-vendor-specific-options
 I see that it says:

"In this example, we also include the Vendor-Specific Information option, which 
conveys our sub-option foo. This is required; otherwise, the option will not be 
included in messages sent to the client."

--> maybe you need to add that ("name": "vendor-encapsulated-options") in 
option-data as well ? like in the doc example:


"option-data": [
{
"name": "cookie",
"space": "APC",
"data": "1APC"
},
{
"name": "vendor-encapsulated-options"
},
...
],


Cheers,
Veronique

From: Kea-users  on behalf of Michael 
Schwartzkopff via Kea-users 
Sent: Sunday, February 5, 2023 3:21 PM
To: kea-users 
Subject: [Kea-users] Option 43 problems

Hi,


I want to implement an option 43 string in the answer of the dhcp
server. especially wand to implement Cisco openpnp as defined here:
https://developer.cisco.com/site/open-plug-n-play/learn/learn-open-pnp-protocol/



The dhcp server should return the string "5A1N;K4;B3;I192.168.100.10".


In ISC dhcpd the following config works:

option space CISCOPNP;
option CISCOPNP.pnpserver code 43 = string;
class "ciscopnp" {
   match if option vendor-class-identifier = "ciscopnp";
   option vendor-class-identifier "ciscopnp";
   vendor-option-space CISCOPNP;
   option CISCOPNP.pnpserver = "5A1D;K4;B2;I192.168.100.10";
}


In kea I read a lot of doc, but I was not able to configure the server
correctly.


"Dhcp4": {
   "option-def": [
 {
   "name": "openpnp",
   "code": 5,
   "space": "vendor-encapsulated-options-space",
   "type": "string",
   "array": false,
   "record-types": "",
   "encapsulate": ""
 }

]

(...)

subnet {

(...)

 "reservations": [
   {
 "hw-address": "00:b8:b3:6b:69:c0",
 "ip-address": "192.168.100.24",
 "hostname":   "staging01",
 "option-data": [
   {
 "name": "openpnp",
 "space": "vendor-encapsulated-options-space",
 "code": 5,
 "data": "5A1D;K4;B2;I192.168.100.10"
   }
 ]
(...)


But the server does not return the option at all:

DEBUG DHCP4_RESPONSE_DATA [hwtype=1 00:b8:b3:6b:69:c0],
cid=[00:63:69:73:63:6f:2d:30:30:62:38:2e:62:33:36:62:2e:36:39:63:30:2d:56:6c:31],
tid=0x1e47: responding with packet DHCPACK (type 5), packet details:
local_address=192.168.100.10:67, remote_address=255.255.255.255:68,
msg_type=DHCPACK (5), transid=0x1e47,
options:
   type=001, len=004: 4294967040 (uint32)
   type=006, len=008: 192.0.2.1 192.0.2.2
   type=012, len=009: "staging01" (string)
   type=015, len=011: "example.org" (string)
   type=051, len=004: 3600 (uint32)
   type=053, len=001: 5 (uint8)
   type=054, len=004: 192.168.100.10
   type=058, len=004: 900 (uint32)
   type=059, len=004: 1800 (uint32)
   type=061, len=025:
00:63:69:73:63:6f:2d:30:30:62:38:2e:62:33:36:62:2e:36:39:63:30:2d:56:6c:31


Any idea what I am missing?


Michael Schwartzkopff

--
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

Re: [Kea-users] DHCPv6 option 16 and built in client class

[Veronique Lefebure]

Hi Xuo,

I don't know if you made any progress on this.

I have been playing a bit more with dhpv6 these days and in fact, when a client 
is assigned to class UNKNOWN I believe that it only means that no 
host-reservation was found by KEA for that client.
It does not mean that your client-class was not assigned to the client.

I have for example a client that got this:

2023-02-02 15:23:50.314 DEBUG [kea-dhcp6.dhcp6/2605.139812835567808] 
DHCP6_CLASS_ASSIGNED duid=[], tid=0x37acf: client packet has been assigned 
to the following class(es): UNKNOWN

2023-02-02 15:23:50.314 WARN  [kea-dhcp6.alloc-engine/2605.139812835567808] 
ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[], tid=0x37acf: Failed to allocate 
an IPv6 address for client with classes: ALL, HA_kea1, my_class1, my_class2, 
my_class3, UNKNOWN

So from the above lines you can see that KEA has associated not only class 
"UNKNOWN" to the client, but also my_class1, my_class2, my_class3 for which we 
got
EVAL_RESULT Expression my_class1 evaluated to 1
EVAL_RESULT Expression my_class2 evaluated to 1
EVAL_RESULT Expression my_class3 evaluated to 1

For each packet, you will find 2 debug lines from KEA, here is another example 
I have (for a KNOWN client this time):

2023-02-02 16:43:59.942 DEBUG [kea-dhcp6.dhcp6/7590.139769432221888] 
DHCP6_CLASS_ASSIGNED duid=[], tid=0x64ffd2: client packet has been assigned 
to the following class(es): KNOWN
2023-02-02 16:43:59.943 DEBUG [kea-dhcp6.dhcp6/7590.139769432221888] 
DHCP6_CLASS_ASSIGNED duid=[], tid=0x64ffd2: client packet has been assigned 
to the following class(es): ALL, HA_kea1, my_class1, my_class2, my_class3, KNOWN

Hope this helps.
Cheers,
Veronique


From: Kea-users  on behalf of Xuo Guoto via 
Kea-users 
Sent: Tuesday, December 6, 2022 8:33 AM
To: Kea-users@lists.isc.org 
Subject: Re: [Kea-users] DHCPv6 option 16 and built in client class

Thanks for your reply, Darren.

I have been trying different approaches to get client class working with DHCPv6.


Sent with Proton Mail secure email.


-- 
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

Re: [Kea-users] DHCPv4 Conflict resolution on MAC change

[Veronique Lefebure]

+1

From: Kea-users  on behalf of GIRSTMAIR Tobias 
via Kea-users 
Sent: Monday, January 30, 2023 10:54 AM
To: dh...@thehobsons.co.uk ; kea-users@lists.isc.org 

Subject: Re: [Kea-users] DHCPv4 Conflict resolution on MAC change

On Fri, 2023-01-27 at 19:58 +, Simon wrote:
> I assume it doesn’t scale in terms of having multiple hell desk
> operators having to do manual steps - in which case, the answer is to
> build a tool into your management toolset allowing them to “click
> here to remove the lease” when they are altering the reservation
> details.

The problem for us is that we manage reservations through a central
MySQL database (through a fancy UI for our hell desk), but leases are
stored in memfiles on each DHCP server (8 HA setups for 16 total). So
our tooling doesn't directly connect to the dhcp servers (and doesn't
even know which dhcp server a reservation 'belongs' to).

If there is no other way, we'll have to rework our tooling to find out
where to send this API call to (and punch some holes into the
firewalls). Not the end of the world, but this seems to be a feature
more people could benefit from.

tobi
--
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

Re: [Kea-users] DHCPv4 Conflict resolution on MAC change

[Veronique Lefebure]

Hi Simon,

The problem is new in the sense that we did not have that "problem" when using 
ISC DHCP since it would not check for the existing leases in case of static IP 
host-reservation.

Cheers,
Veronique



From: Kea-users  on behalf of Simon 

Sent: Friday, January 27, 2023 8:58 PM

Your problem isn’t new - it’s somewhat fundamental to complying with the RFCs. 
You will need to remove any existing lease for the IP before the IP can be 
allocated to another client.
I assume it doesn’t scale in terms of having multiple hell desk operators 
having to do manual steps - in which case, the answer is to build a tool into 
your management toolset allowing them to “click here to remove the lease” when 
they are altering the reservation details.

Simon

--
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

Re: [Kea-users] DHCPv4 Conflict resolution on MAC change

[Veronique Lefebure]

We would have the same use-case as you, Tobi, and I guess we would not be the 
only ones ?
The problem is also mentioned on 
https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag
 by the way.

On 
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations
 doc says
  "The best way to avoid such a recovery is not to define new reservations 
that conflict with existing leases. Another recommendation is to use 
out-of-pool reservations; if the reserved address does not belong to a pool, 
there is no way that other clients can get it."

But indeed, even with out-of-pool reservations, the hardware replacement 
use-case is not going to work :-/


From: Kea-users  on behalf of GIRSTMAIR Tobias 
via Kea-users 
Sent: Friday, January 27, 2023 1:07 PM
To: kea-users@lists.isc.org 
Subject: [Kea-users] DHCPv4 Conflict resolution on MAC change

Hi all,

We recently migrated to Kea 2.2.0 and now ran into the following
situation:

Initially:
 - Leases are valid for a long time (11 days, per customer requirement)
 - There is a host reservation for  and 
 - The device with  got a lease for 

Now, the hardware is replaced and the reservation is updated, so the
new device gets the same IP:
 - remove reservation for  and 
 - add reservation for  and 
 - the old device is unplugged, and therefore cannot release its lease
 - the new device is plugged in and requests a lease

Now, Kea looks for the host reservation for  and notices that
 is still leased to , so it refuses to reassign this IP.
This looks like this in the log:

2023-01-26 08:43:18.065 WARN  [kea-dhcp4.alloc-
engine/1409.139836331153152] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT
[hwtype=1 00:15:bc:28:2b:0c], cid=[01:00:15:bc:28:2b:0c],
tid=0xaf01221b: conflicting reservation for address 10.58.166.192 with
existing lease Address:   10.58.166.192
Valid life:950400
Cltt:  1674552388
Hardware addr: 00:15:bc:28:09:e7
Client id: 01:00:15:bc:28:09:e7
Subnet ID: 5164
State: default

I read through section 8.3.2 of the documentation, and the conflict
resolution protocol used seems to not handle our case here (where the
old device doesn't release its lease). It expects the old device with
 to renew its lease, before responding with DHCPNAK and
reallocating  to .

As a workaround, an operator could manually delete the lease with kea-
shell (or its underlying api), but that does not scale to our size.

The documentation describes that "A naive approach would to be
immediately remove the existing lease for Host A and create a new one
for Host B" -- this would be exactly what we want, and what our
previous setup did. Our reservations are out-of-pool, and we can be
certain that when the MAC of a reservation changes, the old device will
not be online any longer. Is there a way to achieve this?

Thanks,

Tobi
--
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

Re: [Kea-users] Kea HA Heartbeat Failure

[Veronique Lefebure]

Hi,
Have you tried to run a manual curl command from one of the two servers to its 
partner ?


From: Kea-users  on behalf of duluxoz 

Sent: Thursday, January 26, 2023 9:26 AM
To: kea-users@lists.isc.org 
Subject: [Kea-users] Kea HA Heartbeat Failure


Hi All,

Looking for some pointers on an issue we've got.

TL:DR: Our Kea HA Servers' Heartbeat not connecting - permissions issue.

So we've got to Kea servers (v2.2) running on two Rocky Linux v9.1 servers. 
Clients are getting IP Addresses (both dynamic and reserved) and keactrl works 
fine, etc. But we're getting the following error messages showing up in the 
logs:

~~~

2023-01-26 16:20:37.013 WARN  [kea-dhcp4.ha-hooks/7896.140594097562496] 
HA_HEARTBEAT_FAILED heartbeat to kea_dhcp_2 (http://192.168.1.3:8000/) failed: 
Unauthorized, error code 1
2023-01-26 16:20:37.013 WARN  [kea-dhcp4.ha-hooks/7896.140594097562496] 
HA_COMMUNICATION_INTERRUPTED communication with kea_dhcp_2 is interrupted
~~~

Its not SELinux (we turned off SELinux and the problem persisted).

Its not firewalld (we think) - ie the ports are opened, confirmed by netstat.

We are using the default port of 8000 for keactrl and the heartbeat (I assume 
this is OK, as the doco seems to imply that it is).

keactrl is using a basic authentication with a pre-shared key, and we've 
checked that its the same on both servers.

We've bound port 8000 to the actual IPv4 address of the server (not 127.0.0.1). 
We originally had it bound to the loopback address, and we were getting 
"connection refused" errors, so we bound it to the real IP Address and not 
we're getting the above error.

The two servers' IP Addresses are in the correct "allow" statement, and when we 
removed the allow statement from the config (ie opened up connection to all) we 
still had the same problem.

Finally, our config files are practically the same as those shown on numerous 
websites and in the official doco and sample files - with the relevant details 
changed (ie IP Addresses, etc) - I can post them here if required, but I'm 
loath to fill up a post with irrelevant info unless requested.  :-)

So, any pointers would be appreciated

Cheers

Dulux-Oz
-- 
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

Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a reboot

[Veronique Lefebure]

And Francis, you confirm that this is a behaviour which is different between 
KEA (withoit flex-id) and ISC DHCP ?

From: Veronique Lefebure 
Sent: Tuesday, January 17, 2023 5:14 PM
To: Francis Dupont 
Cc: Darren Ankney ; kea-users@lists.isc.org 

Subject: Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a 
reboot

Thanks Francis,
So according to 
https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=flex-id#available-hook-librarieswe
 need to subscribe to ISC support to make use of it.


From: Francis Dupont 
Sent: Tuesday, January 17, 2023 4:53 PM
To: Veronique Lefebure 
Cc: Darren Ankney ; kea-users@lists.isc.org 

Subject: Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a 
reboot

The problem here is the client is changing its DUID so Kea believes
the lease was assigned to a different client using the same mac address.
To override this behavior the simplest is to use the mac address as
the client identifier with flex-id and replace-client-id set to yes.

Another way is to replace on the wire the DUID by a fixed value...

Thanks

Francis Dupont 

PS: DHCPv4 clients have two identifiers: the client-id option and
the mac address. If the client-id option has the precedence this can
be disabled at the subnet level or higher. There is a RFC too explaining
how to deal with this issue when using both DHCPv4 and DHCPv6...
-- 
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

Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a reboot

[Veronique Lefebure]

Thanks Francis,
So according to 
https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=flex-id#available-hook-librarieswe
 need to subscribe to ISC support to make use of it.


From: Francis Dupont 
Sent: Tuesday, January 17, 2023 4:53 PM
To: Veronique Lefebure 
Cc: Darren Ankney ; kea-users@lists.isc.org 

Subject: Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a 
reboot

The problem here is the client is changing its DUID so Kea believes
the lease was assigned to a different client using the same mac address.
To override this behavior the simplest is to use the mac address as
the client identifier with flex-id and replace-client-id set to yes.

Another way is to replace on the wire the DUID by a fixed value...

Thanks

Francis Dupont 

PS: DHCPv4 clients have two identifiers: the client-id option and
the mac address. If the client-id option has the precedence this can
be disabled at the subnet level or higher. There is a RFC too explaining
how to deal with this issue when using both DHCPv4 and DHCPv6...
-- 
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

Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a reboot

[Veronique Lefebure]

More on this:

The mac address is in the host-reservation in the configuration file.
Why is it is used by KEA at the first boot and not at the second one ?

and even more, KEA knows about the mac address since it identifies the 
host-reservation; it logs out the following:

2023-01-16 17:52:09.477 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for 
client duid=[second_duid], tid=0xedb614


2023-01-16 17:52:09.478 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available - trying to 
dynamically allocate leases for client duid=[second_duid], tid=0xedb614


The problem is just that KEA thinks that the lease is not available.
In addition I have done a traffic capture, and I confirm that the client mac 
address is communicated each time to KEA via option 79.

Thanks for any help you may add on this point,
Cheers,
Veronique


From: Kea-users  on behalf of Darren Ankney 

Sent: Tuesday, January 17, 2023 12:32 PM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a 
reboot

The trouble is that the server has no way to know it’s the same client if the 
DUID is unstable.  If the mac address is available, you can assign a 
reservation based on that.  Then it wouldn’t matter what DUID the client 
provides.  This is the same behavior as in ISC DHCP concerning DHCPv6.  It is 
defined in RFC 8415.  Basically: The DUID must be present and the client must 
use the same DUID.  The server must use that as the identifier to assign leases.

On Jan 17, 2023, at 6:18 AM, Veronique Lefebure  
wrote:

Waw. The client behaviour is not under control of the DHCP server admins..
This is a behaviour different from the ISC DHCP server behaviour, right ?

From: Kea-users  on behalf of Kevin P. Fleming 

Sent: Tuesday, January 17, 2023 12:00 PM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a 
reboot

On Tue, Jan 17, 2023, at 04:54, Veronique Lefebure wrote:
Hi,

I have observed that an IPV6 client gets the wrong IP when it reboots.
See detailed logs below.
The problem seems to be due to the fact the DUID of the client changes after 
reboot.
Anyone else has observed the same ?
How to go around that and make sure that the client gets the correct IP 
straightaway after reboot ?

You'll need to find a way to configure the client to use a stable DUID if you 
want it to be given a lease from a host reservation.

--
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

Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a reboot

[Veronique Lefebure]

Waw. The client behaviour is not under control of the DHCP server admins..
This is a behaviour different from the ISC DHCP server behaviour, right ?

From: Kea-users  on behalf of Kevin P. Fleming 

Sent: Tuesday, January 17, 2023 12:00 PM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] IPV6 client gets the wrong IP for sometime after a 
reboot

On Tue, Jan 17, 2023, at 04:54, Veronique Lefebure wrote:
Hi,

I have observed that an IPV6 client gets the wrong IP when it reboots.
See detailed logs below.
The problem seems to be due to the fact the DUID of the client changes after 
reboot.
Anyone else has observed the same ?
How to go around that and make sure that the client gets the correct IP 
straightaway after reboot ?

You'll need to find a way to configure the client to use a stable DUID if you 
want it to be given a lease from a host reservation.

-- 
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

[Kea-users] IPV6 client gets the wrong IP for sometime after a reboot

[Veronique Lefebure]

Hi,

I have observed that an IPV6 client gets the wrong IP when it reboots.
See detailed logs below.
The problem seems to be due to the fact the DUID of the client changes after 
reboot.
Anyone else has observed the same ?
How to go around that and make sure that the client gets the correct IP 
straightaway after reboot ?
Thanks,
Veronique

# Initial boot: client (with hw mac address "CLIENT_MAC_ADDRESS") gets the 
expected reserved IP "good_static_ip" using duid "first_duid" :

2023-01-16 17:01:53.859 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_SELECTED duid=[first_duid], tid=0x3c6a47: the subnet with ID 
2156730624 was selected for client assignments
2023-01-16 17:01:53.860 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for 
client duid=[first_duid], tid=0x3c6a47
2023-01-16 17:01:53.860 INFO  [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_HR_ADDR_GRANTED reserved address good_static_ip was assigned to 
client duid=[first_duid], tid=0x3c6a47
2023-01-16 17:01:53.860 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_DYNAMICALLY_CHANGED duid=[first_duid], tid=0x3c6a47: changed 
selected subnet dynamic_pool/64 to subnet good_subnet/64 from shared network 
Shared-S1000-S-PR90 for client assignments
2023-01-16 17:01:54.721 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_SELECTED duid=[first_duid], tid=0xb60809: the subnet with ID 
2156730624 was selected for client assignments
2023-01-16 17:01:54.722 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for 
client duid=[first_duid], tid=0xb60809
2023-01-16 17:01:54.722 INFO  [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_HR_ADDR_GRANTED reserved address good_static_ip was assigned to 
client duid=[first_duid], tid=0xb60809
2023-01-16 17:01:54.722 INFO  [kea-dhcp6.leases/21898.139652277565632] 
DHCP6_LEASE_ALLOC duid=[first_duid], tid=0xb60809: lease for address 
good_static_ip and iaid=795307976 has been allocated for 3606 seconds

2023-01-16 17:01:54.723 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_DYNAMICALLY_CHANGED duid=[first_duid], tid=0xb60809: changed 
selected subnet dynamic_pool/64 to subnet good_subnet/64 from shared network 
Shared-S1000-S-PR90 for client assignments
2023-01-16 17:02:15.585 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_SELECTED duid=[first_duid], tid=0x992ae0: the subnet with ID 
2156730624 was selected for client assignments
2023-01-16 17:02:16.874 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_SELECTED duid=[first_duid], tid=0x2f49fd: the subnet with ID 
2156730624 was selected for client assignments
2023-01-16 17:02:16.875 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_LEASES_HR leases and static reservations found for client 
duid=[first_duid], tid=0x2f49fd
2023-01-16 17:02:16.875 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS duid=[first_duid], tid=0x2f49fd: lease 
type IA_NA for reserved address/prefix good_static_ip already exists
2023-01-16 17:02:17.871 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_SELECTED duid=[first_duid], tid=0x5abee0: the subnet with ID 
2156730624 was selected for client assignments
2023-01-16 17:02:17.872 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_LEASES_HR leases and static reservations found for client 
duid=[first_duid], tid=0x5abee0
2023-01-16 17:02:17.872 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS duid=[first_duid], tid=0x5abee0: lease 
type IA_NA for reserved address/prefix good_static_ip already exists
2023-01-16 17:02:17.873 INFO  [kea-dhcp6.leases/21898.139652277565632] 
DHCP6_LEASE_ALLOC duid=[first_duid], tid=0x5abee0: lease for address 
good_static_ip and iaid=795307976 has been allocated for 3606 seconds

# IP renew works fine: (note: that lease will get released later at 
18:22:17.301 )

2023-01-16 17:32:21.452 DEBUG [kea-dhcp6.packets/21898.139652277565632] 
DHCP6_SUBNET_SELECTED duid=[first_duid], tid=0x7c37af: the subnet with ID 
2156730624 was selected for client assignments
2023-01-16 17:32:21.453 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_RENEW_REMOVE_RESERVED duid=[first_duid], tid=0x7c37af: checking 
if existing client's leases are reserved for another client
2023-01-16 17:32:21.453 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_RENEW_HR allocating leases reserved for the client 
duid=[first_duid], tid=0x7c37af as a result of Renew
2023-01-16 17:32:21.453 DEBUG [kea-dhcp6.alloc-engine/21898.139652277565632] 
ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS duid=[first_duid], tid=0x7c37af: lease 
type IA_NA for reserved address/prefix good_static_ip already exists
2023-01-16 17:32:21.453 DEBUG 

Re: [Kea-users] Load-Balancing Network issue between Relay and Kea

[Veronique Lefebure]

Very interesting thread.

Mathias, you wrote "Expected behaviour: Kea 2 sees the unacked clients of Kea 1 
and sets Kea 1 in partner-down state and handles all requests.", but, If there 
is no traffic between DHCP clients and Kea1, then the value of 
max-unacked-clients on server1 cannot increase anyway, right ?  In other words, 
Kea2 cannot "see" anything ?

Cheers,
Veronique

From: Kea-users  on behalf of Mathias 
Aichinger 
Sent: Monday, January 2, 2023 1:11 AM
To: kea-users@lists.isc.org 
Subject: [Kea-users] Load-Balancing Network issue between Relay and Kea

Hi,

I currently playing around with the HA and load balancing and I one question 
appeared:

Scenario:

Multiple DHCP-Relays at different sites with both KEA-Servers as DHCP-Servers. 
Both servers are available and the load balancing shifts the requests between 
the two servers.

Incident: Because of a network issue Kea 1 is not available from the clients. 
The network connection between Kea 1 and Kea 2 still works, so no partner-down 
state.

Expected behaviour: Kea 2 sees the unacked clients of Kea 1 and sets Kea 1 in 
partner-down state and handles all requests.

Experienced behaviour: Kea 2 still reports HA_BUFFER4_RECEIVE_NOT_FOR_US and 
does not handle the requests

Is there a misunderstanding or configuration mistake on my side?

{
 "library": "/usr/local/lib/kea//hooks/libdhcp_ha.so",
 "parameters": {
   "high-availability": [
 {
   "this-server-name": "server2",
   "mode": "load-balancing",
   "heartbeat-delay": 1,
   "max-response-delay": 6,
   "max-ack-delay": 1,
   "max-unacked-clients": 1,
   "delayed-updates-limit": 100,
   "peers": [
 {
   "name": "server1",
   "url": "http://192.168.248.1:8080/;,
   "role": "primary",
   "auto-failover": true
 },
 {
   "name": "server2",
   "url": "http://192.168.248.2:8080/;,
   "role": "secondary",
   "auto-failover": true
 }
   ]
 }
   ]
 }
   }

Thank you,

Mathias

-- 
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

Re: [Kea-users] Disable multicast Listening

[Veronique Lefebure]

We are using ip6tables for dropping all traffic coming from ff02::1:2.
Cheers,
Veronique

From: Kea-users  on behalf of Frey, Rick E via 
Kea-users 
Sent: Wednesday, January 4, 2023 5:02 PM
To: s k ; kea-users 
Subject: Re: [Kea-users] Disable multicast Listening


Realized you’re likely asking about DHCPv6 since mentioning “multicast” 
address.  Kea docs indicate that even when unicast address specified for dhcp6, 
the server will still listen on multicast address.



Guessing you have already tried blocking the multicast traffic via server 
firewall (ip6tables/nftables)?



From: Kea-users  on behalf of Frey, Rick E via 
Kea-users 
Date: Wednesday, January 4, 2023 at 9:46 AM
To: s k , kea-users 
Subject: Re: [Kea-users] Disable multicast Listening

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.



Have you tried setting the “dhcp-socket-type” to “udp”?



Docs indicate that if not specified, the default is “raw”.  If you’re only 
needing DHCP on unicast (via relay), you should be able to set to “udp” which 
should disable reception of broadcast packets from directly connected clients.



See 
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#interface-configuration







From: Kea-users  on behalf of s k 

Date: Tuesday, January 3, 2023 at 7:05 PM
To: kea-users 
Subject: [Kea-users] Disable multicast Listening

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.



Hi

Is there a way to stop Kea from listening on multicast address  , since our set 
up only uses relay forwarding to request for ip which is point to point. when i 
enable listening on global interface by default kea listens on multicast 
address and the number of requests received  over multicast is overwhelming .

Thanks

skumar







Sensitivity: Internal



Sensitivity: Internal


Sensitivity: Internal
-- 
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

Re: [Kea-users] subclass handling in kea-dhcp

[Veronique Lefebure]

Hi,

We have something that looks like the following. Hope it helps.
Cheers,
Veronique

{
  "Dhcp4": {
...
"client-classes": [
  {
"name": "blocked-list",
"test": "(pkt4.mac == 0x0 or pkt4.mac == 0xXXX or 
)",
  },
  {
"name": "OkClients",
"test": "not member('blocked-list')"
  },

...

 "pools": [
  {
"client-class": "Okclients",
"pool": "xxx.xxx.xxx.1-xxx.xxx.xxx.2"
  }
],


From: Kea-users  on behalf of Kraishak Mahtha 

Sent: Wednesday, December 14, 2022 3:30 PM
To: kea-users@lists.isc.org 
Subject: [Kea-users] subclass handling in kea-dhcp

Hi All,

I am looking for the equivalent option of ISC dhcp subclass in kea-dhcp4 but I 
couldn't find any, I have a case where I need to decline dhcp-lease grants to 
given specific mac addresses so trying to match the same in kea-version but I  
couldn't find any sub-class equivalent, can we add the specific data (here mac 
address as the members of the specific class) in kea

MY ISC DHCP config
class "denyClients" {
 match substring (hardware, 1, 6);
 deny booting;
}
subclass "denyClients" 11:22:33:44:ab:66;
subclass "denyClients" 11:22:33:43:ab:66;
subclass "denyClients" 11:22:33:42:ab:66;
subnet 12.0.0.0 netmask 255.255.255.0 {
pool {
failover peer "Test";
range 12.0.0.2 12.0.0.2;
deny members of "denyClients";
}
default-lease-time 3600;
 option routers 12.0.0.1;
 option subnet-mask 255.255.255.0;
}


Can anyone please advise or suggest how to add members to the DHCP class or the 
data for which the class should be applied

Thanks in Advance
Kraishak



-- 
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

Re: [Kea-users] KEA sends valid-lifetime = 0

[Veronique Lefebure]

For people who would encounter the same issue, see  
https://gitlab.isc.org/isc-projects/kea/-/issues/2660

From: Kea-users  on behalf of Veronique 
Lefebure 
Sent: Thursday, January 27, 2022 3:31 PM
To: kea-users@lists.isc.org 
Subject: [Kea-users] KEA sends valid-lifetime = 0


Hi,

For the following query:

16:24:15.730401 IP6 (hlim 1, next-header UDP (17) payload length: 143)
cs-lab11-kea.dhcpv6-client > ff02::1:2.dhcpv6-server:
[bad udp cksum 0xc2bb -> 0xa8e1!]
dhcp6 renew (xid=50bedb
(client-ID type 4)
(server-ID hwaddr/time type 1 time 692127779 00259074ca68)
(option-request DNS-server DNS-search-list DNS-server DNS-search-list client-ID)
(elapsed-time 0) (Client-FQDN)
(IA_NA IAID:795336567 T1:3600 T2:5400(IA_ADDR ::101:1 pltime:7200 
vltime:7500))
)

I have observed a case where KEA dhcp6 returns the following:

16:24:16.359170 IP6 (hlim 64, next-header UDP (17) payload length: 171)
gateway.dhcpv6-server > cs-lab11-kea.dhcpv6-client:
[udp sum ok]
dhcp6 reply (xid=50bedb
(client-ID type 4)
(server-ID hwaddr/time type 1 time 692127779 00259074ca68)
(IA_NA IAID:795336567 T1:40 T2:100
(IA_ADDR ::101:1 pltime:120 vltime:120)
(IA_ADDR ::101:1 pltime:0 vltime:0))
(DNS-search-list cern.ch.) (Client-FQDN))

Where there are 2 IA_ADDR, the second one having a vltime of 0.

Any idea how that can happen ?

wireshark shows this:

[...]
Message type: Reply (7)
Transaction ID: 0x52a6e8
Client Identifier
Server Identifier
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 68
xxx
IAID: 2f67df77
T1: 40
T2: 100
IA Address
Option: IA Address (5)
Length: 24
Value: 101000100780078
IPv6 address: 2001:1458:202:1d5::101:1 (::101:1)
Preferred lifetime: 120
Valid lifetime: 120
IA Address
Option: IA Address (5)
Length: 24
Value: 1010001
IPv6 address: 2001:1458:202:1d5::101:1 (::101:1)
Preferred lifetime: 0
Valid lifetime: 0
Domain Search List
Fully Qualified Domain Name

Thanks,
Veronique
-- 
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

Re: [Kea-users] BOOTP clients

[Veronique Lefebure]

Hi,
Have you loaded the bootp hooks-libraries ?
Cheers,
Veronique

From: Kea-users  on behalf of Kraishak Mahtha 

Sent: Friday, December 2, 2022 10:37 AM
To: kea-users@lists.isc.org 
Subject: [Kea-users] BOOTP clients

Hi, I am using the kea 2.2.0 version

I am unable to get a lease for the bootp clients and getting an error message 
like
2022-12-02 09:34:56.035 DEBUG [kea-dhcp4.bad-packets/8880.140634536294592] 
DHCP4_PACKET_DROP_0009 [hwtype=1 11:1f:f1:00:00:01], cid=[no info], 
tid=0x12596530: Option 53 missing (no DHCP message type), is this a BOOTP 
packet?

So, do we have any other alternative way of handling this?

Any help would be appreciated
Thanks in advance
Kraishak

-- 
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

Re: [Kea-users] How to best update the KEA configuration on a HA hot-standby KEA setup

[Veronique Lefebure]

Many thanks for these interesting hints!
A last question then: how do you notify KEA processes (kea-dhcp4, kea-dhcp6) in 
case you modify any of you json files ? with a "reload" command ?
Thanks,
Veronique

From: Dan Oachs 
Sent: Thursday, November 17, 2022 8:36 PM
To: Veronique Lefebure 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

The great thing about Kea is that it is very flexible and you can make it work 
in a wide variety of ways and find the setup that works best for your situation.

In our case we have a hybrid setup.  The kea-dhcp4.conf file has all the global 
settings, and we define the hosts-database for storing host reservations.  We 
also break out all the subnet config into a separate subnets.json file and have 
the main file include that.

We update the database directly from our own registration system, which is not 
recommended, but works fo us.  We chose not to pay for the host commands hook 
library that is required to use the api example you mentioned.

I am pretty sure that you can do almost everything in the database that you can 
do in the config file, but are only using the database to store the host 
information.  I do see tables in the database that start with 
dhcp4_client_class which would lead me to believe that you can do what you want 
with the database configuration.

--Dan


On Thu, Nov 17, 2022 at 9:48 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Thanks Dan!


So you have a hybrid configuration ?
What do you mean by "main configuration" ? Topology (shared-networks and 
subnets) in json file and host-reservations in a database ?
Do you update the database using "reservation-add"  
(https://kea.readthedocs.io/en/latest/api.html?highlight=host%20reservation#reservation-add
 ) ?

We have client classes with a test expression that depends on the mac addresses 
of the clients.
Can these classes be stored in the database as well ?

Thanks,
Veronique



From: Dan Oachs mailto:doa...@gac.edu>>
Sent: Thursday, November 17, 2022 4:20 PM
To: Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>>
Cc: kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> 
mailto:kea-users@lists.isc.org>>
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

We also have all the main configuration in plain json files.  Like you, we 
require hosts on some of our networks to be registered.  Our registration 
system stores the MAC addresses in the Kea database.  For the past year or so, 
this has worked really well for us.

I would highly suggest looking into storing the MAC addresses in a database so 
you don't need to reload kea for every change.  You don't need to use the 
database for anything else if you don't want to.   This can also be done 
without any of the extra hook libraries that cost money.

--Dan



On Thu, Nov 17, 2022 at 2:19 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,

We don't use any database for storing the KEA configuration: we use plain json 
configuration files.
We need to update the configuration very regularly because we allow only known 
clients (pre-registered mac addresses), hence the list of host-reservations is 
quite volatile.

Véronique

From: Dan Oachs mailto:doa...@gac.edu>>
Sent: Wednesday, November 16, 2022 6:31 PM
To: Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>>
Cc: kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> 
mailto:kea-users@lists.isc.org>>
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

I am curious why you are updating the config every 5 minutes.   We used to do 
that with our old DHCP server, but with Kea we moved to storing reservations in 
a database.  That way we rarely need to make changes to the actual Kea 
configuration that would necessitate a reload of the config.

--Dan


On Wed, Nov 16, 2022 at 10:27 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,

When running KEA on one single server, (no HA), and updating the KEA dhcp 
configuration file every 5 minute, using "config-set"
https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
 ,
we can see that KEA does not reply to the DHCP requests during 30-35 seconds 
while "config-set" is running.

Is it expected ?
If yes, if we add a second server in a HA hot-standby mode, can we expect it to 
answer to the DHCP requests while the first server is busy with config-set ?
If yes, we need to update the second server asynchronously with respect to the 
first one, else they would both be busy with "config-set" at the same time.

I would be interested to know how people are upd

Re: [Kea-users] How to best update the KEA configuration on a HA hot-standby KEA setup

[Veronique Lefebure]

Thanks Dan!


So you have a hybrid configuration ?
What do you mean by "main configuration" ? Topology (shared-networks and 
subnets) in json file and host-reservations in a database ?
Do you update the database using "reservation-add"  
(https://kea.readthedocs.io/en/latest/api.html?highlight=host%20reservation#reservation-add
 ) ?

We have client classes with a test expression that depends on the mac addresses 
of the clients.
Can these classes be stored in the database as well ?

Thanks,
Veronique



From: Dan Oachs 
Sent: Thursday, November 17, 2022 4:20 PM
To: Veronique Lefebure 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

We also have all the main configuration in plain json files.  Like you, we 
require hosts on some of our networks to be registered.  Our registration 
system stores the MAC addresses in the Kea database.  For the past year or so, 
this has worked really well for us.

I would highly suggest looking into storing the MAC addresses in a database so 
you don't need to reload kea for every change.  You don't need to use the 
database for anything else if you don't want to.   This can also be done 
without any of the extra hook libraries that cost money.

--Dan



On Thu, Nov 17, 2022 at 2:19 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,

We don't use any database for storing the KEA configuration: we use plain json 
configuration files.
We need to update the configuration very regularly because we allow only known 
clients (pre-registered mac addresses), hence the list of host-reservations is 
quite volatile.

Véronique

From: Dan Oachs mailto:doa...@gac.edu>>
Sent: Wednesday, November 16, 2022 6:31 PM
To: Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>>
Cc: kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> 
mailto:kea-users@lists.isc.org>>
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

I am curious why you are updating the config every 5 minutes.   We used to do 
that with our old DHCP server, but with Kea we moved to storing reservations in 
a database.  That way we rarely need to make changes to the actual Kea 
configuration that would necessitate a reload of the config.

--Dan


On Wed, Nov 16, 2022 at 10:27 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,

When running KEA on one single server, (no HA), and updating the KEA dhcp 
configuration file every 5 minute, using "config-set"
https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
 ,
we can see that KEA does not reply to the DHCP requests during 30-35 seconds 
while "config-set" is running.

Is it expected ?
If yes, if we add a second server in a HA hot-standby mode, can we expect it to 
answer to the DHCP requests while the first server is busy with config-set ?
If yes, we need to update the second server asynchronously with respect to the 
first one, else they would both be busy with "config-set" at the same time.

I would be interested to know how people are updating the KEA DHCP 
configuration in a HA hot-standby setup.

Thanks,
Veronique

--
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<mailto: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

Re: [Kea-users] How to best update the KEA configuration on a HA hot-standby KEA setup

[Veronique Lefebure]

I am wondering whether it is not more efficient to perform a
"config-write" followed by a "config-reload"
rather than a "config-set" ?


From: Kea-users  on behalf of Veronique 
Lefebure 
Sent: Thursday, November 17, 2022 9:19 AM
To: Dan Oachs 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

Hi,

We don't use any database for storing the KEA configuration: we use plain json 
configuration files.
We need to update the configuration very regularly because we allow only known 
clients (pre-registered mac addresses), hence the list of host-reservations is 
quite volatile.

Véronique

From: Dan Oachs 
Sent: Wednesday, November 16, 2022 6:31 PM
To: Veronique Lefebure 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

I am curious why you are updating the config every 5 minutes.   We used to do 
that with our old DHCP server, but with Kea we moved to storing reservations in 
a database.  That way we rarely need to make changes to the actual Kea 
configuration that would necessitate a reload of the config.

--Dan


On Wed, Nov 16, 2022 at 10:27 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,

When running KEA on one single server, (no HA), and updating the KEA dhcp 
configuration file every 5 minute, using "config-set"
https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
 ,
we can see that KEA does not reply to the DHCP requests during 30-35 seconds 
while "config-set" is running.

Is it expected ?
If yes, if we add a second server in a HA hot-standby mode, can we expect it to 
answer to the DHCP requests while the first server is busy with config-set ?
If yes, we need to update the second server asynchronously with respect to the 
first one, else they would both be busy with "config-set" at the same time.

I would be interested to know how people are updating the KEA DHCP 
configuration in a HA hot-standby setup.

Thanks,
Veronique

--
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<mailto: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

Re: [Kea-users] How to best update the KEA configuration on a HA hot-standby KEA setup

[Veronique Lefebure]

Hi,

We don't use any database for storing the KEA configuration: we use plain json 
configuration files.
We need to update the configuration very regularly because we allow only known 
clients (pre-registered mac addresses), hence the list of host-reservations is 
quite volatile.

Véronique

From: Dan Oachs 
Sent: Wednesday, November 16, 2022 6:31 PM
To: Veronique Lefebure 
Cc: kea-users@lists.isc.org 
Subject: Re: [Kea-users] How to best update the KEA configuration on a HA 
hot-standby KEA setup

I am curious why you are updating the config every 5 minutes.   We used to do 
that with our old DHCP server, but with Kea we moved to storing reservations in 
a database.  That way we rarely need to make changes to the actual Kea 
configuration that would necessitate a reload of the config.

--Dan


On Wed, Nov 16, 2022 at 10:27 AM Veronique Lefebure 
mailto:veronique.lefeb...@cern.ch>> wrote:
Hi,

When running KEA on one single server, (no HA), and updating the KEA dhcp 
configuration file every 5 minute, using "config-set"
https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
 ,
we can see that KEA does not reply to the DHCP requests during 30-35 seconds 
while "config-set" is running.

Is it expected ?
If yes, if we add a second server in a HA hot-standby mode, can we expect it to 
answer to the DHCP requests while the first server is busy with config-set ?
If yes, we need to update the second server asynchronously with respect to the 
first one, else they would both be busy with "config-set" at the same time.

I would be interested to know how people are updating the KEA DHCP 
configuration in a HA hot-standby setup.

Thanks,
Veronique

--
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<mailto: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

[Kea-users] How to best update the KEA configuration on a HA hot-standby KEA setup

[Veronique Lefebure]

Hi,

When running KEA on one single server, (no HA), and updating the KEA dhcp 
configuration file every 5 minute, using "config-set"
https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
 ,
we can see that KEA does not reply to the DHCP requests during 30-35 seconds 
while "config-set" is running.

Is it expected ?
If yes, if we add a second server in a HA hot-standby mode, can we expect it to 
answer to the DHCP requests while the first server is busy with config-set ?
If yes, we need to update the second server asynchronously with respect to the 
first one, else they would both be busy with "config-set" at the same time.

I would be interested to know how people are updating the KEA DHCP 
configuration in a HA hot-standby setup.

Thanks,
Veronique

-- 
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

[Kea-users] Questions about importing leases

[Veronique Lefebure]

 Hi, 


 - Is there a tool that can be used to import leases from ISC DHCP lease file 
into a KEA server (where we use  local lease database file) ? 


 - If we add a lease using "lease4-add" to a KEA server, is it supposed to be 
automatically replicated to the hot-standby KEA server in a High-availability 
hot-standby setup ? 


 Thanks, 


 Veronique -- 
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

[Kea-users] role-based access control for the KEA Control Agent

[Veronique Lefebure]

Hi, 

 


Looking at  23. Kea Security — Kea 2.3.1-git documentation  

 
 
https://kea.readthedocs.io/en/latest/arm/security.html#authentication-for-kea-s-restful-api
  


 where it is said  


 Kea 1.9.2 introduced a new auth hook point. With this new hook point, it is 
possible to develop an external hook library to extend the access controls, 
integrate with another authentication authority, or add role-based access 
control to the Control Agent. 


 I wanted to ask if anyone would have an example of such an external library, 
for adding role-based access control o the Control Agent  ? 


 Many thanks, 
 Veronique -- 
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

Re: [Kea-users] KEA allocates an IP while it should not

[Veronique Lefebure]

Dear Francis, thanks for confirming.

Indeed, 
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?highlight=8.3#global-reservations-in-dhcpv4
 clearly says:

"global reservations that assign addresses bypass the whole topology 
determination provided by the DHCP logic implemented in Kea. It is very easy to 
misuse this feature and get a configuration that is inconsistent" .

So, in order to get the same behaviour with KEA than the one we had with ISC 
DHCP, we now need 2 host-reservations for one mac address:
- #1 : one host-reservation in the subnet, where we reserve an IP that matches 
the subnet
- #2 : one additional host-reservation, at the global level, with no reserved 
IP, for the client to get a dynamic IP in case it is not connected to the 
expected subnet.

In ISC DHCP, host-reservation #1 was enough to get both.
Am I correct ?

Thanks again,
Veronique

> On 30/08/2022 17:41 Francis Dupont  wrote:
> 
>  
> Veronique Lefebure writes:
> >  I would like to understand why KEA allocates an IP which should not be 
> > alloc
> > ated. 
> >
> >
> >  I have, on purpose (for testing KEA behaviour), declared the following 
> > globa
> > l host reservation: 
> 
> => the answer is here: you use a global host reservation with a reserved
> address so as it is documented this breaks localization aka subnet selection
> so you can get exactly the kind of results you got...
> 
> >  My question is: 
> >  ISC DHCP would not do that. 
> 
> in ISC DHCP there is no global reservations for an address even it is not
> obvious from the syntax: the reservation is attached to the subnet the
> address belongs to.
> 
> >  Is it expected that KEA does not behave the same way ? 
> 
> => yes, host reservation model is very different in KEA.
> 
> >  Is there any tuning that can be used so that KEA behaves the same way as 
> > ISC
> >  DHCP used to behave ? 
> 
> => put reservations with an address in a subnet the address belongs to.
> Note you can still use global reservations for other things as KNOWN /
> UNKNOWN classification, option setting, etc. With last versions of KEA
> you have also optional early global reservation lookup too.
> 
> Regards
> 
> Francis Dupont 
-- 
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

[Kea-users] KEA allocates an IP while it should not

[Veronique Lefebure]

 Hi, 


 I would like to understand why KEA allocates an IP which should not be 
allocated. 


 I have, on purpose (for testing KEA behaviour), declared the following global 
host reservation: 


 { 
"boot-file-name": "", 
"client-classes": [ ], 
"hostname": "cs-test-1a", 
"hw-address": "xx:xx:xx:xx:ff:3e", 
"ip-address": "yyy.yyy.yyy.11", 
"next-server": "0.0.0.0", 
"option-data": [ ], 
"server-hostname": "", 
"user-context": {""} 
}, 





 IP address "yyy.yyy.yyy.11" is part of a subnet which is NOT configured in 
kea-dhcp4.conf. 


 The client, with mac "xx:xx:xx:xx:ff:3e" , requests an IP from a subnet which 
is correctly identified by KEA, KEA will first allocate the IP (although it 
should not because it is not part fo that subnet), and then in a later step, 
KEA will send a NACK. 
 See logs below. 


 My question is: 
 ISC DHCP would not do that. 
 ISC DHCP would allocate an IP from a pool of the selected subnet because the 
reserved IP does not match. 
 Is it expected that KEA does not behave the same way ? 
 Is there any tuning that can be used so that KEA behaves the same way as ISC 
DHCP used to behave ? 


 Thanks, 
 Veronique 




 logs: 


 # DISCOVER 



 2022-08-30 11:53:03.131 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: DHCPDISCOVER (type 1) received from my_router_ip to 
my_kea_server_ip on interface enp3s0f0 

2022-08-30 11:53:03.132 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_SUBNET_SELECTED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: the subnet with ID 2887444672 was selected for client 
assignments 



 2022-08-30 11:53:03.133 DEBUG [kea-dhcp4.alloc-engine/21553.140195413911744] 
ALLOC_ENGINE_V4_DISCOVER_HR client [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b sending DHCPDISCOVER has reservation for the address 
yyy.yyy.yyy.11 



 # OFFER  


 2022-08-30 11:53:03.133 INFO [kea-dhcp4.leases/21553.140195413911744] 
DHCP4_LEASE_ADVERT [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
lease yyy.yyy.yyy.11 will be advertised 



 2022-08-30 11:53:03.133 DEBUG [kea-dhcp4.options/21553.140195413911744] 
DHCP4_PACKET_PACK [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
preparing on-wire format of the packet to be sent 
2022-08-30 11:53:03.133 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_PACKET_SEND [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
trying to send packet DHCPOFFER (type 2) from my_kea_server_ip:67 to 
my_router_ip:67 on interface enp3s0f0 



 # REQUEST  


 2022-08-30 11:53:03.608 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: DHCPREQUEST (type 3) received from my_router_ip to 
my_kea_server_ip on interface enp3s0f0 



 2022-08-30 11:53:03.611 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_SUBNET_SELECTED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: the subnet with ID 2887444672 was selected for client 
assignments 



 2022-08-30 11:53:03.612 DEBUG [kea-dhcp4.alloc-engine/21553.140195413911744] 
ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no 
info], tid=0xa4a8ab1b: trying to allocate requested address yyy.yyy.yyy.11 



 # ACK  


 2022-08-30 11:53:03.612 INFO [kea-dhcp4.leases/21553.140195413911744] 
DHCP4_LEASE_ALLOC [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
lease yyy.yyy.yyy.11 has been allocated for 242 seconds 



 2022-08-30 11:53:03.613 DEBUG [kea-dhcp4.options/21553.140195413911744] 
DHCP4_PACKET_PACK [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
preparing on-wire format of the packet to be sent 
2022-08-30 11:53:03.613 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_PACKET_SEND [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
trying to send packet DHCPACK (type 5) from my_kea_server_ip:67 to 
my_router_ip:67 on interface enp3s0f0 




 # 2nd REQUEST but this time subnet selection fails 


 2022-08-30 11:54:44.178 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: DHCPREQUEST (type 3) received from yyy.yyy.yyy.11 to 
my_kea_server_ip on interface enp3s0f0 



 2022-08-30 11:54:44.180 DEBUG [kea-dhcp4.packets/21553.140195413911744] 
DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: failed to select subnet for the client 



 2022-08-30 11:54:44.181 ERROR [kea-dhcp4.bad-packets/21553.140195413911744] 
DHCP4_PACKET_NAK_0001 [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], 
tid=0xa4a8ab1b: failed to select a subnet for incoming packet, src 
yyy.yyy.yyy.11, type DHCPREQUEST 



 # NACK 


 2022-08-30 11:54:44.181 DEBUG [kea-dhcp4.options/21553.140195413911744] 
DHCP4_PACKET_PACK [hwtype=1 xx:xx:xx:xx:ff:3e], cid=[no info], tid=0xa4a8ab1b: 
preparing on-wire format of the packet 

Re: [Kea-users] shared-network "interface" and "relay" parameters

[Veronique Lefebure]

Dear Francis,

How is that configured in ISC DHCP ?
We are running ISC DHCP in production today, and we don't have anything like 
that configured in dhcpd.conf.
It looks to me that everything works out-of-the-box, both with ISC DHCP and 
with KEA, following the logic based on the use of ciadddr and giaddr described 
in 
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?highlight=giaddr#how-the-dhcpv4-server-selects-a-subnet-for-the-client
 .


> On 17/06/2022 11:00 Francis Dupont  wrote:
 
> > 2) that these 2 parameters don't exist in ISC DHCP. They are new with KEA, 
> > right ?
> 
> => yes, in ISC DHCP you have to specify them in each subnet member of the
> shared network or use a group to factor them. In general the ISC DHCP
> configuration is far less structured than the Kea one...
-- 
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

[Kea-users] ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR and ALLOC_ENGINE_V6_ALLOC_UNRESERVED

[Veronique Lefebure]

Hi,
Out test client is failing to get an IPv6 IP.
Enabling debug logs, we see messages from the server that seem contradictory:

2022-06-21 16:43:50.948 DEBUG [kea-dhcp6.alloc-engine/13499.139838611867840] 
ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for 
client duid=[00:01:00:01:2a:44:7a:5c:xx:xx:xx:xx:xx:xx], tid=0x93e611 
2022-06-21 16:43:50.948 DEBUG [kea-dhcp6.alloc-engine/13499.139838611867840] 
ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available - trying to 
dynamically allocate leases for client 
duid=[00:01:00:01:2a:44:7a:5c:xx:xx:xx:xx:xx:xx], tid=0x93e611

where xx:xx:xx:xx:xx:xx is the client mac address.
How can that happen ?

Kea has correctly identified the subnet where the client reservation is defined:
2022-06-21 16:43:50.947 DEBUG [kea-dhcp6.packets/13499.139838611867840] 
DHCP6_SUBNET_SELECTED duid=[00:01:00:01:2a:44:7a:5c:xx:xx:xx:xx:xx:xx], 
tid=0x93e611: the subnet with ID 2156789248 was selected for client assignments

Thanks for helping.
Veronique -- 
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

[Kea-users] EVAL_RESULT is in category kea-dhcp4.options for ipv4 but in kea-dhcp6.dhcp6 for ipv6

[Veronique Lefebure]

 Hi, 
 using kea 2.1.6 I see that  
 EVAL_RESULT logs are classified in different categories for ipv4 and ipv6: 
 ipv4:  kea-dhcp4.options  
 ipv6:  kea-dhcp6.dhcp6  


 Is it a (minor) bug or do I have something mis-configured on my side ? 
 Thanks, 
 Veronique -- 
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

Re: [Kea-users] shared-network "interface" and "relay" parameters

[Veronique Lefebure]

Dear Francis,
thanks a lot for your answer.

You say:

> Please note the localization process is the same for ISC DHCP and Kea:
> it follows the standard so selectors are used in the same order,
> and in both when shared networks are used the "selected subnet" is
> in fact the selected shared network: next steps will iterate through
> members, in Kea starting by the selected subnet.
 
Ok, this is clear. 
It is well described on 
https://kea.readthedocs.io/en/latest/umls.html#dhcpv4-subnet-selection 
Can you confirm that "interface" and "relay" parameters, which, in KEA, can be 
configured either at the level of the shared-network, or at the level of the 
subnet, 
1) are both optional parameters and are not really needed in "standard" 
topologies, and 
2) that these 2 parameters don't exist in ISC DHCP. They are new with KEA, 
right ?

Thanks again.
Veronique
-- 
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

[Kea-users] shared-network "interface" and "relay" parameters

[Veronique Lefebure]

Hi,
I have read 
* 
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?highlight=subnet4#local-and-relayed-traffic-in-shared-networks
* and 
https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?highlight=subnet4#using-a-specific-relay-agent-for-a-subnet
But the following is not clear to me. Can someone help clarifying ?

- In ISC DHCP there is no subnet selectors (interface or relay address) , i.e 
no  "interface" nor "relay" parameter in Shared-Network. Why is it needed in 
KEA and not in DHCPD ? What is DHCPD using in order to select the subnet, since 
there is no "interface" nor "relay" parameter in the configuration file ? Why 
does KEA not use the same mechanism ?

- are "interface" and  "relay" exclusive or can we have both ?


Thanks,
Veronique
 -- 
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

[Kea-users] debug logging for HA heartbeat

[Veronique Lefebure]

Hi,

I would like to get a DEBUG logging each time a server receives a heartbeat 
from its partner, in a HA setup.
I have enabled DEBUG level 99 for kea-dhcp4.ha-hooks but it does not provide 
that info,

I am trying to understand why our standby server shows the following every 2 
min:

2022-01-28 13:02:30.869 WARN [kea-dhcp4.ha-hooks/22827.140145289767104] 
HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to kea1 
(http://xx.253:9099/): Connection timed out
2022-01-28 13:02:30.869 WARN [kea-dhcp4.ha-hooks/22827.140145289767104] 
HA_COMMUNICATION_INTERRUPTED communication with kea1 is interrupted


And the primary server then oscillates like this (we have only 1 client for now 
for test purpose):

2022-01-28 13:06:31.887 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_STATE_TRANSITION server transitions from HOT-STANDBY to WAITING state, 
partner state is PARTNER-DOWN
2022-01-28 13:06:31.887 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while 
in WAITING state
2022-01-28 13:06:31.887 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the kea1 is in the 
WAITING state
2022-01-28 13:06:31.887 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_STATE_TRANSITION server transitions from WAITING to SYNCING state, partner 
state is PARTNER-DOWN
2022-01-28 13:06:31.887 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while 
in SYNCING state
2022-01-28 13:06:31.888 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_SYNC_START starting lease database synchronization with kea2
2022-01-28 13:06:31.972 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LEASES_SYNC_LEASE_PAGE_RECEIVED received 1 leases from kea2
2022-01-28 13:06:31.972 DEBUG [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LEASE_SYNC_STALE_LEASE4_SKIP skipping stale lease xx.xx.xx.xx in subnet 
2156789248
2022-01-28 13:06:31.975 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_SYNC_SUCCESSFUL lease database synchronization with kea2 completed 
successfully in 87.082 ms
2022-01-28 13:06:31.976 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_STATE_TRANSITION server transitions from SYNCING to READY state, partner 
state is PARTNER-DOWN
2022-01-28 13:06:31.976 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while 
in READY state



2022-01-28 13:06:52.532 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_STATE_TRANSITION server transitions from READY to HOT-STANDBY state, partner 
state is HOT-STANDBY
2022-01-28 13:06:52.532 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in 
HOT-STANDBY state
2022-01-28 13:06:52.532 INFO [kea-dhcp4.ha-hooks/12849.140566551173312] 
HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the kea1 is in the 
HOT-STANDBY state

Thanks.___
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

[Kea-users] KEA sends valid-lifetime = 0

[Veronique Lefebure]

Hi,

For the following query:

16:24:15.730401 IP6 (hlim 1, next-header UDP (17) payload length: 143)
cs-lab11-kea.dhcpv6-client > ff02::1:2.dhcpv6-server:
[bad udp cksum 0xc2bb -> 0xa8e1!]
dhcp6 renew (xid=50bedb
(client-ID type 4)
(server-ID hwaddr/time type 1 time 692127779 00259074ca68)
(option-request DNS-server DNS-search-list DNS-server DNS-search-list client-ID)
(elapsed-time 0) (Client-FQDN)
(IA_NA IAID:795336567 T1:3600 T2:5400(IA_ADDR ::101:1 pltime:7200 
vltime:7500))
)

I have observed a case where KEA dhcp6 returns the following:

16:24:16.359170 IP6 (hlim 64, next-header UDP (17) payload length: 171)
gateway.dhcpv6-server > cs-lab11-kea.dhcpv6-client:
[udp sum ok]
dhcp6 reply (xid=50bedb
(client-ID type 4)
(server-ID hwaddr/time type 1 time 692127779 00259074ca68)
(IA_NA IAID:795336567 T1:40 T2:100
(IA_ADDR ::101:1 pltime:120 vltime:120)
(IA_ADDR ::101:1 pltime:0 vltime:0))
(DNS-search-list cern.ch.) (Client-FQDN))

Where there are 2 IA_ADDR, the second one having a vltime of 0.

Any idea how that can happen ?

wireshark shows this:

[...]
Message type: Reply (7)
Transaction ID: 0x52a6e8
Client Identifier
Server Identifier
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 68
xxx
IAID: 2f67df77
T1: 40
T2: 100
IA Address
Option: IA Address (5)
Length: 24
Value: 101000100780078
IPv6 address: 2001:1458:202:1d5::101:1 (::101:1)
Preferred lifetime: 120
Valid lifetime: 120
IA Address
Option: IA Address (5)
Length: 24
Value: 1010001
IPv6 address: 2001:1458:202:1d5::101:1 (::101:1)
Preferred lifetime: 0
Valid lifetime: 0
Domain Search List
Fully Qualified Domain Name

Thanks,
Veronique___
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

[Kea-users] KEA High-Availability experience

[Veronique Lefebure]

Hi,
we plan to adopt the "hot-standby" high-availability mode.
The main reason being that compared to load-balancing, it makes the 
configuration files simpler.
Has any one have experience to share on this topic ?
If yes, what is the DHCP traffic rate you have ? 
How many (dynamic) leases in average ? on ipv4 ? on ipv6 ?
With DDNS enabled ?
Are the KEA servers running on bare-metal or on virtual machines ?
On which operating system ? Which KEA version ?

Thanks,
Veronique___
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

[Kea-users] lease state codes

[Veronique Lefebure]

Hi,
In 
https://kea.readthedocs.io/en/latest/api.html?highlight=lease6-get-all#lease6-get-all
  
https://kea.readthedocs.io/en/latest/api.html?highlight=lease6-get-all#lease6-get-all
What is the meaning of the "lease state" ?
What are the possible values ? for ipv4 and for ipv6 ?
Thanks,
Veronique___
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

[Kea-users] fqdn-fwd and fqdn-rev in lease file

[Veronique Lefebure]

Hi,
Do I understand correctly that if an IP is assigned dynamically to a client, 
and ddns-send-updates is set to true, then the lease file should show the 
followin for the assigned lease :

"fqdn-fwd": true, 
"fqdn-rev": true,


It seems to be the case for dhcp6 but not for dhcp4 where I see these 2 fields 
set to false..
Has anyone else noticed the same ?
Is this a bug ?

Thanks,
Veronique

___
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

[Kea-users] valid-lifetime is short than preferred lifetime

[Veronique Lefebure]

Hi,

Our client is refusing an ipv6 lease offered by KEA:

 
[root@cs-lab11-kea ~]# dhclient -6 -v enp7s0f1

Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on Socket/enp7s0f1
Sending on Socket/enp7s0f1
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT: X-- IA_NA 2f:67:df:77
XMT: | X-- Request renew in +3600
XMT: | X-- Request rebind in +5400
XMT: Solicit on enp7s0f1, interval 1040ms.
RCV: Advertise message on enp7s0f1 from ::27f0.
RCV: X-- IA_NA 2f:67:df:77
RCV: | X-- starts 1642517657
RCV: | X-- t1 - renew +32400
RCV: | X-- t2 - rebind +48600
RCV: | X-- [Options]
RCV: | | X-- IAADDR 2001::1
RCV: | | | X-- Preferred lifetime 86400.
RCV: | | | X-- Max lifetime 7500.
RCV: | | | !-- INVALID lifetimes, IAADDR discarded. Check your server 
configuration.
RCV: X-- Server ID: :ca:68
PRC: Lease failed to satisfy.

Any idea why KEA returns 7500 as Max lifetime ?
It is not configured like that.
We have:

"valid-lifetime": 86400,
"min-valid-lifetime": 86400,
"max-valid-lifetime": 86400,
"preferred-lifetime": 86400,
"renew-timer": 32400,
"rebind-timer": 48600,

Thanks___
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

[Kea-users] KEA support for option 150 (tftp-server-ip)

[Veronique Lefebure]

Hello,
In ISC DHCP v4.4.2 we have 
(https://downloads.isc.org/isc/dhcp/4.4.2/dhcp-4.4.2-RELNOTES) : 

Support for sending and receiving additional DHCP4 options has been added to 
both the dhcpd and dhclient. Specifically: option codes 93,94, and 97 (RFC 
4578); code 150 (RFC 5859); and codes 209,219, and 211 (RFC 5071). Beyond 
configuring, sending, requesting, and receiving these options neither server 
nor client apply any additional logic based on their values. Thanks to Peter 
Lewis for requesting this change. [ISC-Bugs 47062]


In KEA, it seems that option 150 is not support.
We get this error: 

 [Validation] Error encountered: definition for the option 
'dhcp4.tftp-server-ip' having code '0' does not exist 

Is there a solution or do we have to define that option ourselves?

Thanks,
Veronique___
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

Re: [Kea-users] HTTP_CONNECTION_HANDSHAKE_FAILED TLS handshake

[Veronique Lefebure]

Many thanks Francis,
we will have a look about how to have that fixed on our side.
Veronique

> On 24/11/2021 20:06 Francis Dupont  wrote:
> 
>  
> The "wrong version number" error is returned by some crypto libraries
> when TLS is expected but clear text HTTP is received.
> 
> Regards
> 
> Francis Dupont 
> 
> PS: I say "some" because at least one has a dedicated code to detect
> this very common error and emits a more user friendly error message
> ("http request" on recent OpenSSL versions, BTW old OpenSSL versions
> have known security bugs so should not be used...).
___
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

[Kea-users] HTTP_CONNECTION_HANDSHAKE_FAILED TLS handshake

[Veronique Lefebure]

Hi,

I am testing a high availibility setup for 2 KEA dhcp4 servers.
I get these errors:

2021-11-24 11:33:41.962 DEBUG [kea-ctrl-agent.http/8134.140201213065408] 
HTTP_CONNECTION_HANDSHAKE_START start TLS handshake with xx.xx.xx.252 with 
timeout 10
2021-11-24 11:33:42.963 INFO [kea-ctrl-agent.http/8134.140201213065408] 
HTTP_CONNECTION_HANDSHAKE_FAILED TLS handshake with xx.xx.xx.252 failed with 
wrong version number
2021-11-24 11:33:42.963 DEBUG [kea-ctrl-agent.http/8134.140201213065408] 
HTTP_CONNECTION_STOP stopping HTTP connection from xx.xx.xx.252

Any idea how I can debug that ?
Both servers are installed and configured the same way.
And I see the same errors on both servers.
Thanks,
Veronique___
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

[Kea-users] Support for supersede together with dhcp-server-identifier

[Veronique Lefebure]

Hi,

please see https://gitlab.isc.org/isc-projects/kea/-/issues/2090 
We are wondering if any of you would have the same need, or maybe have a 
solution.
Thanks___
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

Re: [Kea-users] kea-dhcp4 -t file: check the configuration file syntax and exit but fails because of interface

[Veronique Lefebure]

YES :-)

That's the work around. Thanks !!

On 27/08/2021 15:42, Andrei Pavel wrote:
ip link add x type bridge 

___
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

Re: [Kea-users] kea-dhcp4 -t file: check the configuration file syntax and exit but fails because of interface

[Veronique Lefebure]

Checking every configuration bits for production is definitively an 
excellent thing. But one could have an option to skip validating some 
part(s) of them.


On 27/08/2021 15:38, perl-list wrote:

I understand, but you don't have to put the configuration file in its final 
home, you could drop it in /tmp/ or equivalent and run kea-dhcp4 -t 
/tmp/kea-dhcp4.conf and then copy it into place if it passes the test.

I doubt that ISC is going to be keen to not check certain bits of the 
configuration file (such as the interface section).

- Original Message -

From: "Veronique Lefebure" 
To: "perl-list" , "kea-users" 
Sent: Friday, August 27, 2021 9:29:40 AM
Subject: Re: [Kea-users] kea-dhcp4 -t file: check the configuration file syntax 
and exit but fails because of interface
We want to be able to validate the configuration file without
touching/accessing the production servers, for example for
developing/testing/validating changes in the software that generates the
configuration file.
On 27/08/2021 15:12, perl-list wrote:

Is it not possible to, instead, check the conf file on host2 where it will live?
- Original Message -----

From: "Veronique Lefebure" 
To: "kea-users" 
Sent: Friday, August 27, 2021 5:39:15 AM
Subject: [Kea-users] kea-dhcp4 -t file: check the configuration file syntax and
exit but fails because of interface
Hi,
Before deploying a new kea configuration file on our DHCP server, we
want to validate it.
The configuration file "kea-dhcp4.conf" is generated on host1 where we
want to validate it by running
kea-dhcp4 -t kea-dhcp4.conf
And once validation has passed, we plan to deploy "kea-dhcp4.conf" ho
the KEA server running on host2.
The problem we have is that validation fails with the following error:
Error encountered: Failed to select interface: interface 'x' doesn't
exist in the system (kea-dhcp4.conf:225:9) (kea-dhcp4.conf:224:7)
coming from
"interfaces-config": {
"interfaces": [
"x"
],
"dhcp-socket-type": "udp"
},
Interface 'x' may exist on host2 but not on host1.
Is anyone encountering the same problem ?
Is there a work-around ?
Thanks,
Veronique
___
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

___
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

Re: [Kea-users] kea-dhcp4 -t file: check the configuration file syntax and exit but fails because of interface

[Veronique Lefebure]

We want to be able to validate the configuration file without 
touching/accessing the production servers, for example for 
developing/testing/validating changes in the software that generates the 
configuration file.


On 27/08/2021 15:12, perl-list wrote:

Is it not possible to, instead, check the conf file on host2 where it will live?

- Original Message -

From: "Veronique Lefebure" 
To: "kea-users" 
Sent: Friday, August 27, 2021 5:39:15 AM
Subject: [Kea-users] kea-dhcp4 -t file: check the configuration file syntax and 
exit but fails because of interface
Hi,
Before deploying a new kea configuration file on our DHCP server, we
want to validate it.
The configuration file "kea-dhcp4.conf" is generated on host1 where we
want to validate it by running
kea-dhcp4 -t kea-dhcp4.conf
And once validation has passed, we plan to deploy "kea-dhcp4.conf" ho
the KEA server running on host2.
The problem we have is that validation fails with the following error:
Error encountered: Failed to select interface: interface 'x' doesn't
exist in the system (kea-dhcp4.conf:225:9) (kea-dhcp4.conf:224:7)
coming from
"interfaces-config": {
"interfaces": [
"x"
],
"dhcp-socket-type": "udp"
},
Interface 'x' may exist on host2 but not on host1.
Is anyone encountering the same problem ?
Is there a work-around ?
Thanks,
Veronique
___
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

___
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

[Kea-users] kea-dhcp4 -t file: check the configuration file syntax and exit but fails because of interface

[Veronique Lefebure]

Hi,

Before deploying a new kea configuration file on our DHCP server, we 
want to validate it.


The configuration file "kea-dhcp4.conf" is generated on host1 where we 
want to validate it by running


    kea-dhcp4 -t kea-dhcp4.conf

And once validation has passed, we plan to deploy "kea-dhcp4.conf" ho 
the KEA server running on host2.


The problem we have is that validation fails with the following error:

Error encountered: Failed to select interface: interface 'x' doesn't 
exist in the system (kea-dhcp4.conf:225:9) (kea-dhcp4.conf:224:7)


coming from

    "interfaces-config": {
  "interfaces": [
    "x"
  ],
  "dhcp-socket-type": "udp"
    },

Interface 'x' may exist on host2 but not on host1.

Is anyone encountering the same problem ?

Is there a work-around ?

Thanks,

Veronique



___
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

[Kea-users] How to use ifelse in the client-class definition

[Veronique Lefebure]

Hi,

Now that I got the confirmation that we cannot use ifelse in the host 
reservation, let me give more details about what we are looking for at 
the level of the client-class definition.


(this refers to [Kea-users] Example for ifelse in host reservation or 
class (isc.org) 
 )


We have clients of 2 types: type1 and type2.

Both types need to get, from the DHCP server, a different IP for 
"next-server" and for "Option 54": IP1 for type1, IP2 for type2.


But those options ("next-server" and "Option 54") should be sent to the 
clients ONLY when the clients send "PXEClient" in Vendor-Class Option 60 
of their DHCPDISCOVER or DHCPREQUEST messages.


How can we reach that, without having to make a test, in the class 
definition, on the mac address of the clients ?


Implementing such a test on the mac addresses allows to reach the 
desired behaviour, but then we have several 10 mac addresses to list 
in the test. This makes the configuration file 1) huge 2) unreadable 3) 
unacceptably slow to be validated, especially for ipv6.


Also we cannot set the client-class in the host reservation because, in 
that case, the test is not evaluated (this is what we have observed), 
and consequently the options "next-server" and "option 54" are provided 
to the client *even* when DHCPDISCOVER or DHCPREQUEST messages do NOT 
contain the "PXEClient" string in Vendor-Class Option 60.


Thanks for your help.

Veronique




___
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

[Kea-users] Example for ifelse in host reservation or class

[Veronique Lefebure]

Hi,

Is there a way to use ifelse in a host reservation ?

We would like something like

"reservations": [ { "hw-address": "xx:xx:xx:xx:xx:fa", "ip-address": 
"yy.yy.yy.121", "hostname": "lab-client", "client-classes": [ " ifelse ( 
substring(option[vendor-class-identifier].text, 0, 9) == 'PXEClient' , 
'Desktop', none) " ] },


But the above does not work: KEA interprets the whole string "ifelse ( 
substring(option[vendor-class-identifier].text, 0, 9) == 'PXEClient' , 
'Desktop', none) " as being the client-class name itself.


Alternatively we could use "ifelse" in the client-class definition but 
none of the combinations we have tried works: we always get a syntax 
error reported by the validation of the json configuration file.


What we need is the equivalent of what we have in DHCPD:

group { # Desktop Clients if substring (option vendor-class-identifier, 
0, 9) = "PXEClient" { option vendor-class-identifier "PXEClient"; option 
dhcp-server-identifier aims.xxx; next-server aims.xxx; } host client1 { 
hardware ethernet xx:xx:xx:xx:xx:fa; option host-name "lab-client"; 
fixed-address yy.yy.yy.121; } 


}

Thanks,

Veronique

___
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