Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax

[Marek Hajduczenia]

Thank you, Darren, 

That does indeed at least pass the parser stage (actual device testing will 
have to wait). It is a pity that a regex is not yet available. I saw it was 
planned for 2.6 release?

If I can build on the previous request, this part is more challenging, since it 
relays on a custom vendor address space, specifically, DOCSIS-specific 
sub-options in Option 17. Assume I have a "device-type" sub-option defined as 
follows

"option-def": [
  {
"space": "vendor-4491",
"name": "device-type",
"code": 2,
"type": "string"
  }]

and then I would like to classify based on it to translate the ISC compare 
statement of " match if (option docsis.device-type) = 'EROUTER'". Following 
your example below 

"test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'" 

Should be theoretically possible, but I do not think the parser likes it much: 
[substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'] error: 
:1.17-21: syntax error, unexpected integer, expecting [ or . at 
(/etc/kea/kea-dhcp6.conf:141:17)

Regards

Marek

-Original Message-
From: Kea-users  On Behalf Of Darren Ankney
Sent: Friday, April 19, 2024 3:08 PM
To: Kea user's list 
Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax

Hi Marek,

That is pseudo code generated by KeaMA as Kea doesn't support regex statements 
like ISC DHCP did.  There was probably an additional line output that linked to 
some GL issue explaining.  Something like this might work (I've not tested it):

"client-classes": [
  {
"name": "rpd-1",
    "test": "substring(relay6[1].option[18].hex,-1,9) == 'Md1:0/0.0'"
  }
]

Thank you,
Darren Ankney

On Fri, Apr 19, 2024 at 4:27 PM Marek Hajduczenia  
wrote:
>
> Dear colleagues,
>
>
>
> I ran into a bit of a challenge with the conversion of the config from ISC to 
> Kea, namely this little class definition gem:
>
>
>
> class "rpd-1" { match if v6relay( 1, option dhcp6.interface-id ) ~= 
> "Md1:0/0.0$"; }
>
>
>
> What it does, as you can tell, it matches on the inner relay interface-id 
> field in the DHCPv6 messages. Nothing fancy, it does work as tested.
>
>
>
> I have been looking at the available options and nothing comes to mind 
> so I used keama for automatic conversion and it generated something 
> pretty complex, as follows. Additionally, it is commented out, so I 
> assume this is a non-working configuration element (?)
>
>
>
> "client-classes": [
>
>   {
>
> "name": "rpd-1"
>
> //  /// match if (v6relay(1, option dhcp6.interface-id)) ~= 'Md1:0/0.0$'
>
> //  "match-if": {
>
> //"regex-match": {
>
> //  "left": {
>
> //"v6relay": {
>
> //  "relay": 1,
>
> //  "relay-option": {
>
> //"option": {
>
> //  "universe": "dhcp6",
>
> //  "name": "interface-id",
>
> //  "code": 18
>
> //}
>
> //  }
>
> //}
>
> //  },
>
> //  "right": "Md1:0/0.0$"
>
> //}
>
> //  }
>
>   }]
>
>
>
> If I try to remove the comment markup and apply it with Kea 2.4.1, the parser 
> does not like the “match-if” statement for some reason. I cannot locate it in 
> the list of Kea statements, so not sure why it would be generated by keama. 
> However, the bigger question is on how to build a Kea-compatible match on 
> such embedded message. Any help here would be really appreciated.
>
>
>
> Apr 19 18:54:20 server-kea-node1 systemd[1]: Started Kea DHCPv6 Service.
>
> Apr 19 18:54:20 server-kea-node1 kea-dhcp6[2099]: 2024-04-19 
> 18:54:20.202 ERROR [kea-dhcp6.dhcp6/2099.841038976] DHCP6_INIT_FAIL 
> failed to initialize Kea server: configuration error using file 
> '/etc/kea/kea-dhcp6.conf': /etc/kea/kea-dhcp6.conf:118.9-18: syntax 
> error, unexpected constant string, expecting }
>
> Apr 19 18:54:20 server-kea-node1 systemd[1]: 
> isc-kea-dhcp6-server.service: Main process exited, code=exited, 
> status=1/FAILURE
>
> Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service: 
> Failed with result 'exit-code'.
>
>
>
> Regards
>
>
>
> Marek
>
> --
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ fo

[Kea-users] Converting an ISC IPv6 class definition to Kea syntax

[Marek Hajduczenia]

Dear colleagues, 

 

I ran into a bit of a challenge with the conversion of the config from ISC
to Kea, namely this little class definition gem:

 

class "rpd-1" { match if v6relay( 1, option dhcp6.interface-id ) ~=
"Md1:0/0.0$"; }

 

What it does, as you can tell, it matches on the inner relay interface-id
field in the DHCPv6 messages. Nothing fancy, it does work as tested. 

 

I have been looking at the available options and nothing comes to mind so I
used keama for automatic conversion and it generated something pretty
complex, as follows. Additionally, it is commented out, so I assume this is
a non-working configuration element (?)

 

"client-classes": [

  {

"name": "rpd-1"

//  /// match if (v6relay(1, option dhcp6.interface-id)) ~= 'Md1:0/0.0$'

//  "match-if": {

//"regex-match": {

//  "left": {

//"v6relay": {

//  "relay": 1,

//  "relay-option": {

//"option": {

//  "universe": "dhcp6",

//  "name": "interface-id",

//  "code": 18

//}

//  }

//}

//  },

//  "right": "Md1:0/0.0$"

//}

//  }

  }]

 

If I try to remove the comment markup and apply it with Kea 2.4.1, the
parser does not like the "match-if" statement for some reason. I cannot
locate it in the list of Kea statements, so not sure why it would be
generated by keama. However, the bigger question is on how to build a
Kea-compatible match on such embedded message. Any help here would be really
appreciated. 

 

Apr 19 18:54:20 server-kea-node1 systemd[1]: Started Kea DHCPv6 Service.

Apr 19 18:54:20 server-kea-node1 kea-dhcp6[2099]: 2024-04-19 18:54:20.202
ERROR [kea-dhcp6.dhcp6/2099.841038976] DHCP6_INIT_FAIL failed to initialize
Kea server: configuration error using file '/etc/kea/kea-dhcp6.conf':
/etc/kea/kea-dhcp6.conf:118.9-18: syntax error, unexpected constant string,
expecting }

Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service:
Main process exited, code=exited, status=1/FAILURE

Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service:
Failed with result 'exit-code'.

 

Regards

 

Marek

-- 
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, shared network, and double-relay Solicit messages

[Marek Hajduczenia]

So I think I found the potential solution, though I am not sure I understand 
why this happens. I had to specifically configure the unicast IPv6 address in 
the “interfaces” clause, as follows

"interfaces-config": {
  "interfaces": [
"enp6s18/2600:6ce4:0:42::130"
  ]
},

far from ideal, but it seems to force the association with the unicast IPv6 
address (marked in yellow highlight below)

root@server-kea-node1:/etc/kea# ss -tulpn
Netid State  Recv-Q Send-Q Local 
Address:PortPeer Address:Port Process
udp   UNCONN 0  0  
127.0.0.1:530010.0.0.0:* 
users:(("kea-dhcp-ddns",pid=629,fd=13))
udp   UNCONN 0  0  
127.0.0.53%lo:53   0.0.0.0:* 
users:(("systemd-resolve",pid=610,fd=13))
udp   UNCONN 0  0 
172.17.129.130:67   0.0.0.0:* 
users:(("kea-dhcp4",pid=630,fd=17))
udp   UNCONN 0  0  
[2600:6ce4:0:42::130]:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=17))
udp   UNCONN 0  0
[fe80::be24:11ff:fea6:ccbe]%enp6s18:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=18))
udp   UNCONN 0  0
[ff02::1:2]%enp6s18:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=19))
tcp   LISTEN 0  4096   
127.0.0.1:8000 0.0.0.0:* 
users:(("kea-ctrl-agent",pid=628,fd=7))
tcp   LISTEN 0  128  
0.0.0.0:22   0.0.0.0:* users:(("sshd",pid=673,fd=3))
tcp   LISTEN 0  4096   
127.0.0.53%lo:53   0.0.0.0:* 
users:(("systemd-resolve",pid=610,fd=14))
tcp   LISTEN 0  4096
   *:9119   *:* users:(("stork-agent",pid=632,fd=8))
tcp   LISTEN 0  128 
[::]:22  [::]:* users:(("sshd",pid=673,fd=4))
tcp   LISTEN 0  4096
   *:8080   *:* users:(("stork-agent",pid=632,fd=9))
tcp   LISTEN 0  4096
   *:9547   *:* users:(("stork-agent",pid=632,fd=3)

but this behavior does not seem to be documented anywhere. I did not find any 
indication that for v6 an explicit address allocation is also required, 
otherwise just the link local will be bound. Is this an expected behavior?

Regards

Marek

From: mxhajducze...@gmail.com 
Date: Tuesday, April 23, 2024 at 9:56 AM
To: 'Kea user's list' 
Subject: RE: DHCPv6, shared network, and double-relay Solicit messages
I guess netstat is deprecated. “ss” seems to show the binding but … only to a 
link local address for some reason on the v6 side.

root@server-kea-node1:~# ss -tulpn
Netid  State   Recv-Q   Send-Q  
 Local Address:Port  Peer Address:Port  
Process
udpUNCONN  00   
 127.0.0.1:53001  0.0.0.0:* 
 users:(("kea-dhcp-ddns",pid=629,fd=13))
udpUNCONN  00   
 127.0.0.53%lo:53 0.0.0.0:* 
 users:(("systemd-resolve",pid=610,fd=13))
udpUNCONN  00   
172.17.129.130:67 0.0.0.0:* 
 users:(("kea-dhcp4",pid=630,fd=17))
udpUNCONN  00  
[fe80::be24:11ff:fea6:ccbe]%enp6s18:547   [::]:*
  users:(("kea-dhcp6",pid=1631,fd=17))
udpUNCONN  00   
   [ff02::1:2]%enp6s18:547   [::]:* 
 users:(("kea-dhcp6",pid=1631,fd=18))
tcpLISTEN  04096
 127.0.0.1:8000   0.0.0.0:* 
 users:(("kea-ctrl-agent",pid=628,fd=7))
tcpLISTEN  0128 
   0.0.0.0:22 0.0.0.0:* 
 users:(("sshd",pid=673,fd=3))
tcpLISTEN  04096
 

Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit messages

[Marek Hajduczenia]

I have not been able to find a workaround for this problem on IPv6 side for 
now. 

 

Marek

 

From: Kea-users  On Behalf Of Butler, Glenn 
via Kea-users
Sent: Tuesday, April 23, 2024 3:58 PM
To: Kea user's list 
Cc: Butler, Glenn 
Subject: Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit 
messages

 

I need to figure this out also, as I run Kea in a container that can be 
destroyed and rebuilt anytime.  I am thinking I will update the Kea config via 
a shell script run on boot/init. 

 

Would be nice if there was a "listen on all" option like 0.0.0.0 does for IPv4, 
but all the docs I have read indicate that it only binds to one address.

 

On Apr 23, 2024 09:26, Marek Hajduczenia mailto:mxhajducze...@gmail.com> > wrote:

  _  

WARNING: External email. Please verify sender before opening attachments or 
clicking on links.

  _  

 

So I think I found the potential solution, though I am not sure I understand 
why this happens. I had to specifically configure the unicast IPv6 address in 
the “interfaces” clause, as follows

 

"interfaces-config": {

  "interfaces": [

"enp6s18/2600:6ce4:0:42::130"

  ]

},

 

far from ideal, but it seems to force the association with the unicast IPv6 
address (marked in yellow highlight below)

 

root@server-kea-node1:/etc/kea# ss -tulpn

Netid State  Recv-Q Send-Q Local 
Address:PortPeer Address:Port Process   
 

udp   UNCONN 0  0  
127.0.0.1:530010.0.0.0:* 
users:(("kea-dhcp-ddns",pid=629,fd=13))   

udp   UNCONN 0  0  
127.0.0.53%lo:53   0.0.0.0:* 
users:(("systemd-resolve",pid=610,fd=13)) 

udp   UNCONN 0  0 
172.17.129.130:67   0.0.0.0:* 
users:(("kea-dhcp4",pid=630,fd=17))   

udp   UNCONN 0  0  
[2600:6ce4:0:42::130]:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=17))  

