Re: [Kea-users] yet another question about multiple subnets %)

[Daniel Theisen]

Hello 3,

As Simon has previously pointed out a number of times, a client must send 
multiple IA_NA’s in a request to get multiple addresses. This is discussed in 
section 6.6 Multiple Addresses and Prefixes of RFC8415 
(https://datatracker.ietf.org/doc/rfc8415/ 
)

As per the Kea documentation, you can find the specific reference to how we 
handle Multiple Addresses with Host Reservations in this section in the ARM: 
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#host-reservations-in-dhcpv6
 


> DHCPv6 allows a single client to lease multiple addresses and multiple 
> prefixes at the same time. Therefore ip-addresses and prefixes are plural and 
> are actually arrays. When the client sends multiple IA options (IA_NA or 
> IA_PD), each reserved address or prefix is assigned to an individual IA of 
> the appropriate type. If the number of IAs of a specific type is lower than 
> the number of reservations of that type, the number of reserved addresses or 
> prefixes assigned to the client is equal to the number of IA_NAs or IA_PDs 
> sent by the client; that is, some reserved addresses or prefixes are not 
> assigned. However, they still remain reserved for this client and the server 
> will not assign them to any other client. If the number of IAs of a specific 
> type sent by the client is greater than the number of reserved addresses or 
> prefixes, the server will try to assign all reserved addresses or prefixes to 
> the individual IAs and dynamically allocate addresses or prefixes to the 
> remaining IAs. If the server cannot assign a reserved address or prefix 
> because it is in use, the server will select the next reserved address or 
> prefix and try to assign it to the client. If the server subsequently finds 
> that there are no more reservations that can be assigned to the client at 
> that moment, the server will try to assign leases dynamically.

Thanks,
Dan Theisen
ISC Escalations Engineer

> On Nov 17, 2022, at 10:21 AM, 3  wrote:
> 
>>> seriously? i just killed rad and reconnected the client. shall i tell you 
>>> what has changed? NOTHING! do you think the dhcp client in windows is 
>>> wrong? if so, then will have to redo the rfc for windows, and not windows 
>>> for rfc. lol
>> Did you tell the client to release its leased address ? No ? In that case, 
>> the DHCP client will continue to keep the address configured until it 
>> expires (or another network event causes it to become invalid).
> dear, do you take me for an idiot? of course i deleted the leased address and 
> looked at the dhcpv6 frames. i tell you again- check your statements in 
> practice, otherwise it will turn into trouble for you someday.
> 
>>> exactly, there may not be a router. do you know what the problem with 
>>> link-local addresses is? they can be random!
>> They shouldn’t be random, on an ethernet network they will be based on the 
>> MAC address and will be stable as long as the MAC address is stable.
> so, i see that you know even less than me. this is due to a device tracking 
> issue. it's a long time to write, google it.
> ps: damn it, i came here for help, and it turns out i have to help %)
> 
>>> and often this is not what we need. besides, if everything is so good with 
>>> link-local, then why do local unicast addresses exist? ;)
>> Different address types have different uses.
>> You may have seen 169.254.n.n addresses in the IPv4 world when there is no 
>> DHCP server present. These self-assigned addresses fulfil a similar role to 
>> some of the uses for IPv6 link local addresses - specifically they allow a 
>> group of devices to use multicast DNS to find each other. mDNS underpins a 
>> number of discovery functions around finding printers, network shares, etc.
>> But in a managed network, you would normally prefer to manage the addresses 
>> you put into the internal DNS. So rather than use a link local address for 
>> your internal web server, you would setup a ULA prefix and use that 
>> internally. As it’s independent of any upstream connections, it’s stable and 
>> under your control.
>> For networks without a full time management team (even if that is a one 
>> person team), setting that up is usually “too hard” and not required. For a 
>> typical home network, the users don’t care about all that, they just want 
>> stuff “to work”.
> i'm not stupid enough to tell me the basics ;)
> 
>> If you have a prefix delegation, it’s (in most cases) not very useful unless 
>> the rest of the network knows how to reach that prefix. But even where there 
>> isn’t any routing involved, you still need RAs to tell devices what 
>> prefix(es) are available.
> CHECK YOUR STATEMENT IN PRACTICE! >:(
> 
> -- 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> To 

[Kea-users] kea-dhcp6 failing randomly

[Marek Greško via Kea-users]

Hello,

kea-dhcp6 complains abuout ip_vti0 interface down
2022-11-17 01:15:25.038 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:15:30.713 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:15:35.719 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:15:40.725 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:15:45.732 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:15:50.738 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:15:55.744 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:16:00.749 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:16:05.755 WARN [kea-dhcp6.dhcpsrv/2451.140297934552384] 
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ip_vti0 is down
2022-11-17 01:16:05.756 INFO [kea-dhcp6.dhcp6/2451.140297934552384] 
DHCP6_OPEN_SOCKETS_FAILED maximum number of open service sockets attempts: 10, 
has been exhausted without success

which led to shutdown of the service when "service-sockets-require-all" was 
true,

2022-11-17 01:16:05.756 INFO [kea-dhcp6.dhcp6/2451.140297934552384] 
DHCP6_SHUTDOWN server shutdown

Why it complains also about ip_vti0 where kea is not configured to listen on it?

My interfaces-config section looks like this:

"interfaces-config": {
"interfaces": [ "bond0.10", "bond0.20" ],
"service-sockets-require-all": true,
"service-sockets-max-retries": 10,
"service-sockets-retry-wait-time": 5000
},

The kea-dhcp4 never complains about the interface with the same interfaces 
config.

Thanks for suggestions what am I missing here.

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] How to best update the KEA configuration on a HA hot-standby KEA setup

