Re: [Kea-users] insert into dhcp4_subnet

[Klaus Steden]

Hi,

We have a service that uses Kea on the backend behind an internal REST API
that performs CRUD operations against the lease and reservation tables.

We're still using v1.8, but it uses bog standard INSERT/UPDATE/DELETE
statements.

IMO, you should know why want to do it this way. In our case, the
application was written a few years before hook libraries were available,
and it's one aspect of a larger server provisioning toolchain.

You can do it like we did, but you can quickly end up in the weeds if
you're not careful about how writes are handled.

cheers,
Klaus

On Wed, Jan 10, 2024 at 12:31 AM Nicolò Borghi 
wrote:

> Hi,
>
> I believe you are asking here how to handle the DB directly, therefore
> bypassing the paid hook libraries specific for this task.
>
> I'm not sure this sort of guidance will be offered here...
>
> Best,
> Nicolò.
>
>
> --
> 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] Is Kea-DHCP able to support a /30 network?

[Klaus Steden]

FWIW we've used Kea with /31s in our environment successfully (although
_why_ we used /31s is itself dumb and I can't recommend it)

cheers,
Klaus

On Thu, Jan 11, 2024 at 12:01 PM Scott Rakow  wrote:

> Thanks!
>
> On Thu, Jan 11, 2024 at 7:47 PM Darren Ankney 
> wrote:
>
>> Hi Scott,
>>
>> This would be the correct way:
>>
>> "subnet": "10.10.1.0/30",
>> "pools": [ { "pool":  10.10.1.2 - 10.10.1.2 } ],
>>
>> Thank you,
>>
>> Darren Ankney
>>
>> On Thu, Jan 11, 2024 at 1:50 PM Scott Rakow  wrote:
>> >
>> > In one of my subnets I am having to deploy, I have a /30 network which
>> has only one IP. Will Kea-DHCP be able to support this, as I have not seen
>> anything in the documentation for this.
>> >
>> > If so, would I have to set up the Pool to look like...
>> >
>> > "subnet": "10.10.1.0/30",
>> > "pools": [ { "pool":  10.10.1.2 } ],
>> >
>> > Or would it have to look like...
>> >
>> > "subnet": "10.10.1.0/30",
>> > "pools": [ { "pool":  10.10.1.2 - 10.10.1.2 } ],
>> >
>> > Thanks,
>> > Scott
>> > --
>> > ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>> >
>> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>> >
>> > Kea-users mailing list
>> > Kea-users@lists.isc.org
>> > https://lists.isc.org/mailman/listinfo/kea-users
>> --
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>>
>> Kea-users mailing list
>> Kea-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Hello Simon,

Thank you for demystifying this.

FWIW we are already using MySQL to store lease and reservation data, and we
built an API to manage leases and reservations years ago that is also
integrated with our config management service, which we use to update the
Kea config (e.g., adding/changing/removing pools), so it's already a pretty
closed loop.