udp   UNCONN 0  0
[fe80::be24:11ff:fea6:ccbe]%enp6s18:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=18))  

udp   UNCONN 0  0
[ff02::1:2]%enp6s18:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=19))  

tcp   LISTEN 0  4096   
127.0.0.1:8000 0.0.0.0:* 
users:(("kea-ctrl-agent",pid=628,fd=7))   

tcp   LISTEN 0  128  
0.0.0.0:22   0.0.0.0:* users:(("sshd",pid=673,fd=3))
 

tcp   LISTEN 0  4096   
127.0.0.53%lo:53   0.0.0.0:* 
users:(("systemd-resolve",pid=610,fd=14)) 

tcp   LISTEN 0  4096
   *:9119   *:* 
users:(("stork-agent",pid=632,fd=8))  

tcp   LISTEN 0  128 
[::]:22  [::]:* users:(("sshd",pid=673,fd=4))   
  

tcp   LISTEN 0  4096
   *:8080   *:* 
users:(("stork-agent",pid=632,fd=9))  

tcp   LISTEN 0  4096
   *:9547   *:* users:(("stork-agent",pid=632,fd=3)

 

but this behavior does not seem to be documented anywhere. I did not find any 
indication that for v6 an explicit address allocation is also required, 
otherwise just the link local will be bound. Is this an expected behavior?

 

Regards

 

Marek

 

From: mxhajducze...@gmail.com <mailto:mxhajducze...@gmail.com>  
mailto:mxhajducze...@gmail.com> >
Date: Tuesday, April 23, 2024 at 9:56 AM
To: 'Kea user's list' mailto:kea-users@lists.isc.org> 
>
Subject: RE: DHCPv6, shared network, and double-relay Solicit messages

I guess netstat is deprecated. “ss” seems to show the binding but … only to a 
link local address for some reason on the v6 side. 

 

root@server-kea-node1:~# ss -tulpn

Netid  State   Recv-Q   Send-Q  
 Local Address:Port  Peer Address:Port  
Process 

udpUNCONN  00  

Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit messages

[Marek Hajduczenia]

Thank you, Darren 

 

I did find the other ticket which seems to have been open for 2 years (?): 
https://gitlab.isc.org/isc-projects/kea/-/issues/2212 and added my information 
to it. I can reproduce it now on demand on any nodes. As mentioned, the link 
local bind will work fine when DHCP clients are on the same L2 segment where 
link-local reachability is sufficient for routing purposes. It will not work in 
environment where relays are used, and unicast routing is required. This would 
be the case in Docker and also in my setup. 

 

Regards

 

Marek 

 

From: Kea-users  On Behalf Of Darren Ankney
Sent: Wednesday, April 24, 2024 4:00 AM
To: Kea user's list 
Subject: Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit 
messages

 

This does not seem to be intended behavior: 
https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#interface-configuration
 as this shows the following configurations all as valid:




"interfaces-config": {
"interfaces": [ "*" ]
},
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ]
},
"interfaces-config": {
"interfaces": [ "eth1", "eth3", "*" ]
},
"interfaces-config": {
"interfaces": [ "enp0s2/2001:db8::1234:abcd" ]
},

 

On Tue, Apr 23, 2024 at 7:04 PM Marek Hajduczenia mailto:mxhajducze...@gmail.com> > wrote:

I have not been able to find a workaround for this problem on IPv6 side for 
now. 

 

Marek

 

From: Kea-users mailto:kea-users-boun...@lists.isc.org> > On Behalf Of Butler, Glenn via 
Kea-users
Sent: Tuesday, April 23, 2024 3:58 PM
To: Kea user's list mailto:kea-users@lists.isc.org> >
Cc: Butler, Glenn mailto:glenn.but...@ziply.com> >
Subject: Re: [Kea-users] DHCPv6, shared network, and double-relay Solicit 
messages

 

I need to figure this out also, as I run Kea in a container that can be 
destroyed and rebuilt anytime.  I am thinking I will update the Kea config via 
a shell script run on boot/init. 

 

Would be nice if there was a "listen on all" option like 0.0.0.0 does for IPv4, 
but all the docs I have read indicate that it only binds to one address.

 

On Apr 23, 2024 09:26, Marek Hajduczenia mailto:mxhajducze...@gmail.com> > wrote:

  _  

WARNING: External email. Please verify sender before opening attachments or 
clicking on links.

  _  

 

So I think I found the potential solution, though I am not sure I understand 
why this happens. I had to specifically configure the unicast IPv6 address in 
the “interfaces” clause, as follows

 

"interfaces-config": {

  "interfaces": [

"enp6s18/2600:6ce4:0:42::130"

  ]

},

 

far from ideal, but it seems to force the association with the unicast IPv6 
address (marked in yellow highlight below)

 

root@server-kea-node1:/etc/kea# ss -tulpn

Netid State  Recv-Q Send-Q Local 
Address:PortPeer Address:Port Process   
 

udp   UNCONN 0  0  
127.0.0.1:53001 <http://127.0.0.1:53001> 0.0.0.0:* 
users:(("kea-dhcp-ddns",pid=629,fd=13))   

udp   UNCONN 0  0  
127.0.0.53%lo:53   0.0.0.0:* 
users:(("systemd-resolve",pid=610,fd=13)) 

udp   UNCONN 0  0 
172.17.129.130:67 <http://172.17.129.130:67>0.0.0.0:*   
  users:(("kea-dhcp4",pid=630,fd=17))   

udp   UNCONN 0  0  
[2600:6ce4:0:42::130]:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=17))  

udp   UNCONN 0  0
[fe80::be24:11ff:fea6:ccbe]%enp6s18:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=18))  

udp   UNCONN 0  0
[ff02::1:2]%enp6s18:547 [::]:* 
users:(("kea-dhcp6",pid=2059,fd=19))  

tcp   LISTEN 0  4096   
127.0.0.1:8000 <http://127.0.0.1:8000>  0.0.0.0:* 
users:(("kea-ctrl-agent",pid=628,fd=7))   

tcp   LISTEN 0  128  
0.0.0.0:22 <http://0.0.0.0:22>0.0.0.0:* 
users:(("sshd",pid=673,fd=3)) 

tcp   LISTEN 0  4096   
127.0.0.53%lo:53   0.0.0.0:* 
users:(("systemd-resolve",pid=610,fd=14)) 

tcp   LISTEN 

Re: [Kea-users] "ha_dedicated_ports" warning in Stork

[Marek Hajduczenia]

Thank you, Kevin - in the example you're referring to, do I still need to
configure and run the control agent? I am a bit confounded as to what the
specific change I need to do in my setup (dhcp config or control agent
config) to make it click together

Marek

On Fri, Apr 12, 2024 at 6:31 PM Kevin P. Fleming <
lists.kea-us...@kevin.km6g.us> wrote:

> On Fri, Apr 12, 2024, at 19:36, mxhajducze...@gmail.com wrote:
>
>
>
>
> Can someone please tell me what I am doing wrong here (I did follow the
> configuration instructions) and how to fix this issue? It has been driving
> me insane for a while now …
>
>
> With recent versions of Kea, multi-threaded mode with dedicated HTTP
> listeners are the default configuration, which means that the HA
> connections do not go through the control agent processes. The Stork agent
> communicates with the Kea control agent, but the Kea daemons do not.
>
> The example configuration for HA+MT mode is here:
> https://kea.readthedocs.io/en/latest/arm/hooks.html#multi-threaded-configuration-ha-mt
>
> --
> 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] Converting an ISC IPv6 class definition to Kea syntax

[Marek Hajduczenia]

Thank you, Darren 

I did not notice that - it is buried pretty deep in the list of options. 

A general question, and I know I am an interested party here - would it make 
sense to add to documentation to cover DOCSIS-specific examples? There is going 
to be a lot of interest from this industry and I know the questions that will 
be asked, over and over again likely. 

Marek

-Original Message-
From: Kea-users  On Behalf Of Darren Ankney
Sent: Saturday, April 27, 2024 9:21 AM
To: Kea user's list 
Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax

Hi Marek,

I recently found out that you can use syntax like: 'vendor[].option[].hex' in class test lines to match instead 
of 'option[17].option[2].hex' as noted in the table
here: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#id3
Though it isn't exalty what you were asking for, perhaps it helps in some way?

Thank you,
Darren Ankney