[Dan Oachs]

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

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

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

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

--Dan


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

> Thanks Dan!
>
>
> So you have a hybrid configuration ?
> What do you mean by "main configuration" ? Topology (shared-networks and
> subnets) in json file and host-reservations in a database ?
> Do you update the database using "reservation-add"  (
> https://kea.readthedocs.io/en/latest/api.html?highlight=host%20reservation#reservation-add
>  )
> ?
>
> We have client classes with a test expression that depends on the mac
> addresses of the clients.
> Can these classes be stored in the database as well ?
>
> Thanks,
> Veronique
>
>
> --
> *From:* Dan Oachs 
> *Sent:* Thursday, November 17, 2022 4:20 PM
> *To:* Veronique Lefebure 
> *Cc:* kea-users@lists.isc.org 
> *Subject:* Re: [Kea-users] How to best update the KEA configuration on a
> HA hot-standby KEA setup
>
> We also have all the main configuration in plain json files.  Like you, we
> require hosts on some of our networks to be registered.  Our registration
> system stores the MAC addresses in the Kea database.  For the past year or
> so, this has worked really well for us.
>
> I would highly suggest looking into storing the MAC addresses in a
> database so you don't need to reload kea for every change.  You don't need
> to use the database for anything else if you don't want to.   This can also
> be done without any of the extra hook libraries that cost money.
>
> --Dan
>
>
>
> On Thu, Nov 17, 2022 at 2:19 AM Veronique Lefebure <
> veronique.lefeb...@cern.ch> wrote:
>
> Hi,
>
> We don't use any database for storing the KEA configuration: we use plain
> json configuration files.
> We need to update the configuration very regularly because we allow only
> known clients (pre-registered mac addresses), hence the list of
> host-reservations is quite volatile.
>
> Véronique
> --
> *From:* Dan Oachs 
> *Sent:* Wednesday, November 16, 2022 6:31 PM
> *To:* Veronique Lefebure 
> *Cc:* kea-users@lists.isc.org 
> *Subject:* Re: [Kea-users] How to best update the KEA configuration on a
> HA hot-standby KEA setup
>
> I am curious why you are updating the config every 5 minutes.   We used to
> do that with our old DHCP server, but with Kea we moved to storing
> reservations in a database.  That way we rarely need to make changes to the
> actual Kea configuration that would necessitate a reload of the config.
>
> --Dan
>
>
> On Wed, Nov 16, 2022 at 10:27 AM Veronique Lefebure <
> veronique.lefeb...@cern.ch> wrote:
>
> Hi,
>
> When running KEA on one single server, (no HA), and updating the KEA dhcp
> configuration file every 5 minute, using "config-set"
>
> https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
>  ,
> we can see that KEA does not reply to the DHCP requests during 30-35
> seconds while "config-set" is running.
>
> Is it expected ?
> If yes, if we add a second server in a HA hot-standby mode, can we expect
> it to answer to the DHCP requests while the first server is busy with
> config-set ?
> If yes, we need to update the second server asynchronously with respect to
> the first one, else they would both be busy with "config-set" at the same
> time.
>
> I would be interested to know how people are updating the KEA DHCP
> configuration in a HA hot-standby setup.
>
> Thanks,
> Veronique
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] yet another question about multiple subnets %)

[3]

