Re: [Kea-users] DHCPv4 - respond to option 108 without allocating leases

[Dan Oachs via Kea-users]

Yes, for option 108 to work and have an IPv6-mostly network, you need an
IPv4 pool available.  I believe Kea needs to temporarily allocate an IP
address for the DHCP request, then the client rejects or ignores it if the
client supports being on an IPv6 only network.  If the pool has no
addresses available, it can't respond appropriately.

Option 108, as far as I know, is not really meant to be used in an IPv6
only network.  It allows you to decrease your IPv4 usage for devices that
know they can live on an IPv6 only network, but other devices ( like
windows laptops ) won't use option 108 and will want an IPv4 address.

--Dan


On Wed, May 22, 2024 at 5:57 AM Francis Dupont  wrote:

> Looking the RFC 8925 to try to understand how it is supposed to work...
> I think you should add a pool and have the client to ignore the offered
> address (it is the only MUST in client and server behaviors which can make
> the feature to work). I leave further details to Tomek who is one of the
> authors...
>
> Regards
>
> Francis Dupont 
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
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] lease4-del

[Dan Oachs via Kea-users]

I can delete a lease by doing this...

kea-shell (lots of options followed by) lease4-del
Then I hit enter and type"ip-address": "XXX.XXX.XXX.XXX"
Then hit enter and control-d

That seems to work for me.  I'm sure there are other probably better ways
to make it work as well.

--Dan


On Thu, Mar 28, 2024 at 12:54 PM Jason Keltz  wrote:

> Hi.
>
> I was trying to use lease4-del in the kea API through kea-shell, but
> can't seem to get the syntax right.
>
> I pass into ...
>
>   kea-shell --host localhost --port 8000 --service dhcp4
>
> The following:
>
> {
>
>"command": "lease4-del",
>"arguments": {
>  "ip-address": "1.2.3.4"
>}
> }
>
> and get back: Failed to run: HTTP Error 400: Bad Request (of course
> ip-address that I pass in is valid).
>
> Can I also instead pass in an ether or a hostname?
>
> ---
>
> Just FYI to confirm I have the right setup:
>
> % kea-shell --host localhost --port 8000 --service dhcp4 list-commands
> [ { "arguments": [ "build-report", "config-backend-pull", "config-get",
> "config-hash-get", "config-reload", "config-set", "config-test",
> "config-write", "dhcp-disable", "dhcp-enable", "lease4-add",
> "lease4-del", "lease4-get", "lease4-get-all", "lease4-get-by-client-id",
> "lease4-get-by-hostname", "lease4-get-by-hw-address", "lease4-get-page",
> "lease4-resend-ddns", "lease4-update", "lease4-wipe", "lease4-write",
> "lease6-add", "lease6-bulk-apply", "lease6-del", "lease6-get",
> "lease6-get-all", "lease6-get-by-duid", "lease6-get-by-hostname",
> "lease6-get-page", "lease6-resend-ddns", "lease6-update", "lease6-wipe",
> "lease6-write", "leases-reclaim", "libreload", "list-commands",
> "server-tag-get", "shutdown", "statistic-get", "statistic-get-all",
> "statistic-remove", "statistic-remove-all", "statistic-reset",
> "statistic-reset-all", "statistic-sample-age-set",
> "statistic-sample-age-set-all", "statistic-sample-count-set",
> "statistic-sample-count-set-all", "status-get", "version-get" ],
> "result": 0 } ]
>
> Jason.
>
> --
> 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] dhcp4 config file and ip reservation

[Dan Oachs]

If I understand what you are doing correctly, yes, it will work. I am
running a kea server the same way.  All the configuration is in the config
files and the host reservations are in the MySQL database.

--Dan


On Tue, Jan 16, 2024 at 9:18 AM mtint hpc  wrote:

> Hi All,
>
> I am interested in utilizing mariadb as the backend for host reservations,
> without the need for a dhcp pool. The subnet and other relevant information
> will still be stored in the dhcp4 configuration file. I believe that using
> a database will not hinder kea from utilizing the defined subnet and other
> configurations specified in the config file, and it will only retrieve the
> dhcp reservations from the database. Can someone if this would work?
>
> Kind regards,
>
> Michael
>
> --
> 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] dhcp4 server stops responding to a device

[Dan Oachs]

Is that device using BOOTP instead of DHCP by any chance?  If so, you might
need the Bootp kea hook library.  But that's just a guess.

--Dan


On Tue, Jan 16, 2024 at 6:08 AM Gavin Davenport  wrote:

> I have a “Wiser smart hub”
> https://wiser.draytoncontrols.co.uk/smart-heating-kits
>
>
>
> This is basically a central heating timer with a wifi adapter.
>
>
>
> I can’t set a static IP on it so it is dependent on working DHCP (and
> wifi) to stay connected to the network.
>
>
>
> I’m seeing the kea-dhcp server not respond to its dhcprequests and
> restarting the wifi and restarting the dhcp server do not seem to help.
>
>
>
> Config file has a reservation for it’s address: (fc:fe:c2:05:3e:b7)
>
> {
>
> "Dhcp4": {
>
> "interfaces-config": {
>
> "interfaces": [
>
>   "enp2s0"
>
> ]
>
> },
>
>
>
> "control-socket": {
>
> "socket-type": "unix",
>
> "socket-name": "/tmp/kea4-ctrl-socket"
>
> },
>
>
>
> "lease-database": {
>
> "type": "memfile",
>
> "lfc-interval": 3600
>
> },
>
>
>
>
>
> "expired-leases-processing": {
>
> "reclaim-timer-wait-time": 10,
>
> "flush-reclaimed-timer-wait-time": 25,
>
> "hold-reclaimed-time": 3600,
>
> "max-reclaim-leases": 100,
>
> "max-reclaim-time": 250,
>
> "unwarned-reclaim-cycles": 5
>
> },
>
>
>
> "renew-timer": 900,
>
> "rebind-timer": 1800,
>
> "valid-lifetime": 43200,
>
>
>
> "option-data": [
>
> {
>
> "name": "domain-name-servers",
>
> "data": "10.99.99.119, 10.99.99.111"
>
> },
>
> {
>
> "name": "domain-name",
>
> "data": "ad.domain.net"
>
> },
>
> {
>
> "name": "domain-search",
>
> "data": "ad.domain.net, domain.net"
>
> },
>
> {
>
> "name": "default-ip-ttl",
>
> "data": "0xf0"
>
> }
>
> ],
>
>
>
>
>
> "subnet4": [
>
> {
>
> "subnet": "10.99.99.0/24",
>
> "pools": [ { "pool": "10.99.99.2 - 10.99.99.63" } ],
>
> "reservations": [
>
> {
>
> "hw-address": "fc:fe:c2:05:3e:b7",
>
> "ip-address": "10.99.99.3"
>
> }
>
> ],
>
> "option-data": [
>
> {
>
> "name": "routers",
>
> "data": "10.99.99.1"
>
> }
>
> ]
>
> }
>
> ],
>
>
>
>
>
> "loggers": [
>
> {
>
> "name": "kea-dhcp4",
>
> "output_options": [
>
> {
>
> "output": "/var/log/kea-dhcp4.log"
>
> }
>
> ],
>
> "severity": "DEBUG",
>
> "debuglevel": 7
>
> }
>
>   ]
>
> }
>
> }
>
>
>
> So I reserve 10.99.99.3 for the wiser device.
>
>
>
> For quite long periods of time I get this logged
> 2024-01-16 11:51:22.170 INFO  [kea-dhcp4.leases/1112259.140235902645952]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0x25eeba9a: lease 10.99.99.3 will be advertised
>
> 2024-01-16 11:51:37.918 INFO  [kea-dhcp4.leases/1112259.140235894253248]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0x25eeba9a: lease 10.99.99.3 will be advertised
>
> 2024-01-16 11:51:53.681 INFO  [kea-dhcp4.leases/1112259.140235885860544]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0x25eeba9a: lease 10.99.99.3 will be advertised
>
> 2024-01-16 11:52:04.033 INFO  [kea-dhcp4.leases/1112259.140235911038656]
> DHCP4_LEASE_ADVERT [hwtype=1 fc:fe:c2:05:3e:b7], cid=[no info],
> tid=0xcf035c28: lease 10.99.99.3 will be advertised
>
>
>
> And when I tcpdump I see this (tcpdump -v -n -A -i enp2s0 ether host
> fc:fe:c2:05:3e:b7)
>
>
>
> 11:50:49.034748 IP (tos 0x0, ttl 64, id 17, offset 0, flags [none], proto
> UDP (17), length 328)
>
> 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
> fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 224, Flags [Broadcast]
>
>   Client-Ethernet-Address fc:fe:c2:05:3e:b7
>
>   Vendor-rfc1048 Extensions
>
> Magic Cookie 0x63825363
>
> DHCP-Message (53), length 1: Discover
>
> Hostname (12), length 15: "WiserHeat053EB7"
>
> E..H@
> .y..D.C.4}.%...>...c.Sc5WiserHeat053EB7
>
> 11:51:05.598448 IP (tos 0x0, ttl 64, id 18, offset 0, flags [none], proto
> UDP (17), length 328)
>
> 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from
> fc:fe:c2:05:3e:b7, length 300, xid 0x25eeba9a, secs 240, Flags [Broadcast]
>
>   Client-Ethernet-Address fc:fe:c2:05:3e:b7
>
>  

Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)