On Wed, Apr 24, 2024 at 8:51 AM Marek Hajduczenia  
wrote:
>
> Thank you, Darren,
>
>
>
> If these custom-defined options are outbound only, it would be great if that 
> was mentioned in the documentation somewhere. In all my reading I did not 
> find a single reference to that – perhaps I just missed it. I was treating it 
> as any internally defined variable name, and since it can be used to specify 
> outbound options, I figured they should also work the same way in ingress 
> parser. Clearly, a wrong assumption on my part.
>
>
>
> Regards
>
>
>
> Marek
>
>
>
> From: Darren Ankney 
> Sent: Wednesday, April 24, 2024 3:51 AM
> To: mxhajducze...@gmail.com; Kea user's list 
> Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to 
> Kea syntax
>
>
>
> Understood Marek,
>
>
>
> >  I still dislike the fact that I cannot use option definitions that already 
> > exist in the very same configuration file. They are there, the parser 
> > should be able to reference them internally as part of the vendor-specific 
> > option space.
>
>
>
> I understand this statement too.  However, I feel it necessary to point out 
> that those option definitions are so that you can fill option data in the 
> defined option for outbound packets not so that you can use names to classify 
> inbound packets.
>
>
>
> Thank you,
>
> Darren Ankney
>
>
>
> On Tue, Apr 23, 2024 at 9:50 AM Marek Hajduczenia  
> wrote:
>
> Hi Darren,
>
>
>
> Thanks for the feedback.
>
>
>
> I did run a packet capture from a lab device and it is attached. I 
> hope it comes through - this is a DHCPv6 traffic from a DOCSIS CM 
> running in IPv6 mode only, two relay level deep, i.e., inner relay is 
> a vCMTS and outer relay is the first hop router. I hope clarify some 
> of the questions I have been asking
>
>
>
> Packet 11 is a relayed Solicit with Option 17, containing CableLabs specific 
> sub-option (4491) and then inside of it, there is sub-option 2 (Device Type), 
> which is what I need access to classify packets correctly.
>
>
>
>
>
> The very same device, just EROUTER requesting address (packet 21) and 
> again I will need access to the very same sub-option 2 (Device Type)
>
>
>
>
>
> I will build a configuration pool on a Kea test node next and attempt to use 
> your syntax suggestion, i.e., "test": 
> "substring(option[17].option[2].hex,-1,7) == 'EROUTER'" but even if that 
> works, I still dislike the fact that I cannot use option definitions that 
> already exist in the very same configuration file. They are there, the parser 
> should be able to reference them internally as part of the vendor-specific 
> option space.
>
>
>
> I will report back when I am done with a test
>
>
>
> Thank you !
>
>
>
> Marek
>
>
>
> -Original Message-
> From: Kea-users  On Behalf Of Darren 
> Ankney
> Sent: Tuesday, April 23, 2024 3:32 AM
> To: Kea user's list 
> Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to 
> Kea syntax
>
>
>
> Hi Marek,
>
>
>
> I failed to notice that this was DHCPv6.  I was talking about option
>
> 125 which is DHCPv4 vendor options.  Option 17 is covered in the 
> manual here: 
> https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcpv6-vend
> or-specific-options
>
> I am not clear regarding the presence of option 17 in the inbound packet 
> (Solicit / request).  Is option 17 in the packet?  If so, then you may be 
> able to use a test line like this:
>
>
>
> "test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'"
>
>
>
> Though again, I've not tested it.  But my understanding is that option

Re: [Kea-users] No DHCP Reply sent out from kea server

[Marek Hajduczenia]

You need to add 

 

 
{

 
"space": "dhcp6",

 
"name": "vendor-opts",

 
"code": 17,

 
"data": "4491"

 
}

 

to your "option-data" stanza. Otherwise, the process will not insert the
vendor-specific entry in Option 17. 

 

Marek

 

From: Kea-users  On Behalf Of Xiao, Yu
(CCI-Atlanta) via Kea-users
Sent: Wednesday, May 8, 2024 1:46 PM
To: Kea user's list 
Cc: Xiao, Yu (CCI-Atlanta) 
Subject: [Kea-users] No DHCP Reply sent out from kea server

 

Greetings,

 

I configured some sub-options for DHCPv6 Option 17 for RPD use. I didn't
find too detailed information regarding how to customize those sub-options
under one option such as DHCPv6 option 17. Luckily, I found some examples
from previous discussion email. Before I added those options, I could see
the Solicit, Advertise, Request and Reply packets between the RPD and DHCP
server. After the configuration, now I don't see DHCP server responded to
the Advertise packets anymore. The Advertise packet was sent. I checked the
debug logs, I don't see any reasons why the Advertise packets are not sent.
There's no errors in the debug logs. 

 

I define those options globally while use them under the class but they are
not working. Then I changed the configuration and use them under global
configuration, but still no changes. I suspect my customization
configuration for sub-options have some problem. But I don't see any issue
according to manual 9.2.15. DHCPv6 Vendor-Specific Options. Did I miss
something in the configuration? I also attached my debug settings, not sure
if there could be more detailed debug logs to help our troubleshooting
process. 

 

My kea version is 2.4.1. 

 

 

Option related Config:

 

   # custom definitions

   ### DOCSIS space

   "option-def": [{

"space": "vendor-4491",

"name": "device-type",

"code": 2,

"type": "string"

  },

  {

"space": "vendor-4491",

"name": "tftp-servers",

"code": 32,

"array": true,

"type": "ipv6-address"

  },

  {

"space": "vendor-4491",

"name": "config-file",

"code": 33,

"type": "string"

  },

  {

"space": "vendor-4491",

"name": "syslog-servers",

"code": 34,

"array": true,

"type": "ipv6-address"

  },

  {

"space": "vendor-4491",

"name": "time-servers",

"code": 37,

"array": true,

"type": "ipv6-address"

  },

  {

"space": "vendor-4491",

"name": "time-offset",

"code": 38,

"type": "int32"

  },

  {

"space": "vendor-4491",

"name": "ccap-cores",

"code": 61,

"array": true,

"type": "ipv6-address"

  },

 ],

 

"client-classes": [

{

"name": "RPD",

"test": "substring(option[17].option[2].hex,0,3) == 'RPD'",

"option-data": [

{

"space": "vendor-4491",

"name": "syslog-servers",

"code": 34,

"csv-format": true,

"data": "2001:391:20:7004:10:0:252:120"

},

{

"space": "vendor-4491",

"name": "time-servers",

"code": 37,

"csv-format": true,

"data": "2001:391:20:7004:10:0:252:112"

},

{

"space": "vendor-4491",

"name": "time-offset",

"code": 38,

"csv-format": true,

"data": "0"

},

{

"space": "vendor-4491",

"name": "ccap-cores",

"code": 61,

"csv-format": true,

"data": "2001:391:20:7010:10:0:254:73"

}

]

}

],

 

Debug config:

 

# DHCPv6 configuration ends with the next line

 

"loggers": [

{

"name": "kea-dhcp6",

"output_options": [

{

"output": "/tmp/kea-debug.log",

"maxver": 8,

"maxsize": 4048,

}

],

"severity": "DEBUG",

"debuglevel": 99

}

 

]

 

Debug logs:

.

2024-05-08 14:50:14.577 INFO  [kea-dhcp6.leases/27581.13994037504]
DHCP6_LEASE_ADVERT duid=[00:03:00:01:c4:b2:39:ba:56:98], tid=0x206da9: lease
for address 2001:391:20:7716::447 and iaid=1 will be advertised

2024-05-08 14:50:14.577 DEBUG [kea-dhcp6.leases/27581.13994037504]
DHCP6_LEASE_DATA duid=[00:03:00:01:c4:b2:39:ba:56:98], tid=0x206da9:
detailed lease information for iaid=1: Type:  IA_NA(0)

Address:   2001:391:20:7716::447

Prefix length: 128

IAID:  1

Pref life: 300

Valid 

Re: [Kea-users] [EXTERNAL] RE: No DHCP Reply sent out from kea server

[Marek Hajduczenia]

I do not use RPD in v6 mode so I cannot test that but perhaps try to add a line 
at the end of the new statement as follows

“always-send”: true

That will force transmission of Option 17 unconditionally if this class is 
matched.

Marek

From: Xiao, Yu (CCI-Atlanta) 
Date: Wednesday, May 8, 2024 at 2:50 PM
To: mxhajducze...@gmail.com , 'Kea user's list' 

Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
Hi Marek,

I have added, but there’s no change. I adjusted the position of this part 
configuration to the top and bottom, but still no change.


"client-classes": [
{
"name": "RPD",
"test": "substring(option[17].option[2].hex,0,3) == 'RPD'",
"option-data": [
{
"space": "vendor-4491",
"name": "syslog-servers",
"code": 34,
"data": "2001:578:30:7004:10:0:252:120"
},
{
"space": "vendor-4491",
"name": "time-servers",
"code": 37,
"data": "2001:578:30:7004:10:0:252:112"
},
{
"space": "vendor-4491",
"name": "time-offset",
"code": 38,
"name": "time-offset",
"code": 38,
"data": "0"
},
{
"space": "vendor-4491",
"name": "ccap-cores",
"code": 61,
"data": "2001:578:30:7010:10:0:254:73"
},
{
"space": "dhcp6",
"name": "vendor-opts",
    "code": 17,
"data": "4491"
}
]
}
],




Best Regards,
Yu


From: Xiao, Yu (CCI-Atlanta) 
Date: Wednesday, May 8, 2024 at 4:18 PM
To: mxhajducze...@gmail.com , 'Kea user's list' 

Subject: Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
Thank you, Marek! Let me try!



Best Regards,
Yu


From: Marek Hajduczenia 
Date: Wednesday, May 8, 2024 at 4:10 PM
To: 'Kea user's list' 
Cc: Xiao, Yu (CCI-Atlanta) 
Subject: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea server
You need to add


{

"space": 
"dhcp6",

"name": 
"vendor-opts",

"code": 17,

"data": "4491"

}

to your “option-data” stanza. Otherwise, the process will not insert the 
vendor-specific entry in Option 17.

Marek

From: Kea-users  On Behalf Of Xiao, Yu 
(CCI-Atlanta) via Kea-users
Sent: Wednesday, May 8, 2024 1:46 PM
To: Kea user's list 
Cc: Xiao, Yu (CCI-Atlanta) 
Subject: [Kea-users] No DHCP Reply sent out from kea server

Greetings,

I configured some sub-options for DHCPv6 Option 17 for RPD use. I didn’t find 
too detailed information regarding how to customize those sub-options under one 
option such as DHCPv6 option 17. Luckily, I found some examples from previous 
discussion email. Before I added those options, I could see the Solicit, 
Advertise, Request and Reply packets between the RPD and DHCP server. After the 
configuration, now I don’t see DHCP server responded to the Advertise packets 
anymore. The Advertise packet was sent. I checked the debug logs, I don’t see 
any reasons why the Advertise packets are not sent. There’s no errors in the 
debug logs.

I define those options globally while use them under the class but they are not 
working. Then I changed the configuration and use them under global 
configuration, but still no changes. I suspect my customization configuration 
fo

Re: [Kea-users] [EXTERNAL] RE: No DHCP Reply sent out from kea server

[Marek Hajduczenia]

This is a generic statement telling Kea to send a vendor-4491 space in
reply messages. There are examples of custom vendor spaces in Kea
documentation - this is nothing specific to CableLabs

Marek

On Thu, May 9, 2024 at 10:02 AM Xiao, Yu (CCI-Atlanta) 
wrote:

> Hi Marek,
>
>
>
> Thank you for the information. I am wondering if the following option
> defined by yourself or it is defined by kea? I don’t see its definition in
> the config you shared before.
>
>
>
> {
>
> "space": "dhcp6",
>
> "name": "vendor-opts",
>
> "code": 17,
>
>     "data": "4491"
>
> }
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> *From: *Marek Hajduczenia 
> *Date: *Wednesday, May 8, 2024 at 5:56 PM
> *To: *Xiao, Yu (CCI-Atlanta) , 'Kea user's list' <
> kea-users@lists.isc.org>
> *Subject: *Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea
> server
>
> I do not use RPD in v6 mode so I cannot test that but perhaps try to add a
> line at the end of the new statement as follows
>
>
>
> “always-send”: true
>
>
>
> That will force transmission of Option 17 unconditionally if this class is
> matched.
>
>
>
> Marek
>
>
>
> *From: *Xiao, Yu (CCI-Atlanta) 
> *Date: *Wednesday, May 8, 2024 at 2:50 PM
> *To: *mxhajducze...@gmail.com , 'Kea user's
> list' 
> *Subject: *Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea
> server
>
> Hi Marek,
>
>
>
> I have added, but there’s no change. I adjusted the position of this part
> configuration to the top and bottom, but still no change.
>
>
>
>
>
> "client-classes": [
>
> {
>
> "name": "RPD",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'RPD'",
>
> "option-data": [
>
> {
>
> "space": "vendor-4491",
>
> "name": "syslog-servers",
>
> "code": 34,
>
> "data": "2001:578:30:7004:10:0:252:120"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-servers",
>
> "code": 37,
>
> "data": "2001:578:30:7004:10:0:252:112"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "time-offset",
>
> "code": 38,
>
> "name": "time-offset",
>
> "code": 38,
>
> "data": "0"
>
> },
>
> {
>
> "space": "vendor-4491",
>
> "name": "ccap-cores",
>
> "code": 61,
>
> "data": "2001:578:30:7010:10:0:254:73"
>
> },
>
> {
>
> "space": "dhcp6",
>
> "name": "vendor-opts",
>
> "code": 17,
>
> "data": "4491"
>
> }
>
> ]
>
> }
>
> ],
>
>
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> *From: *Xiao, Yu (CCI-Atlanta) 
> *Date: *Wednesday, May 8, 2024 at 4:18 PM
> *To: *mxhajducze...@gmail.com , 'Kea user's
> list' 
> *Subject: *Re: [EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea
> server
>
> Thank you, Marek! Let me try!
>
>
>
>
>
>
>
> Best Regards,
>
> Yu
>
>
>
>
>
> *From: *Marek Hajduczenia 
> *Date: *Wednesday, May 8, 2024 at 4:10 PM
> *To: *'Kea user's list' 
> *Cc: *Xiao, Yu (CCI-Atlanta) 
> *Subject: *[EXTERNAL] RE: [Kea-users] No DHCP Reply sent out from kea
> server
>
> You need to add
>
>
>
>
> {
>
>
> "space": "dhcp6",
>
>
> "name": "vendor-opts",
>
>
> "code": 17,
>
>
> "data": "4

Re: [Kea-users] Over-riding global settings in specific subnets / prefixes

[Marek Hajduczenia]

Thanks Darren,

I think it was some sort of a fluke - once I rebooted the VM to remedy the
issue with Stork registration, the problem seems to be gone. I hate bugs
like this - they are ephemeral and next to impossible to reproduce, with
the problem going away when the VM is rebooted.

Marek

On Thu, May 9, 2024 at 4:02 AM Darren Ankney 
wrote:

> Hi Marek,
>
> I'm still thinking about this one.  Out of curiosity, could you try
> specifying the option-data inside of the "ecm-vince" client class?  I
> am curious if that overrides the global option data.
>
> Thank you,
> Darren Ankney
>
> On Fri, May 3, 2024 at 4:16 PM  wrote:
> >
> > Good afternoon,
> >
> >
> >
> > I observed a rather surprising behavior today in Kea 2.4.1 DHCPv6 server.
> >
> >
> >
> > I have a global (shared) custom option value defined as follows. Note
> the config file value
> >
> >
> >
> >   {
> >
> > "space": "vendor-4491",
> >
> > "name": "config-file",
> >
> > "code": 33,
> >
> > "data": "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg"
> >
> >   },
> >
> >
> >
> > In one of the subnets, I assigned a custom value as follows
> >
> >
> >
> >   {
> >
> >"id": 102,
> >
> >"interface": "enp6s18",
> >
> >"comment": "CMs connected to Vince's RPDs",
> >
> >"subnet": "2600:6ce4:0:208::/64",
> >
> >"relay": {
> >
> >  "ip-addresses": [ "2600:6ce4:0:3e::1" ]
> >
> >},
> >
> >"pools": [
> >
> >  {
> >
> >   "pool": "2600:6ce4:0:208::2 -
> 2600:6ce4:0:208::::",
> >
> >   "client-class": "ecm-vince",
> >
> >   "option-data": [
> >
> > {
> >
> >  "space": "vendor-4491",
> >
> >  "name": "config-file",
> >
> >  "code": 33,
> >
> >  "data":
> "WBDocCfg166_upgrade.cfg"
> >
> > },
> >
> > {
> >
> >  "space": "dhcp6",
> >
> >  "name": "dns-servers",
> >
> >  "code": 23,
> >
> >  "data":
> "2600:6ce4:40:12c:8000::3"
> >
> > }
> >
> >   ]
> >
> >  }
> >
> >]
> >
> >   },
> >
> >
> >
> > hoping that it would override the parameter value assigned globally.
> Unfortunately, the TFTP server logs show that the previous config file
> value is still being served.
> >
> >
> >
> > 20:01:57.672602 IP6 2600:6ce4:0:208::24.59455 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:01:59.745978 IP6 2600:6ce4:0:208::27.44638 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:00.584499 IP6 2600:6ce4:0:208::39.36093 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:00.684559 IP6 2600:6ce4:0:208::2a.57747 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:03.390078 IP6 2600:6ce4:0:208::9.35267 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:04.210522 IP6 2600:6ce4:0:208::3b.39781 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:04.429295 IP6 2600:6ce4:0:208::6.39985 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:04.483974 IP6 2600:6ce4:0:208::38.41514 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:04.813712 IP6 2600:6ce4:0:208::3a.36185 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> "WBDocCfg166_erouter6_no_nat_usp_v5_commscope_cert.cfg" octet blksize 1428
> tsize 0
> >
> > 20:02:05.034628 IP6 2600:6ce4:0:208::37.42895 > 2600:6ce4:0:42::132.69:
> TFTP, length 83, RRQ
> 

Re: [Kea-users] Combining class definitions with or/and operands

[Marek Hajduczenia]

Thank you, Darren

I logged this as an issue 
https://gitlab.isc.org/isc-projects/kea/-/issues/3369, since I cannot find any 
specific wording in the documentation indicating it is indeed an expected 
behavior. It might be a corner case, but it ought to be covered somewhere

Marek

-Original Message-
From: Kea-users  On Behalf Of Darren Ankney
Sent: Wednesday, May 1, 2024 5:41 AM
To: Kea user's list 
Subject: Re: [Kea-users] Combining class definitions with or/and operands

Hi Marek,

The "client-class" is meant to only contain one class and no logical operands.  
I am not sure if that configuration should throw an error, however.  There may 
be other considerations (such as API use to add classes later) that prevent 
such checking of the name contained therein.

Thank you,
Darren Ankney

On Tue, Apr 30, 2024 at 8:45 PM  wrote:
>
> Just a foreword, I am experimenting with the class definitions and 
> different test structures, since the examples provided in the official 
> documentation are very limited. Specifically, I created these match 
> conditions, and they seem to work just fine
>
>
>
> "client-classes": [
>
>   {
>
> "name": "CTS19-RPDs",
>
>"test": "pkt4.mac == 0x0020a361415b or pkt4.mac == 0x001848fe8f35"
>
>   },
>
>   {
>
> "name": "CTS17-RPDs",
>
>"test": "(pkt4.mac == 0x0020a3283bfb) or (pkt4.mac == 
> 0x0020a3263a4b) or (pkt4.mac == 0x0020a3263a6b) or (pkt4.mac == 
> 0x0020a35a1b0b)"
>
>   },
>
>   {
>
> "name": "CTS18-RPDs",
>
>"test": "(pkt4.mac == 0x0020a325c53b) or (pkt4.mac == 
> 0x0018480ae57d) or (pkt4.mac == 0x0020a32b08bb) or (pkt4.mac == 
> 0x0020a328e02b) or (pkt4.mac == 0x0020a357fc6b) or (pkt4.mac == 
> 0x0020a358a5bb) or (pkt4.mac == 0x0020a35eb56b) or (pkt4.mac == 
> 0x0020a35ecadb) or (pkt4.mac == 0x0018480ae35f) or (pkt4.mac == 
> 0x0018480ae903) or (pkt4.mac == 0x0020a35dfb3b) or (pkt4.mac == 
> 0x0020a380378b) or (pkt4.mac == 0x0020a34f93cb)"
>
>   }
>
> ],
>
>
>
> As you can see, the test structure seems to not care for brackets () or not, 
> and does the matching well even with very long conditions.
>
>
>
> Where the question comes is with the “client-class” statement in individual 
> pool / subnet definitions. In the following example, the client class 
> statement contains an ‘or’ combination for three different classes defined 
> before. It parses fine, but … it does not seem to work. All examples I can 
> find show a single entry in the client-class, but I am wondering whether the 
> example below is a mistake and the parser should throw an error or not. I do 
> know I can create another class that combines three previous classes into 
> one, but I find this cleaner to read, where the match in client-class is 
> performed on and/or combined structure of different atomic classes.
>
>
>
>{
>
> "id": 1,
>
> "subnet": "172.27.60.16/28",
>
> "relay": {
>
>   "ip-addresses": [ "172.27.60.17" ]
>
> },
>
> "pools": [
>
>   {
>
>"pool": "172.27.60.18 - 172.27.60.30",
>
>"client-class": "CTS19-RPDs or CTS18-RPDs or 
> CTS17-RPDs"
>
>   }
>
> ],
>
> "option-data": [
>
>   {
>
>"space": "dhcp4",
>
>"name": "subnet-mask",
>
>"code": 1,
>
>"data": "255.255.255.240"
>
>   },
>
>   {
>
>"space": "dhcp4",
>
>"name": "routers",
>
>"code": 3,
>
>"data": "172.27.60.17"
>
>   },
>
>   {
>
>"space": "dhcp4",
>
>"name": "vendor-encapsulated-options",
>
>"code": 43,
>
>"csv-format": false,
>
>"data": "3d04ac1b3d04"
>
>   }
>
> ]
>
>},
>
>
>
> Is the above shown “client-class” match condition a valid example and should 
> it work?
>
>
>
> Regards
>
>
>
> Marek
>
> --
> 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

Re: [Kea-users] kea-dhcpv6 won't offer adresses to clients

[Marek Hajduczenia]