>> seriously? i just killed rad and reconnected the client. shall i tell you 
>> what has changed? NOTHING! do you think the dhcp client in windows is wrong? 
>> if so, then will have to redo the rfc for windows, and not windows for rfc. 
>> lol
> Did you tell the client to release its leased address ? No ? In that case, 
> the DHCP client will continue to keep the address configured until it expires 
> (or another network event causes it to become invalid).
dear, do you take me for an idiot? of course i deleted the leased address and 
looked at the dhcpv6 frames. i tell you again- check your statements in 
practice, otherwise it will turn into trouble for you someday.

>> exactly, there may not be a router. do you know what the problem with 
>> link-local addresses is? they can be random!
> They shouldn’t be random, on an ethernet network they will be based on the 
> MAC address and will be stable as long as the MAC address is stable.
so, i see that you know even less than me. this is due to a device tracking 
issue. it's a long time to write, google it.
ps: damn it, i came here for help, and it turns out i have to help %)

>> and often this is not what we need. besides, if everything is so good with 
>> link-local, then why do local unicast addresses exist? ;)
> Different address types have different uses.
> You may have seen 169.254.n.n addresses in the IPv4 world when there is no 
> DHCP server present. These self-assigned addresses fulfil a similar role to 
> some of the uses for IPv6 link local addresses - specifically they allow a 
> group of devices to use multicast DNS to find each other. mDNS underpins a 
> number of discovery functions around finding printers, network shares, etc.
> But in a managed network, you would normally prefer to manage the addresses 
> you put into the internal DNS. So rather than use a link local address for 
> your internal web server, you would setup a ULA prefix and use that 
> internally. As it’s independent of any upstream connections, it’s stable and 
> under your control.
> For networks without a full time management team (even if that is a one 
> person team), setting that up is usually “too hard” and not required. For a 
> typical home network, the users don’t care about all that, they just want 
> stuff “to work”.
i'm not stupid enough to tell me the basics ;)

> If you have a prefix delegation, it’s (in most cases) not very useful unless 
> the rest of the network knows how to reach that prefix. But even where there 
> isn’t any routing involved, you still need RAs to tell devices what 
> prefix(es) are available.
CHECK YOUR STATEMENT IN PRACTICE! >:(

-- 
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] yet another question about multiple subnets %)

[3]

> Allocating multiple addresses from one pool or multiple pools is a different 
> question to shared networks.
> You can have multiple pools within one prefix; you can have a single pool in 
> each of multiple prefixes; or any combination (e.g. multiple pools from 
> multiple prefixes). One reason you might want multiple pools within a single 
> prefix could be, for example, so that you can group certain types of clients 
> into address ranges. For example, you might want to put VoIP phones into 
> their own address range (defined by a pool) so that you can limit their 
> access to anything but the phone service they connect to.
> One reason you might want multiple prefixes on one link is if you want to use 
> ULA addresses internally (which would make internal services still work if 
> your upstream connectivity goes down and your global address prefix(es) 
> disappear) and use GUA addresses for everything else.
> The shared network declaration is how you tell the DHCP server that all the 
> prefixes configured in the shared network are on the same wire. It’s not 
> something I’ve used with IPv6, nor with KEA, but in the IPv4 world it can 
> work like this :
> Suppose you have a server connected to a shared network with 192.168.1.0/24 
> and 192.168.2.0/24 in use, and the server had the address 192.168.1.1. If you 
> didn’t tell the server that it’s a shared network, then not only would it not 
> allocate addresses from the 192.168.2.0 subnet, it would NACK any requests 
> from clients for those addresses. The shared network statement tells the 
> server “all these addresses should be considered equal”.
what i told you about it. in general, prefixes are not important, the dhcp 
server operates with pools. you can generally specify the prefix "::/0" and 
forget about prefixes.

> And in the IPv4 world it is possible for a client to ask for multiple 
> addresses - it just needs to make multiple requests using a different 
> client-ID for each one, and the server will handle them individually.
in the world of dhcpv6, this cannot be done, since the rfc directly requires 
that one client has one identifier(windows follows this requirement strictly).
ps: i see that you don't know ipv6 very well either ;)

> No RAs will result in no prefixes (other than fe80 link local) being 
> available on the link. For DHCPv6 to be used at all, there must be an RA for 
> at least one prefix, and it must (IIRC) set the M flag to indicate to devices 
> that this is a managed network offering DHCP - without this, the clients will 
> NOT even ask for an address. You can also optionally turn off the A flag to 
> tell clients that they should not auto-configure (SLAAC) addresses in the 
> prefix.
why don't you just test this statement in practice? ;) if you are not confused 
at least by the fact that in windows and *nix, different daemons are engaged in 
processing RA and dhcp, not communicating with each other in any way %\