[Dan Oachs]

Ah, ok.  In my experience, devices that don't support DHCP option 108, are
not ready to live on an ipv6 only network, and need some sort of ipv4 to
function.

--Dan


On Mon, Jul 31, 2023 at 1:42 PM Brian Candler  wrote:

> On 31/07/2023 19:32, Dan Oachs wrote:
> > I'm confused.  What is the issue with Kea offering v6 only clients an
> > ipv4 address?  The client will not accept the ipv4 address and kea
> > will not reserve that IP address for them.  The end result is a
> > drastic reduction in ipv4 pool usage.  At least, that's how it is
> > working for me.
>
> This is a proof-of-concept IPv6-only network: no IPv4 addresses at all,
> and no NAT44 (only NAT64).
>
> You are correct that RFC8925-aware clients refuse the IPv4 address
> offered. However if someone plugs in a non-RFC8925 client, and Kea
> offers them an IPv4 address, they will use it.
>
> That's why I want to detect whether the client is announcing RFC8925
> capability, and I was hoping for something less ugly (and more robust)
> than this:
>
>  "client-classes": [
>  {
>  "name": "rfc8925",
>  "test": "substring(option[55].hex, 0, 1) == 0x6c or
> substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2,
> 1) == 0x6c or substring(option[55].hex, 3, 1) == 0x6c or
> substring(option[55].hex, 4, 1) == 0x6c or substring(option[55].hex, 5,
> 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c or
> substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8,
> 1) == 0x6c or substring(option[55].hex, 9, 1) == 0x6c or
> substring(option[55].hex, 10, 1) == 0x6c or substring(option[55].hex,
> 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
>  },
>  ],
>
>
-- 
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] Problems trying to implement RFC 8925 (v6-only-preferred)

[Dan Oachs]

I'm confused.  What is the issue with Kea offering v6 only clients an ipv4
address?  The client will not accept the ipv4 address and kea will not
reserve that IP address for them.  The end result is a drastic reduction in
ipv4 pool usage.  At least, that's how it is working for me.

Thanks,
  Dan Oachs


On Sun, Jul 30, 2023 at 2:44 PM Brian Candler  wrote:

> On 30/07/2023 14:28, Darren Ankney wrote:
> > I have not tested this, but you could use the 'v6-only-preferred'
> > setting in the subnet (see:
> >
> https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#ipv6-only-preferred-networks
> ).
>
> As the config I included in my original mail shows, I'm already using
> that option.  Yes it works.  But I still end up *offering* clients an
> IPv4 address from the pool, even those which request the
> v6-only-preferred option and will actually not request the offered
> address; and RFC 8925 says the server should set yiaddr 0.0.0.0 in this
> situation.
>
> > If I'm understanding what you are saying ... DON'T allocate v4 to
> > clients who DON'T send v6 only option?  Won't that result in a bunch
> > of clients with no IP at all?
>
> No, because those clients will still be able to get an IPv6 address (via
> either SLAAC or DHCPv6, depending on what I set up on the network)
>
> > Kea does not appear to offer native support for RFC 2563.  I must not
> > be understanding what you are saying.  You also want the clients that
> > didn't receive any ip address (v4 or v6) to not auto-configure a
> > 169.254 address?
>
> Correct. Clients which don't understand RFC 8925 will still try to
> obtain an IPv4 address.  However, if they support RFC 2563 then I can
> detect this, and use this option to control whether or not they assign a
> link-local IPv4 address.  Again: if I'm not offering them a real IPv4
> address, then the RFC says the yiaddr should be 0.0.0.0.
>
> Clients which don't implement either RFC 2563 or RFC 8925, I don't want
> to respond to.  If they choose to assign a link-local IPv4 address,
> that's up to them.
>
> Regards,
>
> Brian.
>
> --
> 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] Problems trying to implement RFC 8925 (v6-only-preferred)

[Dan Oachs]

I'm a little confused about what you are trying to do.  What don't you like
about the way it is working now?

I have also configured an "ipv6-mostly" network and have kea doing the
option 108 thing and am happy with the way it is all working.

--Dan


On Fri, Jul 28, 2023 at 2:12 PM Brian Candler  wrote:

> Hello,
>
> I have a somewhat out-of-the-ordinary config question. I'm using
> isc-kea-dhcp4 version 2.4.0 under Ubuntu 22.04.  The full config is at
> the end of this mail.
>
> Background: I have set up a "mostly IPv6" subnet, as per this article:
>
> https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/
>
> I have it working when offering IPv4 addresses to all clients. Those
> which support the v6-only-preferred option happily ignore the IPv4
> address that I offer, and will configure themselves as IPv6-only.  Neat.
>
> However, I want to tighten this up to make it a true "IPv6-only"
> network, as follows:
>
> (a) Only make an offer to clients which request the "v6-only-preferred"
> parameter (option 108, RFC 8925).  That is: I don't want to offer IPv4
> addresses to anyone who will actually use them.
>
> (b) Offer yiaddr 0.0.0.0, as RFC 8925 section 3.3 says I should, instead
> of a pool address.  And preferably get rid of the pool entirely.
>
>
> Problem 1: in order to test whether the client supports
> v6-only-preferred, I have to check whether 108 is included in the
> dhcp-parameter-request-list (option 55) from the request.
>
> Unfortunately, "option[108].exists" does not work for this, because the
> client isn't sending option 108; they are only requesting option 108 as
> a response parameter.
>
> The only solution I could come up with was this:
>
>  "client-classes": [
>  {
>  "name": "rfc8925",
>  "test": "substring(option[55].hex, 0, 1) == 0x6c or
> substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2,
> 1) == 0x6c or substring(option[55].hex, 3, 1) == 0x6c or
> substring(option[55].hex, 4, 1) == 0x6c or substring(option[55].hex, 5,
> 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c or
> substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8,
> 1) == 0x6c or substring(option[55].hex, 9, 1) == 0x6c or
> substring(option[55].hex, 10, 1) == 0x6c or substring(option[55].hex,
> 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
>  },
>  ],
>
> ... and even that's not complete, in case the client requests more than
> 13 options.  Is there a better way to do this?
>
>
> Problem 2: how can I return a yiaddr of 0.0.0.0 ?  I thought about
> setting a static dummy flex-id, e.g.
>
>  "reservations": [
>  {
>  "flex-id": "'any'",
>  "ip-address": "0.0.0.0"
>  }
>  ]
>
> but I'm using the open-source version of Kea, which means I don't have
> the flex_id hook.  I don't think a pool starting from 0.0.0.0 will work,
> because once that's been given out to one client, it's no longer
> available for other clients (unless I use a tiny lease time??)  In any
> case, I'd also avoid allocating addresses from a pool in the first
> place, so that the pool doesn't become exhausted.
>
> If I can get this to work, I'd do the same for clients which support RFC
> 2563 (auto-configure option), which also allows the server to return
> yiaddr 0.0.0.0.
>
> Any clues appreciated. If Kea doesn't support this use case, maybe I
> need to cobble together something custom for this.
>
> Thanks in advance,
>
> Brian.
>
>  8< 
>
> {
> "Dhcp4": {
>  "interfaces-config": {
>  "interfaces": [ "enp6s0" ]
>  },
>
>  "control-socket": {
>  "socket-type": "unix",
>  "socket-name": "/tmp/kea4-ctrl-socket"
>  },
>
>  "lease-database": {
>  "type": "memfile",
>  "lfc-interval": 3600
>  },
>
>  "renew-timer": 900,
>  "rebind-timer": 1800,
>  "valid-lifetime": 3600,
>
>  "subnet4": [
>  {
>  // Subnet identifier should be unique for each subnet.
>  "id": 1,
>
>  // Subnet binds to dummy interface address (10.12.65.1)
>  "subnet": "10.12.65.0/24",
>  "authoritative": true,
>
>  // Dummy pool - still needs to be big enough for all unique
> clients
>  "pools": [
>  {
>  // Only give OFFERs to devices which support RFC 8925
>  "pool": "10.12.65.2 - 10.12.65.254",
>  "client-class": "rfc8925"
>  }
>  ],
>
>  //
>
> https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#dhcp4-std-options-list
>  "option-data": [
>  {
>  // RFC 8925: option 108
>  // (Note that client does not *send* this option,
> but includes it in
>  // the requested parameters 

Re: [Kea-users] Getting Started: Dual-stack Dynamic DNS Updates

[Dan Oachs]

I can't answer most of your questions, but I can tell you that the
fd75:81b2:5386:4f06::/64 subnet is part of the Unique Local Address ( ULA
 ) range for IPv6.  And
you are correct, that is somewhat akin to rfc1918 space.  They should only
be getting an address in that range if your router or DHCPv6 server is
telling them to.

--Dan


On Fri, Mar 3, 2023 at 3:23 PM Troy Telford 
wrote:

> I’ve been successful so far in getting Kea to serve IPv4 with both forward
> & reverse dynamic DNS. Thus far I’ve only used SLAAC and static zone files
> for IPv6 in DNS in my test/educational network. (A small network, so I can
> learn & experiment).
>
> I’ve had a notion of also learning DHCPv6 so I know how it works. (I’ve a
> goal to understand and have dual stack DHCP with forward/reverse DNS
> updates).
>
> It’s already clear it’s different from IPv4 DHCP. I’ve been able to piece
> together a rough idea of some basics - enough that there are signs of life:
> I configured `radvd` with the correct flags so macOS & iOS use DHCPv6, for
> example. it seems many of the hosts are getting IPv6 addresses from
> Kea-dhcp6, though it’s equally clear I’m missing important details, as
> things aren’t working as I’d thought:
>
> In this dual-stack environment, it seems kea-dhcp-ddns is sort of all over
> the place: I’m seeing either IPv4 updates, or IPv6 updates, but not both in
> DNS.
>
> I want to make sure I understand the situation properly before getting
> lost in the weeds (ie. Trying to ‘fix’ the wrong thing):
>
>* Is it true that in a dual-stack environment, it’s necessary for the
> _client_ to be configured properly in order for `kea-dhcp-ddns` to be able
> to update the DNS server properly?
>* I’ve read that both v4 and v6 clients need to send the same DUID
> for ddns to work properly - is that correct?
>* Am I wrong that most Linux distributions, and macOS aren’t
> configured this way by default? (I haven’t checked Windows yet…)
>* I’m sure there are minutae I need to learn - any hints?
>* While I don’t _think_ I’m running into any unimplemented
> functionality, is there something I should be aware of for the simple goal
> of dual-stack forward/reverse dynamic DNS? - (I’m using kea-2.2.0 on Debian
> Sid because I’ve apparently 'lived dangerously' for 25 years.)
>
> I’ve also noticed that many hosts are getting “new” IPv6 addresses that
> are from a subnet that’s not link-local (I think), and _not_ the subnet
> that I’m assigning via DHCPv6: fd75:81b2:5386:4f06::/64.
>
> * I think it’s something akin to the 169.254 IPv4 address range, but my
> Google-fu fails me; is there anything special about such a subnet? Why
> would the interfaces be getting such an address?
>
> Thank you.
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

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

[Dan Oachs]

That's basically the same situation we are in.

It would be awesome if there was a configuration option in Kea to tell the
server that it should immediately expire a lease if there is a request for
a static reservation that conflicts with an existing lease.  But maybe
there are issues with that that I am not thinking about.

--Dan


On Mon, Jan 30, 2023 at 3:55 AM GIRSTMAIR Tobias via Kea-users <
kea-users@lists.isc.org> wrote:

> On Fri, 2023-01-27 at 19:58 +, Simon wrote:
> > I assume it doesn’t scale in terms of having multiple hell desk
> > operators having to do manual steps - in which case, the answer is to
> > build a tool into your management toolset allowing them to “click
> > here to remove the lease” when they are altering the reservation
> > details.
>
> The problem for us is that we manage reservations through a central
> MySQL database (through a fancy UI for our hell desk), but leases are
> stored in memfiles on each DHCP server (8 HA setups for 16 total). So
> our tooling doesn't directly connect to the dhcp servers (and doesn't
> even know which dhcp server a reservation 'belongs' to).
>
> If there is no other way, we'll have to rework our tooling to find out
> where to send this API call to (and punch some holes into the
> firewalls). Not the end of the world, but this seems to be a feature
> more people could benefit from.
>
> tobi
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

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

[Dan Oachs]

We have run into the same issue when replacing hardware.  Luckily for us
our lease times are in the range of a few hours instead of days, but it
would still be nice to have a better solution for this.

-- Dan Oachs

On Fri, Jan 27, 2023 at 7:27 AM Veronique Lefebure <
veronique.lefeb...@cern.ch> wrote:

> We would have the same use-case as you, Tobi, and I guess we would not be
> the only ones ?
> The problem is also mentioned on
> https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag
>  by
> the way.
>
> On
> https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations
>  doc
> says
> "The best way to avoid such a recovery is not to define new reservations
> that conflict with existing leases. Another recommendation is to use
> out-of-pool reservations; if the reserved address does not belong to a
> pool, there is no way that other clients can get it."
>
> But indeed, even with out-of-pool reservations, the hardware replacement
> use-case is not going to work :-/
>
> --
> *From:* Kea-users  on behalf of
> GIRSTMAIR Tobias via Kea-users 
> *Sent:* Friday, January 27, 2023 1:07 PM
> *To:* kea-users@lists.isc.org 
> *Subject:* [Kea-users] DHCPv4 Conflict resolution on MAC change
>
> Hi all,
>
> We recently migrated to Kea 2.2.0 and now ran into the following
> situation:
>
> Initially:
>  - Leases are valid for a long time (11 days, per customer requirement)
>  - There is a host reservation for  and 
>  - The device with  got a lease for 
>
> Now, the hardware is replaced and the reservation is updated, so the
> new device gets the same IP:
>  - remove reservation for  and 
>  - add reservation for  and 
>  - the old device is unplugged, and therefore cannot release its lease
>  - the new device is plugged in and requests a lease
>
> Now, Kea looks for the host reservation for  and notices that
>  is still leased to , so it refuses to reassign this IP.
> This looks like this in the log:
>
> 2023-01-26 08:43:18.065 WARN  [kea-dhcp4.alloc-
> engine/1409.139836331153152] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT
> [hwtype=1 00:15:bc:28:2b:0c], cid=[01:00:15:bc:28:2b:0c],
> tid=0xaf01221b: conflicting reservation for address 10.58.166.192 with
> existing lease Address:   10.58.166.192
> Valid life:950400
> Cltt:  1674552388
> Hardware addr: 00:15:bc:28:09:e7
> Client id: 01:00:15:bc:28:09:e7
> Subnet ID: 5164
> State: default
>
> I read through section 8.3.2 of the documentation, and the conflict
> resolution protocol used seems to not handle our case here (where the
> old device doesn't release its lease). It expects the old device with
>  to renew its lease, before responding with DHCPNAK and
> reallocating  to .
>
> As a workaround, an operator could manually delete the lease with kea-
> shell (or its underlying api), but that does not scale to our size.
>
> The documentation describes that "A naive approach would to be
> immediately remove the existing lease for Host A and create a new one
> for Host B" -- this would be exactly what we want, and what our
> previous setup did. Our reservations are out-of-pool, and we can be
> certain that when the MAC of a reservation changes, the old device will
> not be online any longer. Is there a way to achieve this?
>
> Thanks,
>
> Tobi
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
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

[Dan Oachs]

I am not using firewalld, just direct iptables and ip6tables config files.

--Dan


On Tue, Jan 3, 2023 at 9:52 AM Eric Graham 
wrote:

> Dan,
>
> Would you be wlling to dump your iptables filter and nat tables before and
> after the restart and take a diff? Are you using firewalld on top of
> iptables, by chance? I've been running into issues with my firewall
> completely breaking when switching the backend of firewalld from nftables
> to iptables, but I suspect that's an entirely different issue.
>
> I do want to add that the article Stefan linked does mention that the
> network being "up" varies in definition. I know that I have needed to write
> retries into some of my own services that require that target, because the
> network might be "up" and DNS still might not resolve, pings fail, etc.
>
> *Eric Graham*
> *DevOps Specialist*
> Direct: 605.990.1859
> eric.gra...@vantagepnt.com 
>
> --
> *From:* Kea-users  on behalf of Dan
> Oachs 
> *Sent:* Tuesday, January 3, 2023 9:25 AM
> *To:* Stefan G. Weichinger 
> *Cc:* kea-users@lists.isc.org 
> *Subject:* Re: [Kea-users] Monitoring a Kea cluster
>
> *CAUTION:* This email originated outside the organization. Do not click
> any links or attachments unless you have verified the sender.
> I have noticed something similar with our Kea servers.
>
> Running Kea 2.0.3 on Rocky Linux 8.7
>
> After a server reboot dhcpv6 is running but not handing out leases.
> There is some issue with the way things start up and the firewall blocking
> packets.  My current workaround is to add a few lines in /etc/rc.local to
> stop ip6tables, restart kea-dhcp6, then start ip6tables.
>
> I'm sure there is a correct way to fix this, but the workaround is
> functional for me at the moment.
>
> --Dan
>
>
> On Tue, Jan 3, 2023 at 2:20 AM Stefan G. Weichinger 
> wrote:
>
> 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"
>  },
>
>
> --
> 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

[Dan Oachs]

I have noticed something similar with our Kea servers.

Running Kea 2.0.3 on Rocky Linux 8.7

After a server reboot dhcpv6 is running but not handing out leases.   There
is some issue with the way things start up and the firewall blocking
packets.  My current workaround is to add a few lines in /etc/rc.local to
stop ip6tables, restart kea-dhcp6, then start ip6tables.

I'm sure there is a correct way to fix this, but the workaround is
functional for me at the moment.

--Dan


On Tue, Jan 3, 2023 at 2:20 AM Stefan G. Weichinger  wrote:

> 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"
>  },
>
>
> --
> 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

[Dan Oachs]

I am running Kea on RockyLinux8 and RHEL8.  For those systems I usually run
"service kea-dhcp4 reload" and "service kea-dhcp6 reload" anytime I update
the .json configuration files.  And as far as I can tell, when I do that
there are no DHCP replies from the server for 10-20 seconds.  Or at least
nothing is logged during that time.  I have not looked at that very closely
as reloading the Kea service is not very common for us now that it is all
up and running.

--Dan


On Fri, Nov 18, 2022 at 2:24 AM Veronique Lefebure <
veronique.lefeb...@cern.ch> wrote:

> Many thanks for these interesting hints!
> A last question then: how do you notify KEA processes (kea-dhcp4,
> kea-dhcp6) in case you modify any of you json files ? with a "reload"
> command ?
> Thanks,
> Veronique
> --
> *From:* Dan Oachs 
> *Sent:* Thursday, November 17, 2022 8:36 PM
> *To:* Veronique Lefebure 
> *Cc:* kea-users@lists.isc.org 
> *Subject:* Re: [Kea-users] How to best update the KEA configuration on a
> HA hot-standby KEA setup
>
> The great thing about Kea is that it is very flexible and you can make it
> work in a wide variety of ways and find the setup that works best for your
> situation.
>
> In our case we have a hybrid setup.  The kea-dhcp4.conf file has all the
> global settings, and we define the hosts-database for storing host
> reservations.  We also break out all the subnet config into a separate
> subnets.json file and have the main file include that.
>
> We update the database directly from our own registration system, which is
> not recommended, but works fo us.  We chose not to pay for the host
> commands hook library that is required to use the api example you
> mentioned.
>
> I am pretty sure that you can do almost everything in the database that
> you can do in the config file, but are only using the database to store the
> host information.  I do see tables in the database that start with
> dhcp4_client_class which would lead me to believe that you can do what you
> want with the database configuration.
>
> --Dan
>
>
> On Thu, Nov 17, 2022 at 9:48 AM Veronique Lefebure <
> 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 <

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

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] How do I install and configure ISC Kea DHCP Server on RHEL 9.0?

[Dan Oachs]

RockyLinux 8 is a replacement for Centos8 and you can convert from one to
the other.
RockyLinux 9 is equivalent to RHEL 9.

I have Kea running on RHEL 8 and RockyLinux 8.  I assume it would also run
fine on either RHEL 9 or RockyLinux 9.  Which is what I would do if I were
installing a new Kea server today.

--Dan


On Tue, Nov 15, 2022 at 9:09 PM Turritopsis Dohrnii Teo En Ming <
tdtemc...@gmail.com> wrote:

> On Tue, 15 Nov 2022 at 15:51, Kenneth Porter 
> wrote:
> >
> > On 11/14/2022 7:53 AM, Dan Oachs wrote:
> >
> > I would start by installing the cloudsmith repository and then you can
> use yum/dnf to install kea:
> > https://cloudsmith.io/~isc/repos/kea-2-2/setup/#formats-rpm
> >
> > Once you have kea installed, follow the Kea documentation here:
> > https://kea.readthedocs.io/en/kea-2.2.0/
> >
> > Is there any reason to avoid kea-2.3? I've been using 2.1.7 on CentOS 7
> and am about to migrate my config to a Rocky 8 server.
>
> Is Rocky Linux similar to CentOS Linux?
>
> Regards,
>
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
>
> >
> >
> > Also, the instructions for setting the repo up here say to use yum for
> RHEL distros, but RHEL uses dnf since RHEL-8. (There's a courtesy symlink
> so one can use the "yum" command but it just invokes dnf.) I tried to use
> the manual instructions for dnf for Fedora but they assume one is using
> Fedora 29. I edited the resulting /etc/yum.repos.d/isc-kea-2-3.repo to
> replace fedora/29 with el/8 and that made Rocky 8's dnf work and find the
> 2.3 packages.
> >
> > https://cloudsmith.io/~isc/repos/kea-2-3/setup/#formats-rpm
> >
> >
> > --
> > 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] How to best update the KEA configuration on a HA hot-standby KEA setup

[Dan Oachs]

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

[Dan Oachs]

If you really wanted to make sure the standby was serving requests during
that period, you could try starting and stopping via the
ha-maintenance-start command.  I don't do it that frequently, but I run
that command before installing updates and rebooting the main kea server.

--Dan


On Wed, Nov 16, 2022 at 10:42 AM perl-list  wrote:

> The hot-standby will only start after some criteria are met.  Some of the
> parameters are tunable.  See:
> https://kea.readthedocs.io/en/kea-1.8.1/arm/hooks.html#load-balancing-configuration
> Not sure if you can tune it to start responding within a 30 to 35 second
> window.
>
> We just modify the config on disk and then restart the kea process, but
> then we aren't doing anything special with databases or anything, just the
> JSON config in a single file.  We also aren't changing the config and
> restarting every 5 minutes.
>
> - Original Message -
> > From: "Veronique Lefebure" 
> > To: "kea-users" 
> > Sent: Wednesday, November 16, 2022 11:27:07 AM
> > Subject: [Kea-users] How to best update the KEA configuration on a HA
> hot-standby KEA setup
>
> > 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
> > |
> >
> 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
>
-- 
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 do I install and configure ISC Kea DHCP Server on RHEL 9.0?

[Dan Oachs]

I would strongly suggest going with Kea.  I have Kea running on RHEL 8.

I would start by installing the cloudsmith repository and then you can use
yum/dnf to install kea:
https://cloudsmith.io/~isc/repos/kea-2-2/setup/#formats-rpm

Once you have kea installed, follow the Kea documentation here:
https://kea.readthedocs.io/en/kea-2.2.0/

--Dan


On Mon, Nov 14, 2022 at 9:47 AM Turritopsis Dohrnii Teo En Ming <
tdtemc...@gmail.com> wrote:

> Subject: How do I install and configure ISC Kea DHCP Server on RHEL 9.0?
>
> Good day from Singapore,
>
> I understand Kea is a relatively new implementation.
>
> How do I install and configure ISC Kea DHCP Server on RHEL 9.0?
>
> Are there any well written documentation?
>
> Not sure whether to use the classic/legacy ISC DHCP Server or the new ISC
> Kea DHCP Server.
>
> Thank you.
>
> Regards,
>
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> Blogs:
> https://tdtemcerts.blogspot.com
> https://tdtemcerts.wordpress.com
> --
> 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] dhcp6 address assignment

[Dan Oachs]

I'm guessing you might need to use the flex_id hook library and define a
flex-id to make that work?  Though I don't really know as I have not looked
into using the flex_id hook library myself.

--Dan


On Wed, Oct 19, 2022 at 4:09 PM Marek Greško via Kea-users <
kea-users@lists.isc.org> wrote:

> Hello,
>
> I have one more question on that topic. I have one client having both
> ethernet and wifi interface in the same vlan/subnet. I want to assign ipv6
> address to both of them. Is it possible to differentiate by both duid and
> iaid?
>
> Thanks
>
> Marek
>
>
>
>
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Wednesday, October 19th, 2022 at 19:12, perl-list <
> perl-l...@network1.net> wrote:
>
>
> >
> > - Original Message -
> >
> > > From: "Marek Greško via Kea-users" kea-users@lists.isc.org
> > > To: "Dan Oachs" doa...@gac.edu
> > > Cc: "kea-users" kea-users@lists.isc.org
> > > Sent: Wednesday, October 19, 2022 12:59:56 PM
> > > Subject: Re: [Kea-users] dhcp6 address assignment
> >
> > > Hello,
> >
> > > I run into another problems with this. To simplify the migration I use
> global
> > > reservations. I have two definitions for that machine. One for
> ethernet adapter
> > > and one for wifi adapter. Unfortunately the DUID is the same with both
> > > interfaces so the kea-dhcp6 cannot start with that configuration. ISC
> DHCPD6
> > > hed no problem with that and everything was working correctly. It was
> because I
> > > was able to define both mac address and duid. Since I defined
> different value
> > > for mac for wifi there was no conflict.
> >
> > > Probably the only one solution for this is to drop global reservations
> and
> > > switch to per subnet reservations?
> >
> >
> > It would seem it is best to not use global reservations in your scenario:
> >
> > "This feature can be used to assign certain parameters, such as hostname
> or other dedicated, host-specific options. It can also be used to assign
> addresses or prefixes. However, global reservations that assign either of
> these bypass the whole topology determination provided by the DHCP logic
> implemented in Kea. It is very easy to misuse this feature and get a
> configuration that is inconsistent. To give a specific example, imagine a
> global reservation for the address 2001:db8:::1 and two subnets
> 2001:db8:::/48 and 2001:db8:::/48. If global reservations are used
> in both subnets and a device matching global host reservations visits part
> of the network that is covered by 2001:db8:::/48, it will get the IP
> address 2001:db8:::1, which is outside of the prefix announced by its
> local router using router advertisements. Such a configuration is unusable
> or, at the very least, riddled with issues, such as downlink traffic not
> reaching the device."
> >
> >
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html?highlight=global
> reservation#global-reservations-in-dhcpv6
> >
> > > Thanks
> >
> > > Marek
> >
> > > --- Original Message ---
> > > On Tuesday, October 18th, 2022 at 20:48, Dan Oachs doa...@gac.edu
> wrote:
> >
> > > > Have you looked at using multiple reservations for the same IP?
> Would that solve
> > > > any of your issues?
> >
> > > > [
> > > >
> https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html?highlight=unique#multiple-reservations-for-the-same-ip
> > > > |
> > > >
> https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html?highlight=unique#multiple-reservations-for-the-same-ip
> > > > ]
> >
> > > > --Dan
> >
> > > > On Tue, Oct 18, 2022 at 1:15 PM Marek Greško via Kea-users < [
> > > > mailto:kea-users@lists.isc.org | kea-users@lists.isc.org ] > wrote:
> >
> > > > > Hello,
> >
> > > > > I am in a phase of migration ISC DHCPD into kea and I am suffering
> several
> > > > > problems in ipv6 address assignment.
> >
> > > > > 1. I used to assign same ipv6 address for the same machine which
> was dial boot
> > > > > linux/windows. It was possible by assigning same ipv6 address to
> both DUIDs
> > > > > before. But in kea this is not allowed. I found out there is a
> possibility to
> > > > > assign ipv6 address by MAC address which was not possible in ISC
> DHCPD. I was
> > > > > very

Re: [Kea-users] dhcp6 address assignment

[Dan Oachs]

Have you looked at using multiple reservations for the same IP?  Would that
solve any of your issues?

https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html?highlight=unique#multiple-reservations-for-the-same-ip

--Dan


On Tue, Oct 18, 2022 at 1:15 PM Marek Greško via Kea-users <
kea-users@lists.isc.org> wrote:

> Hello,
>
> I am in a phase of migration ISC DHCPD into kea and I am suffering several
> problems in ipv6 address assignment.
>
>
>1. I used to assign same ipv6 address for the same machine which was
>dial boot linux/windows. It was possible by assigning same ipv6 address to
>both DUIDs before. But in kea this is not allowed. I found out there is a
>possibility to assign ipv6 address by MAC address which was not possible in
>ISC DHCPD. I was very happy with that finding but fallen into second
>problem.
>2. The windows machine got 2 interfaces ethernet and wifi. I
>configured kea to assign one ipv6 address to the ethernet adapter and
>another one to the wifi adapter. But after investigating logs kea was
>receiving dhcp6 request over wifi using the ethernet adapter mac address.
>How is this possible? Is it possible the MAC address in DHCP does not match
>L2 MAC address? I did not sniff the request, yet. I decided to switch back
>to DUID assignment since this problem is worse than the previous.
>3. Maybe it would be possible to overcome the above problems if kea is
>able to match both DUID and MAC address, but it is not allowed in kea. I am
>ought to select one option only. Why?
>
>
> Thanks
>
> Marek
>
>
> Thanks
>
> 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

Re: [Kea-users] dhcp6 address assignment

[Dan Oachs]

I have recently learned that it is normal and expected that the DUID may
contain the MAC address of a different network device.  For example, an
Apple laptop ( that has only wifi ) will generate its DUID the first time
it boots and use that DUID for everything.  Wifi, usb-ethernet dongle, etc.

Windows has its own way of generating a DUID.  And on Linux, most distro's
will use a DUID but you can change a config file to have it use a link
local address instead.

While this info does not directly solve your problems, hopefully it helps
you understand how things are working.

The short answer is that you might need to rethink the way you use DHCP
(v6) on your network.  I know I have been struggling with some of the
differences making it difficult or impossible to do things the way we had
in the past.  For example, we can no longer assume a usb to ethernet
adapter will have a specific IPv6 address assigned to it, the address might
change depending on what host it is connected to :(


Thanks,
  Dan Oachs



On Tue, Oct 18, 2022 at 1:15 PM Marek Greško via Kea-users <
kea-users@lists.isc.org> wrote:

> Hello,
>
> I am in a phase of migration ISC DHCPD into kea and I am suffering several
> problems in ipv6 address assignment.
>
>
>1. I used to assign same ipv6 address for the same machine which was
>dial boot linux/windows. It was possible by assigning same ipv6 address to
>both DUIDs before. But in kea this is not allowed. I found out there is a
>possibility to assign ipv6 address by MAC address which was not possible in
>ISC DHCPD. I was very happy with that finding but fallen into second
>problem.
>2. The windows machine got 2 interfaces ethernet and wifi. I
>configured kea to assign one ipv6 address to the ethernet adapter and
>another one to the wifi adapter. But after investigating logs kea was
>receiving dhcp6 request over wifi using the ethernet adapter mac address.
>How is this possible? Is it possible the MAC address in DHCP does not match
>L2 MAC address? I did not sniff the request, yet. I decided to switch back
>to DUID assignment since this problem is worse than the previous.
>3. Maybe it would be possible to overcome the above problems if kea is
>able to match both DUID and MAC address, but it is not allowed in kea. I am
>ought to select one option only. Why?
>
>
> Thanks
>
> Marek
>
>
> Thanks
>
> 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

Re: [Kea-users] problems enabling HA Hot-Standby setup (OPEN)

[Dan Oachs]

Good point.  I think the default for the kea-ctrl-agent is to use port
8000.  In that case you should change the kea control agent to use a
different port such as 8001 since you can't have both trying to use the
same port.  If you have not already, look at /etc/kea/kea-ctrl-agent.conf

--Dan


On Tue, Mar 22, 2022 at 8:28 AM Bohnenberger, Mark <
mark.bohnenber...@bechtle.com> wrote:

> Do have configured the kea-ctrl-agent, which is responsible for the
> activation / communication of the RESTful service?
>
>
>
> Mark
>
>
>
>
>
> *Von:* Kea-users  *Im Auftrag von *Dan
> Oachs
> *Gesendet:* Dienstag, 22. März 2022 14:08
> *An:* Weisteen Per 
> *Cc:* kea-users@lists.isc.org
> *Betreff:* Re: [Kea-users] problems enabling HA Hot-Standby setup (OPEN)
>
>
>
> That looks very similar to my setup which is working.  Are you sure the
> kea service is not listening on port 8000? One way to check would be with
> "lsof -i -P| grep kea-dhcp" and look for a line showing the hostname:8000
> (LISTEN).
>
>
>
> If the service is listening, then perhaps there is a firewall blocking
> incoming traffic to port 8000?
>
>
>
> --Dan
>
>
>
>
>
> On Tue, Mar 22, 2022 at 6:53 AM Weisteen Per 
> wrote:
>
> Hi, I've set up a HA Hot-Standby config according to docs but I can't
> figure out why the servers doesn't listen on port 8000.
> I thought that was the port configured for heartbeat. I'm a little
> confused and would be very happy if someone could explain how this is
> supposed to work ?
>
> I'm running KEA on RHEL 8 servers installed from KEA 2.0 repo using yum
> install.
>
> My HA config for primary server (pls ignore any missing parentheses ad
> this is just an extract:
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [{
> "this-server-name": "tst-dhcp01",
> "mode": "hot-standby",
> "heartbeat-delay": 1,
> "max-response-delay": 1,
> "max-ack-delay": 5000,
> "max-unacked-clients": 5,
> "multi-threading": {
> "enable-multi-threading": true,
> "http-dedicated-listener": true,
> "http-listener-threads": 4,
> "http-client-threads": 4
> },
> "peers": [{
> "name": "tst-dhcp01",
> "url": "http://10.123.10.10:8000/
> <https://urldefense.com/v3/__http:/10.123.10.10:8000/__;!!J748QdifiTU!yBWK0nZy5mHL2PL9-6HyJxFlHKds79HoSewLccSsq7Jo2-Btrw22dfTb6nrGDbdjo1pyseY$>
> ",
> "role": "primary",
> "auto-failover": true
> },{
>   "name": "tst-dhcp02",
>"url": "http://10.123.20.20:8000/
> <https://urldefense.com/v3/__http:/10.123.20.20:8000/__;!!J748QdifiTU!yBWK0nZy5mHL2PL9-6HyJxFlHKds79HoSewLccSsq7Jo2-Btrw22dfTb6nrGDbdjTMMBPog$>
> ",
>"role": "standby",
>"auto-failover": true
> }]
>
> and for standby server:
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [{
> "this-server-name": "tst-dhcp02",
> "mode": "hot-standby",
> "heartbeat-delay": 1,
> "max-response-delay": 1,
> "max-ack-delay": 5000,
> "max-unacked-clients": 5,
> "multi-threading": {
> "enable-multi-threading": true,
> "http-dedicated-listener": true,
> "http-listener-threads": 4,
> "http-client-threads": 4
>  

Re: [Kea-users] problems enabling HA Hot-Standby setup (OPEN)

[Dan Oachs]

That looks very similar to my setup which is working.  Are you sure the kea
service is not listening on port 8000? One way to check would be with "lsof
-i -P| grep kea-dhcp" and look for a line showing the hostname:8000
(LISTEN).

If the service is listening, then perhaps there is a firewall blocking
incoming traffic to port 8000?

--Dan


On Tue, Mar 22, 2022 at 6:53 AM Weisteen Per 
wrote:

> Hi, I've set up a HA Hot-Standby config according to docs but I can't
> figure out why the servers doesn't listen on port 8000.
> I thought that was the port configured for heartbeat. I'm a little
> confused and would be very happy if someone could explain how this is
> supposed to work ?
>
> I'm running KEA on RHEL 8 servers installed from KEA 2.0 repo using yum
> install.
>
> My HA config for primary server (pls ignore any missing parentheses ad
> this is just an extract:
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [{
> "this-server-name": "tst-dhcp01",
> "mode": "hot-standby",
> "heartbeat-delay": 1,
> "max-response-delay": 1,
> "max-ack-delay": 5000,
> "max-unacked-clients": 5,
> "multi-threading": {
> "enable-multi-threading": true,
> "http-dedicated-listener": true,
> "http-listener-threads": 4,
> "http-client-threads": 4
> },
> "peers": [{
> "name": "tst-dhcp01",
> "url": "http://10.123.10.10:8000/;,
> "role": "primary",
> "auto-failover": true
> },{
>   "name": "tst-dhcp02",
>"url": "http://10.123.20.20:8000/;,
>"role": "standby",
>"auto-failover": true
> }]
>
> and for standby server:
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
> "parameters": {
> "high-availability": [{
> "this-server-name": "tst-dhcp02",
> "mode": "hot-standby",
> "heartbeat-delay": 1,
> "max-response-delay": 1,
> "max-ack-delay": 5000,
> "max-unacked-clients": 5,
> "multi-threading": {
> "enable-multi-threading": true,
> "http-dedicated-listener": true,
> "http-listener-threads": 4,
> "http-client-threads": 4
> },
> "peers": [{
> "name": "tst-dhcp01",
> "url": "http://10.123.10.10:8000/;,
> "role": "primary",
> "auto-failover": true
> },{
> "name": "tst-dhcp02",
> "url": "http://10.123.20.20:8000/;,
> "role": "standby",
> "auto-failover": true
> }] /* peers */
> }] /* high-availability */
> }
>
> Kea-debug.log shows :
>
> HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to tst-dhcp02 (
> http://10.123.20.20:8000/): Connection refused
> HA_COMMUNICATION_INTERRUPTED communication with tst-dhcp02 is interrupted
>
> And similar on the standby server but differet IP-address and name of
> course.
>
> ./PerW
>
> --
> 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] Unable to send DHCPOFFER packet

[Dan Oachs]

I feel like I had a similar error message when the firewall on my system
was not allowing the traffic.

Another possibility would be selinux if you have that enabled.

--Dan

On Tue, Mar 8, 2022 at 11:24 AM Dustin Berube 
wrote:

> Thanks Chad & Bob, I'm replying to the list to update the thread. I double
> checked the permissions and went ahead as a test and ran kea as root and
> I'm still getting the same error.
>
> ps aux | grep kea
> root   13707  0.0  1.2  44312 25060 ?Ss   17:17   0:00
> /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
>
> getcap /usr/sbin/kea-dhcp4
> /usr/sbin/kea-dhcp4 = cap_net_bind_service,cap_net_raw+ep
>
> On Tue, Mar 8, 2022 at 10:46 AM Chad Catlett <> wrote:
>
>> On 3/8/22 08:54, Dustin Berube wrote:
>>
>> Hello,
>>
>> I'm running into an issue with Kea that I am unable to send the DHCPOFFER
>> packet to the client. After enabling debug I see that I'm getting a
>> permission denied error. The server is running Ubuntu 20.04, I've tried
>> the isc-kea packages for both 2.0.1 and 2.0.2 with the same results. Does
>> anyone have any suggestions on what to try?
>>
>> 2022-03-08 14:09:14.872 DEBUG [kea-dhcp4.packets/6691.140535278995904]
>> DHCP4_BUFFER_RECEIVED received buffer from 10.201.1.6:67 to 10.201.1.2:67
>> over interface ens192
>> 2022-03-08 14:09:14.872 DEBUG [kea-dhcp4.options/6691.140535278995904]
>> DHCP4_BUFFER_UNPACK parsing buffer received from 10.201.1.6 to 10.201.1.2
>> over interface ens192
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.packets/6691.140535278995904]
>> DHCP4_PACKET_RECEIVED [hwtype=1 94:40:c9:40:f4:5c],
>> cid=[00:94:40:c9:40:f4:5c:00:00:00], tid=0x20: DHCPDISCOVER (type 1)
>> received from 10.201.1.6 to 10.201.1.2 on interface ens192
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.packets/6691.140535278995904]
>> DHCP4_QUERY_DATA [hwtype=1 94:40:c9:40:f4:5c],
>> cid=[00:94:40:c9:40:f4:5c:00:00:00], tid=0x20, packet details:
>> local_address=10.201.1.2:67, remote_address=10.201.1.6:67,
>> msg_type=DHCPDISCOVER (1), transid=0x20,
>> options:
>>   type=012, len=010: "esx-01-ilo" (string)
>>   type=050, len=004: 10.201.1.10 (ipv4-address)
>>   type=053, len=001: 1 (uint8)
>>   type=055, len=015: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 6(uint8)
>> 15(uint8) 28(uint8) 33(uint8) 42(uint8) 43(uint8) 44(uint8) 58(uint8)
>> 59(uint8) 100(uint8) 101(uint8)
>>   type=060, len=007: "CPQRIB3" (string)
>>   type=061, len=010: 00:94:40:c9:40:f4:5c:00:00:00
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.dhcpsrv/6691.140535278995904]
>> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.201.1.0/24 for packet
>> received by matching address 10.201.1.6
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.packets/6691.140535278995904]
>> DHCP4_SUBNET_SELECTED [hwtype=1 94:40:c9:40:f4:5c],
>> cid=[00:94:40:c9:40:f4:5c:00:00:00], tid=0x20: the subnet with ID 1 was
>> selected for client assignments
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.packets/6691.140535278995904]
>> DHCP4_SUBNET_DATA [hwtype=1 94:40:c9:40:f4:5c],
>> cid=[00:94:40:c9:40:f4:5c:00:00:00], tid=0x20: the selected subnet details:
>> 10.201.1.0/24
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.hosts/6691.140535278995904]
>> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation
>> for subnet id 1, identified by hwaddr=9440C940F45C
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.hosts/6691.140535278995904]
>> HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
>> identifier: hwaddr=9440C940F45C
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.hosts/6691.140535278995904]
>> HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier: hwaddr=9440C940F45C,
>> found host: hwaddr=9440C940F45C ipv4_subnet_id=1 hostname=esx-01-ilo
>> ipv4_reservation=10.201.1.10 siaddr=(no) sname=(empty) file=(empty)
>> key=(empty) ipv6_reservations=(none)
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.hosts/6691.140535278995904]
>> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=9440C940F45C,
>> found 1 host(s)
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.hosts/6691.140535278995904]
>> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 1 and
>> identifier hwaddr=9440C940F45C, found host: hwaddr=9440C940F45C
>> ipv4_subnet_id=1 hostname=esx-01-ilo ipv4_reservation=10.201.1.10
>> siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none)
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.dhcp4/6691.140535278995904]
>> DHCP4_CLASS_ASSIGNED [hwtype=1 94:40:c9:40:f4:5c],
>> cid=[00:94:40:c9:40:f4:5c:00:00:00], tid=0x20: client packet has been
>> assigned to the following class(es): KNOWN
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.dhcp4/6691.140535278995904]
>> DHCP4_CLASS_ASSIGNED [hwtype=1 94:40:c9:40:f4:5c],
>> cid=[00:94:40:c9:40:f4:5c:00:00:00], tid=0x20: client packet has been
>> assigned to the following class(es): ALL, VENDOR_CLASS_CPQRIB3, KNOWN
>> 2022-03-08 14:09:14.873 DEBUG [kea-dhcp4.ddns/6691.140535278995904]
>> DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 94:40:c9:40:f4:5c],
>> 