I’d say it is the very same problem I ran into, i.e., your DHCPv6 Kea process 
is not bound to unicast v6 address on your interface eth1 when using only 
interface name. Check out 
https://gitlab.isc.org/isc-projects/kea/-/issues/2212#note_454562 and consider 
adding the unicast IPv6 address to your interface statement.

Regards

Marek

From: Kea-users  on behalf of Django [Bastard 
Operator from Hell] via Kea-users 
Date: Saturday, May 4, 2024 at 6:49 AM
To: kea-users@lists.isc.org 
Cc: Django [Bastard Operator from Hell] 
Subject: [Kea-users] kea-dhcpv6 won't offer adresses to clients
HI,

I am currently familiarising myself with Kea and am trying to switch
from ISC-dhcpd to the new Kea server.

The distribution of IPv4 addresses works so far without any problems,
but I'm having a hard time with IPv6 and DHCPv6.

O.K. what have I done: I have installed Kea on an Arch Lunux host:

root@vml000110:~# kea-dhcp6 -v
2.4.1

The rudimentary kea-dhcp6.conf looks like this:
{
   ‘Dhcp6’: {
 ‘interfaces-config’: {
   ‘interfaces’: [‘eth1’]
 },
 ‘subnet6’: [
   {
 ‘subnet’: ‘2003:a:e0d:7607::/64’,
 ‘pools’: [
   {
 ‘pool’: ‘2003:a:e0d:7607:10:0:10:1000 -
2003:a:e0d:7607:10:0:10:2000’,
 ‘option-data’: [
   {
 ‘name’: ‘domain-search’,
 ‘data’: ‘nausch.org’
   }
 ]
   }
 ]
   }
 ]
   }
}

Calling kea-dhcp6 with the -t option shows the following:

root@vml000110:~# kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
2024-05-04 14:29:26.477 INFO [kea-dhcp6.hosts/1936.129529300112128]
HOSTS_BACKENDS_REGISTERED the following host backend types are
available: mysql postgresql
2024-05-04 14:29:26.478 WARN [kea-dhcp6.dhcpsrv/1936.129529300112128]
DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when
multi-threading is enabled.
2024-05-04 14:29:26.478 WARN [kea-dhcp6.dhcp6/1936.129529300112128]
DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and
host reservations lookup is always performed first.
2024-05-04 14:29:26.478 WARN [kea-dhcp6.dhcpsrv/1936.129529300112128]
DHCPSRV_CONFIGURED_SUBNET_WITHOUT_ID a subnet was configured without an
id: 2003:a:e0d:7607::/64
2024-05-04 14:29:26.478 INFO [kea-dhcp6.dhcpsrv/1936.129529300112128]
DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration:
2003:a:e0d:7607::/64 with params: valid-lifetime=7200, rapid-commit is false
2024-05-04 14:29:26.478 INFO [kea-dhcp6.dhcpsrv/1936.129529300112128]
DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2024-05-04 14:29:26.478 INFO [kea-dhcp6.dhcpsrv/1936.129529300112128]
DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth1

The daemon starts without any apparent problems:

root@vml000110:~# systemctl status kea-dhcp6.service
● kea-dhcp6.service - ISC Kea IPv6 DHCP daemon
  Loaded: loaded (/usr/lib/systemd/system/kea-dhcp6.service;
disabled; preset: disabled)
  Active: active (running) since Sat 2024-05-04 12:40:29 CEST; 1h
50min ago
Docs: man:kea-dhcp6(8)
Main PID: 1618 (kea-dhcp6)
   Tasks: 9 (limit: 9510)
  Memory: 2.5M (peak: 5.4M)
 CPU: 415ms
  CGroup: /system.slice/kea-dhcp6.service
  └─1618 /usr/bin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

May 04 13:40:29 vml000110 kea-dhcp6[1618]: 2024-05-04 13:40:29.919 INFO
[kea-dhcp6.dhcpsrv/1618.130457064129280] DHCPSRV_MEMFILE_LFC_START starti>
May 04 13:40:29 vml000110 kea-dhcp6[1618]: 2024-05-04 13:40:29.921 INFO
[kea-dhcp6.dhcpsrv/1618.130457064129280] DHCPSRV_MEMFILE_LFC_EXECUTE exec>
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO [DhcpLFC.12824676480]
LFC_START Starting lease file cleanup
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO [DhcpLFC.12824676480]
LFC_PROCESSING Previous file: /var/lib/kea/kea-leases6.csv.2, copy file: >
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO
[DhcpLFC.dhcpsrv.12824676480] DHCPSRV_MEMFILE_LEASE_FILE_LOAD
loading leases from file /var/lib>
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO
[DhcpLFC.dhcpsrv.12824676480] DHCPSRV_MEMFILE_LEASE_FILE_LOAD
loading leases from file /var/lib>
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO [DhcpLFC.12824676480]
LFC_READ_STATS Leases: 0, attempts: 2, errors: 0.
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO [DhcpLFC.12824676480]
LFC_WRITE_STATS Leases: 0, attempts: 0, errors: 0.
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO [DhcpLFC.12824676480]
LFC_ROTATING LFC rotating files
May 04 13:40:29 vml000110 DhcpLFC[1740]: INFO [DhcpLFC.12824676480]
LFC_TERMINATE LFC finished processing

The relevant ports are also open:

root@vml000110:~# ss -tulpn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process

udp UNCONN 0 0 10.0.10.110:67 0.0.0.0:*
users:((‘kea-dhcp4’,pid=892,fd=17))
udp UNCONN 0 0 10.0.0.110:67 0.0.0.0:*
users:((‘kea-dhcp4’,pid=892,fd=15))
udp UNCONN 0 0 0.0.0.0:123 0.0.0.0:* users:((‘chronyd’,pid=491,fd=8))

udp UNCONN 0 0 127.0.0.1:323 

[Kea-users] High memory utilization for Kea server / Stork agent

[Marek Hajduczenia]

Dear colleagues, 

 

I have been observing very high memory utilization for Kea VMs. In ~4 days,
the memory utilization has grown from ~2 GB to close to 8GB for no good
reason. 

 



 



 

I seem to be running multiple copies of processes for some reason, with
stork-agent likely being the primary culprit, and Kea DHCP servers being
likely the second culprit. I have the very same situation on both lab nodes.
I have to restart the server / stork agent periodically to eliminate the
memory bloat. 

 

634 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  7:35.77
/usr/bin/stork-agent

709 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:18.34
/usr/bin/stork-agent

710 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:34.27
/usr/bin/stork-agent

711 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:00.00
/usr/bin/stork-agent

713 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:00.01
/usr/bin/stork-agent

727 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:00.00
/usr/bin/stork-agent

740 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  1:29.63
/usr/bin/stork-agent

894 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  1:24.96
/usr/bin/stork-agent

   1921 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  1:29.49
/usr/bin/stork-agent

  15986 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:53.26
/usr/bin/stork-agent

   1340 _kea   20   0  507M 23864 16784 S  0.0  0.3  4:54.19
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1341 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1342 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1343 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1344 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1352 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:05.43
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1353 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:05.49
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1354 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:08.22
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1355 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:08.25
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

  20544 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

  20545 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

679 root   20   0  107M 20736 12596 S  0.0  0.3  0:00.04
/usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown
--wait-for-signal

732 root   20   0  107M 20736 12596 S  0.0  0.3  0:00.00
/usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown
--wait-for-signal

   1889 _kea   20   0  507M 19292 14552 S  0.0  0.2  3:05.41
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1890 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1891 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1892 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1893 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1897 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:05.47
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1898 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:05.15
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1899 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:10.02
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1900 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:09.95
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

  20586 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.09
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

 20587 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.08
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

 

Regards

 

Marek

 

-- 
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] High memory utilization for Kea server / Stork agent

[Marek Hajduczenia]

Looking at the historic utilization over the week 

 



 

you can clearly see a rather dramatic increase in memory utilization
starting 5/10, with no specific changes to what the node is doing. 

 

Marek

 

From: Marek Hajduczenia  
Sent: Monday, May 13, 2024 12:12 PM
To: 'Kea user's list' 
Subject: High memory utilization for Kea server / Stork agent 

 

Dear colleagues, 

 

I have been observing very high memory utilization for Kea VMs. In ~4 days,
the memory utilization has grown from ~2 GB to close to 8GB for no good
reason. 

 



 



 

I seem to be running multiple copies of processes for some reason, with
stork-agent likely being the primary culprit, and Kea DHCP servers being
likely the second culprit. I have the very same situation on both lab nodes.
I have to restart the server / stork agent periodically to eliminate the
memory bloat. 

 

634 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  7:35.77
/usr/bin/stork-agent

709 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:18.34
/usr/bin/stork-agent

710 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:34.27
/usr/bin/stork-agent

711 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:00.00
/usr/bin/stork-agent

713 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:00.01
/usr/bin/stork-agent

727 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:00.00
/usr/bin/stork-agent

740 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  1:29.63
/usr/bin/stork-agent

894 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  1:24.96
/usr/bin/stork-agent

   1921 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  1:29.49
/usr/bin/stork-agent

  15986 stork-age  20   0 1866M 26240 15824 S  0.0  0.3  0:53.26
/usr/bin/stork-agent

   1340 _kea   20   0  507M 23864 16784 S  0.0  0.3  4:54.19
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1341 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1342 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1343 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1344 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1352 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:05.43
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1353 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:05.49
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1354 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:08.22
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

   1355 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:08.25
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

  20544 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

  20545 _kea   20   0  507M 23864 16784 S  0.0  0.3  0:00.00
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

679 root   20   0  107M 20736 12596 S  0.0  0.3  0:00.04
/usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown
--wait-for-signal

732 root   20   0  107M 20736 12596 S  0.0  0.3  0:00.00
/usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown
--wait-for-signal

   1889 _kea   20   0  507M 19292 14552 S  0.0  0.2  3:05.41
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1890 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1891 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1892 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1893 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.00
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1897 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:05.47
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1898 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:05.15
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1899 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:10.02
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

   1900 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:09.95
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

  20586 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.09
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

 20587 _kea   20   0  507M 19292 14552 S  0.0  0.2  0:00.08
/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

 

Regards

 

Marek

 

-- 
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] Two questions regarding to kea subnet configuration

[Marek Hajduczenia]

Thank you, that is super handy !

 

From: Kea-users  On Behalf Of Dan Geist
Sent: Monday, May 6, 2024 10:17 AM
To: Kea user's list 
Subject: Re: [Kea-users] Two questions regarding to kea subnet configuration

 

It was actually IPv6, so:
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp6-srv.html#allocation-strategies-in-dhcpv6

 

- On May 6, 2024, at 12:12 PM, David Farje mailto:davidabelfa...@gmail.com> > wrote:



Definitely string ID is nicer to manage.  The thing is, Kea seems to be 
designed to support a large number of subnets and DB backend.  In this case it 
is better to use an integer because I don't think you want a string based 
primary key on a DB table with millions of entries.

Regarding your second question I believe you may find some answers here:

https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#address-allocation-strategies-in-dhcpv4

 

Regards,

David

 

 

On Mon, May 6, 2024 at 9:21 AM mailto:mxhajducze...@gmail.com> > wrote:

I can confirm – the lack of support for string ID is pretty annoying right now, 
and forces me to create ranges for specific applications, which will not scale 
well in production. 

 

On the second one, I observed that it goes numerically from the bottom of the 
pool range up, so ::2, ::3, etc. In ISC, it seems to have been random selection 
from the pool, with attempt made to populate all stanzas. Kea seems to prefer 
numerically incrementing assignment, which is pretty bad for security purposes 
(if a user knows it, they can pretty much guess previous assignments). I 
preferred personally the old ISC way of doing things. 

 

Marek

 

From: Kea-users mailto:kea-users-boun...@lists.isc.org> > On Behalf Of Xiao, Yu (CCI-Atlanta) 
via Kea-users
Sent: Monday, May 6, 2024 6:10 AM
To: Kea user's list mailto:kea-users@lists.isc.org> >
Cc: Xiao, Yu (CCI-Atlanta) mailto:yu.x...@cox.com> >
Subject: [Kea-users] Two questions regarding to kea subnet configuration

 

Greetings,

 

I have two questions related to the kea design. First, seems currently we can 
only assign numeric IDs to subnets, but for subnet management, it’s more 
convenient to use a string, is it possible to add this feature? Second, how kea 
design to distribute the ip addresses inside of the subnet esp ipv6 subnet? Is 
it totally random? Thank you. 

 

 

 

 

Best Regards,

Yu

 

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

 

-- 

Dan Geist dan(@)polter.net
http://www.polter.net
(404)786-6206

-- 
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] Two questions regarding to kea subnet configuration

[Marek Hajduczenia]

I understand the scaling factor and just throwing it out there – it would help 
to have perhaps non-key ID to search for, say “name” or something in the line 
of, making it a more unique value to search for. 

 

From: Kea-users  On Behalf Of David Farje
Sent: Monday, May 6, 2024 10:13 AM
To: Kea user's list 
Subject: Re: [Kea-users] Two questions regarding to kea subnet configuration

 

Definitely string ID is nicer to manage.  The thing is, Kea seems to be 
designed to support a large number of subnets and DB backend.  In this case it 
is better to use an integer because I don't think you want a string based 
primary key on a DB table with millions of entries.

 

Regarding your second question I believe you may find some answers here:

https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#address-allocation-strategies-in-dhcpv4

 

Regards,

David

 

 

On Mon, May 6, 2024 at 9:21 AM mailto:mxhajducze...@gmail.com> > wrote:

I can confirm – the lack of support for string ID is pretty annoying right now, 
and forces me to create ranges for specific applications, which will not scale 
well in production. 

 

On the second one, I observed that it goes numerically from the bottom of the 
pool range up, so ::2, ::3, etc. In ISC, it seems to have been random selection 
from the pool, with attempt made to populate all stanzas. Kea seems to prefer 
numerically incrementing assignment, which is pretty bad for security purposes 
(if a user knows it, they can pretty much guess previous assignments). I 
preferred personally the old ISC way of doing things. 

 

Marek

 

From: Kea-users mailto:kea-users-boun...@lists.isc.org> > On Behalf Of Xiao, Yu (CCI-Atlanta) 
via Kea-users
Sent: Monday, May 6, 2024 6:10 AM
To: Kea user's list mailto:kea-users@lists.isc.org> >
Cc: Xiao, Yu (CCI-Atlanta) mailto:yu.x...@cox.com> >
Subject: [Kea-users] Two questions regarding to kea subnet configuration

 

Greetings,

 

I have two questions related to the kea design. First, seems currently we can 
only assign numeric IDs to subnets, but for subnet management, it’s more 
convenient to use a string, is it possible to add this feature? Second, how kea 
design to distribute the ip addresses inside of the subnet esp ipv6 subnet? Is 
it totally random? Thank you. 

 

 

 

 

Best Regards,

Yu

 

-- 
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] [EXTERNAL] Re: Two questions regarding to kea subnet configuration

[Marek Hajduczenia]

I did look at it but it is a highly ineffective way of doing such 
classification. I do not have much commonality between individual subnets and 
adding extra complexity of tracking them via client classes is not worth the 
effort IMHO. I will see what I can do with comments, and just wish they were 
visible in Stork, via – perhaps, a customizable field. Right now, having 
several [1] prefixes is hard to track 

 

Marek

 

From: David Farje  
Sent: Monday, May 6, 2024 12:12 PM
To: Kea user's list 
Cc: mxhajducze...@gmail.com; Xiao, Yu (CCI-Atlanta) 
Subject: Re: [Kea-users] [EXTERNAL] Re: Two questions regarding to kea subnet 
configuration

 

You can use client classes.  You can create a client class with only the "name" 
parameter and associate the subnet with the client class.  That way the subnet 
object has a descriptive string you can use to reference. See the following

 

https://kea.readthedocs.io/en/kea-2.2.0/arm/classify.html#configuring-subnets-with-class-information

 

Best Regards,

David

 

On Mon, May 6, 2024 at 12:47 PM Xiao, Yu (CCI-Atlanta) via Kea-users 
mailto:kea-users@lists.isc.org> > wrote:

I agree, So if we have string name for those subnets, we can use our tools to 
manipulate those information much easier and people who use them will 
understand easier. It’s better we have another  non-key ID as Marek suggested. 

 

 

 

Best Regards,

Yu

 

 

From: Kea-users mailto:kea-users-boun...@lists.isc.org> > on behalf of Marek Hajduczenia 
mailto:mxhajducze...@gmail.com> >
Date: Monday, May 6, 2024 at 12:31 PM
To: 'Kea user's list' mailto:kea-users@lists.isc.org> 
>
Subject: [EXTERNAL] Re: [Kea-users] Two questions regarding to kea subnet 
configuration

I understand the scaling factor and just throwing it out there – it would help 
to have perhaps non-key ID to search for, say “name” or something in the line 
of, making it a more unique value to search for. 

 

From: Kea-users mailto:kea-users-boun...@lists.isc.org> > On Behalf Of David Farje
Sent: Monday, May 6, 2024 10:13 AM
To: Kea user's list mailto:kea-users@lists.isc.org> >
Subject: Re: [Kea-users] Two questions regarding to kea subnet configuration

 

Definitely string ID is nicer to manage.  The thing is, Kea seems to be 
designed to support a large number of subnets and DB backend.  In this case it 
is better to use an integer because I don't think you want a string based 
primary key on a DB table with millions of entries.

 

Regarding your second question I believe you may find some answers here:

https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#address-allocation-strategies-in-dhcpv4
 
<https://urldefense.com/v3/__https:/kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html*address-allocation-strategies-in-dhcpv4__;Iw!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuIsTwbvG$>
 

 

Regards,

David

 

 

On Mon, May 6, 2024 at 9:21 AM mailto:mxhajducze...@gmail.com> > wrote:

I can confirm – the lack of support for string ID is pretty annoying right now, 
and forces me to create ranges for specific applications, which will not scale 
well in production. 

 

On the second one, I observed that it goes numerically from the bottom of the 
pool range up, so ::2, ::3, etc. In ISC, it seems to have been random selection 
from the pool, with attempt made to populate all stanzas. Kea seems to prefer 
numerically incrementing assignment, which is pretty bad for security purposes 
(if a user knows it, they can pretty much guess previous assignments). I 
preferred personally the old ISC way of doing things. 

 

Marek

 

From: Kea-users mailto:kea-users-boun...@lists.isc.org> > On Behalf Of Xiao, Yu (CCI-Atlanta) 
via Kea-users
Sent: Monday, May 6, 2024 6:10 AM
To: Kea user's list mailto:kea-users@lists.isc.org> >
Cc: Xiao, Yu (CCI-Atlanta) mailto:yu.x...@cox.com> >
Subject: [Kea-users] Two questions regarding to kea subnet configuration

 

Greetings,

 

I have two questions related to the kea design. First, seems currently we can 
only assign numeric IDs to subnets, but for subnet management, it’s more 
convenient to use a string, is it possible to add this feature? Second, how kea 
design to distribute the ip addresses inside of the subnet esp ipv6 subnet? Is 
it totally random? Thank you. 

 

 

 

 

Best Regards,

Yu

 

-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ 
<https://urldefense.com/v3/__https:/www.isc.org/contact/__;!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuGFCeiXp$>
  for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users 
<https://urldefense.com/v3/__https:/lists.isc.org/mailman/listinfo/kea-users__;!!Hit2Ag!xde9ThTb7f7wzSlNi38OV3QQiTWY7eArrNaoR1tsT44zCY3x94jQ3Seg_P5d18-jL0k5A0YY61YHuIWs4xfY$>
 .

Kea-users mail

Re: [Kea-users] kea-dhcpv6 won't offer adresses to clients

[Marek Hajduczenia]

I am sorry, I cannot process this information dump in its current format. If 
you want to send / attach logs and config files via text files + perhaps a 
packet capture on the affected interface, I will be happy to look at it

Marek

-Original Message-
From: Kea-users  On Behalf Of Django [Bastard 
Operator from Hell] via Kea-users
Sent: Friday, May 10, 2024 3:47 AM
To: 'Kea user's list' 
Cc: Django [Bastard Operator from Hell] 
Subject: Re: [Kea-users] kea-dhcpv6 won't offer adresses to clients

HI Marek,

Here I am again and I'm afraid I'm probably going to rob you of your sanity - 
I've probably already lost mine ...

Am 05.05.24 um 00:20 schrieb mxhajducze...@gmail.com:

> PS. I am a tad confused about your mixes use of "" and '' in the config file. 
> Not sure whether it is formally supported.

O.K. So first of all, I used the last few days to read the documentation at 
https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#dhcpv6-server-configuration
again and tried to understand it.

Here are a few framework values that may be relevant for further
consideration:


My host where's Kea running is an ArchLinux KVM based virtual machine:
root@vml000110:~# uname -a
Linux vml000110 6.6.30-2-lts #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 
21:45:29 + x86_64 GNU/Linux


Here is the output of kea-dhcp6 -V :

root@vml000110:~# kea-dhcp6 -V
2.4.1
tarball
linked with:
log4cplus 2.1.0
OpenSSL 3.3.0 9 Apr 2024
database:
MySQL backend 19.0, library 3.3.9
PostgreSQL backend 18.0, library 160002
Memfile backend 5.0


This host has two network interfaces, eth0 and eth1. eth1 is where Kea 
should listen for dhcp requests and offer.

root@vml000110:~# ip addr show eth1
3: eth1:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
 link/ether 52:54:00:41:11:02 brd ff:ff:ff:ff:ff:ff
 altname enp2s0
 inet 10.0.10.110/24 brd 10.0.10.255 scope global eth1