I could modify the API code to include the address of the relay in each
subnet declaration (I did some experiments with this several weeks ago,
when we were initially exploring solutions to the problem, and that worked
fine), but even then, we're still stuck with the same problem -- we don't
know, aren't told, and can't predict what the next relay IP will be, or to
which subnet it will be assigned. What a pisser. :-(

It sounds like I will have to circle back with the network team and hammer
out something better; one bright spot is that they're at least using an
IPAM that has an API, and it *may* be possible to codify some kind of
association between subnets and their relays. Then it becomes less of a
management problem, and more of a programming one.

thanks!
Klaus

On Thu, Mar 2, 2023 at 8:59 AM Simon  wrote:

> Klaus Steden  wrote:
>
> > … so it’s been an uphill battle just to push for basic changes like
> "let's use one DHCP server for multiple subnets instead of standing up a
> separate local DHCP server on each subnet because L3 is not actually that
> complicated".
>
> I guess you can be grateful for the little wins !
>
> > To answer your questions:
> >
> > 1. yes, each distinct subnet has a distinct relay IP that is not reused
> by the other subnets
> > 2. yes, all of the relay IPs are part of a specific subnet (iirc it's a
> /21 or /22), although I don't know if there's a pattern to how relay IPs
> are chosen (sequentially? randomly? stepwise? etc.) from this subnet
>
> OK, so some good news then.
>
> > And yes, there have been a lot of "interesting times" so far.
>
> I bet :-(
>
> > FWIW, this is the relevant section of my Kea4 config file:
> >
> > """
> > "shared-networks": [
> >   {
> > "name": "iad1",
> > "relay": {
> >   "ip-addresses": 
> > },
> > "subnet4": [
> >   
> > ]
> >   }
> > ],
> > """
>
> That’s not going to work. That says “all of the subnets, and all of the
> relay addresses, are in one big shared network. As I understand KEA config,
> you need :
> "shared-networks": [
>   {
> "name": “VLAN57",
> "subnet4": [
>   {
> "subnet": “192.168.120.66/32",
>   },
>   {
> "subnet": "192.0.57.0/24",
> "pools": [ { "pool":  "192.0.57.100 - 192.0.57.199" } ]
> "option-data": [
>   {
> "name": "routers",
> "data": "192.0.57.1"
>   } ]
>   }
> ]
>   },
>   {
> "name": “VLAN123",
> "subnet4": [
>   {
> "subnet": “192.168.120.250/32",
>   },
>   {
> "subnet": "192.0.123.0/24",
> "pools": [ { "pool":  "192.0.123.100 - 192.0.123.199" } ]
>   {
> "name": "routers",
> "data": "192.0.123.1"
>   } ]
>
>   }
> ]
>   }
>
> ],
>
> Yes, it’s going to be one right p.i.t.a. to manage.
> What that says is that if you receive a relayed packet from the subnet
> 192.168.120.66/32 then treat it as including clients from subnet
> 192.0.57.0/24 as well. Since there is no pool for the 192.168.120.66/32
> subnet, then only addresses from the 192.0.57.0/24 subnet will get
> considered for offering to the client. In the general case you can have
> multiple subnets for clients within the shared network - and the server
> will consider them as all equal in terms of what can be handed out to
> clients.
>
> From memory, I think you mentioned that all devices have static address
> reservations, in which case you’ll need to adapt the subnet declarations,
> so :
>   {
> "subnet": "192.0.57.0/24",
> "pools": [ { "pool":  "192.0.57.100 - 192.0.57.199" } ]
> "option-data": [
>   {
> "name": "routers",
> "data": "192.0.

Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Hello Darren,

Could you elaborate a bit on what you mean? We are already using the
shared-networks configuration pattern, although in our use case, relay IPs
are scoped to all subnets, not specifically assigned to each subnet
individually. Here's the relevant section of our Kea config file:

"""
"shared-networks": [
  {
"name": "iad1",
"relay": {
  "ip-addresses": 
},
"subnet4": [
  
]
  }
],
"""

and the kea-relay4.json file is just a JSON list of /32 IPs that are used
to forward DHCPREQUEST packets from prospective client machines, and the
kea-pool4.json file looks something like this:

"""
...
{
"id": ,
"option-data": [{"data": "192.168.167.129", "name": "routers"}],
"pools": [{"pool": "192.168.167.139-192.168.167.254"}],
"subnet": "192.168.167.128/25"
},
{
"id": ,
"option-data": [{"data": "192.168.164.1", "name": "routers"}],
"pools": [{"pool": "192.168.164.11-192.168.164.254"}],
"subnet": "192.168.164.0/24"
},
{
"id": ,
"option-data": [{"data": "192.168.182.1", "name": "routers"}],
"pools": [{"pool": "192.168.182.11-192.168.183.254"}],
"subnet": "192.168.182.0/23"
},
...
""""

I'm hoping that's a bit more informative than what I fear may have involved
a bit of word salad from me.

cheers,
Klaus

On Fri, Feb 24, 2023 at 4:49 AM Darren Ankney 
wrote:

> Klaus,
>
> If your relays fallin a known CIDR per subnet(s) in a shared network,
> then you can add a "subnet" to the shared network with no pool that is
> just for the relays and dispense with the relays parameter.  It
> doesn't even have to be a real subnet.  example:
>
> Network "A" is 10.1.2.0/24 and 10.1.3.0/24 and relays will be between
> 192.0.2.1 - 192.0.2.254 even though the relay subnet is actually
> 192.0.0.0/21
>
> You could add a "subnet" in your shared network for Network "A" that
> has 192.0.2.0/24 even though that is not really a subnet configured on
> your network.
>
> That assumes some rhyme or reason to the allocation of relay IP
> addresses by your network people.
>
> On Fri, Feb 24, 2023 at 7:12 AM Klaus Steden  wrote:
> >
> >
> > Hi Darren,
> >
> > Correct, I am currently listing all relay IPs individually. It seems to
> be the case that by using the shared-network parameter and defining my DHCP
> pools within that context that I only have to include the list of relays
> once, and then requests from any of these relay IPs are processed correctly
> for every pool.
> >
> > But ... it's still a static list of relays that requires making updates
> that we're not always informed of -- hence the desire to use range or CIDR
> prefix notation -- as the only thing that is known for sure is that future
> relay IPs will always be found only on specific subnets within our network.
> >
> > I think I should also mention as additional context that each device is
> given a static IP which is unchanged over the lifetime of the hardware;
> it's a large data center environment where dynamic address assignments
> would wreak havoc, so IPs in the pool are never offered to more than one
> MAC address.
> >
> > cheers,
> > Klaus
> >
> >
> > On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney 
> wrote:
> >>
> >> Klaus,
> >>
> >> Then my proposed solution will not work (assuming there is only one
> >> subnet for the relay agent source ip).  It seems that you will need to
> >> list each address anyway since they could be all over the place?
> >> Hypothetical example:
> >>
> >> relay 10.1.2.1 might be a relay source for network "A"
> >> relay 10.1.2.2 might be a relay source for network "B"
> >> relay 10.1.2.3 might be a relay source for network "A"
> >>
> >> On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden 
> wrote:
> >> >
> >> >
> >> > Correct.
> >> >
> >> > Hypothetical networks "A" and "B" do not share a broadcast domain.
> >> >
> >> > cheers,
> >> > Klaus
> >> >
> >> > On Thu, Feb 23, 2023 at 2:57 AM Darren Ankney <
> darren.ank...@gmail.com> wrote:
> >> >>
> >>

Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Hello Simon,

Unfortunately, while my team has argued that this is, in fact, bad network
design ... that fell on deaf ears, so we're stuck with this design for the
foreseeable future, and "having to manually configure something" seems to
me to be a feature, not a bug, in the eyes of management. We got rolled up
into a larger org as the result of a merger, so it's been an uphill battle
just to push for basic changes like "let's use one DHCP server for multiple
subnets instead of standing up a separate local DHCP server on each subnet
because L3 is not actually that complicated". But I digress.

To answer your questions:

1. yes, each distinct subnet has a distinct relay IP that is not reused by
the other subnets
2. yes, all of the relay IPs are part of a specific subnet (iirc it's a /21
or /22), although I don't know if there's a pattern to how relay IPs are
chosen (sequentially? randomly? stepwise? etc.) from this subnet

And yes, there have been a lot of "interesting times" so far.

FWIW, this is the relevant section of my Kea4 config file:

"""
"shared-networks": [
  {
"name": "iad1",
"relay": {
  "ip-addresses": 
},
"subnet4": [
  
]
  }
],
"""

The kea-relay4.json file is just a JSON list of unicast (/32) IPs that are
used to relay DHCP requests (I posted it up-thread a few back), and the
kea-pool4.json file contains only a series of bog-standard scope
definitions like these:

"""
...
{
"id": ,
"option-data": [{"data": "192.168.167.129", "name": "routers"}],
"pools": [{"pool": "192.168.167.139-192.168.167.254"}],
"subnet": "192.168.167.128/25"
},
{
"id": ,
"option-data": [{"data": "192.168.164.1", "name": "routers"}],
"pools": [{"pool": "192.168.164.11-192.168.164.254"}],
"subnet": "192.168.164.0/24"
},
{
"id": ,
"option-data": [{"data": "192.168.182.1", "name": "routers"}],
"pools": [{"pool": "192.168.182.11-192.168.183.254"}],
"subnet": "192.168.182.0/23"
},
...
"""

I'll cop to not entirely understanding all of the nuances of the
shared-networks approach yet -- this is what we were able to make work in
the time we had available to make it work -- but I'm completely on board
with any suggestions or recommendations for improvement.

cheers,
Klaus

On Mon, Feb 27, 2023 at 11:26 AM Simon  wrote:

> Klaus Steden  wrote:
>
> > FWIW, my team had no input into the network design process, we just got
> saddled with a bespoke implementation and have been adapting as we go.
>
> Ah, the joys of inheriting someone else’s “bright idea”.
>
> > This is the basic model:
> >
> > - an instance of Kea behind a single unicast IP handles all DHCP for the
> entire physical site
> > - each switch is configured to use this same unicast IP as its DHCP
> helper address
> > - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
>
> So far, so good.
>
> > - each VXLAN uses a distinct relay address to forward DHCP requests to
> the helper IP
> > - each relay address is in a subnet reserved specifically just for relay
> addresses
>
> At this point I would argue that the network design is broken.
> The expectation is that each relay agent should use a unicast address from
> a subnet in which the served clients reside. If this is done, then
> allocation happens “automagically” as the server will automatically
> associate the relay address with the subnet(s) served (or more accurately,
> the broadcast domain containing those subnets).
> The way they’ve done it, you need to “do something” manually with the
> config in order to associate relay address with client network.
>
> Questions:
> Are distinct IP addresses associated with each client network ? I.e., each
> relay address is used for only one client network, and there is no
> duplication ?
> Is there a pattern to this, e.g. a /27 range used for each client network,
> or are random single addresses used ?
>
> What I’m thinking is that you could define a shared-network containing the
> client subnet(s) and the allowed relay addresses for each of the VLANs.
> That will automatically associate clients to the correct network for
> picking up network specific options (e.g. router address(es)). That’s going
> to be simpler if you can use (e.g.) 192.168.120.16/28 than if you need to
> use multiple

Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Hi Darren,

Correct, I am currently listing all relay IPs individually. It seems to be
the case that by using the shared-network parameter and defining my DHCP
pools within that context that I only have to include the list of relays
once, and then requests from any of these relay IPs are processed correctly
for every pool.

But ... it's still a static list of relays that requires making updates
that we're not always informed of -- hence the desire to use range or CIDR
prefix notation -- as the only thing that is known for sure is that future
relay IPs will always be found only on specific subnets within our network.

I think I should also mention as additional context that each device is
given a static IP which is unchanged over the lifetime of the hardware;
it's a large data center environment where dynamic address assignments
would wreak havoc, so IPs in the pool are never offered to more than one
MAC address.

cheers,
Klaus


On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney 
wrote:

> Klaus,
>
> Then my proposed solution will not work (assuming there is only one
> subnet for the relay agent source ip).  It seems that you will need to
> list each address anyway since they could be all over the place?
> Hypothetical example:
>
> relay 10.1.2.1 might be a relay source for network "A"
> relay 10.1.2.2 might be a relay source for network "B"
> relay 10.1.2.3 might be a relay source for network "A"
>
> On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden  wrote:
> >
> >
> > Correct.
> >
> > Hypothetical networks "A" and "B" do not share a broadcast domain.
> >
> > cheers,
> > Klaus
> >
> > On Thu, Feb 23, 2023 at 2:57 AM Darren Ankney 
> wrote:
> >>
> >> Hi Klaus,
> >>
> >> So to be clear (with a hypothetical example), 192.168.120.16 might
> >> need to serve distinct network "A" with one or more subnets and
> >> 192.168.120.17 might need to serve distinct network "B" with other
> >> subnets.  These "distinct" networks do not share the same broadcast
> >> domain?
> >>
> >> On Wed, Feb 22, 2023 at 8:07 PM Klaus Steden 
> wrote:
> >> >
> >> >
> >> > Hello all,
> >> >
> >> > Thanks for the responses, and sorry for the ambiguity in my original
> question, so I'll try to clarify. FWIW, my team had no input into the
> network design process, we just got saddled with a bespoke implementation
> and have been adapting as we go.
> >> >
> >> > This is the basic model:
> >> >
> >> > - an instance of Kea behind a single unicast IP handles all DHCP for
> the entire physical site
> >> > - each switch is configured to use this same unicast IP as its DHCP
> helper address
> >> > - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
> >> > - each VXLAN uses a distinct relay address to forward DHCP requests
> to the helper IP
> >> > - each relay address is in a subnet reserved specifically just for
> relay addresses
> >> >
> >> > We're already using the  macro to manage the existing
> (and growing) list of relay IPs, but what I'm really looking for is to be
> able to use CIDR notation or Kea range notation instead of using individual
> IPs, e.g., this is what the relays list looks like right now:
> >> >
> >> > """
> >> > ["192.168.120.16", "192.168.120.17", "192.168.120.18",
> "192.168.120.19", "192.168.120.20", "192.168.120.21", "192.168.120.22",
> "192.168.120.23", "192.168.120.232", "192.168.120.233", "192.168.120.234",
> "192.168.120.235", "192.168.120.236", "192.168.120.237", "192.168.120.238",
> "192.168.120.239", "192.168.120.240", "192.168.120.241", "192.168.120.242",
> "192.168.120.243", "192.168.120.244", "192.168.120.245", "192.168.120.246",
> "192.168.152.18", "192.168.152.19", "192.168.152.20", "192.168.152.21",
> "192.168.152.22", "192.168.152.23", "192.168.152.24", "192.168.152.25",
> "192.168.152.26", "192.168.152.27", "192.168.152.28", "192.168.152.29",
> "192.168.184.18", "192.168.184.19", "192.168.184.20", "192.168.184.21",
> "192.168.184.22", "192.168.184.23", "192.168.216.16", "192.168.216.17",
> &q

Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Correct.

Hypothetical networks "A" and "B" do not share a broadcast domain.

cheers,
Klaus

On Thu, Feb 23, 2023 at 2:57 AM Darren Ankney 
wrote:

> Hi Klaus,
>
> So to be clear (with a hypothetical example), 192.168.120.16 might
> need to serve distinct network "A" with one or more subnets and
> 192.168.120.17 might need to serve distinct network "B" with other
> subnets.  These "distinct" networks do not share the same broadcast
> domain?
>
> On Wed, Feb 22, 2023 at 8:07 PM Klaus Steden  wrote:
> >
> >
> > Hello all,
> >
> > Thanks for the responses, and sorry for the ambiguity in my original
> question, so I'll try to clarify. FWIW, my team had no input into the
> network design process, we just got saddled with a bespoke implementation
> and have been adapting as we go.
> >
> > This is the basic model:
> >
> > - an instance of Kea behind a single unicast IP handles all DHCP for the
> entire physical site
> > - each switch is configured to use this same unicast IP as its DHCP
> helper address
> > - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
> > - each VXLAN uses a distinct relay address to forward DHCP requests to
> the helper IP
> > - each relay address is in a subnet reserved specifically just for relay
> addresses
> >
> > We're already using the  macro to manage the existing (and
> growing) list of relay IPs, but what I'm really looking for is to be able
> to use CIDR notation or Kea range notation instead of using individual IPs,
> e.g., this is what the relays list looks like right now:
> >
> > """
> > ["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19",
> "192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23",
> "192.168.120.232", "192.168.120.233", "192.168.120.234", "192.168.120.235",
> "192.168.120.236", "192.168.120.237", "192.168.120.238", "192.168.120.239",
> "192.168.120.240", "192.168.120.241", "192.168.120.242", "192.168.120.243",
> "192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18",
> "192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22",
> "192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26",
> "192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18",
> "192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22",
> "192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18",
> "192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16",
> "192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20",
> "192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24",
> "192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28",
> "192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32",
> "192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36",
> "192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40",
> "192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"]
> > """
> >
> > and what I would love to do instead is write that as this:
> >
> > """
> > ["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", "
> 192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"]
> > """
> >
> > or perhaps more accurately as this:
> >
> > """
> > ["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62",
> "192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126",
> "192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"]
> > """
> >
> > The driver here is that it's been difficult to maintain the list of
> individual IPs because we're not kept in the loop when a new relay IP gets
> allocated, a

Re: [Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Hello all,

Thanks for the responses, and sorry for the ambiguity in my original
question, so I'll try to clarify. FWIW, my team had no input into the
network design process, we just got saddled with a bespoke implementation
and have been adapting as we go.

This is the basic model:

- an instance of Kea behind a single unicast IP handles all DHCP for the
entire physical site
- each switch is configured to use this same unicast IP as its DHCP helper
address
- the site has multiple distinct networks distributed across multiple
switches via VXLAN
- each VXLAN uses a distinct relay address to forward DHCP requests to the
helper IP
- each relay address is in a subnet reserved specifically just for relay
addresses

We're already using the  macro to manage the existing (and
growing) list of relay IPs, but what I'm really looking for is to be able
to use CIDR notation or Kea range notation instead of using individual IPs,
e.g., this is what the relays list looks like right now:

"""
["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19",
"192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23",
"192.168.120.232", "192.168.120.233", "192.168.120.234", "192.168.120.235",
"192.168.120.236", "192.168.120.237", "192.168.120.238", "192.168.120.239",
"192.168.120.240", "192.168.120.241", "192.168.120.242", "192.168.120.243",
"192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18",
"192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22",
"192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26",
"192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18",
"192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22",
"192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18",
"192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16",
"192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20",
"192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24",
"192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28",
"192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32",
"192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36",
"192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40",
"192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"]
"""

and what I would love to do instead is write that as this:

"""
["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", "
192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"]
"""

or perhaps more accurately as this:

"""
["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62",
"192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126",
"192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"]
"""

The driver here is that it's been difficult to maintain the list of
individual IPs because we're not kept in the loop when a new relay IP gets
allocated, and the only solid info I can squeeze out of our network team is
the subnets they've set aside specifically for relay IP addresses.

So I figured that if I could use address ranges in the relays list instead
of individual IPs then I don't have to update the relays file as frequently
and DHCP is less likely to not offer an IP because the incoming relay
address is currently unknown.

I hope this adds a bit more context to my original question!

thanks,
Klaus


On Wed, Feb 22, 2023 at 6:32 AM Simon  wrote:

> Darren Ankney  wrote:
>
> > In addition to what Peter said, another option would be to use shared
> > networks and add the subnet for relays along with the subnet of
> > addresses that you wish to allocate to the clients to a shared
> > network.  See:
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
> >
> > Example:
> >
> > {
> > "Dhcp4": {
> >"shared-networks": [
> >{
> >   "subnet4": [
> >   

[Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Klaus Steden]

Hi there,

In some of our environments, we deal with DHCP relays, and their addresses
seem to proliferate faster than we can update our configs, which leads to
delays with DHCP service.

However, they have reserved an entire /21 for relay IPs, and ideally, I
would like to be able to add that entire network as a relay instead of what
I'm currently doing, which is adding individual IPs when I notice them
reported in the log.

Is this even possible? The examples in the Kea documentation only mention
single addresses, but for big networks with lots of relays like ours, it
would be very helpful to be able to just add an entire range of IPs and
have Kea figure it out automatically.

thanks,
Klaus
-- 
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] Using DHCP Relays

[Klaus Steden]

This is what we added to our Kea configs to deal with the encapsulated
requests:


...
"option-def": [
  {
"name": "link",
"code": 150,
"space": "relay-cisco",
"type": "ipv4-address",
"record-types": "",
"array": false,
"encapsulate": ""
  },
  {
"name": "server-id",
"code": 152,
"space": "relay-cisco",
"type": "ipv4-address",
"record-types": "",
"array": false,
"encapsulate": ""
  }
 ],
...
"""

We're using UDP sockets and the shared-networks option, with the relays in
a separate file (as a JSON-formatted list):

"""
...
"shared-networks": [
  {
"name": "my-site-relays",
"relay": {
  "ip-addresses": 
},
"subnet4": [
  
]
  }
],
...
"""

Hopefully this is useful to you ...

cheers,
Klaus

On Sat, Jan 21, 2023 at 7:53 AM Simon  wrote:

> Stefan G. Weichinger  wrote:
>
> >> I will start by stopping one of my 2 kea-nodes, and then remove the
> VLAN interfaces on the remaining one. Plus enable the DHCP-relay, plus
> adding that fw-rule.
> >> In kea I have to remove the various vlan-interfaces and edit the
> subnets to all listen on the same and only LAN-interface.
> >
> > Did my changes but today there are no more workers on site there so it's
> a bit hard to test for me from remote.
> >
> > Went back to the old setup for now.
> >
> > questions around config:
> >
> > Could I remove the separate interface lines from the subnets:
> >
> >
> > {
> >   "interface": "enp0s31f6",  # THIS LINE
> >   "id": 3,
> >   "subnet": "192.168.103.0/24",
> >
> >
> > In the first lines I already have:
> >
> >
> > {
> >"Dhcp4": {
> >"interfaces-config": {
> >"interfaces": [ "enp0s31f6" ],
> >"dhcp-socket-type": "raw",
> >   "service-sockets-require-all": false,
> >   "service-sockets-max-retries": 1000,
> >   "service-sockets-retry-wait-time": 1
> >},
> >
> >
> > That defines the interface anyway, right?
>
> I think so, but I’m not a Kea user and have only had a fairly quick look
> at the documentation - most of the previous advice is based on relaying
> being generic and not really affecting server config much/at all.
> With dhcpd (where my experience is for about 25 years !), the only config
> for interfaces is to specify which ones to listen on.
>
> > "dhcp-socket-type" is ok? "raw" seems to be the default anyway.
>
>
> The manual at
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#interface-configuration
> says :
> > Kea supports responding to directly connected clients which do not have
> an address configured. This requires the server to inject the hardware
> address of the destination into the data-link layer of the packet being
> sent to the client. The DHCPv4 server uses raw sockets to achieve this, and
> builds the entire IP/UDP stack for the outgoing packets. The downside of
> raw socket use, however, is that incoming and outgoing packets bypass the
> firewalls (e.g. iptables).
>
>
> > Using UDP sockets automatically disables the reception of broadcast
> packets from directly connected clients. This effectively means that UDP
> sockets can be used for relayed traffic only. When using raw sockets, both
> the traffic from the directly connected clients and the relayed traffic are
> handled.
>
>
> So it’s clear that you want to keep raw sockets (default, no need to
> specify it) if you have any locally connected clients - but if you have no
> locally connected clients and want packets to pass through a firewall then
> use UDP.
>
>
> Also, looking at
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#dhcp4-subnet-selection
> it seems fairly clear that you don’t need to tie subnets to interfaces in
> the config - simply defining the interfaces to listen on, and the subnets
> to be served, is sufficient for the server to automagically associate
> clients with the right subnet.
>
>
> Simon
>
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

Re: [Kea-users] Kea System Requirements

[Klaus Steden]

Our largest environment serves about ~5700 clients and is an active-passive
pair of VMs with 2 vCPUs and 8 GB of vRAM using the MySQL backend.

The load average hovers around 0.00 on most days, although it's serving
predominantly bare metals in a data center and the default lease duration
is 120H.

cheers,
Klaus

On Wed, Jan 4, 2023 at 7:21 AM Eric Graham 
wrote:

> Running compiled Kea 2.2 in a Docker container that had one CPU and 500MB
> of memory, in a VM that had 4 vCPUs and 4GB of memory, allowed me to reach
> 1,700 lps with 3% drops using dhcperf on a second VM on the same host (and
> memfile backend). I'd recommend that as bare minimum specs. In production I
> would recommend much higher, to be safe. It really depends on your
> environment, hooks, other services running on the system, etc.
>
> *Eric Graham*
> *DevOps Specialist*
> Direct: 605.990.1859
> eric.gra...@vantagepnt.com 
>
> --
> *From:* Kea-users  on behalf of JT ISC <
> jtis...@gmail.com>
> *Sent:* Tuesday, January 3, 2023 7:20 PM
> *To:* kea-users@lists.isc.org 
> *Subject:* [Kea-users] Kea System Requirements
>
> *CAUTION:* This email originated outside the organization. Do not click
> any links or attachments unless you have verified the sender.
> What are the system requirements for Kea?
>
> 4 GB RAM and 100GB HD adequate?
>
> Thanks
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
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

[Klaus Steden]

FWIW we also primarily use Monit to keep tabs on the Kea daemons in our
environment. Because we're using MySQL backends, the Monit watchdog can
safely restart the daemon if it crashes or becomes unresponsive.

There is an external watchdog service we use to check the process table for
the daemon as well, but that sees almost no usage because Monit does the
job so well.

cheers,
Klaus

On Tue, Dec 27, 2022 at 12:42 PM Darren Ankney 
wrote:

> I had a thought regarding how you could implement some sort of monitoring
> solution for DHCPv6.  I don’t think you could implement a client but it
> should be possible to pretend to be a relay agent to perform a monitoring
> function for DHCPv6 like I described for DHCPv4.  I think that is the way
> that dhcperf functions depending on the options chosen…
>
> On Dec 27, 2022, at 3:35 PM, Eric Graham 
> wrote:
>
> One way to monitor is with Stork. It won't alert you, but it does have an
> API that collects events such as failure to communicate with a daemon using
> the Kea control agent, or HA state changed. One can poll that API and emit
> alerts based on the interesting events. Stork agents also have Prometheus
> built in, so you can have your Prometheus server send alerts on some
> conditions. For example, alert if a subnet is 80% full, 20% lower than
> average, has only been decreasing in count for x minutes, etc. (disclaimer,
> I haven't done this yet).
>
> I would be much more comfortable with an actual DHCP client, though, like
> Darren described. One could use dhcperf, or something like scapy. But I am
> also interested in a better monitoring solution.
>
> *Eric Graham*
> *DevOps Specialist*
> Direct: 605.990.1859
> eric.gra...@vantagepnt.com 
>
> **
> --
> *From:* Kea-users  on behalf of Stefan
> G. Weichinger 
> *Sent:* Tuesday, December 27, 2022 12:10 AM
> *To:* kea-users@lists.isc.org 
> *Subject:* [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.
>
> As I upgraded my isc-kea cluster to Debian 11.6 last week and rebooted
> the 2 nodes we noticed that initially there were no DHCP-leases offered
> until I restarted the isc-kea-dhcp4 service (on the primary node of the
> cluster).
>
> Maybe a one time issue, I don't know.
>
> -
>
> In consequence I´d like to monitor the DHCP-services somehow.
>
> I don't run a "real" monitoring like Nagios or Icinga at that site, but
> use "monit" for basic monitoring ...
>
> I added a check to monitor the isc-kea-dhcp4 service itself: does it
> run, does it behave, if not, restart it.
>
> And I added a check to monitor the timestamp of the leases file: if not
> changed for N minutes, alert me.
>
> That is very basic and not even fully OK IMO: the leases file gets
> rotated ... etc etc
>
> I browsed for a check tool and found "dhcping". So far I wasn't able to
> get a working reply out of that tool :-( ...
>
> How do you monitor Kea, are there any recommended ways of doing that?
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us athttps://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

Re: [Kea-users] Kea VM sizing ?

[Klaus Steden]

Our Kea solution is pretty lightweight:

2 VMs running Ubuntu 18
2 vCPUs per VM
8 GB vMEM (but using less than 4 GB)

DHCP VMs use hosted MySQL so neither VM runs a database process locally.

We're serving about 11K clients, load average hovers pretty close to zero
the whole time.

hth,
Klaus

On Tue, Apr 12, 2022 at 7:24 AM David Ramsey  wrote:

> Thank you for the feedback, folks, both on-list and off.
>
> Bjørn - your scenario very closely resembles what we plan to deploy -
> thank you for the detail.  I am impressed that you can serve 40k+ subs with
> only 2 vCPU and especially only 2GB RAM -- great news.
>
> --dmr
>
>
> On Tue, Apr 12, 2022 at 5:08 AM Bjørn Skovlund  wrote:
>
>> Hi David,
>>
>> We're running well over 40K customers on a set of HA KEA DHCP on 2 vCPU
>> and 2 GB memory, with MariaDB backend (placed on the VMs). Lease time is 1
>> hour and we can recover from outages.
>>
>> We're running Flex ID and forensic logs. CPU usage is averaging about 25%.
>>
>> Best, Bjørn
>>
>> On Fri, Apr 8, 2022 at 11:08 PM David Ramsey 
>> wrote:
>>
>>> Is there any virtual machine sizing data available for ISC Kea DHCP ?
>>>
>>> In particular I don't know how to spec out RAM and # vCPUs..
>>>
>>> I realize "it depends", of course, but are there any ballpark guides or
>>> formulas anywhere?
>>>
>>> Thanks, --David
>>> --
>>> 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] DHCP fingerprinting hook

[Klaus Steden]

This looks pretty cool, but if I can offer a suggestion, I would report the
options in a slightly different format (comma-separated perhaps?) to make
it easier to distinguish from a MAC address ... I did a bit of a
double-take when I looked at the sample log message in your GitHub README.

cheers,
Klaus

On Thu, Dec 9, 2021 at 10:20 PM Munroe Sollog  wrote:

> I finally found the time to dig into kea's code and dust off my very old
> C++ knowledge.  The result is this hook:
>
> https://github.com/mroe1234/DHCPfingerprintHook
>
> It adds a log line with the mac address and the specific option order a
> client requested.
>
> --
> Munroe Sollog (He/Him/His)
> Network Architect
> mun...@lehigh.edu
> ___
> 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] Leases storage format

[Klaus Steden]

The hwaddr field in MySQL is stored as hexadecimal.

You want to use HEX/UNHEX to convert between ASCII presentation and hex
encoding.

cheers,
Klaus

On Tue, Sep 7, 2021 at 4:19 AM  wrote:

> Hello.
> I have 1 question and one issue with storing leases information in mysql
> database in kea.
>
> The issue is that hwaddr field and client_id   field are in "strange"
> format.
> I enabled query log in mysql and in logs i found the following query from
> kea
>
> UPDATE lease4 SET address = 1682022402, hwaddr = '`▒\\', client_id =
> '`▒\\', valid_lifetime = 21600, expire = '2021-09-07 20:12:16', subnet_id =
> 2, fqdn_fwd = 0, fqdn_rev = 0, hostname = 'hg8247u', state = 0,
> user_context = NULL WHERE address = 1682022402 AND expire = '2021-09-07
> 18:52:56'
>
> So you can see " hwaddr = '`▒\\', client_id = '`▒\\' "
> Does someone faced same problem? How to fix it?
>
> Second part is question.
> Lease4 table have several fields. The question: is it possible to store
> additional information, like option 82, suboption 9?
> ___
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

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

[Klaus Steden]

My approach to this problem was to separate subnet definitions, via the
JSON file include mechanism, from the overall service configuration. The
service configuration doesn't change, so I just need to validate the
subnets file before updating, which can now be done in a hitless fashion.

So, +2 for includes!

cheers,
Klaus

On Fri, Aug 27, 2021 at 6:45 AM Veronique Lefebure <
veronique.lefeb...@cern.ch> wrote:

> YES :-)
>
> That's the work around. Thanks !!
>
> On 27/08/2021 15:42, Andrei Pavel wrote:
> > ip link add x type bridge
> ___
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
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] Can KEA CA Use TCP Socket Type

[Klaus Steden]

Yes: https://kea.readthedocs.io/en/kea-1.8.0/arm/agent.html

Although quickly skimming it looks like you'd probably want to bind it to
localhost and put an nginx reverse proxy in front of it to handle SSL
termination if you want to go the HTTPS route as the control agent does not
support this natively.

cheers,
Klaus

On Sun, May 23, 2021 at 6:37 AM Onur GURSOY 
wrote:

> Hello Everyone,
>
> KEA Control Agent (CA) is a very useful and well thought project.
> I wonder one thing!
> Can i use KEA Control Agent over TCP socket instead of Unix Socket?
> Is it possible ?
>
> Many thanks in advance,
> With best regards
> --
> Onur GÜRSOY
> R Engineer in Embedded Systems
> Master Student at Gebze Institute Of Technology
> Department Of Electronic Engineering
> GSM : 0(545) 764 7653
> e-mail: onurgursoyg...@gmail.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] KEA AND NETCONF IN A DOCKER

[Klaus Steden]

Honestly, I don't think this would be the most robust due to the way Docker
networking works. You will probably have more luck running Kea inside a
virtual machine that has raw socket access rather than a Docker container
that may or may not support raw socket passthrough.

I do not work for the Kea team, though, so they may say otherwise, but I've
been working with Docker a while and it can have some very curious network
behaviors.

cheers,
Klaus

On Tue, May 4, 2021 at 11:45 PM Onur GURSOY 
wrote:

> Hello Folks,
>
> First, I have to say: KEA is a great solution.
> I used isc-dhcp but KEA is more modern than isc-dhcp.
>
> So Nowadays,
> I'm working on dhcp which can be controlled over netconf.
> In this case, I've noticed that kea is on the stage.
> As far as i know, KEA supports netconf and sysrepo.
> But i couldn't see official docker support?
>
> I want to execute KEA on a docker container
> and
> I want to execute SYSREPO on a different docker container
> and
> I want to configure KEA over netconf.
>
> How can I do this ?
> Is there any official guideline ?
> or Is it possibly ?
>
> By the way, Is it possible to build KEA on a docker container?
> Again Is there any official guideline ?
>
> Many thanks in advance,
> Have nice and healthy day,
> With best regards.
>
> --
> Onur GÜRSOY
> R Engineer in Embedded Systems
> Master Student at Gebze Institute Of Technology
> Department Of Electronic Engineering
> GSM : 0(545) 764 7653
> e-mail: onurgursoyg...@gmail.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] Lease same IP for same MAC

[Klaus Steden]

Honestly, this is arguably the cleanest and most stable solution to this
particular problem.

>From my own experience with a variety of DHCP clients (Linux bare metal,
Linux/Windows VMs, PXE, iPXE, and a variety of IPMI controllers), you are
likely to run into a lot of variability with client behavior from the
different DHCP clients. We couple our Kea service with a managed iPXE
implementation, and early on, had to resort to using the iPXE variant that
provided lease persistence (see
https://forum.ipxe.org/showthread.php?tid=6989) in order to ensure that a
given lease was reused by Linux after the PXE environment had successfully
bootstrapped the installer. I don't think that's in play here, but I think
it's germane to a conversation about Packer playing fast and loose with
lease information.

If you have any kind of IPAM solution in place, you can leverage it to
manage the reserved MAC/IP information, and if you end up needing to build
more templates later on, it eliminates a lot of ambiguity and confusion to
do things in this manner. We're up to half a dozen weekly OVF builds
leveraging this approach and they're reliable like clockwork.

cheers,
Klaus


On Sun, Dec 27, 2020 at 1:56 PM Roland Berger 
wrote:

> Hi Klaus
>
> I just did it like you say and it worked. I don't like the solution
> because it is more work but for now its ok.
> In the packer vsphere-iso builder
> https://www.packer.io/docs/builders/vsphere-iso.html I configured the
> 'mac_address' according to this information
> https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-ADFECCE5-19E7-4A81-B706-171E279ACBCD.html
> and then configured a reservation in kea.
>
> If somebody has a cleaner solution please let us know.
>
> Best Roland
>
> [image: www.exasoft.ch] <http://www.exasoft.ch>
> On 12/27/20 9:59 PM, Klaus Steden wrote:
>
>
> I've got a similar workflow set up but I use VMware's *dcli* module to
> create my instance, which also allows me to explicitly set the MAC address
> (and thus force reservations).
>
> Looking at the Packer docs (
> https://www.packer.io/docs/builders/vsphere-iso.html) you may be able to
> do this as well by defining the Network Adapter before starting the
> instance, and use a reservation in Kea to fix the IP.
>
> hth,
> Klaus
>
> On Sun, Dec 27, 2020 at 10:40 AM Roland Berger 
> wrote:
>
>> Hi John
>>
>> Thanks. Packer is a tool to automatically bring up and configure a
>> virtual machine for the first time. It is like installing, for example an
>> ubuntu, machine from an iso image: The installer runs and after completion
>> the new machine makes a reboot and you can continue to configure the new
>> machine. So, I do not know the MAC address in advance to make a
>> reservation.
>>
>> The challenge I think I face is to make sure that the IP address after
>> the reboot is the same like during first power up when the os installer is
>> running.
>> I think I have to create a configuration where kea issues the same IP for
>> the above scenario. I tried this to make sure that the MAC address and the
>> hostname are the same. I also configured networking of the new machine to
>> send 'dhcp-identifier: mac'. But that is obviously not enough.
>>
>> Thanks to your answer I see the following things I can try. But may be
>> you have even a better, simpler idea.
>> - Create a MAC address by hand and make a reservation
>> - Try to play around with the lease time for the first DHCP request.
>> - Use static IP but in this case I don't want to do that if I can avoid
>> it.
>> - Configure kea to use only "host-reservation-identifiers":
>> ["hw-address"] but not sure if this would help.
>>
>> Best Roland
>>
>> 192.168.178.*251*,00:50:56:92:07:82,01:00:50:56:92:07:82,0   
>> ,1609062019,1,1,1,ubuntu-server,0,
>> 192.168.178.*252*,00:50:56:92:07:82,01:00:50:56:92:07:82,4000,1609066573,1,1,1,ubuntu-server,0,
>>
>>
>>
>> [image: www.exasoft.ch] <http://www.exasoft.ch>
>> On 12/27/20 12:06 PM, Gibbins, John (IM, Black Mountain) wrote:
>>
>> Hi Roland,
>>
>> If the client does not request the same IP as it had before you probably 
>> need to assign a fixed IP to the device.
>>
>> I'm assuming you have a config which includes your subnet.  Something like:
>> ...
>> "subnet4": [
>>   {
>> "subnet": "192.168.178.0/24",
>> ...
>>   }
>> ]
>> ...
>>
>> To ensure that you always get the same IP you need to create a reservation 
>> which maps the MAC to the desired IP.  Such as:
>> ...
>&

Re: [Kea-users] Lease same IP for same MAC

[Klaus Steden]

I've got a similar workflow set up but I use VMware's *dcli* module to
create my instance, which also allows me to explicitly set the MAC address
(and thus force reservations).

Looking at the Packer docs (
https://www.packer.io/docs/builders/vsphere-iso.html) you may be able to do
this as well by defining the Network Adapter before starting the instance,
and use a reservation in Kea to fix the IP.

hth,
Klaus

On Sun, Dec 27, 2020 at 10:40 AM Roland Berger 
wrote:

> Hi John
>
> Thanks. Packer is a tool to automatically bring up and configure a virtual
> machine for the first time. It is like installing, for example an ubuntu,
> machine from an iso image: The installer runs and after completion the new
> machine makes a reboot and you can continue to configure the new machine.
> So, I do not know the MAC address in advance to make a reservation.
>
> The challenge I think I face is to make sure that the IP address after the
> reboot is the same like during first power up when the os installer is
> running.
> I think I have to create a configuration where kea issues the same IP for
> the above scenario. I tried this to make sure that the MAC address and the
> hostname are the same. I also configured networking of the new machine to
> send 'dhcp-identifier: mac'. But that is obviously not enough.
>
> Thanks to your answer I see the following things I can try. But may be you
> have even a better, simpler idea.
> - Create a MAC address by hand and make a reservation
> - Try to play around with the lease time for the first DHCP request.
> - Use static IP but in this case I don't want to do that if I can avoid it.
> - Configure kea to use only "host-reservation-identifiers": ["hw-address"]
> but not sure if this would help.
>
> Best Roland
>
> 192.168.178.*251*,00:50:56:92:07:82,01:00:50:56:92:07:82,0   
> ,1609062019,1,1,1,ubuntu-server,0,
> 192.168.178.*252*,00:50:56:92:07:82,01:00:50:56:92:07:82,4000,1609066573,1,1,1,ubuntu-server,0,
>
>
>
> [image: www.exasoft.ch] 
> On 12/27/20 12:06 PM, Gibbins, John (IM, Black Mountain) wrote:
>
> Hi Roland,
>
> If the client does not request the same IP as it had before you probably need 
> to assign a fixed IP to the device.
>
> I'm assuming you have a config which includes your subnet.  Something like:
> ...
> "subnet4": [
>   {
> "subnet": "192.168.178.0/24",
> ...
>   }
> ]
> ...
>
> To ensure that you always get the same IP you need to create a reservation 
> which maps the MAC to the desired IP.  Such as:
> ...
> "subnet4": [
>   {
> "subnet": "192.168.178.0/24",
> ...
> "reservations": [
>   {
> "hw-address": "00:50:56:92:07:82",
> "ip-address": "192.168.178.251"
>   }
> ]
>   }
> ]
> ...
>
> You may want to check out the "reservation-mode" attribute if you have both 
> pools and reservations on the same subnet.
>
> Regards
> johng
> -Original Message-
> From: Kea-users  
>  On Behalf Of rondal
> Sent: Sunday, 27 December 2020 9:23 PM
> To: kea-users@lists.isc.org
> Subject: [Kea-users] Lease same IP for same MAC
>
> Hi, I try to deploy an ubuntu server to vsphere with packer. After
> installation has finished the machine reboots an gets an other IP address.
> Packer can not complete its work because it is still trying to connect to
> the old ip address.
>
> From the kea log I see the following:
>
> 192.168.178.*251*,00:50:56:92:07:82,01:00:50:56:92:07:82,0
> ,1609062019,1,1,1,ubuntu-server,0,
> 192.168.178.*252*,00:50:56:92:07:82,01:00:50:56:92:07:82,4000,1609066573,1,1,1,ubuntu-server,0,
>
> In the client I configure networking (netplan) with dhcp-identifier: mac
>
> - Any ideas how I can tell kea to lease the same ip, in this case *.251,
> again?
>
>
> Best Roland
>
>
>
> --
> Sent from: http://kea-users.7364.n8.nabble.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 
> listkea-us...@lists.isc.orghttps://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

Re: [Kea-users] Can't upgrade MySQL schema past v6.0

[Klaus Steden]

Responses inline below ...

On Mon, Aug 31, 2020 at 1:11 PM Tomek Mrugalski  wrote:

> On 27/08/2020 03:58, Klaus Steden wrote:
> > I'm not sure what to do, but I'm stuck. I was trying to switch over
> > to the ISC's 1.6 packages of everything, so after installing, I ran
> > through the database upgrade procedure but it only got from 5.0 to
> > 6.0.
> >
> > For some reason, the 6.0 to 7.0 upgrade keeps failing, so I can't
> > run the 1.6 software version.
> It would help if the "some reason" be a bit more specific. It looks like
> the first attempt to upgrade failed half-way with some parts of the
> schema being updated, but not all. The follow-up tries to run the update
> fails. I have no idea or suspicion why that would happen. The 7.0 schema
> was introduced long time ago and I don't remember specific complaints
> about it.
>
> > Anyone else run into this one? Any advice or things I can try to fix
> > this issue?
> You may try to run the schema update manually. Take a look at the 6.0 to
> 7.0 update script here:
>
>
> https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/share/database/scripts/mysql/upgrade_6.0_to_7.0.sh.in
>
> It should also be available in your system if you installed kea-admin:
> /usr/share/kea/scripts/mysql/upgrade_6.0_to_7.0.sh


Yup, I installed 1.6.3 from ISC's repo so the tools are there as expected
(I did experiment with different package versions -- 1.6.1, 1.6.2, 1.8.0,
etc. of the upgrade script to see if that made a difference, but it did
not; diffs indicate no changes between versions so I didn't expect anything
different, but I did still think it useful to rule that out as a
possibility.


>
> Copy the actual schema update (everything between < 19 and EOF in line 647) to a file and run this as a script in mysql
> and see what happens.
>

I wrangled someone from our database team, I will take a look at this with
his help and see what happens when we try that.


> Oh, and you did backup your DB before upgrading, right?
>
>
Unfortunately not with this one but this is just sandbox so it's not
valuable data regardless. I will make sure to do so with our production DBs
if they're not already backed up (I believe they are, but as part of a
larger SQL cluster backup process).

cheers,
Klaus
___
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] Can't upgrade MySQL schema past v6.0

[Klaus Steden]

Hello Vicky,

Yes, I did, but I thought I followed the instructions. I was starting from
v1.3, though, not v1.5, but I couldn't find any documentation about
upgrading from a version that old. I opened a bug report as well (
https://gitlab.isc.org/isc-projects/kea/-/issues/1401)

I notice that the link you sent discusses schema changes from v1.4 but I've
only ever used the MySQL backend here, so I'm quite stumped!

cheers,
Klaus

On Thu, Aug 27, 2020 at 11:00 AM Victoria Risk  wrote:

> Klaus,
>
>
> On Aug 26, 2020, at 6:58 PM, Klaus Steden  wrote:
>
>
> Hi there,
>
> I'm not sure what to do, but I'm stuck. I was trying to switch over to the
> ISC's 1.6 packages of everything, so after installing, I ran through the
> database upgrade procedure but it only got from 5.0 to 6.0.
>
>
> Did you see
> https://gitlab.isc.org/isc-projects/kea/-/wikis/migrating-to-kea-1.6?
>
> We changed quite a few things from 1.5 to 1.6 and the upgrade was more
> complicated.
>
> Vicky
>
___
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] Can't upgrade MySQL schema past v6.0

[Klaus Steden]

Hi there,

I'm not sure what to do, but I'm stuck. I was trying to switch over to the
ISC's 1.6 packages of everything, so after installing, I ran through the
database upgrade procedure but it only got from 5.0 to 6.0.

For some reason, the 6.0 to 7.0 upgrade keeps failing, so I can't run the
1.6 software version.

Anyone else run into this one? Any advice or things I can try to fix this
issue?

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

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

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

Re: [Kea-users] Kea Configuration Backend Example / Documentation

[Klaus Steden]

Hey Kenny,

I can't speak to the experience of using any of the native Kea methods, but
working with the MySQL API has proven effective for us; I would recommend
being extra cautious since whatever application method you use if you go
the MySQL route will have to deal with locking, consistency, etc. concerns
directly.

We were able to build what we needed by consulting the MySQL Kea schema
directly; it should get installed with the application (it's in kea-admin
if you're on Ubuntu/Debian). I found that to be enough for creating
programmatic tools for managing leases/reservations, options should be
reasonably straightforward as well.

cheers,
Klaus

On Mon, Aug 24, 2020 at 5:07 AM Kenny Unger  wrote:

> Klaus,
>
> Thank you very much for taking the time to respond to my inquiry. I would
> be very interested in the more technical aspects of your process flow. I
> have no problem setting up a separate source of truth in regards to the
> DHCP configuration data as long as I can actually get that data into Kea.
> This is where I'm struggling. Unless I'm mistaken, my only options for
> inputting DHCP subnet/scope/option data into Kea is via direct MySQL or via
> the cb_cmds premium hook library. Does anyone know of alternate methods? I
> have no problem utilizing direct MySQL. I'm currently stuck on how the
> option value data should be formatted in the dhcp4_options table. I
> somewhat feel like there's some documentation out there that I'm unable to
> find. There must be some guide for developers or automation engineers which
> describes which records and columns are required, how they're to be
> formatted, etc.
>
> I'd be happy for someone to tell me a simpler way of achieving this that
> I've overlooked! :)
>
> Thanks!
> Kenny
>
> On Sun, Aug 23, 2020 at 5:58 PM Klaus Steden  wrote:
>
>>
>> Hi there,
>>
>> We use MySQL as a backend for our Kea infrastructure, and at the time we
>> were doing application development, the hook libraries were all licensed
>> products and a lot of the other nice glue just didn't exist. Granted we
>> don't do anything terrible sophisitcated with our setup, but within our
>> environment, Kea itself is managed by the aforementioned application using
>> standard MySQL APIs; the configuration itself that Kea supports lives in
>> that application's database (VLAN info, subnet IDs, scopes, etc.) using
>> fairly basic but predictable rules, and the application has an HTTP
>> endpoint that will generate YAML of all our scopes that we then feed into
>> Salt states to manage the Kea config. It sounds maybe a bit more
>> complicated than it actually is, but the basic gist is:
>>
>> - scope information is managed by an in-house provisioning application
>> - said application generates configuration data that is loaded directly
>> into our configuration management pipeline
>> - said configuration management pipeline is used to keep our Kea servers
>> up to date
>> - said application supports API-driven management of lease/reservation
>> data directly in Kea via Python's MySQL API
>>
>> Granted, our use case is very specific -- we use Kea as more of a
>> programmatic resource for a general-purpose infrastructure provisioning
>> service -- but it's definitely done a lot of heavy lifting for us over the
>> last 2-3 years. I guess maybe what I'm saying is you may get where you want
>> to go using other approaches to managing DHCP as a service via Kea without
>> having to dive directly into its APIs, and while a separate information
>> source adds complexity, if you can script the interactions between it and
>> Kea, it's possible to end up with the results it sounds like you're looking
>> for.
>>
>> hth,
>> Klaus
>>
>> On Fri, Aug 21, 2020 at 11:08 AM KennyU05  wrote:
>>
>>> Hello,
>>>
>>> I'm attempting to build some in-house automation processes on top of
>>> Kea. It
>>> will utilize a MariaDB Galera database on the backend. As part of this
>>> tool,
>>> I will be required to insert configuration data directly into the Kea
>>> MySQL
>>> database. I've been frustratingly fumbling my way through creating the
>>> subnet, the pool, and all the associated links between the subnet and the
>>> server. Right now I'm trying to figure out how to create the options. We
>>> don't use anything non-standard. However, I'm having difficulty
>>> understanding what the requirements are for the dhcp4_options table. I've
>>> read through the ARM as well as the database creation script in source. I
>>> even dug into some of Kea's code to try to understand what it was looking
>>

[Kea-users] Kea + ZTP?

[Klaus Steden]

Hi there,

Has anyone done any work with ZTP-capable switches with Kea? Specifically
Arista, although Juniper supports ZTP as well. I did some proof of concept
stuff back in 2016 with I think v0.9.0 and EOS back then, and met with some
success, but we've finally circled back to it looking to integrate Kea DHCP
with Arista Cloudvision, but for the life of me, can't seem to get the
next-server handoff working (so switches never acquire a lease, and ZTP
never kicks off)

Any insights are welcome.

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

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

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

Re: [Kea-users] Kea Configuration Backend Example / Documentation

[Klaus Steden]

Hi there,

We use MySQL as a backend for our Kea infrastructure, and at the time we
were doing application development, the hook libraries were all licensed
products and a lot of the other nice glue just didn't exist. Granted we
don't do anything terrible sophisitcated with our setup, but within our
environment, Kea itself is managed by the aforementioned application using
standard MySQL APIs; the configuration itself that Kea supports lives in
that application's database (VLAN info, subnet IDs, scopes, etc.) using
fairly basic but predictable rules, and the application has an HTTP
endpoint that will generate YAML of all our scopes that we then feed into
Salt states to manage the Kea config. It sounds maybe a bit more
complicated than it actually is, but the basic gist is:

- scope information is managed by an in-house provisioning application
- said application generates configuration data that is loaded directly
into our configuration management pipeline
- said configuration management pipeline is used to keep our Kea servers up
to date
- said application supports API-driven management of lease/reservation data
directly in Kea via Python's MySQL API

Granted, our use case is very specific -- we use Kea as more of a
programmatic resource for a general-purpose infrastructure provisioning
service -- but it's definitely done a lot of heavy lifting for us over the
last 2-3 years. I guess maybe what I'm saying is you may get where you want
to go using other approaches to managing DHCP as a service via Kea without
having to dive directly into its APIs, and while a separate information
source adds complexity, if you can script the interactions between it and
Kea, it's possible to end up with the results it sounds like you're looking
for.

hth,
Klaus

On Fri, Aug 21, 2020 at 11:08 AM KennyU05  wrote:

> Hello,
>
> I'm attempting to build some in-house automation processes on top of Kea.
> It
> will utilize a MariaDB Galera database on the backend. As part of this
> tool,
> I will be required to insert configuration data directly into the Kea MySQL
> database. I've been frustratingly fumbling my way through creating the
> subnet, the pool, and all the associated links between the subnet and the
> server. Right now I'm trying to figure out how to create the options. We
> don't use anything non-standard. However, I'm having difficulty
> understanding what the requirements are for the dhcp4_options table. I've
> read through the ARM as well as the database creation script in source. I
> even dug into some of Kea's code to try to understand what it was looking
> for. Granted, I'm a SysAdmin by trade, so my coding abilities aren't as
> skilled as the Kea devs.
>
> What I'm hoping to find is more clear documentation or examples of a MySQL
> configuration backend that demonstrates the data required to have a fully
> functioning DHCP server. This could be as simple as a MySQL dump of a
> simple
> working database.
>
> I know that ISC probably wants to encourage people to use the cb_cmds
> subscriber-only hook, and I don't blame them. At the same time, if they
> want
> people to really switch away from the old ISC-DHCP implementation they
> should make Kea as easy to adopt as possible.
>
> If I can't get the Kea CB figured out, I'll just end up writing scripts to
> generate the old JSON configuration files based of a database of my own
> creation.
>
> Any help or insight from people who have gone through this struggle would
> be
> greatly appreciated!
>
> Thanks!
> Kenny
>
>
>
> --
> Sent from: http://kea-users.7364.n8.nabble.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] Subnet name or description

[Klaus Steden]

You can also use one of the many unused DHCP options for this. IIRC we used
option 245 in our environment (clients ignore it by default, so it's really
just for information purposes for humans).

cheers,
Klaus

On Thu, Jul 2, 2020 at 1:37 PM Francis Dupont  wrote:

> > In Kea 1.6.2 how do I set a name or description to a subnet?
>
> => use a comment or user-context comment entry. At the opposite of
> #, // and /**/ comments, user contexts and comments (which are
> syntactic sugar for comment entries in user contexts) are saved
> in subject objects. This is true for a lot of other objects.
>
> Thanks
>
> Francis Dupont 
> ___
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

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

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

Re: [Kea-users] High availability setup

[Klaus Steden]

A number of different HA scenarios are covered in the Kea documentation:

https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/High-Availability-Design

cheers,
Klaus

On Fri, May 22, 2020 at 10:14 PM Software Info 
wrote:

> Hi All
> I am moving from ISC-DHCP which I have had running now for several
> years. It coexists with BIND 9 and Windows Domain Controllers. No
> issues. I have decided to migrate to Kea but I would like to have no
> single point of failure so I want to have a PostgreSQL backend with
> three Kea servers, two for Prod and one for DR. I also want the
> Postgresql server to replicate to a backup server. My question is, can
> I configure the two Kea servers to store lease and host data in a
> backup database server if the primary SQL Server is unavailable?
>
> If anyone has done this, I would love to see a sample config file.
> Thanks so much for any help.
>
> Best Regards,
> SI
> ___
> 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] Server deployments

[Klaus Steden]

We have a similar concern with our data centers and ended up rolling our
own app that handles this problem.

Basically, if you use a database backend, you can use the database API (in
our case, MySQL) to create/remove reservations and manage leases (although
generally we don't do this all that often).

AFAIK this is not the best practice recommended by the Kea engineering team
as there are hooks that can be exposed in the application to perform CRUD
operations on leases and reservations, but at the very least, I think that
you should definitely use a database backend to make managing this problem
easier, regardless of how you end up doing so.

hth,
Klaus

On Fri, Oct 25, 2019 at 12:37 AM Thomas Andersen  wrote:

> Hi,
>
>
>
> I’m a bit unsure how to obtain this and even more how to configure.
>
> So a few pointers would be appreciated.
>
>
>
> I have made a new subnet for servers. I’d like to use DHCP on this network
> as people never clean up after themselves when taking down servers, and
> also to ease deployment and configuration.
>
> But how do I get around the lease time and add the server to host
> reservations automatically.
>
> I don’t really care which IP the server get, as long as it’s static. The
> logic view for me is to copy a lease from the lease db to the host
> reservation db after first lease.
>
>
>
> I hope you understand what I’m trying explain.
>
>
>
> --
>
> Med venlig hilsen / With best regards
>
> Thomas Andersen
>
>
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Kea 1.6 Configuration Backend

[Klaus Steden]

You want something like this:

{

  "Dhcp4":

  {

...


# Use MySQL lease database backend to store leases in a database.

  "lease-database": {

"type": "mysql",

"host": "__MYSQL_HOST__",

"name": "__MYSQL_DB__",

"user": "__MYSQL_USER__",

"password": "__MYSQL_PASSWORD__"

  },


# Use MySQL hosts database backend to store reservations in a database.

  "hosts-database": {

"type": "mysql",

"host": "__MYSQL_HOST__",

"name": "__MYSQL_DB__",

"user": "__MYSQL_USER__",

"password": "__MYSQL_PASSWORD__"

  },

  ...

  }

}

where the tokens are whatever your SQL credential/database parameters are.

hth,
Klaus

On Wed, Sep 4, 2019 at 3:39 AM Marc Boisis  wrote:

>
> Where can I find where to put dhcp4 parameters in mysql configuration
> backend ? (which table ? values...).
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea hands out 2 ip addresses

[Klaus Steden]

On the outside chance you're using iPXE somewhere in your environment, I
had a very similar problem with some of our hardware where it would solicit
two separate leases by advertising two different hardware addresses (once
during PXE, and once at boot, if memory serves).

I was able to work around the issue by using the *kkpxe* bootloader, which
caches the initial lease request, thus avoiding making a second DHCPREQUEST
later on.

That might do the trick, if iPXE is part of your tool chain.

cheers,
Klaus

On Thu, Jul 11, 2019 at 4:08 AM eacool  wrote:

> I have made the suggested alterations to the conf file.
>
> However the same behaviour is happening, apologies if I have missed
> something simple but I think I have followed the manual correctly.  I have
> included a log snippet for the creation of a single machine which has 2 ip
> addresses incorrectly assigned to it in short succession.
>
> {
>   "Dhcp4": {
> "interfaces-config": {
>   "interfaces": [
> "*"
>   ],
>   "dhcp-socket-type": "raw"
> },
> "lease-database": {
>   "type": "mysql",
>   "name": "keadhcp",
>   "host": "10.172.0.30",
>   "user": "keadhcp",
>   "password": "password"
> },
> "expired-leases-processing": {
>   "reclaim-timer-wait-time": 10,
>   "flush-reclaimed-timer-wait-time": 25,
>   "hold-reclaimed-time": 360,
>   "max-reclaim-leases": 100,
>   "max-reclaim-time": 250,
>   "unwarned-reclaim-cycles": 5
> },
> "dhcp-ddns": {
>   "enable-updates": true,
>   "qualifying-suffix": "eu-ldn-west.compute.internal",
>   "replace-client-name": "always",
>   "generated-prefix": "ip"
> },
> "valid-lifetime": 300,
> *"host-reservation-identifiers": [ "hw-address" ],*
> "subnet4": [
>   {
> "subnet": "10.172.0.0/24",
> "pools": [
>   {
> "pool": "10.172.0.150 - 10.172.0.200"
>   }
> ],
> "option-data": [
>   {
> "name": "routers",
> "data": "10.172.0.1"
>   },
>   {
> "name": "domain-name-servers",
> "data": "10.172.0.42"
>   }
> ]
>   }
> ]
>   },
>  "Logging": {
>   "loggers": [
>   {
>   "name": "kea-dhcp4",
>   "output_options": [
>   {
>   "output": "/var/log/kea-dhcp4.log"
>   }
>   ],
>   "severity": "DEBUG",
>   "debuglevel": 99
>   }
>   ]
>   }
> }
>
> 
>
> 2019-07-11 11:06:16.291 DEBUG [kea-dhcp4.packets/33] DHCP4_BUFFER_RECEIVED
> received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface
> ens192
> 2019-07-11 11:06:16.292 DEBUG [kea-dhcp4.options/33] DHCP4_BUFFER_UNPACK
> parsing buffer received from 0.0.0.0 to 255.255.255.255 over interface
> ens192
> 2019-07-11 11:06:16.292 DEBUG [kea-dhcp4.dhcpsrv/33]
> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.172.0.0/24 for packet
> received by matching address 10.172.0.25
> 2019-07-11 11:06:16.293 DEBUG [kea-dhcp4.packets/33] DHCP4_SUBNET_SELECTED
> [hwtype=1 00:50:56:95:5c:e5],
> cid=[ff:2d:1a:a1:33:00:02:00:00:ab:11:f3:96:b3:e8:1c:16:57:29],
> tid=0xefbdc39a: the subnet with ID 1 was selected for client assignments
> 2019-07-11 11:06:16.293 DEBUG [kea-dhcp4.packets/33] DHCP4_SUBNET_DATA
> [hwtype=1 00:50:56:95:5c:e5],
> cid=[ff:2d:1a:a1:33:00:02:00:00:ab:11:f3:96:b3:e8:1c:16:57:29],
> tid=0xefbdc39a: the selected subnet details: 10.172.0.0/24
> 2019-07-11 11:06:16.293 DEBUG [kea-dhcp4.packets/33] DHCP4_PACKET_RECEIVED
> [hwtype=1 00:50:56:95:5c:e5],
> cid=[ff:2d:1a:a1:33:00:02:00:00:ab:11:f3:96:b3:e8:1c:16:57:29],
> tid=0xefbdc39a: DHCPDISCOVER (type 1) received from 0.0.0.0 to
> 255.255.255.255 on interface ens192
> 2019-07-11 11:06:16.294 DEBUG [kea-dhcp4.packets/33] DHCP4_QUERY_DATA
> [hwtype=1 00:50:56:95:5c:e5],
> cid=[ff:2d:1a:a1:33:00:02:00:00:ab:11:f3:96:b3:e8:1c:16:57:29],
> tid=0xefbdc39a, packet details: local_address=255.255.255.255:67,
> remote_address=0.0.0.0:68, msg_type=DHCPDISCOVER (1), transid=0xefbdc39a,
> options:
>   type=053, len=001: 1 (uint8)
>   type=055, len=009: 1(uint8) 3(uint8) 12(uint8) 15(uint8) 6(uint8)
> 26(uint8) 33(uint8) 121(uint8) 42(uint8)
>   type=057, len=002: 576 (uint16)
>   type=061, len=019:
> ff:2d:1a:a1:33:00:02:00:00:ab:11:f3:96:b3:e8:1c:16:57:29
> 2019-07-11 11:06:16.294 DEBUG [kea-dhcp4.dhcpsrv/33]
> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.172.0.0/24 for packet
> received by matching address 10.172.0.25
> 2019-07-11 11:06:16.294 DEBUG [kea-dhcp4.packets/33] DHCP4_SUBNET_SELECTED
> [hwtype=1 00:50:56:95:5c:e5],
> cid=[ff:2d:1a:a1:33:00:02:00:00:ab:11:f3:96:b3:e8:1c:16:57:29],
> tid=0xefbdc39a: the subnet with ID 1 was selected for client assignments
> 2019-07-11 11:06:16.295 DEBUG [kea-dhcp4.packets/33] DHCP4_SUBNET_DATA
> [hwtype=1 

Re: [Kea-users] Compilation of ISC DHCP code

[Klaus Steden]

You probably want the ISC DHCP mailing list, this list is for Kea DHCP,
which is a different product ...

hth,
Klaus

On Wed, Jun 19, 2019 at 3:04 PM Mayank Tiwari  wrote:

> Hi,
>
>   I am trying to compile ISC DHCP code as I want to use relay feature from
> it. When I compile the code from
> ftp://ftp.isc.org/isc/dhcp/4.4.1/dhcp-4.4.1.tar.gz link it works fine.
>
>   However, when I try to checkout the code from git and compile it fails.
> I check out the code from https://github.com/isc-projects/dhcp/tree/v4_4_1
>
>   Steps used for compilation:
> autoreconf -f -i
> ./configure
> make
> make install
>
>   The requirement is make code compilable from the code checked out of git.
>
>   The failure happens in configure step and the error is:
> "configure: error: Where to find or build bind includes and libraries must
> be specified'
>
>   When I compared the code and the compilation steps between working and
> non-working code I have observed that the bind folder is missing when I
> checkout the code from git. However, the code downloaded from ftp server
> has that folder.
>
> $ ls -lrt bind/ --> Code from ftp folder
> total 9576
> -rw-rw-r-- 1 mayank mayank4702 May 29 10:29 Makefile.in
> -rw-rw-r-- 1 mayank mayank 183 May 29 10:29 version.tmp
> -rw-rw-r-- 1 mayank mayank 9793066 May 29 10:29 bind.tar.gz
>
>  My query. What are different steps for compilation from the code checked
> out from git so that this bind related error does not come. Please provide
> any inputs or reference. Or is there any other way to integrate bind
> related code with the code checked out from git to make compilation work.
>
>   I am doing the compilation inside the alpine docker container. Here is
> the spec for it.
>
> FROM alpine:3.8
> RUN apk update && apk upgrade && apk add curl tar make gcc build-base wget
> gnupg && \
> apk add tcpdump libtool autoconf automake alpine-sdk libcap-dev
> openssl-dev --no-update && \
> apk add --no-cache bash libgcc git openssh
>
>
> RUN mkdir /isc
> RUN git clone --branch=v4_4_1 https://github.com/isc-projects/dhcp.git
> /isc
> WORKDIR /isc
>
>
>
> RUN autoreconf -f -i && \
> ./configure  && \
> make && \
> make install
>
>   Please let me know if there is any alpine package which I need to
> install to make it work so that the bind related error does not come. The
> same spec works fine for the code checked out from ftp server which has
> bind folder.
>
> Thanks and Regards,
> Mayank
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Subnet + mysql backend

[Klaus Steden]

Hi Carlos,

If I'm understanding your question correctly, yes, you have to keep all
this information in the configuration file, it doesn't live in the database.

We had a similar problem in our environment where we allocated separate
subnets to each rack, a problem we solved by generating synthetic scope IDs
using a checksum of a unique identifier for each DHCP scope, e.g.,
checksum("VLAN
100 rack 10") generates some unique number, while checksum("VLAN 50 rack
10") generates some other unique number, and then that number is the scope
ID for that subnet. We throw this in one of the reserved DHCP options --
clients ignore it, but it allows us to differentiate.

In your case, if you're doing one scope per host, you could use a similar
approach on the MAC address and get unique IDs that way; in our case, we
used this Python snippet:

return binascii.crc32(name) & 0x

which forces the results to be a positive number.

HTH,
Klaus

On Fri, Apr 5, 2019 at 6:20 AM Carlos Carluccio <
carlos.carluc...@totalserversolutions.com> wrote:

> Guys,
>
>
>
> I am trying to provision dhcp to have each computer its own subnet/gw/etc
> . Do I need to add each one on the config file? There is no way I can have
> all this inside the mysql backend?
>
>
>
>
>
>
>
> Carlos
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Hosts refusing lease offers?

[Klaus Steden]

... and it turns out our system integrator had the iDRAC interfaces set
to tag traffic, whereas our switches are configured for untagged traffic.
I'll throw myself out. :-)

thanks,
Klaus

On Fri, Feb 15, 2019 at 8:55 AM Klaus Steden  wrote:

>
> Thanks for the suggestions, I checked both of those, and it looks like
> we're already using valid-lifetime, renew-timer, and rebind-timer
> attributes already (12H, 4H, and 6H, respectively), and based on the flags
> I'm seeing in the bootp section of packet capture traffic, both client and
> server are talking unicast to each other (the client is actually being
> relayed by a switch, so the server wouldn't see any broadcast traffic from
> the client anyway).
>
> We're going to try a full power cycle next, as this hardware has been
> sitting in the data center for several weeks already trying to initialize,
> so maybe there's some weird state issue in play that we're not aware of.
>
> Still looking.
>
> cheers,
> Klaus
>
> On Fri, Feb 15, 2019 at 4:24 AM Thomas Andersen  wrote:
>
>> Hi,
>>
>>
>>
>> Another suggestion:
>>
>> Have you checked with wireshark what the request and offer is?
>>
>>
>>
>> We have had the same issue when it came to unicast and broadcast offers.
>>
>> If the host had broadcast flag set in discover, it would reject any
>> offers sent as unicast.
>>
>> Most clients do not differ on this, but PXE, UEFI, iDRAC and some
>> specific windows 7 installations CAN filter them if there is the slightest
>> mismatch.
>>
>>
>>
>> Kea 0.9 and 1.0 had default unicast response even though client asked for
>> broadcast. Was changed in 1.1 I think.
>>
>>
>>
>> Br,
>>
>> Thomas
>>
>>
>>
>> *From: *Kea-users  on behalf of Joelson
>> Vendramin 
>> *Date: *Friday, 15 February 2019 at 12.05
>> *To: *"KEA-Users (kea-users@lists.isc.org)" ,
>> Klaus Steden 
>> *Subject: *Re: [Kea-users] Hosts refusing lease offers?
>>
>>
>>
>> Hi Klaus,
>>
>>
>>
>> I remember a similar tricky situation. Some clients complaining about
>> leases offers.
>>
>>
>>
>> Then I find a strange solution: configuring KEA to send "renew-timer" and
>> "rebind-timer" optional parameters together with "valid-lifetime"
>> (mandatory).
>>
>>
>>
>> This way:
>>
>>   "valid-lifetime": X,
>>   "renew-timer": 50% * X,
>>   "rebind-timer": 87,5% * X,
>>
>> Hope this clue helps you someway.
>>
>>
>>
>> Regards,
>>
>> --
>>
>> Joelson Vendramin
>>
>>
>>
>>
>>
>> Em quinta-feira, 14 de fevereiro de 2019 22:36:38 BRST, Klaus Steden <
>> klausfi...@gmail.com> escreveu:
>>
>>
>>
>>
>>
>>
>>
>> Hi there,
>>
>>
>>
>> I've got a bit of a puzzler on my hands. We've racked some new gear and
>> are preparing to provision it.
>>
>>
>>
>> Scope definitions have been added to Kea, and are active.
>>
>>
>>
>> Hosts are on the network, and are generating DHCP requests.
>>
>>
>>
>> Kea is responding as expected and offering leases, but none of these
>> machines (6 racks worth) are accepting the offers, leaving them stranded.
>>
>>
>>
>> The hardware is Dell, so it's actually the iDRAC that's not leasing, but
>> a different batch of similar hardware in other racks (installed two weeks
>> ago) had no such issues.
>>
>>
>>
>> We're reasonably confident that it's not something on the switches, but
>> for the life of me I can't identify why these aren't accepting leases.
>>
>>
>>
>> I've attached a sample of the debug output in the log (cranked up to 99)
>> with only DNS info redacted.
>>
>>
>>
>> Again, the most confusing thing here is that a comparable platform in the
>> same data center in different racks had no issues, and the only change is
>> additional DHCP scopes.
>>
>>
>>
>> thanks,
>>
>> Klaus
>>
>> ___
>> Kea-users mailing list
>> Kea-users@lists.isc.org
>> 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] Hosts refusing lease offers?

[Klaus Steden]

Thanks for the suggestions, I checked both of those, and it looks like
we're already using valid-lifetime, renew-timer, and rebind-timer
attributes already (12H, 4H, and 6H, respectively), and based on the flags
I'm seeing in the bootp section of packet capture traffic, both client and
server are talking unicast to each other (the client is actually being
relayed by a switch, so the server wouldn't see any broadcast traffic from
the client anyway).

We're going to try a full power cycle next, as this hardware has been
sitting in the data center for several weeks already trying to initialize,
so maybe there's some weird state issue in play that we're not aware of.

Still looking.

cheers,
Klaus

On Fri, Feb 15, 2019 at 4:24 AM Thomas Andersen  wrote:

> Hi,
>
>
>
> Another suggestion:
>
> Have you checked with wireshark what the request and offer is?
>
>
>
> We have had the same issue when it came to unicast and broadcast offers.
>
> If the host had broadcast flag set in discover, it would reject any offers
> sent as unicast.
>
> Most clients do not differ on this, but PXE, UEFI, iDRAC and some specific
> windows 7 installations CAN filter them if there is the slightest mismatch.
>
>
>
> Kea 0.9 and 1.0 had default unicast response even though client asked for
> broadcast. Was changed in 1.1 I think.
>
>
>
> Br,
>
> Thomas
>
>
>
> *From: *Kea-users  on behalf of Joelson
> Vendramin 
> *Date: *Friday, 15 February 2019 at 12.05
> *To: *"KEA-Users (kea-users@lists.isc.org)" ,
> Klaus Steden 
> *Subject: *Re: [Kea-users] Hosts refusing lease offers?
>
>
>
> Hi Klaus,
>
>
>
> I remember a similar tricky situation. Some clients complaining about
> leases offers.
>
>
>
> Then I find a strange solution: configuring KEA to send "renew-timer" and
> "rebind-timer" optional parameters together with "valid-lifetime"
> (mandatory).
>
>
>
> This way:
>
>   "valid-lifetime": X,
>   "renew-timer": 50% * X,
>   "rebind-timer": 87,5% * X,
>
> Hope this clue helps you someway.
>
>
>
> Regards,
>
> --
>
> Joelson Vendramin
>
>
>
>
>
> Em quinta-feira, 14 de fevereiro de 2019 22:36:38 BRST, Klaus Steden <
> klausfi...@gmail.com> escreveu:
>
>
>
>
>
>
>
> Hi there,
>
>
>
> I've got a bit of a puzzler on my hands. We've racked some new gear and
> are preparing to provision it.
>
>
>
> Scope definitions have been added to Kea, and are active.
>
>
>
> Hosts are on the network, and are generating DHCP requests.
>
>
>
> Kea is responding as expected and offering leases, but none of these
> machines (6 racks worth) are accepting the offers, leaving them stranded.
>
>
>
> The hardware is Dell, so it's actually the iDRAC that's not leasing, but a
> different batch of similar hardware in other racks (installed two weeks
> ago) had no such issues.
>
>
>
> We're reasonably confident that it's not something on the switches, but
> for the life of me I can't identify why these aren't accepting leases.
>
>
>
> I've attached a sample of the debug output in the log (cranked up to 99)
> with only DNS info redacted.
>
>
>
> Again, the most confusing thing here is that a comparable platform in the
> same data center in different racks had no issues, and the only change is
> additional DHCP scopes.
>
>
>
> thanks,
>
> Klaus
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Hosts refusing lease offers?

[Klaus Steden]

Hi there,

I've got a bit of a puzzler on my hands. We've racked some new gear and are
preparing to provision it.

Scope definitions have been added to Kea, and are active.

Hosts are on the network, and are generating DHCP requests.

Kea is responding as expected and offering leases, but none of these
machines (6 racks worth) are accepting the offers, leaving them stranded.

The hardware is Dell, so it's actually the iDRAC that's not leasing, but a
different batch of similar hardware in other racks (installed two weeks
ago) had no such issues.

We're reasonably confident that it's not something on the switches, but for
the life of me I can't identify why these aren't accepting leases.

I've attached a sample of the debug output in the log (cranked up to 99)
with only DNS info redacted.

Again, the most confusing thing here is that a comparable platform in the
same data center in different racks had no issues, and the only change is
additional DHCP scopes.

thanks,
Klaus
2019-02-14 16:01:04.507 DEBUG [kea-dhcp4.dhcp4/1430] DHCP4_CLASS_ASSIGNED 
[hwtype=1 4c:d9:8f:00:e3:3a], cid=[01:4c:d9:8f:00:e3:3a], tid=0xeb9575f1: 
client packet has been assigned to the following class(es): VENDOR_CLASS_iDRAC
2019-02-14 16:01:04.507 DEBUG [kea-dhcp4.packets/1430] DHCP4_PACKET_RECEIVED 
[hwtype=1 4c:d9:8f:00:e3:3a], cid=[01:4c:d9:8f:00:e3:3a], tid=0xeb9575f1: 
DHCPDISCOVER (type 1) received from 10.164.160.131 to 10.17.1.11 on interface 
eth0
2019-02-14 16:01:04.507 DEBUG [kea-dhcp4.packets/1430] DHCP4_QUERY_DATA 
[hwtype=1 4c:d9:8f:00:e3:3a], cid=[01:4c:d9:8f:00:e3:3a], tid=0xeb9575f1, 
packet details: local_address=10.17.1.11:67, remote_adress=10.164.160.131:67, 
msg_type=DHCPDISCOVER (1), transid=0xeb9575f1,
options:
  type=012, len=013: "iDRAC-XXX" (string)
  type=053, len=001: 1 (uint8)
  type=055, len=009: 1(uint8) 3(uint8) 12(uint8) 15(uint8) 6(uint8) 42(uint8) 
33(uint8) 121(uint8) 43(uint8)
  type=057, len=002: 576 (uint16)
  type=060, len=005: "iDRAC" (string)
  type=061, len=007: 01:4c:d9:8f:00:e3:3a
2019-02-14 16:01:04.507 DEBUG [kea-dhcp4.dhcpsrv/1430] 
DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.164.160.128/26 for packet 
received by matching address 10.164.160.131
2019-02-14 16:01:04.507 DEBUG [kea-dhcp4.packets/1430] DHCP4_SUBNET_SELECTED 
[hwtype=1 4c:d9:8f:00:e3:3a], cid=[01:4c:d9:8f:00:e3:3a], tid=0xeb9575f1: the 
subnet with ID 36066044 was selected for client assignments
2019-02-14 16:01:04.507 DEBUG [kea-dhcp4.packets/1430] DHCP4_SUBNET_DATA 
[hwtype=1 4c:d9:8f:00:e3:3a], cid=[01:4c:d9:8f:00:e3:3a], tid=0xeb9575f1: the 
selected subnet details: 10.164.160.128/26
2019-02-14 16:01:04.508 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for 
subnet id 36066044, identified by hwaddr=4CD98F00E33A
2019-02-14 16:01:04.508 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: 
hwaddr=4CD98F00E33A
2019-02-14 16:01:04.508 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=4CD98F00E33A, found 
0 host(s)
2019-02-14 16:01:04.508 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 
36066044 and identifier hwaddr=4CD98F00E33A
2019-02-14 16:01:04.576 DEBUG [kea-dhcp4.ddns/1430] 
DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 4c:d9:8f:00:e3:3a], 
cid=[01:4c:d9:8f:00:e3:3a], tid=0xeb9575f1: processing client's Hostname option
2019-02-14 16:01:04.576 DEBUG [kea-dhcp4.dhcpsrv/1430] 
DHCPSRV_MYSQL_GET_SUBID_CLIENTID obtaining IPv4 lease for subnet ID 36066044 
and client ID 01:4c:d9:8f:00:e3:3a
2019-02-14 16:01:04.643 DEBUG [kea-dhcp4.dhcpsrv/1430] 
DHCPSRV_MYSQL_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID 36066044 and 
hardware address hwtype=1 4c:d9:8f:00:e3:3a
2019-02-14 16:01:04.711 DEBUG [kea-dhcp4.alloc-engine/1430] 
ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease 
to the client [hwtype=1 4c:d9:8f:00:e3:3a], cid=[01:4c:d9:8f:00:e3:3a], 
tid=0xeb9575f1
2019-02-14 16:01:04.711 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet 
id 36066044 and IPv4 address 10.164.160.148
2019-02-14 16:01:04.711 DEBUG [kea-dhcp4.hosts/1430] HOSTS_CFG_GET_ALL_ADDRESS4 
get all hosts with reservations for IPv4 address 10.164.160.148
2019-02-14 16:01:04.711 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.164.160.148, found 0 host(s)
2019-02-14 16:01:04.711 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 
36066044 and address 10.164.160.148
2019-02-14 16:01:04.712 DEBUG [kea-dhcp4.hosts/1430] 
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate source for host 
using subnet id 36066044 and address 10.164.160.148
2019-02-14 16:01:04.779 DEBUG [kea-dhcp4.dhcpsrv/1430] DHCPSRV_MYSQL_GET_ADDR4 
obtaining IPv4 lease for address 10.164.160.148
2019-02-14 

Re: [Kea-users] puppet & ldap to mysql

[Klaus Steden]

Hi Kristof,

We don't use Puppet, but we do use Salt to manage our Kea configurations.
Our usage is fairly tightly defined, however, as our scope definitions are
generated by an in-house IPAM application, so all the Salt state really
does is ensure the necessary software is in place and the configuration
files are kept up to date.

Not sure what kind of info you're looking for, but in our case, because
Salt supports data in YAML, we just generate subnet definitions in YAML and
they merge automagically into the existing configuration.

cheers,
Klaus

On Fri, Feb 8, 2019 at 2:43 AM Kristof Van Doorsselaere <
kristof.vandoorssela...@hogent.be> wrote:

> Dear Kea User list,
>
>
>
> I was planning to move from isc dhcpd to kea dhcp next summer, and have 2
> questions:
>
>
>
>1. We are currently using openldap as a backend (mac addresses need to
>be registered in our company for wired access and are stored in openldap):
>I’m willing to move away from openldap to mysql, but I was wondering are
>there any known migration guides available for this?
>
>
>
>
>
>1. Is anyone using puppet to automate the kea configuration, can’t
>find an existing module on puppet forge
>
>
>
>
>
> Thanks in Advance for your replies.
>
>
>
> Kristof
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] KEA MySQL Cluster

[Klaus Steden]

Hi Jordan,

You should be able to do a dump/restore from one database to the other when
you spin up the clustered ones. For separate tables, you should be able to
do this in stages, rather than migrating all your databases at once.

I would make sure your lease time is sufficiently long -- substantially
longer than your standard maintenance window duration -- as you will need
to also update your DHCP helper information on your switches, allow for DNS
propagation, etc., which will take more than you're likely to need to copy
data between databases.

cheers,
Klaus

On Tue, Dec 11, 2018 at 11:02 AM Jordan Tinsley 
wrote:

> Hello,
>
>
>
> I have a question.
>
>
>
> I currently have 2 Kea servers that run MySQL locally.  Each server
> contains subnet pools for 2 separate vLANS ( Server 1 – vLANs 1 & 2, Server
> 2 – vLANs 3 & 4).  In the future, I may build more Kea servers (such as
> each vLAN will have a couple servers for redundancy)  as well as build
> MySQL clusters for each vLAN and their servers.
>
>
>
> Is it possible to start off in this scenario and then add the databases to
> a cluster and retain some data from the databases from each vLAN?
>
>
>
> Or will I have to start over from scratch on database data when adding
> clusters?
>
>
>
> Never have setup a cluster nor redundant databases before.
>
>
>
> Thanks,
> Jordan
>
>
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea 1.3.0 dying with mysql error

[Klaus Steden]

This happens to us, too, using a shared MySQL backend for our
lease/reservation DBs.

I put Monit up on our Kea backends to automatically restart when it detects
that the process isn't running, and with a bit of tweaking, it's been
pretty bulletproof, with a bonus of handling other, unrelated crashes
(although I haven't really seen any of those).

cheers,
Klaus

On Mon, Jun 18, 2018 at 8:34 AM,  wrote:

> On 06/18/2018 05:03 AM, Satish Patel wrote:
> > Thanks you for comments, I told you half story, full story is we have
> two kea instance for HA and they are pointed to galera DB cluster for
> centralize Shared DB.
> >
> > Both node active and inserting records in cluster DB and everything
> works but every few hour node-2 kea is dying with mentioned error,
> everything same node dying. Node-1 never had any issue.
> >
> > Do you think this is clustering issue they both trying to do same thing
> and one of node dying? I have check network and every possible thing but
> nothing wrong there, also I have increase max_packet_size in db but no luck
> :(
> >
>
> I have galera cluster too and also observe routine cases of 'server has
> gone away' across sql apps, which is being dealt with by application
> layer checks to 'reconnect' to the db. Have not investigated the
> underlying cause other than tcpdump but I think this is squarely a
> galera / mysql issue.
>
> MIke-
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Best practice recommendation for reserving/blocking out VIPs?

[Klaus Steden]

Hi Francis,

Thanks for the feedback. Your first point seems like the best practice
implementation, although in practice just using a dummy MAC for a
blocked-out address will work well enough.

We manage reservations through an external application talking to MySQL
directly, and so don't store reservations in the config file itself.

cheers,
Klaus

On Fri, Jun 15, 2018 at 12:38 AM, Francis Dupont  wrote:

> I don't fully understand your problem but:
>  - the simplest is to not have addresses you want reserve in a pool
>
>  - using host reservations work too but with a performance penalty
>   (cf out-of-pool text in the doc) and with a hairy but handle case
>   if you change dynamically the config (cf conflict text in the doc).
>
> Note you do not need to use an existing MAC in a host reservation,
> the only constraint is to use a different MAC (or identifier in general)
> between host reservations.
>
> Regards
>
> Francis Dupont 
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Best practice recommendation for reserving/blocking out VIPs?

[Klaus Steden]

Hi everyone,

We had a new (for us) problem come up, and I wanted to poll the community
informally to see how everyone else has approached the issue.

We have a Windows cluster that uses L3 HA and passes a VIP back and forth
between two or more physical hosts.

To ensure that a Linux machine doesn't claim any of these addresses during
our standard provisioning procedure, we blocked out the IPs for these
physical hosts using reservations with the primary MACs of the machines
themselves, but we weren't sure what to do to then block out the VIP.

We settled on blocking out the VIP by creating a reservation using the MAC
address of an unused NIC on one of the physical machines, but that seems
like a bit of a kludge.

If you've had to deal with this problem out there in Kea-land, how did you
approach it?

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

Re: [Kea-users] feature request - status check

[Klaus Steden]

I use Monit to keep tabs on mine (and also make sure they stay running).

cheers,
Klaus

On Fri, Jun 8, 2018 at 7:24 AM, Owen Dunn  wrote:

> On Fri, 8 Jun 2018, itay cohen wrote:
>
> hi all
>>
>>
>> i want to check the availability of the kea-dhcp process with an external
>> program (via control agent).
>>
>> there is no "status-check" command.
>> so i tried "config-check" but its writing a log each time i use it ( every
>> 2 seconds. ).
>>
>> can you offer an idea ?
>>
>
> I use dhcping to check it can do DHCP,  gather statistics from it with
> statistic-get-all, and notify of recent ALLOC_ENGINE_V4_ALLOC_FAIL events
> from the log.
>
> Owen
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea http uefi boot

[Klaus Steden]

The UEFI section of my DHCP config looks like this:

{
  "name": "bootstrap-efi",
  "test": "substring(option[60].hex, 0, 20) == 'PXEClient:Arch:7'",
  "option-data": [
{
  "name": "boot-file-name",
  "data": "ipxe/snponly.efi"
},
{
  "name": "domain-name-servers",
  "data": "$nameserver1, $nameserver2"
}
  ]
}

My embedded IPXE script (used when building *snponly.efi)* looks like this:

#!ipxe

goto boot_${platform} ||
shell

:boot_efi
dhcp || goto failed_dhcp
chain ${bootstrap_server}/${net0/mac} || goto failed_chain

:failed_dhcp
echo DHCP configuration failed, dropping to iPXE shell
shell
exit

:failed_chain
echo Chain loading failed, dropping to iPXE shell
shell
exit

The actual boot stanza looks a bit like this:

#!ipxe
set base_url $bootstrap_server

kernel ${base_url}/linux
initrd ${base_url}/initrd.gz

imgargs linux noapic acpi=off auto=true fb=false ip=dhcp
ipv6.disable=1 interface=eth0 biosdevname=0 init=/init root=/dev/ram0
rdshell url=${base_url}/preseed/${net0/mac} language=en country=US
locale=C priority=critical netcfg/dhcp_timeout=120 initrd=initrd.gz ||
boot ||

I don't do a lot of UEFI, but the above works quite well for us. Don't
forget to disable IMAGE_COMBOOT if you use the same embedded script for
both UEFI and BIOS mode, and to include the initrd in the boot stanza of
your actual iPXE bootstrap (BIOS doesn't need that option in the kernel
command line, but UEFI does). You could combine all of these into a single
IPXE script, but YMMV.

Hope this helps.

cheers,
Klaus

On Tue, Jun 5, 2018 at 1:38 PM, Jorell F  wrote:

> What would be the kea config equivalent of the following dhcp config
>
> if option client-architecture = encode-int ( 16, 16 ) {
>  option vendor-class-identifier "HTTPClient";
>  filename "http://my.web.server/ipxe.efi; ;
> }
>
>
>
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] HA based on galera

[Klaus Steden]

In our case, our MySQL server is basically DBaaS. There was a Meetup
presentation about it (https://www.meetup.com/la-mysql/events/228737163/). If
you want, I can try to track it down -- the actual MySQL step isn't
something I had to engineer myself -- so I was able to take HA for granted.

In our use case, different scopes are handled by different individual Kea
servers (as the network is naturally partitioned), so avoiding write
conflicts is easy, but ultimately that's not the complicated part of our
configuration.

cheers,
Klaus

On Wed, Mar 14, 2018 at 10:10 AM, Jason Guy <j...@cumulusnetworks.com>
wrote:

> Hey Klaus,
>
> Can you elaborate a bit on your design? I am in the middle of testing Kea
> 1.3 with a 3 node mysql setup, and have not seen any issues yet. I
> researched both MySQL-Cluster and MySQL Group Replication in MySQL5.7. I
> settled on first testing with group replication, since it did not require
> an extra management server arbitrating the writes.
>
> The group replication HA allows all devices to be a master, and uses GTIDs
> to prevent 2 nodes from writing the same row. So my curiosity here is if I
> am missing something in the design, and how I would easily stress test
> this, to see if the SQL group can handle the distributed writes from the
> Kea server.
>
> Thanks,
> Jason
>
> On Tue, Mar 13, 2018 at 8:17 PM, Klaus Steden <klausfi...@gmail.com>
> wrote:
>
>>
>> We have HA-MySQL behind our Kea servers, but the scopes themselves are
>> sharded to avoid this kind of write contention. In our case, we've got a
>> network partition that serves as an effective bright line between who's
>> responsible for what.
>>
>> cheers
>> Klaus
>>
>> On Tue, Mar 13, 2018 at 4:18 AM, <l...@ezelink.com> wrote:
>>
>>> Hey, pal, that's my thread ))
>>>
>>> if you installed boost and configure can't find it - use ./configure
>>> --help
>>> there should be option --with-boost-source or smth like that
>>>
>>>
>>>
>>> On 2018-03-13 15:10, Tobi Obadiah wrote:
>>>
>>>> Hello there,
>>>>
>>>> Am just getting started with Kea, on my attempt to install kea on
>>>> Ubuntu16.04 desktop  I keep getting the "Missing required header
>>>> files" errors
>>>> I have to manage to fix some of them but wonder if there is a standard
>>>> procedure to get this fix.  Though I have boost installed
>>>> "boost/shared_ptr.hpp"
>>>> is reported missing.
>>>>
>>>> I appreciate your help.
>>>>
>>>> On Tue, Mar 13, 2018 at 11:37 AM, Dominik Epple
>>>> <dominik.ep...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> it might help if you pick a dedicated galera write node, i.e. both
>>>>> of your kea servers write to the same galera node at each point in
>>>>> time. You can still configure that in a HA fashion by some
>>>>> active-passive loadbalancer or a failover IP or something.
>>>>>
>>>>> The other option would be that the kea code gets adjusted for
>>>>> running "galera-aware" but I am no expert on what exactly needs to
>>>>> happen there. But if it can't be fixed on application level, it
>>>>> probably can be fixed on system level by picking a dedicated write
>>>>> node.
>>>>>
>>>>> Dominik
>>>>>
>>>>> 2018-03-13 11:28 GMT+01:00 <l...@ezelink.com>:
>>>>>
>>>>> Hi guys,
>>>>>>
>>>>>> I'm running 2 kea dhcp servers and connect them to galera-mysql
>>>>>> cluster for HA.
>>>>>> Everything is ok, but sometimes i have this message in logs:
>>>>>>
>>>>>> 2018-03-13 14:14:45.036 ERROR [kea-dhcp4.alloc-engine/11864]
>>>>>> ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 b8:53:ac:xx:xx:xx],
>>>>>> cid=[01:b8:53:ac:xx:xx:xx], tid=0xa56d03a4: error during attempt
>>>>>> to allocate an IPv4 address: unable to execute for >>>>> address, hwaddr, client_id, valid_lifetime, expire, subnet_id,
>>>>>> fqdn_fwd, fqdn_rev, hostname, state FROM lease4 WHERE client_id =
>>>>>> ? AND subnet_id = ?>, reason: Deadlock found when trying to get
>>>>>> lock; try restarting transaction (error code 1213)
>>>>>>
>>>>>> the network is relatively small - not more than 50-100 requests
>>>>

Re: [Kea-users] HA based on galera

[Klaus Steden]

We have HA-MySQL behind our Kea servers, but the scopes themselves are
sharded to avoid this kind of write contention. In our case, we've got a
network partition that serves as an effective bright line between who's
responsible for what.

cheers
Klaus

On Tue, Mar 13, 2018 at 4:18 AM,  wrote:

> Hey, pal, that's my thread ))
>
> if you installed boost and configure can't find it - use ./configure --help
> there should be option --with-boost-source or smth like that
>
>
>
> On 2018-03-13 15:10, Tobi Obadiah wrote:
>
>> Hello there,
>>
>> Am just getting started with Kea, on my attempt to install kea on
>> Ubuntu16.04 desktop  I keep getting the "Missing required header
>> files" errors
>> I have to manage to fix some of them but wonder if there is a standard
>> procedure to get this fix.  Though I have boost installed
>> "boost/shared_ptr.hpp"
>> is reported missing.
>>
>> I appreciate your help.
>>
>> On Tue, Mar 13, 2018 at 11:37 AM, Dominik Epple
>>  wrote:
>>
>> Hi,
>>>
>>> it might help if you pick a dedicated galera write node, i.e. both
>>> of your kea servers write to the same galera node at each point in
>>> time. You can still configure that in a HA fashion by some
>>> active-passive loadbalancer or a failover IP or something.
>>>
>>> The other option would be that the kea code gets adjusted for
>>> running "galera-aware" but I am no expert on what exactly needs to
>>> happen there. But if it can't be fixed on application level, it
>>> probably can be fixed on system level by picking a dedicated write
>>> node.
>>>
>>> Dominik
>>>
>>> 2018-03-13 11:28 GMT+01:00 :
>>>
>>> Hi guys,

 I'm running 2 kea dhcp servers and connect them to galera-mysql
 cluster for HA.
 Everything is ok, but sometimes i have this message in logs:

 2018-03-13 14:14:45.036 ERROR [kea-dhcp4.alloc-engine/11864]
 ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 b8:53:ac:xx:xx:xx],
 cid=[01:b8:53:ac:xx:xx:xx], tid=0xa56d03a4: error during attempt
 to allocate an IPv4 address: unable to execute for >>> address, hwaddr, client_id, valid_lifetime, expire, subnet_id,
 fqdn_fwd, fqdn_rev, hostname, state FROM lease4 WHERE client_id =
 ? AND subnet_id = ?>, reason: Deadlock found when trying to get
 lock; try restarting transaction (error code 1213)

 the network is relatively small - not more than 50-100 requests
 per second

 How can I get rid of these messages? Cause after getting this
 error, server sends NACK to client
 ___
 Kea-users mailing list
 Kea-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/kea-users [1]

>>>
>>> ___
>>> Kea-users mailing list
>>> Kea-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/kea-users [1]
>>>
>>
>>
>>
>> Links:
>> --
>> [1] 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 mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] subnet and DHCP options for MySQL backend

[Klaus Steden]

Yeah, it's lease/reservation info only. We generate our scopes
programmatically and add/remove them using configuration management.

cheers,
Klaus

On Mon, Feb 26, 2018 at 8:38 AM, xbgmsharp  wrote:

> Thanks for the feedback, by using a backend i was expecting to have all
> the config in the backend, like isc-dhcp with the LDAP backend.
>
> I have pretty standard configuration, name servers, time server, netbios
> server, lease time, etc...
>
> Regards
>
>
> On 2018-02-26 13:01, Francis Dupont wrote:
>
>> A lease database backend is for the whole server. If you have
>> specific subnet / options setting they go into the configuration
>> inside subnet entries independently of backends.
>>
>> Regards
>>
>> Francis Dupont 
>>
>> PS: BTW there must be at least one subnet because incoming packets are
>> localized (aka subnet selection) with success to get useful services
>> (cf. subnet[46]_select last statement in the developer guide, i.e.
>> https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html
>> copied here in the case you have no access to it:
>> If any callout sets the status to SKIP, the server will not select any
>> subnet. Packet processing will continue, but will be severely limited. )
>>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Build warnings under Debian Stretch

[Klaus Steden]

I've seen "unknown substitution variable ${shlibs:Depends}" many times
building Debian packages but I can't recall that it's ever caused an issue.
I think you're probably okay to ignore that one, it's a message burped by
the packaging process but shouldn't affect the binaries themselves.

cheers,
Klaus

On Sat, Feb 3, 2018 at 9:15 AM, Jason Guy  wrote:

> Hi folks. I was working on getting the 1.3 debian package build tested.
> There are a few errors in the debian git repo that I need to get fixed, but
> I am trying to help the maintainer keep the kea package up to date, and
> hopefully stay that way.
>
> In my latest build, I see a few warnings, and I was not sure if these are
> something I should file a bug for, or simply ignore under Debian. None of
> these cause a problem, but I want to verify these will not be an issue:
>
> dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.8.0.0 was
> not linked against libz.so.1 (it uses none of the library's symbols)
>
> dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/kea-common/usr/lib/x86_64-linux-gnu/hooks/libdhcp_lease_cmds.so
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-dhcp_ddns.so.1.0.2
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-process.so.1.0.0
> debian/kea-common/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.8.0.0 were
> not linked against libkea-cfgclient.so.4 (they use none of the library's
> symbols)
>dh_installdeb -O-B
>dh_gencontrol -O-B
>
> dpkg-gencontrol: warning: Depends field of package kea-dev: unknown
> substitution variable ${shlibs:Depends}
>dh_md5sums -O-B
>dh_builddeb -O-B
>
> This last one is a little strange. I am not entirely why the kea-dev
> package would not have any shared library dependencies. This may be a
> Debian specific thing... Anyhow, looking for any help/advice on these.
>
> Thanks,
> Jason
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] kea API

[Klaus Steden]

+1 to this request.

cheers,
Klaus

On Mon, Dec 4, 2017 at 1:19 PM, Munroe Sollog  wrote:

> Has there been any discussion about using GET instead of POST for the
> read-only (statistics) API?  I'm working on integrating our monitoring and
> metrics with kea, and it would have been very helpful to have a POST API
> and a GET API so I can limit access accordingly.
>
> As it is I have to write an intermediary web service to allow statistics
> collection without allowing nagios/icinga/etc to 'shutdown' the server.
>
> --
> Munroe Sollog
> Senior Network Engineer
> mun...@lehigh.edu
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] DHCP redundancy [faked-from]

[Klaus Steden]

We manage configurations with a Salt state, and the application we
integrated with Kea that we built in-house generates the scope definitions
as YAML, so it's easy to push changes into the Salt state file.

It's not fully automated yet as the Kea version we're using doesn't support
a configuration syntax test option, but that's on our internal roadmap so
that a merge to the master branch will trigger a Jenkins job to incorporate
updates automatically, test, and deploy.

The benefit for us of using Salt is that scope changes go through code
review like everything else, so that lowers the risk of bad changes and
builds an audit trail if they get introduced.

cheers,
Klaus

On Mon, Nov 27, 2017 at 7:49 AM, Hugh Connolly <hconno...@gcet.net> wrote:

> Check out Rudder
>
>
> If very happy with it.
>
> https://www.rudder-project.org/site/
> Rudder <https://www.rudder-project.org/site/>
> www.rudder-project.org
> Rudder is an easy to use, web-driven, role-based solution for IT
> Infrastructure Automation and Compliance.
>
> That or Chef, Puppet etc.
>
>
> Or just rsync and cron.
> --
> *From:* Sutherland, Rob <robert.b.sutherl...@windstream.com>
> *Sent:* Thursday, November 23, 2017 10:10:16 AM
> *To:* Hugh Connolly; Klaus Steden; SoupNazi izaNpuoS
> *Cc:* KEA-Users (kea-users@lists.isc.org)
> *Subject:* RE: [Kea-users] DHCP redundancy [faked-from]
>
>
> I’m using that setup as well: Pacemaker with a replicated postgres lease
> database. It works quite well. There’s only one missing piece: a way to
> keep the configuration in sync across nodes. In the database, perhaps?
> (aside: the configuration is quite fluid in our production environment,
> changing multiple times per day).
>
>
>
> *From:* Kea-users [mailto:kea-users-boun...@lists.isc.org] *On Behalf Of *Hugh
> Connolly
> *Sent:* Wednesday, November 22, 2017 8:34 AM
> *To:* Klaus Steden; SoupNazi izaNpuoS
> *Cc:* KEA-Users (kea-users@lists.isc.org)
> *Subject:* Re: [Kea-users] DHCP redundancy [faked-from]
>
>
>
> I'm working on something similar.
>
>
>
> It uses 2+ Kea instances with the postgresql lease db in Amazons RDS.
>
> To manage the VIP the cluster uses ocf_heartbeat_IPaddr2 (pacemaker)
>
>
>
> Works quite well thus far.
>
>
>
> What do you think?
>
>
>
> One improvement (beyond in-housing the Postgresql cluster) that comes to
> mind is better fencing in PCS to restart the service or shutdown the node
> if there is a problem. Something beyond just checking that the service is
> running, maybe checking the ports?
>
>
>
> Was fairly straight forward to setup
> --
>
> *From:* Kea-users <kea-users-boun...@lists.isc.org> on behalf of Klaus
> Steden <klausfi...@gmail.com>
> *Sent:* Friday, November 17, 2017 4:14:00 PM
> *To:* SoupNazi izaNpuoS
> *Cc:* KEA-Users (kea-users@lists.isc.org)
> *Subject:* Re: [Kea-users] DHCP redundancy
>
>
>
>
>
> Our implementation uses a single database backend (which is itself HA, but
> the endpoint is a VIP, so it appears to be just a single host)  with a
> different server per environment running a Kea server. It seems they
> coexist quite happily as long as they're not trying to both handle the same
> row/table, which means each environment only uses a single IP helper.
>
>
>
> We use Monit on the servers themselves to keep the Kea daemon running,
> since as noted it doesn't retry when it encounters an error talking to the
> database; the whole system is generally fairly resilient, FWIW, even if
> it's less than industrial strength.
>
>
>
> cheers,
>
> Klaus
>
>
>
> On Fri, Nov 17, 2017 at 6:48 AM, SoupNazi izaNpuoS <soupnaz...@gmail.com>
> wrote:
>
> Not at all.  It does split the pools, automatically.  You just need to
> make sure you don't use more than 90% of your addresses as it may have
> difficulty transferring IPs amongst the devices if you do (say if the
> secondary runs out, the primary may not be able to send IPs to it).
>
>
>
> On Fri, Nov 17, 2017 at 9:44 AM, John Ratliff <j...@bluemarble.net> wrote:
>
> On 11/17/2017 9:37 AM, SoupNazi izaNpuoS wrote:
>
> Out of curiosity, was there a reason you didn't use the built in failover
> configuration in ISC DHCP?
>
>
> It's extremely confusing to me. Perhaps my understanding is flawed, but as
> I understand it, you need to split your pool and have one side responsible
> for their individual split. Our pools do not have enough spare IPs to allow
> that. It just never seemed work the effort.
>
> --John
>
>
> On Fri, Nov 17, 2017 at 9:25 AM, John Ratliff <j...@bluemarble.net
> <mailto:j

Re: [Kea-users] Does anybody use Debian stretch as OS?

[Klaus Steden]

I've run into something like that building from source as well, did you
file a bug with the Kea maintainers? They were pretty quick with a fix for
my issue.

cheers,
Klaus

On Mon, Nov 27, 2017 at 1:18 PM, Munroe Sollog <m...@lehigh.edu> wrote:

> I just tried to build kea-1.3 on a fresh install of Debian Stretch.  I did
> run into a version issue with automake.  Stretch ships 1.15 instead of
> 1.14.1 which is what is hardcoded in the Make file and configure file.  I
> had to massage some values to get kea to compile.
>
> On Sun, Nov 26, 2017 at 7:19 PM, Jason Guy <j...@cumulusnetworks.com>
> wrote:
>
>> I have built it a couple times for Stretch, seeme to work fine. In fact,
>> I decided to start learning how to make a debian package, since the
>> "maintainer" has not done anything since 1.1. Since I use Ansible to deploy
>> my servers in the lab, it is a lot easier to deploy from a .deb package.
>>
>> Cheers,
>> Jason
>>
>> On Fri, Nov 24, 2017 at 4:52 AM, Klaus Steden <klausfi...@gmail.com>
>> wrote:
>>
>>>
>>> Owen -- I've done likewise for us, but we're using U14 servers for our
>>> environment. A bit fiddly editing the checksums in the .dsc and making sure
>>> none of the vendor patches break things, but it builds well enough against
>>> sources from Git.
>>>
>>> cheers,
>>> Klaus
>>>
>>> On Thu, Nov 23, 2017 at 6:25 AM, Zayer, Sebastian <
>>> sebastian.za...@takko.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> thank you very much.
>>>>
>>>>
>>>> With kind regards
>>>>
>>>>
>>>>
>>>>
>>>> <https://m.exactag.com/cl.aspx?tc=622d63de2c2dfa4e3133f6eff7f4a2cb=https://www.takko.com/de-de/?utm_source=mail_medium=intern_campaign=Takko_DE_Mailing_Signatur>
>>>>
>>>> <https://www.facebook.com/TakkoFashionDE>
>>>> <https://www.youtube.com/user/TakkoFashion1>
>>>> <https://instagram.com/takko_fashion> *Sebastian Zayer*
>>>> Specialist IT Systems
>>>>
>>>> T: +49 2504 923 865 <+49%202504%20923865>
>>>> F: +49 2504 923 797 <+49%202504%20923797>
>>>> M: +49 152 21811579 <+49%201522%201811579>
>>>>
>>>> Takko Holding GmbH
>>>> Alfred-Krupp-Straße 21
>>>> <https://maps.google.com/?q=Alfred-Krupp-Stra%C3%9Fe+21+%0D+48291+Telgte,+Deutschland=gmail=g>
>>>> 48291 Telgte, Deutschland
>>>>
>>>> Geschäftsführer: Ulrich Eickmann, Thomas Helmreich, Alexander
>>>> Mattschull, Arnold Mattschull
>>>> Amtsgericht Münster HRB 8939 | Ust.-Id Nr. DE209094382 | *takko.com
>>>> <https://m.exactag.com/cl.aspx?tc=622d63de2c2dfa4e3133f6eff7f4a2cb=https://www.takko.com/de-de/?utm_source=mail_medium=intern_campaign=Takko_DE_Mailing_Signatur>*
>>>> Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail
>>>> erforderlich ist.
>>>> -Original Message-
>>>> From: Jason Lixfeld [mailto:jason-...@lixfeld.ca <jason-...@lixfeld.ca>
>>>> ]
>>>> Sent: Thursday, November 23, 2017 3:26 AM
>>>> To: Francis Dupont <fdup...@isc.org>
>>>> Cc: Zayer, Sebastian <sebastian.za...@takko.de>; KEA-Users (
>>>> kea-users@lists.isc.org) <kea-users@lists.isc.org>
>>>> Subject: Re: [Kea-users] Does anybody use Debian stretch as OS?
>>>>
>>>> Sure.  Done.
>>>>
>>>> > On Nov 22, 2017, at 7:01 PM, Francis Dupont <fdup...@isc.org> wrote:
>>>> >
>>>> > Can you fill an entry in "Install Kea from sources" in the wiki
>>>> > (http://kea.isc.org/wiki/Install)?
>>>> >
>>>> > Thanks
>>>> >
>>>> > Francis Dupont <fdup...@isc.org>
>>>> >
>>>> > PS: we should keep these more up to date (:-)...
>>>>
>>>>
>>>> ___
>>>> Kea-users mailing list
>>>> Kea-users@lists.isc.org
>>>> 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 mailing list
>> Kea-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
>>
>
>
> --
> Munroe Sollog
> Senior Network Engineer
> mun...@lehigh.edu
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Help diagnosing (and potentially addressing) a possible performance problem?

[Klaus Steden]

Hello Rasmus,

After about a week or so of time for analysis, it turns out that it was a
couple of factors working in concert, for the most part:

1. lease times were too short (1H), resulting in request storms as entire
racks leases would expire roughly simultaneously, swamping the server with
requests; I changed the default lease time to 12H, applied some monitoring
to keep track, and lease counts recovered within an hour or so and
stabilized

2. some racks timed out when requesting due to distances between the client
and the DHCP server due to either simple network distance or packets lost
due to asymmetric routing; one of the affected areas is in another segment
entirely with different routing and eventually will be firewalled off, so
the fastest way to resolve the issue was simply spin up another DHCP server
and point the segment's switches IP helpers to it, instead of the original
DHCP server. As they're not sharing the same lease/reservation tables, they
can get along using the same database without causing conflicts (I think
this scenario was actually explicitly tested by the Kea dev team, and found
to be stable)

3. I think the ALLOC_FAIL messages were actually red herring false
positives from a rack or racks(s) that haven't yet been assigned scopes, so
no leases are available to be granted yet

Thank you for the feedback -- I was able to work through these issues using
insights from your comments, a bit of "rubber duck" debugging with one of
our network engineers, and some instrumentation help generated with
InfluxDB. :-)

cheers,
Klaus

On Thu, Oct 5, 2017 at 2:02 AM, Rasmus Edgar <r...@arch-ed.dk> wrote:

> Hi Klaus,
>
> I have seen something very similar on vmware with another application
> receiving a lot udp traffic and unfortunately we never found a solution for
> it and switched to bare metal as a workaround, which has irked me ever
> since and I'm interested in finding a root causes for these kinds of
> problems.
>
> As far as I understand, and according to the netstat man page, Recv-Q is
> the count of bytes not yet copied by the user program connected to the
> socket.
>
> Do you have special rules, execute something or do dns lookups when
> handling dhcp requests?
>
> Have you read the comments on ALLOC_ENGINE_V4_ALLOC_FAIL?
>
> "% ALLOC_ENGINE_V4_ALLOC_FAIL %1: failed to allocate an IPv4 address after
> %2 attempt(s)
> The DHCP allocation engine gave up trying to allocate an IPv4 address
> after the specified number of attempts.  This probably means that the
> address pool from which the allocation is being attempted is either
> empty, or very nearly empty.  As a result, the client will have been
> refused a lease. The first argument includes the client identification
> information.
>
> This message may indicate that your address pool is too small for the
> number of clients you are trying to service and should be expanded.
> Alternatively, if the you know that the number of concurrently active
> clients is less than the addresses you have available, you may want to
> consider reducing the lease lifetime.  In this way, addresses allocated
> to clients that are no longer active on the network will become available
> sooner."
>
> Br,
>
> Rasmus
>
> Klaus Steden skrev den 2017-10-05 03:03:
>
>
> Hi everyone,
>
> We've been using Kea successfully for several months now as a key part of
> our provisioning process. However, it seems like the server we're running
> it on (a VM running under XenServer 6.5) isn't beefy enough, but I'm not
> 100% confident in that diagnosis.
>
> There are currently ~200 unique subnets defined, about 2/3rd of which are
> use to provide a single lease during provisioning, at which point the host
> in question assigns itself a static IP. There are 77 subnets that are
> actively in use (for IPMI), with the following lease attributes:
>
>   "valid-lifetime": 4000,
>   "renew-timer": 1000,
>   "rebind-timer": 2000,
>
> From what I'm seeing in the output of tcpdump, there are a LOT more
> requests coming in than replies going out, and *netstat* seems to confirm
> that:
>
> # netstat -us
> ...
> Udp:
> 71774 packets received
> 100 packets to unknown port received.
> 565 packet receive errors
> 4911 packets sent
>
> If I monitor *netstat* continuously, I see spikes on the RecvQ for Kea
> that fluctuate wildly, anywhere between 0 and nearly 500K (and sometimes
> higher) moment to moment.
>
> The log also reports a lot of ALLOC_ENGINE_V4_ALLOC_FAIL errors after
> typically 53 attempts (not sure why 53, but that number seems to be the
> typical upper limit before failure is confirmed).
>
> I've been experimenting over the last hour or so with tuning various
> kernel pa

Re: [Kea-users] New Kea hook to call external scripts: kea-hook-runscript

[Klaus Steden]

This looks like it's got some real possibilities. Thank you, Baptiste!

cheers,
Klaus

On Thu, Aug 24, 2017 at 4:10 AM, Eron Lloyd  wrote:

> Thank you for this, Baptiste! We're are preparing our Kea deployment now,
> and will test it out.
>
> On Thu, Aug 24, 2017 at 6:21 AM, Baptiste Jonglez <
> bapti...@bitsofnetworks.org> wrote:
>
>> Hi,
>>
>> I have developed a generic hook that calls an external script at all hook
>> points provided by Kea.  The goal is to simplify integration with Kea: for
>> many simple use-cases, it is overkill to have to write a full-blown Kea
>> hook, where a simple shell script can do the job.
>>
>> This could be useful for several use-cases, but we currently use it to
>> add/remove routes in the kernel routing table when DHCP clients connect or
>> disconnect.
>>
>> The code and documentation are here:
>>
>>   https://code.ffdn.org/zorun/kea-hook-runscript
>>   https://github.com/zorun/kea-hook-runscript (mirror)
>>
>> If you find this useful or would like more variables to be provided to the
>> external script, please send feedback or pull requests!  In particular,
>> feel free to provide more examples (Kea config + script).
>>
>> Note that the code is still a bit rough, especially for DHCPv6: see the
>> TODO list at https://code.ffdn.org/zorun/kea-hook-runscript#todo
>>
>> Baptiste
>>
>> ___
>> Kea-users mailing list
>> Kea-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
>>
>
>
> --
> Eron Lloyd
> President and Chief Analyst
> Lloyd Analytics LLC
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] GUI and minimum hardware requeriments for KEA

[Klaus Steden]

I run all my Kea instances on Xen VMs with pretty lean provisioning, but
it's really going to depend on your use case.

A single lease transaction if you're using a SQL backend can take 2-3s to
complete, so if you're handing out thousands of leases per second, you'll
need a lot more horsepower than if you're using Kea to manage a couple of
/24s with long lease times and not a lot of churn.

cheers,
Klaus

On Thu, Jun 8, 2017 at 11:43 AM, Francis Dupont  wrote:

> For 2- I didn't try recently but IMHO you can run Kea on a 50 USD hardware.
> The constraint is more on the side of the operating system (for instance
> Linux is known to require twice memory than dedicated systems).
> I currently use some VMs for testing and if you don't install a window
> system/manager I believe 128 M of memory and 4 GB of disk can be enough.
> But don't forget to leave enough place for lease database / file in
> proportion of the number of expected clients...
>
> Regards
>
> Francis Dupont 
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Slightly OT ... trying to debug a Kea/iPXE/tftpd issue ...

[Klaus Steden]

As a footnote, I've also noticed that the machines I've tested so far do
not have any kind of GUID, e.g., it's all zeroes.

On Fri, Jun 2, 2017 at 3:11 AM, Klaus Steden <klausfi...@gmail.com> wrote:

>
> Hi there,
>
> I realize that this isn't strictly speaking a Kea DHCP issue, but I
> thought I'd ask anyway in hopes someone else may have seen what I'm seeing.
>
> Basically, it looks like the onboard NIC firmware is getting confused
> while talking to the tftpd server, so it abruptly stops reading the iPXE
> boot file that Kea tells it to fetch.
>
> It's a newer machine with an Intel 10 GigE NIC, so I suspect it's probably
> some firmware quirk or compatibility issue, but it's definitely got me
> scratching my head. It basically looks like this issue, but that of course
> is 2+ years old.
>
> http://forum.ipxe.org/showthread.php?tid=7356
>
> Sorry for the spam, just hoping I might find someone else who's run into
> this before.
>
> cheers,
> Klaus
>
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

[Kea-users] Slightly OT ... trying to debug a Kea/iPXE/tftpd issue ...

[Klaus Steden]

Hi there,

I realize that this isn't strictly speaking a Kea DHCP issue, but I thought
I'd ask anyway in hopes someone else may have seen what I'm seeing.

Basically, it looks like the onboard NIC firmware is getting confused while
talking to the tftpd server, so it abruptly stops reading the iPXE boot
file that Kea tells it to fetch.

It's a newer machine with an Intel 10 GigE NIC, so I suspect it's probably
some firmware quirk or compatibility issue, but it's definitely got me
scratching my head. It basically looks like this issue, but that of course
is 2+ years old.

http://forum.ipxe.org/showthread.php?tid=7356

Sorry for the spam, just hoping I might find someone else who's run into
this before.

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

Re: [Kea-users] Host Reservations flexability

[Klaus Steden]

We had a similar problem, and our approach was to define a custom DHCP
attribute (ignored, but there for comment purposes) and generate the subnet
ID programmatically based on the contents of said comment using a hash
function to create a unique 32-bit integer.

e.g., "rack 41 VLAN 200" and "rack 42 VLAN 200" should hash to different
numbers, so when you generate your scope definitions, you know what the
subnet ID is ahead of time, and can easily derive it based on the label you
gave to each scope.

And yes, strong agree from me -- Kea is awesome, and it was a huge windfall
for our design when we found out about it.

cheers,
Klaus

On Thu, Apr 13, 2017 at 9:57 AM, Jason Guy  wrote:

> Hi folks,
>
> Well, I re-read a few threads related to using the host reservations to
> only supply hostnames for specific known hwaddrs. We have many devices in
> the lab, and frequently move devices in the racks, erase and reinstall, so
> the hwaddr is the only constant. Each rack of equipment has a separate
> top-of-rack switch and subnet, so specifying the subnet_id in the host
> table is not useful. Ultimately it seemed logical that if a subnet_id was
> NOT specified, the hwaddr would be globally known.
>
> Currently I am using Kea 1.1, and like in the other email threads,
> specifying ONLY the hostname and hwaddress in the host table does not work.
> However, if I add a subnet id, things start working. Is there any way
> (aside from using Hooks), to have the server do an unconstrained lookup in
> the host table for the incoming hwaddr? Something like this:
> SELECT * FROM host WHERE dhcp_identifier = 'discovery_hwaddr' LIMIT 1
>
> Even if there was a well-known subnet_id that is used for unassigned host
> entries, it would be good. Seems to me that the subnet_id for a host entry
> should be a mandatory field, if it is not usable when left NULL.
>
> Other than this little snag, I really like Kea, and I think it is a HUGE
> step forward. I am using it with PowerDNS, and it is nice having everything
> in a database. :)
>
> Thanks,
> Jason
>
>
>
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] IP address conflict handling

[Klaus Steden]

Hi Tomek,

Thanks! That was a terrific explanation. Where does Kea store the record
for the "hijacked" address? Does it live in the existing lease table, or
somewhere else (we're using MySQL as the backend, so I don't know if it
will be visible in the DB, or if it gets stored locally in another
lease-file-like file.)

cheers,
Klaus

On Wed, Feb 8, 2017 at 8:43 AM, Tomek Mrugalski <tom...@isc.org> wrote:

> W dniu 08.02.2017 o 00:20, Klaus Steden pisze:
> >
> > Hi there,
> >
> > I realize I don't know what the expected behaviour is for Kea when
> > dealing with an IP conflict, e.g., an address has been assigned by "not
> > Kea", but it's within one of Kea's defined scopes.
> >
> > Does Kea have any internal mechanisms to check if an address is already
> > in use?
> You haven't mentioned whether you're asking about v4 or v6. The answers
> are slightly different for both. RFC2131 says that the server should
> send ICMP echo request to the address that is about to be assigned and
> assign it to the client only if there's no reply. That mechanism is not
> implemented in Kea. The reason for this is that ping check was a nice
> feature back in the days when clients could wait extra second or two and
> there was no rush. Nowadays the server is often expected to grant 1000s
> of leases per second, so the delays introduced by ping checks are out of
> question, especially that the likelihood of detection is very small.
>
> Fortunately, both DHCPv4 and DHCPv6 protocols have a safe guard
> mechanism for duplicates. If a client detects that the address assigned
> is already used, it can report this back to the server using DECLINE
> message. This is supported by Kea. By default Kea then will mark the
> address as used by unknown entity, log a warning about it and will start
> a timer. The default for that is 24 hours, but can be configured to
> other values. After that time the address is returned back to the pool
> of available addresses. This recovery mechanism is implemented this way
> to automatically recover without any manual intervention. If the 24h
> time elapses and the address is still hijacked, Kea will get another
> DECLINE message and put it back in the probation period.
>
> For details, see Sections 7.6 and 8.10 of Kea User's Guide:
> https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-decline
>
> Tomek Mrugalski
> ISC
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Config syntax test option?

[Klaus Steden]

Perfect. Thanks!

On Thu, Dec 8, 2016 at 11:48 AM, Thomas Markwalder <tm...@isc.org> wrote:

> On 12/8/16 2:44 PM, Klaus Steden wrote:
>
>
> Hi there,
>
> Is there a command line option that can be used to validate a
> configuration file without starting the daemon, similar to '/usr/sbin/dhcpd
> -t -cf dhcpd.conf' supported by the older ISC DHCP server?
>
> If not, are there plans to add a feature like this? A few of our internal
> workflows use the config test syntax in CI/CD pipelines to deploy server
> config changes automatically from Git triggers, and I would love to be able
> to automate this approach with our Kea server configs, too.
>
> cheers,
> Klaus
>
>
> ___
> Kea-users mailing 
> listkea-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/kea-users
>
> Yes, we plan to add this in 1.2 due out Spring '17.
>
> Regards,
>
>
> Thomas Markwalder
>
> ISC Software Engineering
>
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] PXE booting to PHP file and on commit, release, expiry

[Klaus Steden]

Yeah, I'm doing something similar with my iPXE setup -- although I have to
use the kkpxe variant because some of my servers are requesting a lease
twice and get two different leases, which KEA can't manage since it can't
isolate a single device lease.

On Wed, Sep 14, 2016 at 9:31 AM, Christoffer Jönsson <bonc...@imap.cc>
wrote:

> Hi there.
>
> I have tried to find the ID using tcpdump on my dhcp server running
> openbsd. But I only get some kind useless output.
> Have tried these commands:
>
> tcpdump -lenx -s 1500 -i vio1 port bootps or port bootpc:
>
> 18:15:39.199104 36:39:31:35:37:30 ff:ff:ff:ff:ff:ff 0800 450: 0.0.0.0.68 >
> 255.255.255.255.67: xid:0x9f31e34 secs:14 vend-rfc1048 DHCP:REQUEST
> MSZ:1472 T93:0 T94:1.2.1 VC:80.88.69.67.108.105.101.
> 110.116.58.65.114.99.104.58.48.48.48.48.48.58.85.78.68.73.58.48.48.50.48.48.49
> T77:1766873157 
> PR:SM+DG+NS+LOG+HN+DN+RP+VO+VC+TFTP+BF+119+128+129+130+131+132+133+134+135+175+203
> T175:177.5.1.26.244.16.0.235.3.1.0.0.23.1.1.34.1.1.19.1.1.
> 17.1.1.39.1.1.25.1.1.16.1.2.33.1.1.21.1.1.24.1.1.18.1.1
> CID:1.54.57.49.53.55.48 T97:0.210.70.225.140.162.19.
> 12.66.131.81.115.228.78.228.23.33 SID:10.0.0.1 RQ:10.0.0.180
>
> *very long hex*
>
> 18:15:39.199613 36:34:36:65:61:31 36:39:31:35:37:30 0800 342:
> 10.0.0.181.67 > 10.0.0.180.68: xid:0x9f31e34 secs:14 Y:10.0.0.180
> S:10.0.0.9 sname "fw" file "http://10.0.0.9/tftp/boot.php;
> <http://10.0.0.9/tftp/boot.php> vend-rfc1048 DHCP:ACK SID:10.0.0.1
> LT:7200 SM:255.255.255.0 DG:10.0.0.1 NS:10.0.0.23,10.0.0.1 HN:"in-cc01" DN:"
> chrjsn.se" [tos 0x10]
>
> *very long hex*
>
>
>  tcpdump -vlenxx -i vio1 -s 1500  port bootps or port bootpc:
>
> 18:22:21.56 36:39:31:35:37:30 ff:ff:ff:ff:ff:ff 0800 450: 0.0.0.0.68 >
> 255.255.255.255.67: [udp sum ok] xid:0x47cead35 secs:14 vend-rfc1048
> DHCP:REQUEST MSZ:1472 T93:0 T94:1.2.1 VC:80.88.69.67.108.105.101.
> 110.116.58.65.114.99.104.58.48.48.48.48.48.58.85.78.68.73.58.48.48.50.48.48.49
> T77:1766873157 
> PR:SM+DG+NS+LOG+HN+DN+RP+VO+VC+TFTP+BF+119+128+129+130+131+132+133+134+135+175+203
> T175:177.5.1.26.244.16.0.235.3.1.0.0.23.1.1.34.1.1.19.1.1.
> 17.1.1.39.1.1.25.1.1.16.1.2.33.1.1.21.1.1.24.1.1.18.1.1
> CID:1.54.57.49.53.55.48 T97:0.210.70.225.140.162.19.
> 12.66.131.81.115.228.78.228.23.33 SID:10.0.0.1 RQ:10.0.0.180 (ttl 64, id
> 873, len 436)
>
> *very long hex*
>
> 18:22:21.569432 36:34:36:65:61:31 36:39:31:35:37:30 0800 342:
> 10.0.0.181.67 > 10.0.0.180.68: [udp sum ok] xid:0x47cead35 secs:14
> Y:10.0.0.180 S:10.0.0.9 sname "fw" file "http://10.0.0.9/tftp/boot.php;
> <http://10.0.0.9/tftp/boot.php> vend-rfc1048 DHCP:ACK SID:10.0.0.1
> LT:7200 SM:255.255.255.0 DG:10.0.0.1 NS:10.0.0.23,10.0.0.1 HN:"in-cc01" DN:"
> chrjsn.se" [tos 0x10] (ttl 128, id 0, len 328)
>
> *very long hex*
>
> tcpdump -i vio1 -s 1500 -vvv port bootps or port bootpc also gives similar
> results.
>
> But from what I've read from tcpdumps on google, the ID changes for
> different hardware.
> Isn't there a way to simply check if undionly.kpxe is loaded and then load
> the PHP?
>
> "if not exists gpxe.bus-id" worked for all devices and also with ipxe.
>
> Thanks!
>
>
> Hi Chris,
>
> 'd-i' is the DHCP signature of the preseed Debian Installer (hence,
> 'd-i'). I've only ever used iPXE, I've never used gPXE before it, so yeah,
> a couple of minutes with tcpdump to inspect the ID it's sending in the
> option string should help you along; once you have that ID field, change
> the test condition in the second stanza and you should be good to go.
>
> BTW the problem you're encountering with the looping boot process is one
> that affected ISC DHCP in a similar way, you just have to tune the
> conditions the DHCP server uses to distinguish the state of the booting
> client in order to direct it where you want to go. ... or flash iPXE on the
> firmware of all your servers hahaha :-)
>
> cheers,
> Klaus
>
> On Tue, Sep 13, 2016 at 9:29 AM, Christoffer Jönsson <bonc...@imap.cc>
> wrote:
>
>>
>>
>> On 2016-09-12 22:58, Klaus Steden wrote:
>>
>>
>> I don't know about updating PowerDNS, but I suspect you'll have to write
>> a plugin. As for the designated boot menu, you can still do that, although
>> the syntax is different.
>>
>> This snippet below -should- do more or less what you're doing with
>> vanilla ISC DHCP:
>>
>> -- cut --
>>   "client-classes": [
>> {
>> "name": "bootstrap",
>> "test" : "option[60].exists
>> "option-data": [
>>

Re: [Kea-users] PXE booting to PHP file and on commit, release, expiry

[Klaus Steden]

Hi Chris,

'd-i' is the DHCP signature of the preseed Debian Installer (hence, 'd-i').
I've only ever used iPXE, I've never used gPXE before it, so yeah, a couple
of minutes with tcpdump to inspect the ID it's sending in the option string
should help you along; once you have that ID field, change the test
condition in the second stanza and you should be good to go.

BTW the problem you're encountering with the looping boot process is one
that affected ISC DHCP in a similar way, you just have to tune the
conditions the DHCP server uses to distinguish the state of the booting
client in order to direct it where you want to go. ... or flash iPXE on the
firmware of all your servers hahaha :-)

cheers,
Klaus

On Tue, Sep 13, 2016 at 9:29 AM, Christoffer Jönsson <bonc...@imap.cc>
wrote:

>
>
> On 2016-09-12 22:58, Klaus Steden wrote:
>
>
> I don't know about updating PowerDNS, but I suspect you'll have to write a
> plugin. As for the designated boot menu, you can still do that, although
> the syntax is different.
>
> This snippet below -should- do more or less what you're doing with vanilla
> ISC DHCP:
>
> -- cut --
>   "client-classes": [
> {
> "name": "bootstrap",
> "test" : "option[60].exists
> "option-data": [
>   {
> "name": "boot-file-name",
> "data": "ipxe/undionly.kpxe"
>   }
> ]
> },
> {
> "name": "preseed",
> "test": "option[60].hex == 'd-i'",
> "option-data": [
>   {
>   "data" : "http://10.0.0.9/tftp/boot.php;,
>   "name" : "boot-file-name"
>}
> ]
>  }
>   ],
> -- cut --
>
> You're probably going to have to tune that a bit, but this is the approach
> I'm using to manage both server and switch booting, and it works well.
>
> hth,
> Klaus
>
> On Mon, Sep 12, 2016 at 11:57 AM, Christoffer Jönsson <bonc...@imap.cc>
> wrote:
>
>> Hello again!
>>
>> Since the 1.1 release i decided to try and migrate from isc-dhcp. And
>> there is a few things I have questions about.
>>
>> For years I have been using a python script to feed my PowerDNS it's
>> records using this:
>>
>> on commit {
>> set ClientIP = binary-to-ascii(10, 8, ".",
>> leased-address);
>> set ClientMac = binary-to-ascii(16, 8, ":",
>> substring(hardware, 1, 6));
>> log(concat("Commit: IP: ", ClientIP, " Mac: ", ClientMac,
>> "Hostname: ", option host-name));
>> execute("/etc/pdns/dhcp-event", "commit", ClientIP,
>> ClientMac, option host-name);
>> }
>>
>> Is it still possible to call and external script?
>>
>> At the same time I've been using a php file that loads the designated
>> boot menu for the booted mac-address:
>>
>> subnet 10.0.0.0 netmask 255.255.255.0 {
>> [...]
>>
>> if not exists gpxe.bus-id {
>> filename "undionly.kpxe";
>> } else {
>> filename "http://10.0.0.9/tftp/boot.php;;
>> }
>> [...]
>> }
>>
>> I'm not sure I can still use this line of code?
>>
>> Thanks in advance!
>> ___
>> Kea-users mailing list
>> Kea-users@lists.isc.org
>> 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 mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Multiple Subnets - 1 NIC

[Klaus Steden]

Hi Maxime,

Have you defined the subnet as one that's owned by Kea in the config file?
Assuming you have different routers, netmasks, etc., you would have to
define a separate scope for both networks.

Presumably you've got DHCP forwarding enabled on your switches as well so
that DHCP requests get relayed through to your Kea server, which is the
only way you can have any DHCP server provide leases for a network it is
not directly connected to.

If it's useful, here's a sample from my config that serves three different
subnets via a single NIC on a different network:

-- cut --
  "subnet4": [
{
"subnet": "10.129.129.0/29",
"id": 1,
"pools": [{ "pool": "10.129.129.2 - 10.129.129.6" }],
"option-data": [{ "name": "routers", "data": "10.129.129.1" }]
},
{
"subnet": "10.129.129.8/29",
"id": 2,
"pools": [{ "pool": "10.129.129.10 - 10.129.129.14" }],
"option-data": [{ "name": "routers", "data": "10.129.129.9" }]
},
{
"subnet": "10.0.194.0/28",
"id": 3,
"pools": [{ "pool": "10.0.194.2 - 10.0.194.14" }],
"option-data": [{ "name": "routers", "data": "10.0.194.1" }]
}
  ]
-- cut --

cheers,
Klaus



On Mon, Aug 15, 2016 at 5:08 AM, Maxime Lareo  wrote:

> Hi,
>
> I currently testing KEA with 2 servers for HA with a Mariadb Galera
> Cluster Backend and it works pretty well.
>
> It running like a charm with one subnet, but when it come managing
> multiple subnet, with only 1 NIC, it seems impossible to make it work. KEA
> just doesn't want to give an IP address that doesn't belong to its own
> subnet.
>
> I don't succeed to use ip relay or client classification properly to make
> it work.
>
> Do I missing something ?
>
> I just want to have VoIP devices on another subnet than the original
> subnet. All the devices (VoIP or not) are on the same VLAN and switch.
>
> To explain my actual configuration :
>
> I have a client classes testing the option 60 and it work, I can see in
> the log file, the expression evaluated to 1, but KEA doesn't choose the
> subnet with the client-class but the one who match its subnet (the one my
> server ip address belong to), which is after the VoIP subnet in the conf
> file.
>
> Someone know a way to make it works ?
>
> Thank you !
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Auto start

[Klaus Steden]

CentOS 7 uses systemd. I'm by no means an expert on it, but you may be able
to shoehorn systemd into thinking that it's a managed service (there's
apparently legacy support for SVR4-style init scripts) using systemctl.
Again, being still new to systemd myself, I can't really offer much useful
advice beyond that, but that's where I'd start looking.

hth,
Klaus

On Wed, Jul 20, 2016 at 5:25 PM, Todd Simmons (todsimmo)  wrote:

> Kea Users,
>
> I’m on CentOS 7 running the Kea 1.0.0 server without issues.  My only
> problem is that if my system is shutdown or rebooted I have to manually run
> “keactrl start” to get the server running again.  What options do I have to
> have the DHCP server startup automatically?  I tried chkconfig, but keactrl
> or the kea-dhcp4/6 are not listed as services.
>
> Thanks for the help,
>
>
>
> Todd
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] Using Host Reservations in Kea