Re: [Kea-users] How to add a second subnet?

[Dan Oachs]

Have you looked at the example configuration files?  On my server there are
a bunch of good example files in /usr/share/doc/isc-kea/examples/kea4

If you can find an example that is similar to what you are trying to do, it
might make it easier.

--Dan


On Thu, Mar 3, 2022 at 7:21 AM Stephen Berg, Code 7309 via Kea-users <
kea-users@lists.isc.org> wrote:

> I've gotten kea working on one subnet.  Doing installs with pxeboot is
> functioning as needed.  My next step is start migrating other subnets
> from their dhcp into this. Right now we've got dhcp servers on each
> subnet and my plan is to consolidate into one server and relay agents on
> the other subnets.
>
> I've tried this on my test bed and as soon as I configure a second or
> third subnet it all seems to break.  Clients with reserved addresses no
> longer get a lease even on the first subnet where the server is.  I
> think I need to configure some sort of id for each subnet and then a
> flag for the reserved leases to match that but what I've tried so far
> has not worked.  Is there a simple way to set this up so one server can
> manage multiple subnets and reserved addresses for each client?
>
> --
> Stephen Berg, IT Specialist, Ocean Sciences Division, Code 7309
> Naval Research Laboratory
> W:   (228) 688-5738
> DSN: (312) 823-5738
> C:   (228) 365-0162
> Email: stephen.b...@nrlssc.navy.mil  <- (Preferred contact)
> Flank Speed: stephen.p.berg@us.navy.mil
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