valid_lft forever preferred_lft forever
 inet6 2003:a:e0d:7607:10:0:10:110/64 scope global
valid_lft forever preferred_lft forever
 inet6 fd00::7:10:0:0:110/64 scope global
valid_lft forever preferred_lft forever
 inet6 fe80::7:10:ff:fe10:110/64 scope link
valid_lft forever preferred_lft forever


The firewall on the host is based on nftables and firewalld:

root@vml000110:~# firewall-cmd --zone=intra --list-all
intra (active)
   target: default
   ingress-priority: 0
   egress-priority: 0
   icmp-block-inversion: no
   interfaces: eth1
   sources:
   services: dhcp dhcpv6 smtp ssh
   ports:
   protocols:
   forward: no
   masquerade: no
   forward-ports:
   source-ports:
   icmp-blocks:
   rich rules:
rule family="ipv6" source address="2003:a:e0d:7607::/64" service 
name="ssh" accept
rule family="ipv6" source address="2003:a:e0d:7607::/64" destination 
address="2003:a:e0d:7607:10:0:10:110/64" port port="123" protocol="udp" 
accept
rule family="ipv4" source address="10.0.10.0/24" destination 
address="10.0.10.110/32" port port="123" protocol="udp" accept
rule family="ipv6" source address="fd00::/10" destination 
address="fd00::7:10:0:0:110/64" port port="123" protocol="udp" accept
rule family="ipv4" source address="10.0.10.0/24" service name="ssh" 
accept

Following services are allowd: dhcp dhcpv6 smtp ssh

For testing purposes, I connected my laptop directly to the NIC of the 
KVM host using a network cable. The laptop is assigned IPv4 addresses by 
the kea-dhcp4 daemon and can also use this connection (IPv4), e.g. via 
SSH (port 22) or SMTP (port 25).

root@vml000110:~# ss -tulpn
NetidState Recv-QSend-Q 
  Local Address:Port 
Peer Address:PortProcess 

udp  UNCONN0 0 
10.0.10.110:67 
 0.0.0.0:* 
users:(("kea-dhcp4",pid=1736,fd=17))
udp  UNCONN0 0 
 10.0.0.110:67 
 0.0.0.0:* 
users:(("kea-dhcp4",pid=1736,fd=15))


So far so good, now we come to my <-redacted-> kea-dhcp6 problem ... :/

I have completely revised and rebuilt the DHCPv6 configuration file:

root@vml000110:~# cat /etc/kea/kea-dhcp6.conf
# This is our basic configuration for the Kea DHCPv6 server. See section
# 9.2 DHCPv6 Server Configuration for detailed informations.
#
# This configuration file contains only DHCPv6 server's configuration.
# If configurations for other Kea services are also included in this
# file they# are ignored by the DHCPv6 server.

{
   # DHCPv6 configuration starts here. This section will be read by
   # DHCPv6 server and will be ignored by other components.
   "Dhcp6": {

 # First we set up global values
 # Global timers specified here apply to all subnets, unless there
 # are subnet specific values defined in particular subnets. See
 # section 9.2.1. Introduction.
 

[Kea-users] KEA Option 17 structure (example)

[Marek Hajduczenia]

 Dear mailing list users,

I have been trying to create an Option 17 with a specific structure for a
vendor with the ID of 14810, where all I have is a sub-option 1, containing
a string with an arbitrary FQDN. I have a working code for ISC DHCP, but I
have not been able to locate a working example of an implementation for
Kea.

# ADB VSIO
option space worldbox_adb code width 2 length width 2 hash size 1;
option worldbox_adb.bmc code 1 = text;
option vsio.worldbox_adb code 14810 = encapsulate worldbox_adb;

# use the option within a subnet
...
option worldbox_adb.bmc "tmpwh2.cvs.adbglobal.com";
...

My failed attempt to translate looks like the following, but it does not
produce any particular output as confirmed with the packet capture. DNS
servers are present, so I am sure the config is parsed correctly.

"option-data": [
{
"name": "dns-servers",
"data": "2001:db8:2::dead:beef,
2001:db8:2::cafe:babe"
}, {
"space": "vendor-14810",
"name": "bmc",
"data": "tmpwh2.cvs.adbglobal.com"
}, {
"name": "vendor-14810-bmc"
} ]
} ],

"option-def": [ {
// We define a short name, so the option can be
referenced by name.
// The option has code 2 and resides within vendor
space 25167.
// Its data is a plain string.
"name": "bmc",
"code": 1,
"space": "vendor-14810",
"type": "string",
"array": false,
"encapsulate": ""
}, {
"name": "vendor-14810-bmc",
"code": 14810,
"type": "empty",
"space": "dhcp6",
"encapsulate": "bmc"
} ],

I did not see any example showing how to build Option 17 anywhere. Any
pointers / examples would be really appreciated.

Marek
-- 
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 Option 17 structure (example)

[Marek Hajduczenia]

Yeah, I forgot to mentioned that indeed - Option 17 is specific to IPv6. I
was able to get that done for DHCPv4 without any problems, but v6 side
seems to be using slightly different configuration logic, which does not
seem to be documented anywhere, at least that I can find.

Thanks !

Marek

On Fri, Mar 8, 2024 at 3:42 AM Darren Ankney 
wrote:

> Hi Marek,
>
> It is unclear to me.  Is this for DHCPv6?
>
> Thank you,
> Darren Ankney
>
> On Thu, Mar 7, 2024 at 10:51 PM Marek Hajduczenia
>  wrote:
> >
> > Dear mailing list users,
> >
> > I have been trying to create an Option 17 with a specific structure for
> a vendor with the ID of 14810, where all I have is a sub-option 1,
> containing a string with an arbitrary FQDN. I have a working code for ISC
> DHCP, but I have not been able to locate a working example of an
> implementation for Kea.
> >
> > # ADB VSIO
> > option space worldbox_adb code width 2 length width 2 hash size 1;
> > option worldbox_adb.bmc code 1 = text;
> > option vsio.worldbox_adb code 14810 = encapsulate worldbox_adb;
> >
> > # use the option within a subnet
> > ...
> > option worldbox_adb.bmc "tmpwh2.cvs.adbglobal.com";
> > ...
> >
> > My failed attempt to translate looks like the following, but it does not
> produce any particular output as confirmed with the packet capture. DNS
> servers are present, so I am sure the config is parsed correctly.
> >
> > "option-data": [
> > {
> > "name": "dns-servers",
> > "data": "2001:db8:2::dead:beef,
> 2001:db8:2::cafe:babe"
> > }, {
> > "space": "vendor-14810",
> > "name": "bmc",
> > "data": "
> tmpwh2.cvs.adbglobal.com"
> > }, {
> > "name": "vendor-14810-bmc"
> > } ]
> > } ],
> >
> > "option-def": [ {
> > // We define a short name, so the option can be
> referenced by name.
> > // The option has code 2 and resides within
> vendor space 25167.
> > // Its data is a plain string.
> > "name": "bmc",
> > "code": 1,
> > "space": "vendor-14810",
> > "type": "string",
> > "array": false,
> > "encapsulate": ""
> > }, {
> > "name": "vendor-14810-bmc",
> > "code": 14810,
> > "type": "empty",
> > "space": "dhcp6",
> > "encapsulate": "bmc"
> > } ],
> >
> > I did not see any example showing how to build Option 17 anywhere. Any
> pointers / examples would be really appreciated.
> >
> > Marek
> > --
> > 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 Option 17 structure (example)

[Marek Hajduczenia]

And confirmed, with the switch to 2.5.6, I can see two separate entries as 
expected. 

Thank you !

Marek

-Original Message-
From: Marek Hajduczenia  
Sent: Wednesday, March 13, 2024 2:17 PM
To: 'Kea user's list' 
Subject: RE: [Kea-users] KEA Option 17 structure (example)

Thanks, Darren

The config snippet you shared matches my config pretty closely and it does 
result in a single Option 17 instance with vendor ID 1 only. If I change 
the order of vendor ID options, I will get 14810 only, and no trace 1. I 
wonder whether the support for multiple Option 17 / multiple sub-options per 
Option 17 instance is there. If it is not, do I just log it as a bug / feature 
request with the Kea development team?

Regards

Marek

-Original Message-
From: Kea-users  On Behalf Of Darren Ankney
Sent: Wednesday, March 13, 2024 3:39 AM
To: Kea user's list 
Subject: Re: [Kea-users] KEA Option 17 structure (example)

Hello,

I don't think you need to encapsulate the vendor options ... I believe Kea 
knows to do that in this case.  An example is shown at the ARM link I posted 
previously.  Something like the below might work.  You may want to send some 
other value for the second option while testing as it might be confusing in the 
packet capture.

{
  "Dhcp6": {
"option-def": [
  {
"name": "worldbox_adb_bmc",
"code": 1,
"type": "string",
"space": "vendor-14810",
"encapsulate": ""
  },
  {
"name": "vendor-1-test",
"code": 111,
"type": "string",
"space": "vendor-1",
"encapsulate": ""
  }
],
"option-data": [
  {
"name": "worldbox_adb_bmc",
"space": "vendor-14810",
"data": "'tmpwh2.cvs.adbglobal.com'",
"always-send": true
  },
  {
"name": "vendor-1-test",
"space": "vendor-1",
"data": "'tmpwh2.cvs.adbglobal.com'",
"always-send": true
  },
  {
"name": "vendor-opts",
"data": "14810"
  },
  {
"name": "vendor-opts",
"data": "1"
  }
]
  }
}

Thank you,
Darren Ankney

