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

[Eric Graham]

CCing the list.. sorry.

Eric Graham
DevOps Specialist
Direct: 605.990.1859
eric.gra...@vantagepnt.com
[cid:16f20d06-c1b9-49c2-80f4-06819b01d04a]

From: Eric Graham 
Sent: Wednesday, January 4, 2023 4:13 PM
To: Kevin P. Fleming 
Subject: Re: [Kea-users] Load-Balancing Network issue between Relay and Kea

You're right. There's a table of values against which the DUID (if IPv6) is 
hashed. The result % number of servers is used as an index pointing to the 
server that will process the packet.

https://gitlab.isc.org/isc-projects/kea/-/blob/46dc8d276efda1a240f0c05580bdcba62ae5a6c7/src/hooks/dhcp/high_availability/query_filter.cc#L416-L446

Even though the Kea load balancing algorithm (as well as the DHCPd load 
balancing algorithm) is not exactly RFC compliant, this part seems to be. See 
RFC 3074 § 6.

I have encountered this same issue when one server cannot communicate. For me, 
it was partially caused by my socket type being wrong. However, I found the 
load balancing behavior to be sufficiently finnicky that I have standardized on 
hot-standby. With the size deployments I deal with, load balancing provides 
marginal performance improvement at the cost of issues like this and more 
complicated configuration.

Additionally, having a RADIUS backend made this issue even worse. Load 
balancing + RADIUS = a bad time.

Eric Graham
DevOps Specialist
Direct: 605.990.1859
eric.gra...@vantagepnt.com
[cid:611bb96b-af22-42ae-9890-37d6469ab42b]

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

Sent: Wednesday, January 4, 2023 3:59 PM
To: kea-users@lists.isc.org 
Subject: Re: [Kea-users] Load-Balancing Network issue between Relay and Kea

CAUTION: This email originated outside the organization. Do not click any links 
or attachments unless you have verified the sender.

On Wed, Jan 4, 2023, at 15:54, Simon wrote:

> Kevin P. Fleming  wrote:
>
>> If 'max-unacked-clients' isn't sufficient to address this, then this leaves 
>> a fairly large opening in the Kea high-availability story, as any network 
>> disruption which causes a server to no longer receive discovery packets from 
>> clients, but otherwise receives all expected network traffic, won't be 
>> noticed except by the clients! This concerns me, as (like other users here) 
>> my Kea servers receive all client traffic via DHCP relays, and 
>> misconfiguration of the relay such that it only relays to one server and not 
>> both will result in half of my clients not getting DHCP service at all.
>
> Surely, if you misconfigure a relay agent in that way, around half your
> clients will initially be unable to renew their leases, but eventually
> will get serviced by the available server once their active lease has
> expired ? That would mean the clients would drop their network config
> momentarily before setting up a new one - meaning that active
> connections would drop, but new ones would connect just fine once the
> new settings are in place.

That's why I posted; I don't really know!

If the server receiving the client requests is not in partner-down state, based 
on my understanding of the Kea ARM section on HA it will not respond to those 
requests. That certainly seems to be the case while the lease is still active; 
once the lease has expired I'm not sure what will happen.

In my network with Kea in load-balancing mode, there seems to be some sort of 
algorithm involved even for DHCP DISCOVER, where only one of the two servers 
responds with DHCP OFFER even though they are both running in a normal state. 
It has been my assumption (untested) up to this point that Kea is using the 
client's identifier (MAC address, DUID, etc.) to choose one or the other of the 
active servers to respond to that DISCOVER. If that's true, and both servers 
are in normal operation (neither is in partner-down), then that algorithm would 
continue telling the second server to *not* respond to requests from that 
client because it believes the other server will do so... even if the other 
server is not receiving the client's requests.

To summarize, that's what I assumed (against untested) 'max-unacked-clients' is 
for; if the second server assumes the first server will respond to those 
clients, but it does not (no leases are offered to them), it could notice the 
situation and decide that the first server is unhealthy or partitioned and 
force it into a 'down' state.
--
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 

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

[Mathias Aichinger]