Re: [Kea-users] IPv6 High Availability hooks library not accepting ipv6 address in square brackets for peers?

[Dan Oachs]

Thanks.  I should know better than ask for help without mentioning the
version number I am running.  :)That looks exactly like the error I am
seeing.  Good to know it should get fixed in the next update.

I am using version 2.0.1.

Thanks,
   Dan Oachs


On Fri, Feb 25, 2022 at 4:08 PM Peter Davies <
peter.watson.dav...@outlook.com> wrote:

> Hi Dan,
>
>You don't mention  what version of Kea you are running,  but I think
> this may be a known issue. One which was fixed in release 2.1.2
>
>
> see https://gitlab.isc.org/isc-projects/kea/-/issues/2264 "error parsing
> url with ipv6 address"
>
>
> Kind Regard Peter
>
>
> Sent from Outlook <http://aka.ms/weboutlook>
> ------
> *From:* Kea-users  on behalf of Dan
> Oachs 
> *Sent:* 25 February 2022 22:36
> *To:* kea-users@lists.isc.org 
> *Subject:* [Kea-users] IPv6 High Availability hooks library not accepting
> ipv6 address in square brackets for peers?
>
> I currently have ipv6 dhcp working great with high availability and am
> trying to set up a pair of dhcpv6 servers.  However when I try to configure
> the hook with ipv6 addresses in square brackets as mentioned in the
> documentation, I get this error
>
> HA_CONFIGURATION_FAILED failed to configure High Availability hooks
> library: bad url 'http://[2001:db8::1]:8080/': Failed to convert string
> to address '[2001:db8::1]': Invalid argument for server
>
> The line in my configuration looks like this...
> {"name": "servername","basic-auth-user":
> "usernamehere","basic-auth-password": "passwordhere","url": 
> "http://[2001:db8::1]:8080/","role":
> "primary"}
>
> Do I have the configuration wrong, or is there a bug here?  Hopefully I am
> missing something simple.
>
> Thanks,
>   Dan Oachs
>
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