> As I have pointed out, this is a known issue and there isn’t a simple answer.
> As to devices using ULA and GUA addresses, once they have them both then 
> there are routing rules (priorities) which will prefer ULA over GUA where the 
> other end of the connection is a GUA address. As to how the device knows to 
> talk to something at a GUA address, that would either be via multicast DNS, 
> or via regular DNS for things like internal web servers at fixed addresses.
> And as I’ve already said, AT THE MOMENT there isn’t a way to signal to 
> clients that they need to ask for multiple address in multiple prefixes. I 
> haven’t looked, but I would not be surprised if at least some clients will 
> default to asking for at least one ULA and at least one GUA when it detects 
> the two different types of prefix.
> And while DHCP is not able to control what traffic any device can engage in, 
> it can manage the addresses issued - see the note above about putting (e.g.) 
> VoIP phones into their own range of addresses so different router/firewall 
> rules can be applied. In this respect, it’s not much different to IPv4 where 
> such techniques have been used for a long time.
yes, there is a problem(at least on win 10) of the client choosing the suitable 
address(when he has several of them) in each case, but this is not a problem of 
the dhcp server, this is a problem of the dhcp client, we cannot and should not 
save all kittens. i'm not an engineer or an admin, i'm a simple home user, but 
if to think about this problem for a day or two, i think can find a solution %D 
at least the problem doesn't look complicated with the available start data.

> I have a feeling that you do not understand IPv6 too well, that’s 
> understandable as some aspects are quite different to IPv4 - IPv6 is not just 
> IPv4 with more address bits.
> Two resources that come to mind are :
> https://ipv6.he.net/certification/
> You don’t need to go all the way through and get certified - just working 
> through the stages which introduces 

Re: [Kea-users] yet another question about multiple subnets %)

[Simon]

3  wrote:

>> RA are absolutely needed for DHCPv6 to work.  Properly working clients won't 
>> do anything but sit there with an fe80:: address on its interface if no RA 
>> tells it what else to assign and how to do so 
>> (https://www.rfc-editor.org/rfc/rfc5175.html) leaving your only option to 
>> manually assign address information to the interface on the client.  
> seriously? i just killed rad and reconnected the client. shall i tell you 
> what has changed? NOTHING! do you think the dhcp client in windows is wrong? 
> if so, then will have to redo the rfc for windows, and not windows for rfc. 
> lol

Did you tell the client to release its leased address ? No ? In that case, the 
DHCP client will continue to keep the address configured until it expires (or 
another network event causes it to become invalid).


> 
>> If there is no router, then there will be no upstream routing and you have 
>> no need of anything other than an fe80:: as clients on the local network 
>> will discover each other and happily talk to each other's fe80:: address.
> exactly, there may not be a router. do you know what the problem with 
> link-local addresses is? they can be random!

They shouldn’t be random, on an ethernet network they will be based on the MAC 
address and will be stable as long as the MAC address is stable.

> and often this is not what we need. besides, if everything is so good with 
> link-local, then why do local unicast addresses exist? ;)

Different address types have different uses.
You may have seen 169.254.n.n addresses in the IPv4 world when there is no DHCP 
server present. These self-assigned addresses fulfil a similar role to some of 
the uses for IPv6 link local addresses - specifically they allow a group of 
devices to use multicast DNS to find each other. mDNS underpins a number of 
discovery functions around finding printers, network shares, etc.
But in a managed network, you would normally prefer to manage the addresses you 
put into the internal DNS. So rather than use a link local address for your 
internal web server, you would setup a ULA prefix and use that internally. As 
it’s independent of any upstream connections, it’s stable and under your 
control.
For networks without a full time management team (even if that is a one person 
team), setting that up is usually “too hard” and not required. For a typical 
home network, the users don’t care about all that, they just want stuff “to 
work”.


>>> one more time: address allocation and traffic routing are completely 
>>> different
>>> tasks that practically do not overlap. at least because there may not be a
>>> router on the network, but ip addresses will still needs
>> In the case of DHCPv6 prefix delegation, DHCPv6 and routing absolutely 
>> overlap.  Routes must be added to the upstream router telling said router 
>> that your client has been allocated such prefix or you won't be routing 
>> anywhere as the router will have no idea that said prefix exists on your 
>> local network behind your DHCPv6 client.
> who said that need to route something somewhere? O_o

If you have a prefix delegation, it’s (in most cases) not very useful unless 
the rest of the network knows how to reach that prefix. But even where there 
isn’t any routing involved, you still need RAs to tell devices what prefix(es) 
are available.


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] yet another question about multiple subnets %)

[Simon]

3  wrote:

>>> "shared network" is not about how to allocate multiple addresses(it doesn't 
>>> matter if we have one pool or several), but about how to combine several 
>>> pools into one.
>> Almost - it’s about how to have multiple (IPv4) subnets/(IPv6) prefixes on 
>> one wire.
> where do you see even a word about this in the documentation? in any 
> documentation, not only for kea, the "shared network" is referred to as a 
> pooled pool of addresses from which the dhcp server will take an address to 
> assign to the client. could you quote exactly the place where it says about 
> allocating multiple addresses at the same time from the pooled pool?

Allocating multiple addresses from one pool or multiple pools is a different 
question to shared networks.
You can have multiple pools within one prefix; you can have a single pool in 
each of multiple prefixes; or any combination (e.g. multiple pools from 
multiple prefixes). One reason you might want multiple pools within a single 
prefix could be, for example, so that you can group certain types of clients 
into address ranges. For example, you might want to put VoIP phones into their 
own address range (defined by a pool) so that you can limit their access to 
anything but the phone service they connect to.
One reason you might want multiple prefixes on one link is if you want to use 
ULA addresses internally (which would make internal services still work if your 
upstream connectivity goes down and your global address prefix(es) disappear) 
and use GUA addresses for everything else.

The shared network declaration is how you tell the DHCP server that all the 
prefixes configured in the shared network are on the same wire. It’s not 
something I’ve used with IPv6, nor with KEA, but in the IPv4 world it can work 
like this :
Suppose you have a server connected to a shared network with 192.168.1.0/24 and 
192.168.2.0/24 in use, and the server had the address 192.168.1.1. If you 
didn’t tell the server that it’s a shared network, then not only would it not 
allocate addresses from the 192.168.2.0 subnet, it would NACK any requests from 
clients for those addresses. The shared network statement tells the server “all 
these addresses should be considered equal”.

And in the IPv4 world it is possible for a client to ask for multiple addresses 
- it just needs to make multiple requests using a different client-ID for each 
one, and the server will handle them individually.

>> As has already been said, your client will need to ask for multiple 
>> addresses/prefixes. The client knows (for IPv6) the prefixes configured for 
>> any link from the RAs it receives.
> no RA is needed for dhcpv6 to work.

No RAs will result in no prefixes (other than fe80 link local) being available 
on the link. For DHCPv6 to be used at all, there must be an RA for at least one 
prefix, and it must (IIRC) set the M flag to indicate to devices that this is a 
managed network offering DHCP - without this, the clients will NOT even ask for 
an address. You can also optionally turn off the A flag to tell clients that 
they should not auto-configure (SLAAC) addresses in the prefix.

This is different to IPv4 where DHCP is the primary means of client config, and 
clients will default to using DHCP unless configured not to.
>> 
>> Having said that, if there is a GUA and a ULA advertised, then it would be 
>> logical for a client to request addresses from both and use them accordingly 
>> - ULA for communications with other ULA addresses, GUA for everything else.

> do you want to talk about how this can be implemented? the answer is simple- 
> you do not need to tell the client how to live, especially since you do not 
> have any levers to force him to fulfill your requirements. the router can at 
> least block traffic from the rebel, but the dhcp server does not have such an 
> opportunity. therefore, all you can do as a dhcp server is to offer the 
> client all the prefixes that you have- the client will choose the ones he 
> needs and notify you of his choice in a reply message. you will only have to 
> keep track of this connection. it's obvious! dhcp is not a tool for political 
> repression of clients, like go here and don't go there %). a router should 
> deal with such repression- it exists for this very purpose. what makes you 
> think that dhcpv6 is being developed by mad people? :D
> one more time: address allocation and traffic routing are completely 
> different tasks that practically do not overlap. at least because there may 
> not be a router on the network, but ip addresses will still needs

As I have pointed out, this is a known issue and there isn’t a simple answer.

As to devices using ULA and GUA addresses, once they have them both then there 
are routing rules (priorities) which will prefer ULA over GUA where the other 
end of the connection is a GUA address. As to how the device knows to talk to 
something at a GUA address, that would either be via multicast DNS, or 

Re: [Kea-users] yet another question about multiple subnets %)

[3]

>> where do you see even a word about this in the documentation? in any
>> documentation, not only for kea, the "shared network" is referred to as a
>> pooled pool of addresses from which the dhcp server will take an address to
>> assign to the client. could you quote exactly the place where it says about
>> allocating multiple addresses at the same time from the pooled pool?
> It wouldn't say anything about allocating 'n' addresses in the shared network 
> documentation.  Shared network is a concept that groups subnets together.  
> Its only purpose is to tell the DHCP server that all of these subnets exist 
> on the same interface or VLAN or whatever and that a client may use any 
> address or prefix that is in this shared network.  
the interface has nothing to do with the shared pool from the "shared network". 
there can be several interfaces(for example, for load balancing), each with its 
own pool. all these pools can be combined into one, and a dhcp server located 
on a specific interface will be able to serve them all(for this he will need to 
forward requests from other interfaces, but this is no longer his concern)