[Klaus Steden]

Fantastic. The documentation looks great, too. Is there an official
expected date for release available yet? I'm liking the software so far,
getting the reservation features working in MySQL will make it even better.

cheers,
Klaus

On Wed, Jun 22, 2016 at 8:39 AM, Marcin Siodelski  wrote:

> On 22.06.2016 17:31, Thomas Andersen wrote:
> >
> > On 22/06/16 17:24, "kea-users-boun...@lists.isc.org on behalf of
> Templin, Fred L"  fred.l.temp...@boeing.com> wrote:
> >
> > > This is the case we are interested in - many kea servers connected to
> the
> > > single database. We want that each server will then have consistent
> host
> > > reservation information for the clients that may come to them for
> service.
> > >
> > > This means that the site administrators will only need to add and
> remove
> > > host reservations in a single database rather than having to push the
> same
> > > information into multiple places, which I think would ease
> administrative
> > > overhead and be less prone to errors. Sounds like this should work with
> > > the new features kea 1.1.0 will be providing?
> >
> >
> > This is what we do today in our installation with 1.0.0
> >
> >
> > /Thomas
> >
> >
> One thing to say about Kea 1.0.0 is that it doesn't allow you to specify
> DHCP options per host. It also doesn't work with IPv6 reservations in the
> database. Kea 1.1.0 will also use database more efficiently, by reducing
> the number of queries made to the database to retrieve host information.
>
> Marcin
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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] iPXE menu troubles