>> Surely, if you misconfigure a relay agent in that way, around half your 
>> clients will initially be unable to renew their leases, but eventually 
>> will get serviced by the available server once their active lease has 
>> expired ? That would mean the clients would drop their network config 
>> momentarily before setting up a new one - meaning that active 
>> connections would drop, but new ones would connect just fine once the 
>> new settings are in place.
That's exactly how it tested it. I removed one relay and even the DISCOVER got 
dropped. I have checked the code and instead of some round robin, it's using a 
hashed hwaddress (or client id) and modulo function to always select the same 
server. If this server is not reachable, the customer has bad luck.

> In my network with Kea in load-balancing mode, there seems to be some sort of 
> algorithm involved even for DHCP DISCOVER, where only one of the two servers 
> responds with DHCP OFFER even though they are both running in a normal state. 
> It has been my assumption (untested) up to this point that Kea is using the 
> client's identifier (MAC address, DUID, etc.) to choose one or the other of 
> the active servers to respond to that DISCOVER. If that's true, and both 
> servers are in normal operation (neither is in partner-down), then that 
> algorithm would continue telling the second server to *not* respond to 
> requests from that client because it believes the other server will do so... 
> even if the other server is not receiving the client's requests.
That's the case.

> To summarize, that's what I assumed (against untested) 'max-unacked-clients' 
> is for; if the second server assumes the first server will respond to those 
> clients, but it does not (no leases are offered to them), it could notice the 
> situation and decide that the first server is unhealthy or partitioned and 
> force it into a 'down' state.
I also assumed that.

> So it would seem that an alternative to a load balancer is to script 
> detection of the problem and handle it according to the automation level 
> desired by the admin - at one extreme, simply alert it so manual intervention 
> can be done; at the other extreme, automatically put a server into 
> partner-down state.
That would be my Plan-B.




-- 
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] Load-Balancing Network issue between Relay and Kea

[Kevin P. Fleming]

On Wed, Jan 4, 2023, at 15:54, Simon wrote:

> Kevin P. Fleming  wrote:
>
>> If 'max-unacked-clients' isn't sufficient to address this, then this leaves 
>> a fairly large opening in the Kea high-availability story, as any network 
>> disruption which causes a server to no longer receive discovery packets from 
>> clients, but otherwise receives all expected network traffic, won't be 
>> noticed except by the clients! This concerns me, as (like other users here) 
>> my Kea servers receive all client traffic via DHCP relays, and 
>> misconfiguration of the relay such that it only relays to one server and not 
>> both will result in half of my clients not getting DHCP service at all.
>
> Surely, if you misconfigure a relay agent in that way, around half your 
> clients will initially be unable to renew their leases, but eventually 
> will get serviced by the available server once their active lease has 
> expired ? That would mean the clients would drop their network config 
> momentarily before setting up a new one - meaning that active 
> connections would drop, but new ones would connect just fine once the 
> new settings are in place.

That's why I posted; I don't really know!

If the server receiving the client requests is not in partner-down state, based 
on my understanding of the Kea ARM section on HA it will not respond to those 
requests. That certainly seems to be the case while the lease is still active; 
once the lease has expired I'm not sure what will happen.

In my network with Kea in load-balancing mode, there seems to be some sort of 
algorithm involved even for DHCP DISCOVER, where only one of the two servers 
responds with DHCP OFFER even though they are both running in a normal state. 
It has been my assumption (untested) up to this point that Kea is using the 
client's identifier (MAC address, DUID, etc.) to choose one or the other of the 
active servers to respond to that DISCOVER. If that's true, and both servers 
are in normal operation (neither is in partner-down), then that algorithm would 
continue telling the second server to *not* respond to requests from that 
client because it believes the other server will do so... even if the other 
server is not receiving the client's requests.

To summarize, that's what I assumed (against untested) 'max-unacked-clients' is 
for; if the second server assumes the first server will respond to those 
clients, but it does not (no leases are offered to them), it could notice the 
situation and decide that the first server is unhealthy or partitioned and 
force it into a 'down' state.
-- 
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] Load-Balancing Network issue between Relay and Kea