> Why do you refuse to investigate if your client is actually asking for 
> multiple addresses?
i have no idea what it should look like, so what should i investigate the? all 
i see is:
-the client to the group address of the dhcp servers: hey! is there anyone 
here? give me an address!
-the dhcp server to the link-local address of the client: i am here. here's the 
one address for you.
-the client to the server: can i to take this one address for myself?
-the server to the client: no problem!
so in what place should the client request multiple addresses from the server 
so that it doesn't look absurd?

>> no RA is needed for dhcpv6 to work. these are different protocols, different
>> group addresses. moreover, there may not be a router in the network at all, 
>> but
>> what does this have to do with dhcp(no matter v4 or v6)? maybe you are
>> confusing ff02::1:2 and ff02::2? these are not the same thing, they are
>> generally different things. so when we don't have a router with its RA on the
>> network, the client cannot request something specific in any way(but to 
>> request
>> two, three, etc. addresses is to request something specific) before the 
>> server
>> tells him about the existence of this particular one. can't you see that 
>> you're
>> traveling in time?
> RA are absolutely needed for DHCPv6 to work.  Properly working clients won't 
> do anything but sit there with an fe80:: address on its interface if no RA 
> tells it what else to assign and how to do so 
> (https://www.rfc-editor.org/rfc/rfc5175.html) leaving your only option to 
> manually assign address information to the interface on the client.  
seriously? i just killed rad and reconnected the client. shall i tell you what 
has changed? NOTHING! do you think the dhcp client in windows is wrong? if so, 
then will have to redo the rfc for windows, and not windows for rfc. lol

> If there is no router, then there will be no upstream routing and you have no 
> need of anything other than an fe80:: as clients on the local network will 
> discover each other and happily talk to each other's fe80:: address.
exactly, there may not be a router. do you know what the problem with 
link-local addresses is? they can be random! and often this is not what we 
need. besides, if everything is so good with link-local, then why do local 
unicast addresses exist? ;)

>> one more time: address allocation and traffic routing are completely 
>> different
>> tasks that practically do not overlap. at least because there may not be a
>> router on the network, but ip addresses will still needs
> In the case of DHCPv6 prefix delegation, DHCPv6 and routing absolutely 
> overlap.  Routes must be added to the upstream router telling said router 
> that your client has been allocated such prefix or you won't be routing 
> anywhere as the router will have no idea that said prefix exists on your 
> local network behind your DHCPv6 client.
who said that need to route something somewhere? O_o

-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

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

[Veronique Lefebure]

Thanks Dan!


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

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

Thanks,
Veronique



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

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

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

--Dan



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

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

Véronique

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

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

--Dan


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

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

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

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

Thanks,
Veronique

--
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
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] yet another question about multiple subnets %)

[perl-list]

> where do you see even a word about this in the documentation? in any
> documentation, not only for kea, the "shared network" is referred to as a
> pooled pool of addresses from which the dhcp server will take an address to
> assign to the client. could you quote exactly the place where it says about
> allocating multiple addresses at the same time from the pooled pool?


It wouldn't say anything about allocating 'n' addresses in the shared network 
documentation.  Shared network is a concept that groups subnets together.  Its 
only purpose is to tell the DHCP server that all of these subnets exist on the 
same interface or VLAN or whatever and that a client may use any address or 
prefix that is in this shared network.  

Why do you refuse to investigate if your client is actually asking for multiple 
addresses?


> no RA is needed for dhcpv6 to work. these are different protocols, different
> group addresses. moreover, there may not be a router in the network at all, 
> but
> what does this have to do with dhcp(no matter v4 or v6)? maybe you are
> confusing ff02::1:2 and ff02::2? these are not the same thing, they are
> generally different things. so when we don't have a router with its RA on the
> network, the client cannot request something specific in any way(but to 
> request
> two, three, etc. addresses is to request something specific) before the server
> tells him about the existence of this particular one. can't you see that 
> you're
> traveling in time?