[Klaus Steden]

Is this the -stable release? I had issues with it not renewing / reacquiring a 
lease after loading iPXE. I rolled forward to the latest version in Git which 
didn't have this issue. Not sure if that's helpful. 
cheers,Klaus

Sent from my tri-corder




On Thu, Jun 16, 2016 at 8:32 PM -0700, "Jorell F."  wrote:










On 4/15/2016 10:40 AM, Jorell F. wrote:
> kea v1.0.0
> CentOS 7
>
> The ipxe file loads and the client-class is recognized but the ipxe 
> menu is not passed to the client.
> In the logs this message appears:
> EVAL_RESULT Expression Client_iPXE evaluated to 1
> I know the menu works with dhcpd I don't know how to make it work with 
> kea.
>
>
> {
>"Dhcp4":
>{
>  "interfaces-config":
>  {
>"interfaces": [ "eth1" ]
>  },
>  "lease-database":
>  {
>"type": "memfile"
>  },
>  "valid-lifetime": 129600,
>  "renew-timer":43200,
>  "rebind-timer":   50400,
>
>  "match-client-id": false,
>
>  "option-data":
>  [
>{
>  "name": "boot-file-name",
>  "data": "ipxe/undionly.kpxe"
>},
>{
>  "name": "time-offset",
>  "data": "-28800"
>},
>{
>  "name": "ntp-servers",
>  "data": "192.168.3.99"
>},
>{
>  "name": "domain-name-servers",
>  "data": "192.168.3.99"
>},
>{
>  "name": "tftp-server-name",
>  "data": "192.168.3.99"
>}
>  ],
>  "client-classes":
>  [
>{
>  "name": "Client_iPXE",
>  "test": "substring(option[77].hex,0,4) == 'iPXE'",
>  "option-data":
>  [
>{
>  "name": "boot-file-name",
>  "code": 67,
>  "space": "dhcp4",
>  "data": "http://192.168.3.99:80/ipxe/preboot.php;
>}
>  ]
>}
>  ],
>  "next-server": "192.168.3.99",
>  "subnet4":
>  [
>{
>  "pools": [ { "pool": "192.168.21.1 - 192.168.21.200" } ],
>  "subnet": "192.168.21.0/24",
>  "interface": "eth1",
>  "option-data":
>  [
>{
>  "name": "routers",
>  "data": "192.168.21.254"
>},
>{
>  "name": "domain-name",
>  "data": "LC01.staging.lan"
>}
>  ]
>}
>  ],
>
>  "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
>  }
>},
>
>"Logging":
>{
>  "loggers":
>  [
>{
>  "name": "kea-dhcp4",
>  "output_options":
>  [
>{
>  "output": "/var/log/kea-debug.log"
>}
>  ],
>  "severity": "INFO"
>}
>  ]
>}
> }
>