[Simon]

Francis Dupont  wrote:

> I leave details to our HA expert but it seems your setup requires an active
> load-balancer:
> - the path between clients and the first server is broken so this server
>   does not receive queries or clients do not receive responses
> - the path between the two servers work so for the second server the
>   first server is ok
> - the path between clients and the second server works so the second
>   server believes queries from first server clients are served by the
>   first server so it does not serve them
> - the second server has no way to detect the problem as it does not follow
>   responses
> 
> I suggest to use an active load-balancer i.e. a box between clients and
> servers which splits and monitors exchanges: not only it should solve the
> problem but it will avoid extra traffic. With other words you are outside
> what the Kea load-balancing can support...

I see an alternative, making assumption about what Kea can do.

Scenario like this are why the ISC DHCP server did not do automatic state 
change to partner-down - there are too many variables in terms of what the two 
partners see traffic wise and what they can assume about their partner. So by 
default, it is up to the admin to determine if a partner is down and set the 
other server to partner-down state accordingly.

So it would seem that an alternative to a load balancer is to script detection 
of the problem and handle it according to the automation level desired by the 
admin - at one extreme, simply alert it so manual intervention can be done; at 
the other extreme, automatically put a server into partner-down state.



Kevin P. Fleming  wrote:

> If 'max-unacked-clients' isn't sufficient to address this, then this leaves a 
> fairly large opening in the Kea high-availability story, as any network 
> disruption which causes a server to no longer receive discovery packets from 
> clients, but otherwise receives all expected network traffic, won't be 
> noticed except by the clients! This concerns me, as (like other users here) 
> my Kea servers receive all client traffic via DHCP relays, and 
> misconfiguration of the relay such that it only relays to one server and not 
> both will result in half of my clients not getting DHCP service at all.

Surely, if you misconfigure a relay agent in that way, around half your clients 
will initially be unable to renew their leases, but eventually will get 
serviced by the available server once their active lease has expired ? That 
would mean the clients would drop their network config momentarily before 
setting up a new one - meaning that active connections would drop, but new ones 
would connect just fine once the new settings are in place.

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

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

[Kevin P. Fleming]

On Wed, Jan 4, 2023, at 13:07, Francis Dupont wrote:
> I leave details to our HA expert but it seems your setup requires an active
> load-balancer:
>  - the path between clients and the first server is broken so this server
>does not receive queries or clients do not receive responses
>  - the path between the two servers work so for the second server the
>first server is ok
>  - the path between clients and the second server works so the second
>server believes queries from first server clients are served by the
>first server so it does not serve them
>  - the second server has no way to detect the problem as it does not follow
>responses

How does 'max-unacked-clients' factor into this situation? It's important that 
our servers are able to notice that their peer servers are not responding to 
clients in a timely fashion and transition those peers to 'partner-down' so 
they will start serving the peer's clients.

If 'max-unacked-clients' isn't sufficient to address this, then this leaves a 
fairly large opening in the Kea high-availability story, as any network 
disruption which causes a server to no longer receive discovery packets from 
clients, but otherwise receives all expected network traffic, won't be noticed 
except by the clients! This concerns me, as (like other users here) my Kea 
servers receive all client traffic via DHCP relays, and misconfiguration of the 
relay such that it only relays to one server and not both will result in half 
of my clients not getting DHCP service at all.
-- 
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] Load-Balancing Network issue between Relay and Kea

[Francis Dupont]

I leave details to our HA expert but it seems your setup requires an active
load-balancer:
 - the path between clients and the first server is broken so this server
   does not receive queries or clients do not receive responses
 - the path between the two servers work so for the second server the
   first server is ok
 - the path between clients and the second server works so the second
   server believes queries from first server clients are served by the
   first server so it does not serve them
 - the second server has no way to detect the problem as it does not follow
   responses

I suggest to use an active load-balancer i.e. a box between clients and
servers which splits and monitors exchanges: not only it should solve the
problem but it will avoid extra traffic. With other words you are outside
what the Kea load-balancing can support...