[Kea-users] IPv6 High Availability hooks library not accepting ipv6 address in square brackets for peers?

[Dan Oachs]

I currently have ipv6 dhcp working great with high availability and am
trying to set up a pair of dhcpv6 servers.  However when I try to configure
the hook with ipv6 addresses in square brackets as mentioned in the
documentation, I get this error

HA_CONFIGURATION_FAILED failed to configure High Availability hooks
library: bad url 'http://[2001:db8::1]:8080/': Failed to convert string to
address '[2001:db8::1]': Invalid argument for server

The line in my configuration looks like this...
{"name": "servername","basic-auth-user":
"usernamehere","basic-auth-password": "passwordhere","url":
"http://[2001:db8::1]:8080/","role":
"primary"}

Do I have the configuration wrong, or is there a bug here?  Hopefully I am
missing something simple.

Thanks,
  Dan Oachs
-- 
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] DHCPSRV_NO_SOCKETS_OPEN problem

[Dan Oachs]

I am running kea 2.0.1 on Rocky Linux 8.5.

My interfaces option is set to:
  "interfaces": ["eth0"]

And I have ip helper addresses set for all the vlans to point dhcp traffic
to this server.

Are you 100% sure there is not some other process or dhcp server listening
on port 67 on your server?

I also have a second kea 2.0.1 server ( setup in HA mode with this
server).  The second server has an interface on each vlan so it can get the
dhcp requests directly and not need them forwarded from the router.