RA are absolutely needed for DHCPv6 to work.  Properly working clients won't do 
anything but sit there with an fe80:: address on its interface if no RA tells 
it what else to assign and how to do so 
(https://www.rfc-editor.org/rfc/rfc5175.html) leaving your only option to 
manually assign address information to the interface on the client.  If there 
is no router, then there will be no upstream routing and you have no need of 
anything other than an fe80:: as clients on the local network will discover 
each other and happily talk to each other's fe80:: address.


> one more time: address allocation and traffic routing are completely different
> tasks that practically do not overlap. at least because there may not be a
> router on the network, but ip addresses will still needs


In the case of DHCPv6 prefix delegation, DHCPv6 and routing absolutely overlap. 
 Routes must be added to the upstream router telling said router that your 
client has been allocated such prefix or you won't be routing anywhere as the 
router will have no idea that said prefix exists on your local network behind 
your DHCPv6 client.
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

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

[Dan Oachs]

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

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

--Dan



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

> Hi,
>
> We don't use any database for storing the KEA configuration: we use plain
> json configuration files.
> We need to update the configuration very regularly because we allow only
> known clients (pre-registered mac addresses), hence the list of
> host-reservations is quite volatile.
>
> Véronique
> --
> *From:* Dan Oachs 
> *Sent:* Wednesday, November 16, 2022 6:31 PM
> *To:* Veronique Lefebure 
> *Cc:* kea-users@lists.isc.org 
> *Subject:* Re: [Kea-users] How to best update the KEA configuration on a
> HA hot-standby KEA setup
>
> I am curious why you are updating the config every 5 minutes.   We used to
> do that with our old DHCP server, but with Kea we moved to storing
> reservations in a database.  That way we rarely need to make changes to the
> actual Kea configuration that would necessitate a reload of the config.
>
> --Dan
>
>
> On Wed, Nov 16, 2022 at 10:27 AM Veronique Lefebure <
> veronique.lefeb...@cern.ch> wrote:
>
> Hi,
>
> When running KEA on one single server, (no HA), and updating the KEA dhcp
> configuration file every 5 minute, using "config-set"
>
> https://kea.readthedocs.io/en/latest/arm/ctrl-channel.html?highlight=config-set#the-config-set-command
>  ,
> we can see that KEA does not reply to the DHCP requests during 30-35
> seconds while "config-set" is running.
>
> Is it expected ?
> If yes, if we add a second server in a HA hot-standby mode, can we expect
> it to answer to the DHCP requests while the first server is busy with
> config-set ?
> If yes, we need to update the second server asynchronously with respect to
> the first one, else they would both be busy with "config-set" at the same
> time.
>
> I would be interested to know how people are updating the KEA DHCP
> configuration in a HA hot-standby setup.
>
> Thanks,
> Veronique
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] yet another question about multiple subnets %)

[3]

>> "shared network" is not about how to allocate multiple addresses(it doesn't 
>> matter if we have one pool or several), but about how to combine several 
>> pools into one.
> Almost - it’s about how to have multiple (IPv4) subnets/(IPv6) prefixes on 
> one wire.
where do you see even a word about this in the documentation? in any 
documentation, not only for kea, the "shared network" is referred to as a 
pooled pool of addresses from which the dhcp server will take an address to 
assign to the client. could you quote exactly the place where it says about 
allocating multiple addresses at the same time from the pooled pool?

>> A client connected to a shared network may be assigned a lease (address or 
>> prefix) from any of the pools defined within the subnets belonging to the 
>> shared network. Internally, the server selects one of the subnets belonging 
>> to a shared network and tries to allocate a lease from this subnet. If the 
>> server is unable to allocate a lease from the selected subnet (e.g., due to 
>> pool exhaustion), it uses another subnet from the same shared network and 
>> tries to allocate a lease from this subnet. The server typically allocates 
>> all leases available in a given subnet before it starts allocating leases 
>> from other subnets belonging to the same shared network. 


>> but i want several addresses AT THE SAME TIME. this is stated in rfc8415. 
>> and here is what is said about rfc8415 in the kea documentation:
>> 
>> The server will allocate, renew, or rebind a maximum of one lease for a 
>> particular IA option (IA_NA or IA_PD) sent by a client. RFC 8415 allows for 
>> multiple addresses or prefixes to be allocated for a single IA.

> As has already been said, your client will need to ask for multiple 
> addresses/prefixes. The client knows (for IPv6) the prefixes configured for 
> any link from the RAs it receives.
no RA is needed for dhcpv6 to work. these are different protocols, different 
group addresses. moreover, there may not be a router in the network at all, but 
what does this have to do with dhcp(no matter v4 or v6)? maybe you are 
confusing ff02::1:2 and ff02::2? these are not the same thing, they are 
generally different things. so when we don't have a router with its RA on the 
network, the client cannot request something specific in any way(but to request 
two, three, etc. addresses is to request something specific) before the server 
tells him about the existence of this particular one. can't you see that you're 
traveling in time?