Thanks

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

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

[Mathias Aichinger]

Thank you for your answers.

Unfortunately it's not increasing the unacked packets and I have many log 
outputs with following:

2023-01-04 17:29:04.289 DEBUG [kea-dhcp4.ha-hooks/1427854.139856620329408] 
HA_BUFFER4_RECEIVE_NOT_FOR_US [hwtype=1], cid=[], tid=0x4036b3d: dropping query 
to be processed by another server

But these packets cannot be processed by the other server because I'm dropping 
them for testing purposes.

Maybe somebody from the KEA team can clarify?

Best Regards,


> On 02.01.2023, at 15:50, Frey, Rick E  wrote:
> 
> I’ve only used Kea in Hot-Standby configuration so I don’t have direct 
> experience with Load-Balancing config but failover is similar. 
>  
> Docs indicate that your Kea 2 host should mark Kea 1 as “partner-down” state 
> if number of un-ack’d clients is exceeded ( 1 in your configuration ).  In 
> order for Kea 2 to detect the un-ack’d requests (that should be handled by 
> Kea 1), the secs (Seconds elaspsed) field must exceed max-ack-delay value ( 
> 10 seconds in your case ). 
>  
> Do your DHCP request include the secs field and exceed 10 seconds in your 
> tests?
> Does “Kea 2” show any unacked-clients during your test/network disruption? 
> (status-get cmd will show unacked-clients as well as current state).
>  
>  
> From: Kea-users  > on behalf of Mathias Aichinger 
> mailto:mathias.aichin...@easysol.at>>
> Date: Sunday, January 1, 2023 at 6:11 PM
> To: kea-users@lists.isc.org  
> mailto:kea-users@lists.isc.org>>
> Subject: [Kea-users] Load-Balancing Network issue between Relay and Kea
> 
> 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,
> 
> 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
>  
> 
> 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] Disable multicast Listening

[Frey, Rick E via Kea-users]

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] Disable multicast Listening

[Frey, Rick E via Kea-users]

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

[Eric Graham]

Running compiled Kea 2.2 in a Docker container that had one CPU and 500MB of 
memory, in a VM that had 4 vCPUs and 4GB of memory, allowed me to reach 1,700 
lps with 3% drops using dhcperf on a second VM on the same host (and memfile 
backend). I'd recommend that as bare minimum specs. In production I would 
recommend much higher, to be safe. It really depends on your environment, 
hooks, other services running on the system, etc.

Eric Graham
DevOps Specialist
Direct: 605.990.1859
eric.gra...@vantagepnt.com
[cid:cf310f7d-3f51-46e2-ac27-1114f49b9a73]

From: Kea-users  on behalf of JT ISC 

Sent: Tuesday, January 3, 2023 7:20 PM
To: kea-users@lists.isc.org 
Subject: [Kea-users] Kea System Requirements

CAUTION: This email originated outside the organization. Do not click any links 
or attachments unless you have verified the sender.
What are the system requirements for Kea?

4 GB RAM and 100GB HD adequate?

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 MySQL & Advanced Features Requirements

[Eric Graham]

Last time I used the RPMs from their repository (1.8), MariaDB was baked in. 
I'd assume it to be so today. It's a pretty commonly used feature. I would make 
a VM, set up that repo, and then run kea-dhcp4 -W​ to show what features are 
enabled.

Eric Graham
DevOps Specialist
Direct: 605.990.1859
eric.gra...@vantagepnt.com
[cid:cf2ae7ea-8147-4b9a-a56c-7c537d290f25]

From: Kea-users  on behalf of JT ISC 

Sent: Tuesday, January 3, 2023 7:28 PM
To: kea-users@lists.isc.org 
Subject: [Kea-users] Kea MySQL & Advanced Features Requirements

CAUTION: This email originated outside the organization. Do not click any links 
or attachments unless you have verified the sender.
I have a question regarding Kea with MySQL and other advanced features.

Is the only way to get most of the features of Kea, such as MySQL features and 
other advanced features, is to build/install from source, correct?