On Sat, Mar 9, 2024 at 11:24 PM  wrote:
>
> Thanks, again 
>
>
>
> Drilling a bit on the multiple entries in Option 17, I created two entries, 
> one for vendor 14810 and one for vendor 1. I was hoping for two Option 17 
> instances to be added *or* one instance with two vendor-specific entries. A 
> single entry is added and just for vendor 1, i.e., the latter one in the 
> option stack is created. Is that the expected behavior?
>
>
>
> "option-data": [
>
> {
>
> "name": "dns-servers",
>
> "data": "2001:db8:2::dead:beef, 
> 2001:db8:2::cafe:babe"
>
> }, {
>
> "space": "vendor-14810",
>
> "name": "bmc",
>
> "data": 
> "tmpwh2.cvs.adbglobal.com",
>
> "always-send": true
>
> }, {
>
> "name": "vendor-opts",
>
> "data": "14810"
>
> }, {
>
> "space": "vendor-1",
>
> "name": "test",
>
> "data": 
> "tmpwh2.cvs.adbglobal.com",
>
> "always-send": true
>
> }, {
>
> "name": "vendor-opts",
>
> "data": "1"
>
> //}, {
>
> //"name": "ntp",
>
> //"csv-format": true,
>
> //"data": 

Re: [Kea-users] KEA Option 17 structure (example)

[Marek Hajduczenia]

Thank you for the additional information, Darren, much appreciated !

-Original Message-
From: Kea-users  On Behalf Of Darren Ankney
Sent: Friday, March 15, 2024 4:31 AM
To: Kea user's list 
Subject: Re: [Kea-users] KEA Option 17 structure (example)

Hi Marek,

FYI: 2.5.6 is a development version and, as such, could contain bugs.
2.4.1 is the latest "stable" version.  This version supports multiple option 17.

Thank you,
Darren Ankney

On Thu, Mar 14, 2024 at 5:03 PM Marek Hajduczenia  
wrote:
>
> And confirmed, with the switch to 2.5.6, I can see two separate entries as 
> expected.
>
> Thank you !
>
> Marek
>
> -----Original Message-
> From: Marek Hajduczenia 
> Sent: Wednesday, March 13, 2024 2:17 PM
> To: 'Kea user's list' 
> Subject: RE: [Kea-users] KEA Option 17 structure (example)
>
> Thanks, Darren
>
> The config snippet you shared matches my config pretty closely and it does 
> result in a single Option 17 instance with vendor ID 1 only. If I change 
> the order of vendor ID options, I will get 14810 only, and no trace 1. I 
> wonder whether the support for multiple Option 17 / multiple sub-options per 
> Option 17 instance is there. If it is not, do I just log it as a bug / 
> feature request with the Kea development team?
>
> Regards
>
> Marek
>
> -Original Message-
> From: Kea-users  On Behalf Of Darren 
> Ankney
> Sent: Wednesday, March 13, 2024 3:39 AM
> To: Kea user's list 
> Subject: Re: [Kea-users] KEA Option 17 structure (example)
>
> Hello,
>
> I don't think you need to encapsulate the vendor options ... I believe Kea 
> knows to do that in this case.  An example is shown at the ARM link I posted 
> previously.  Something like the below might work.  You may want to send some 
> other value for the second option while testing as it might be confusing in 
> the packet capture.
>
> {
>   "Dhcp6": {
> "option-def": [
>   {
> "name": "worldbox_adb_bmc",
> "code": 1,
> "type": "string",
> "space": "vendor-14810",
> "encapsulate": ""
>   },
>   {
> "name": "vendor-1-test",
> "code": 111,
> "type": "string",
> "space": "vendor-1",
> "encapsulate": ""
>   }
> ],
> "option-data": [
>   {
> "name": "worldbox_adb_bmc",
> "space": "vendor-14810",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
>   },
>   {
> "name": "vendor-1-test",
> "space": "vendor-1",
> "data": "'tmpwh2.cvs.adbglobal.com'",
> "always-send": true
>   },
>   {
> "name": "vendor-opts",
> "data": "14810"
>   },
>   {
> "name": "vendor-opts",
> "data": "1"
>   }
> ]
>   }
> }
>
> Thank you,
> Darren Ankney
>
> On Sat, Mar 9, 2024 at 11:24 PM  wrote:
> >
> > Thanks, again 
> >
> >
> >
> > Drilling a bit on the multiple entries in Option 17, I created two entries, 
> > one for vendor 14810 and one for vendor 1. I was hoping for two Option 
> > 17 instances to be added *or* one instance with two vendor-specific 
> > entries. A single entry is added and just for vendor 1, i.e., the 
> > latter one in the option stack is created. Is that the expected behavior?
> >
> >
> >
> > "option-data": [
> >
> > {
> >
> > "name": "dns-servers",
> >
> > "data": "2001:db8:2::dead:beef, 
> > 2001:db8:2::cafe:babe"
> >
> > }, {
> >
> > "space": "vendor-14810",
> >
> > "name": "bmc",
> >
> > "data":
> > "tmpwh2.cvs.adbglobal.com",
> >
> >

Re: [Kea-users] KEA Option 17 structure (example)

[Marek Hajduczenia]

t; "code": 1,
>
> "space": "vendor-14810",
>
> "type": "string",
>
> "array": false,
>
> "encapsulate": ""
>
> }, {
>
> "name": "vendor-14810-bmc",
>
> "code": 14810,
>
> "type": "empty",
>
> "space": "dhcp6",
>
> "record-types": "",
>
> "encapsulate": "vendor-14810"
>
> }, {
>
> "name": "test",
>
> "code": 111,
>
> "space": "vendor-1",
>
> "type": "string",
>
> "array": false,
>
> "encapsulate": ""
>
> }, {
>
> "name": "vendor-1-test",
>
> "code": 1,
>
> "type": "empty",
>
> "space": "dhcp6",
>
> "record-types": "",
>
> "encapsulate": "vendor-1"
>
> }, {
>
> "name": "ntp",
>
> "code": 56,
>
> "space": "dhcp6",
>
> "array": true,
>
> "type": "ipv6-address"
>
> } ],
>
>
>
> -Original Message-
> From: Kea-users  On Behalf Of Darren 
> Ankney
> Sent: Saturday, March 9, 2024 3:25 PM
> To: Kea user's list 
> Subject: Re: [Kea-users] KEA Option 17 structure (example)
>
>
>
> Hi Marek,
>
>
>
> That is my understanding. However, I've never tried any of the option 17 
> setup.
>
>
>
> Thank you,
>
> Darren Ankney
>
>
>
> On Sat, Mar 9, 2024 at 8:55 AM  wrote:
>
> >
>
> > Thank you, Darren
>
> >
>
> > So essentially the magic glue is the vendor ID (14810) used as data under 
> > "vendor-ops" (option 17). That's neat.
>
> >
>
> > Is it possible to have multiple vendor-specific options inserted into a 
> > single Option 17 instance this way?
>
> >
>
> > Marek
>
> >
>
> > -Original Message-
>
> > From: Kea-users  On Behalf Of 
> > Darren
>
> > Ankney
>
> > Sent: Saturday, March 9, 2024 4:38 AM
>
> > To: Kea user's list 
>
> > Subject: Re: [Kea-users] KEA Option 17 structure (example)
>
> >
>
> > Hi Marek,
>
> >
>
> > I was able to find in the correct section of the documentation by first 
> > looking at this chart of options in Kea:
>
> > https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#id3 and 
> > following the link there for option 17:
>
> > https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcp6-ven
> > do
>
> > r-opts
>
> >
>
> > Something like this MIGHT work:
>
> >
>
> > {
>
> >   "Dhcp6": {
>
> > "option-def": [
>
> >   {
>
> > "name": "worldbox_adb_bmc",
>
> > "code": 1,
>
> > "type": "string",
>
> > "space": "vendor-14810",
>
> > "encapsulate": ""
>
> >   }
>
> > ],
>
> > "option-data": [
>
> >   {
>
> > "name": "worldbox_adb_bmc",
>
> > "space": "vendor-14810",
>
> > "data": "'tmpwh2.cvs.adbglobal.com'",
>
> > "always-send": true
>
> >   },
>
> >   {
>
> > "name": "vendor-opts",
>
> > "data": "14810"
>
> >   }
>
> > ]
>
> >   }
>
> > }
>
> >
>
> > Thank you,

Re: [Kea-users] Partially failed upgrade from 2.4.1 to 2.6.0: DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/etc/kea/kea-dhcp4.conf': Error initializing h>

[Marek Hajduczenia]

Thank you, Darren,

I wonder how it worked in 2.4.1 then, but fair point - I will need to
modify the IP addresses to IPv6 on the DHCPv6 side.

Regards

Marek

On Thu, May 30, 2024 at 11:40 AM Darren Ankney 
wrote:

> Hi Marek,
>
> According to your attached keav4 and keav6 files, your HA
> configuration for both DHCPv4 and DHCPv6 is exactly the same as
> pertains to "url".  Both are trying to listen on
> http://192.168.150.221:8000/ and http://192.168.150.222:8000/
> respectively.  You can either use a different port for DHCPv6 or use
> the IPv6 address.
>
> Thank you,
> Darren Ankney
>
> On Wed, May 29, 2024 at 5:35 PM  wrote:
> >
> > So I ventured to the upgrade from 2.4.1 to 2.6.0 to see if that helps my
> integration problems with Stork in any way. Agent and DHCPv6 restarted fine
> after reboot. DHCPv4 for some reason is complaining about address being
> already in use. The system worked just fine under 2.4.1 without any
> complaints about address binding being a problem.
> >
> >
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136]
> DHCPSRV_MEMFILE_BEGIN_EXTRACT_EXTENDED_INFO4 extract extended info with fix
> sanity check level
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388
> INFO  [kea-dhcp4.dhcpsrv/2755.140174953331136]
> DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4 extracting extended info saw 0
> leases, extended info sanity checks modified 0 / update>
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388
> INFO  [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_MEMFILE_LFC_SETUP
> setting up the Lease File Cleanup interval to 3600 sec
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136]
> DHCPSRV_TIMERMGR_REGISTER_TIMER registering timer: memfile-lfc, using
> interval: 360 ms
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.388
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_START_TIMER
> starting timer: memfile-lfc
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136]
> DHCPSRV_TIMERMGR_REGISTER_TIMER registering timer: reclaim-expired-leases,
> using interval: 1 ms
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_START_TIMER
> starting timer: reclaim-expired-leases
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136]
> DHCPSRV_TIMERMGR_REGISTER_TIMER registering timer: flush-reclaimed-leases,
> using interval: 25000 ms
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_TIMERMGR_START_TIMER
> starting timer: flush-reclaimed-leases
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUTS_BEGIN begin
> all callouts for hook dhcp4_srv_configured
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> INFO  [kea-dhcp4.ha-hooks/2755.140174953331136] HA_LOCAL_DHCP_DISABLE local
> DHCP service is disabled while the dhcp-kea-node2 is in the WAITING state
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.http/2755.140174953331136] HTTP_CLIENT_MT_STARTED
> HttpClient has been started in multi-threaded mode running 4 threads
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> INFO  [kea-dhcp4.ha-hooks/2755.140174953331136] HA_SERVICE_STARTED
> dhcp-kea-node2: started high availability service in hot-standby mode as
> standby server
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUT_CALLED hooks
> library with index 3 has called a callout on hook dhcp4_srv_configured that
> has address 0x7f7d044>
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> DEBUG [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUTS_COMPLETE
> completed callouts for hook dhcp4_srv_configured (total callouts duration:
> 0.213 ms)
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.404
> INFO  [kea-dhcp4.dhcpsrv/2755.140174953331136] DHCPSRV_CFGMGR_USE_ALLOCATOR
> using the iterative allocator for V4 leases in subnet 10.10.1.0/24
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.405
> DEBUG [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUTS_BEGIN begin
> all callouts for hook command_processed
> >
> > May 29 21:18:09 dhcp-kea-node2 kea-dhcp4[2755]: 2024-05-29 21:18:09.405
> DEBUG [kea-dhcp4.callouts/2755.140174953331136] HOOKS_CALLOUT_CALLED hooks
> library with index 3 has called a