> However, as this thread has highlighted, one of the complications of multiple 
> prefixes by default (having only one is simply multiple prefixes where “n=1”) 
> is that there is then the gap in how to inform clients how they are expected 
> to use them. Having been following a couple of IETF mailing lists, this is 
> not yet a solved problem - and I suspect may never be due to the complexity 
> involved to cover all situations.
> One particular variation involves having two (or more) upstream internet 
> providers - each providing a different prefix. There is currently no portable 
> way to inform clients how to use the different prefixes - hence calls by some 
> for NPT (network prefix translation) so that the network layer (i.e. routers) 
> can route packets according to admin defined rules (e.g. email via a cheap 
> but high latency link, web browsing via an expensive but low latency link), 
> or switch routing on the fly (e.g. switching to a backup link if the primary 
> fails).

> Having said that, if there is a GUA and a ULA advertised, then it would be 
> logical for a client to request addresses from both and use them accordingly 
> - ULA for communications with other ULA addresses, GUA for everything else.
do you want to talk about how this can be implemented? the answer is simple- 
you do not need to tell the client how to live, especially since you do not 
have any levers to force him to fulfill your requirements. the router can at 
least block traffic from the rebel, but the dhcp server does not have such an 
opportunity. therefore, all you can do as a dhcp server is to offer the client 
all the prefixes that you have- the client will choose the ones he needs and 
notify you of his choice in a reply message. you will only have to keep track 
of this connection. it's obvious! dhcp is not a tool for political repression 
of clients, like go here and don't go there %). a router should deal with such 
repression- it exists for this very purpose. what makes you think that dhcpv6 
is being developed by mad people? :D
one more time: address allocation and traffic routing are completely different 
tasks that practically do not overlap. at least because there may not be a 
router on the network, but ip addresses will still needs 

-- 
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] yet another question about multiple subnets %)

[Simon]

3  wrote:

> "shared network" is not about how to allocate multiple addresses(it doesn't 
> matter if we have one pool or several), but about how to combine several 
> pools into one.

Almost - it’s about how to have multiple (IPv4) subnets/(IPv6) prefixes on one 
wire.

> A client connected to a shared network may be assigned a lease (address or 
> prefix) from any of the pools defined within the subnets belonging to the 
> shared network. Internally, the server selects one of the subnets belonging 
> to a shared network and tries to allocate a lease from this subnet. If the 
> server is unable to allocate a lease from the selected subnet (e.g., due to 
> pool exhaustion), it uses another subnet from the same shared network and 
> tries to allocate a lease from this subnet. The server typically allocates 
> all leases available in a given subnet before it starts allocating leases 
> from other subnets belonging to the same shared network. 


> but i want several addresses AT THE SAME TIME. this is stated in rfc8415. and 
> here is what is said about rfc8415 in the kea documentation:
> 
> The server will allocate, renew, or rebind a maximum of one lease for a 
> particular IA option (IA_NA or IA_PD) sent by a client. RFC 8415 allows for 
> multiple addresses or prefixes to be allocated for a single IA.

As has already been said, your client will need to ask for multiple 
addresses/prefixes. The client knows (for IPv6) the prefixes configured for any 
link from the RAs it receives.

However, as this thread has highlighted, one of the complications of multiple 
prefixes by default (having only one is simply multiple prefixes where “n=1”) 
is that there is then the gap in how to inform clients how they are expected to 
use them. Having been following a couple of IETF mailing lists, this is not yet 
a solved problem - and I suspect may never be due to the complexity involved to 
cover all situations.
One particular variation involves having two (or more) upstream internet 
providers - each providing a different prefix. There is currently no portable 
way to inform clients how to use the different prefixes - hence calls by some 
for NPT (network prefix translation) so that the network layer (i.e. routers) 
can route packets according to admin defined rules (e.g. email via a cheap but 
high latency link, web browsing via an expensive but low latency link), or 
switch routing on the fly (e.g. switching to a backup link if the primary 
fails).

Having said that, if there is a GUA and a ULA advertised, then it would be 
logical for a client to request addresses from both and use them accordingly - 
ULA for communications with other ULA addresses, GUA for everything else.

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] How to best update the KEA configuration on a HA hot-standby KEA setup

[Veronique Lefebure]

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


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

Hi,

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

Véronique

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

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

--Dan


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

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

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

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

Thanks,
Veronique

--
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

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

[Veronique Lefebure]

Hi,

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

Véronique

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

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

--Dan


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

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

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

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

Thanks,
Veronique

--
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
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