On this server the interfaces option looks like this:
   "interfaces": ["*"]


--Dan


On Fri, Feb 18, 2022 at 8:33 AM Stephen Berg, Code 7309 via Kea-users <
kea-users@lists.isc.org> wrote:

> I'm evaluating kea 1.8 to eventually integrate into my network.  I've
> got 6 subnets that I'll be managing eventually.  Relay agents will be on
> all but one subnet. An initial install and test setup with mysql backend
> went okay but I have one show stopper problem now.
>
> Whenever I start the service I see in the log:
> DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on
> interface eth0, reason: failed to bind fallback socket to address
> , port 67, reason: Address already in use - is another DHCP
> server running?
> 2022-02-18 08:23:27.547 WARN [kea-dhcp4.dhcpsrv/3416.140158564502848]
> DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
>
> I changed dhcp-socket-type to udp to see if that would change the
> behavior and got this:
> 2022-02-18 08:14:13.653 WARN [kea-dhcp4.dhcpsrv/3218.139637232491840]
> DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on
> interface eth0, reason: Failed to bind socket 15 to /port=67
> 2022-02-18 08:14:13.653 WARN [kea-dhcp4.dhcpsrv/3218.139637232491840]
> DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
>
> This is running on a virtual machine, rocky linux 8.5.  Selinux and
> firewall have been disabled for testing.  Network seems fine on the
> system other than this.  My initial config is just a couple of reserved
> address based on mac address and no pool.  If I can get this working I
> plan to add reservations for all clients in each of the subnets.
>
> --
> Stephen Berg, IT Specialist, Ocean Sciences Division, Code 7309
> Naval Research Laboratory
> W:   (228) 688-5738
> DSN: (312) 823-5738
> C:   (228) 365-0162
> Email: stephen.b...@nrlssc.navy.mil  <- (Preferred contact)
> Flank Speed: stephen.p.berg@us.navy.mil
>
> --
> 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