The pre-built Kea packages don't allow MySQL and the other advanced features, 
correct?

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 MySQL & Advanced Features Requirements

[Darren Ankney]

I don’t know for sure, but you could certainly download the package for your 
system and check dependancies.  If MySQL / MariaDB shows up, then it was 
compiled with such support:  https://cloudsmith.io/~isc/repos/kea-2-2/groups/ 

> On Jan 3, 2023, at 8:28 PM, JT ISC  wrote:
> 
> I have a question regarding Kea with MySQL and other advanced features.
> 
> Is the only way to get most of the features of Kea, such as MySQL features 
> and other advanced features, is to build/install from source, correct?
> 
> The pre-built Kea packages don't allow MySQL and the other advanced features, 
> correct?
> 
> 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

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

[Darren Ankney]

That is highly dependent on the number of clients you will be serving.  There 
really is no easy way to answer that question.  Have a look at dhcperf.  you 
can use that to simulate the expected client load and see if your server can 
handle it.

> On Jan 3, 2023, at 8:20 PM, JT ISC  wrote:
> 
> What are the system requirements for Kea?
> 
> 4 GB RAM and 100GB HD adequate?
> 
> 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

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

[Darren Ankney]

You can directly upgrade.  If you are using database backend, be sure and check 
the version there as well.

> On Jan 3, 2023, at 8:16 PM, JT ISC  wrote:
> 
> Hello,
> 
> I might be overlooking the documentation somewhere, but I wanted to be sure.
> 
> I have been running Kea 2.0.1.  Can you directly upgrade from Kea 2.0.1 to 
> 2.2.0?  Or is there an upgrade path that you have to perform?
> 
> Thank you in advance!
> -- 
> 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] Disable multicast Listening

[Darren Ankney]

I’m assuming we are talking about DHCPv6 here.

I don’t believe there is a way to cause the server to not listen to the 
multicast address.  I believe RFC 8415 requires that the server listen on that 
address.  You could limit the server to listening on the loopback interface.  
Then you could use the server’s firewall to forward traffic sent to port 567 to 
the server on the loopback interface.  You’d probably need to set something 
like this:

"interfaces-config": {
"interfaces": [ “lo/::1" ]
}

and then forward to ::1 using the firewall.

Disclaimer: I’ve never tried that but it might work.

> On Jan 3, 2023, at 8:05 PM, s k  wrote:
> 
> 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
> 
> 
> -- 
> 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] Monitoring a Kea cluster

[Oscar Carlsson via Kea-users]

"Stefan G. Weichinger"  writes:


Am 27.12.22 um 12:46 schrieb Darren Ankney:

In any case, I’d be concerned why it was running but not 
answering

requests more-so than I would be about how to monitor it using
actual DHCP.  I vaguely remember having some trouble with Kea 
and
systemd startup ordering (ie: it started up before the server’s 
IP
was on the interface).  Setting After=network.target took care 
of

it.


We saw the behavior again yesterday: no DHCP leases after a 
reboot

until we restarted kea.

In the service file there are these lines:

Wants=network-online.target
After=network-online.target
After=time-sync.target

https://systemd.io/NETWORK_ONLINE/ gives some information about 
these
targets ... "network-online.target" should fit better .. but 
doesn't

seem to be enough.

We use raw sockets for kea, but the server listens on multiple
vlan-interfaces:

{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "enp0s31f6", 
"enp0s31f6.101",

"enp0s31f6.102", "enp0s31f6.103",
   "enp0s31f6.200" ],
"dhcp-socket-type": "raw"
},


Hi,

I've run Kea (in my homelab, not in production) on a machine with 
multiple vlan

interfaces without issues, on Debian 10/11 and FreeBSD 13.0/13.1.

I've found that I had to instruct systemd when the network is to 
be regarded as
online, as my default route came through a sub-interface 
(enp1s0.10 in my

case).

# systemctl edit --full systemd-networkd-wait-online.service
[...]
[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i 
enp1s0.10

RemainAfterExit=yes

Hope that helps.


Regards,
Oscar
--
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