it is trying to pass the menu to iPXE but iPXE is not receiving a IP address


2016-06-16 20:29:39.051 INFO  [kea-dhcp4.dhcp4/16356] DHCP4_STARTED Kea 
DHCPv4 server version 1.0.0 started
2016-06-16 20:29:39.052 DEBUG [kea-dhcp4.packets/16356] 
DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms
2016-06-16 20:29:45.059 DEBUG [kea-dhcp4.packets/16356] 
DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 
255.255.255.255:67 over interface eth1
2016-06-16 20:29:45.060 DEBUG [kea-dhcp4.options/16356] 
DHCP4_BUFFER_UNPACK parsing buffer received from 0.0.0.0 to 
255.255.255.255 over interface eth1
2016-06-16 20:29:45.061 DEBUG [kea-dhcp4.options/16356] EVAL_RESULT 
Expression 5iPXE evaluated to 0
2016-06-16 20:29:45.061 DEBUG [kea-dhcp4.dhcp4/16356] 
DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:29:dc:ca:ea], cid=[no info], 
tid=0x2adccaea: client packet has been assigned to the following 
class(es): VENDOR_CLASS_PXEClient:Arch:0:UNDI:002001
2016-06-16 20:29:45.061 DEBUG [kea-dhcp4.packets/16356] 
DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:29:dc:ca:ea], cid=[no info], 
tid=0x2adccaea: the subnet with ID 1 was selected for client assignments
2016-06-16 20:29:45.061 DEBUG [kea-dhcp4.packets/16356] 
DHCP4_SUBNET_DATA [hwtype=1 00:0c:29:dc:ca:ea], cid=[no info], 
tid=0x2adccaea: the selected subnet details: 192.168.21.0/24
2016-06-16 20:29:45.061 DEBUG [kea-dhcp4.packets/16356] 
DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:29:dc:ca:ea], cid=[no info], 
tid=0x2adccaea: DHCPDISCOVER (type 1) received from 0.0.0.0 to 
255.255.255.255 on interface eth1
2016-06-16 20:29:45.062 DEBUG [kea-dhcp4.packets/16356] DHCP4_QUERY_DATA 
[hwtype=1 00:0c:29:dc:ca:ea], cid=[no info], tid=0x2adccaea, packet 
details: local_address=255.255.255.255:67, remote_adress=0.0.0.0:68, 
msg_type=DHCPDISCOVER (1), transid=0x2adccaea,
options:
   type=053, len=001: 1 (uint8)
   type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 5(uint8) 6(uint8) 
11(uint8) 12(uint8)