Re: [Kea-users] Logger not found in Stork

[Marcin Siodelski]

Ronald,

Kea 2.5.2 introduced an alias for output_options. When you configure the 
Kea server you can now use "output-options" or "output_options" in the 
logger configuration. However, no matter which parameter name you use in 
your configuration file, Kea will return the default (i.e., 
"output-options") when you issue a config-get commanad. Stork uses this 
command to collect Kea configurations.


Unfortunately, we neglected to update Stork to recognize the parameter 
name with a hyphen, resulting in a behavior you're seeing.


I will create a new Stork ticket to address this issue in 1.14. I don't 
see any workaround for it other than use an older Kea version that 
doesn't use the new alias.


Marcin Siodelski
Sr. Software Engineer,
ISC

On 13.10.2023 08:28, DDFR | Ronald Blaas wrote:

Hi all,

I already asked a question about this on the sstork userlist but perhaps 
someone on kea already has seen this behaviour.


I recently upgraded Stork to version 1.13 and now the log file is not 
displayed in stork. This is as well for DHCPv4 and CA.

Would love to get the logfile back in stork.

Using kea version 2.5.2
and in the kea conf i use the output_options (with underscore and not 
with dash)


"loggers": [
     {
         "name": "kea-dhcp4",
         "output_options": [
             {
                 "output": "/var/log/kea/kea-dhcp4.log"
             }
         ],
         "severity": "INFO",

         "debuglevel": 0
     }

Any idea?

regards,

Ronald



--
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] HA survivor not taking over avec after communication interrupted with partner

[Marcin Siodelski]

Hello Alex,

Your configuration includes `max-unacked-clients` parameter set to 5. It 
means that when the communication between the two servers is interrupted 
the surviving server starts checking if the other server responds to the 
DHCP queries. It assumes that the other server doesn't respond  to the 
queries when the `secs` field value the clients set in the discover or 
rebind messages exceed the value of `max-ack-delay` (5 seconds in your 
case). It must find at least 5 distinct clients retransmitting with 
bumped `secs` field value before it may assume that the partner is dead 
and take over.


This process can take a while depending on the lease lifetime (rebind 
time), number of new or rebinding clients etc.


You can read more about the parameters controlling the failover process 
in the Kea ARM:


https://kea.readthedocs.io/en/kea-2.4.0/arm/hooks.html#load-balancing-configuration

In your failover scenario, please make sure that after the communication 
failure the clients properly set the `secs` field value upon 
retransmissions. If you want to bypass this mechanism, you can set the 
`max-unacked-clients` to 0.


Marcin Siodelski
Senior Software Engineer
ISC

On 9.10.2023 19:37, Alexandre Lessard wrote:

Hello everyone,

I'm new here! I'm working for an ISP as a network administrator.
Furthermore, I got about 7 years of experience doing all sort of IT
stuff for this company. I've been using and configuring Kea DHCP for
about 2 weeks now. Prior to that, I was using ISC DHCP, but since it's
now deprecated, I'm preparing two new servers to migrate all customers
on them.

The setup:
The setup is DHCP relay with two Kea servers in HA hot-standby. There
is three particularity that I want to mention right now.

First, because I couldn't find an out-of-the-box solution, I made a
script that replicate the configuration through the API on both server
when they are restarted. I don't think it interferes with the service
as it is run prior to the service startup, but I don't want to
overlook it either.

Second, they both have an IP configured on their loop back interface
to be use kind of like an any cast address. That being said, I don't
use them for the HA, it's only used by the Relay agents.

Third, they are Proxmox containers. I don't think it's problematic but
tell me if I'm wrong, I will make VMs for them.

My problem:
When I simulated an outage by stopping the server1, only 2 (test2 and
test3) of the 4 subnets recover eventually. Even if they recover, it
takes about 5 minutes. As much as I understand, it's supposed to be
configured at 1 minute. The two other subnets never recovers.
Why some subnets never recover?
Why the 2 that recover take so long?

I observed that the state of server2 stays to "hot-standby" even if
the remote communication is interrupted.

I have been working on fixing that for more than 10 hours now.
Likewise, I really don't know what to look for anymore.

The config:
The Control Agents have almost default configuration, except for the
http-host that is set to the IP interface that receive the request
(eth0).

The Dhcp6 server is disabled.

Has for the Dhcp4 config, it has been saved through the API, so it is
massive! All default configs have been written in the config file. For
this reason, I won't post it here if not required to avoid sending a
wall of config. I've put it on a public repository of GitHub:
https://github.com/AlexTargo/Kea-Dhcp

If I'm missing anything, let me know, and I'll share it as soon as possible.

I hope someone have good pointers for me.

Regards
Alex


--
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] Stork does not see new dhcp4 subnet

[Marcin Siodelski]

Do you observe periodic log messages in the Stork server logs like this one:

stork-server-1  | time="2023-09-08 12:44:35" level="info" 
msg="Completed pulling information from machines: 1/1 succeeded" file="  
statepuller.go:73   "

Marcin

- Original Message -
From: "Apu" 
To: kea-users@lists.isc.org
Sent: Thursday, September 7, 2023 5:39:29 AM
Subject: Re: [Kea-users] Stork does not see new dhcp4 subnet

On 9/6/23 15:52, Marcin Siodelski wrote:
> As I earlier suggested, it would be good to verify that this subnet is 
> visible in Stork when you navigate to the Raw JSON configuration view 

The new subnet is not found in the raw JSON; only the original ones.


> for that Kea server. Then, check the logs from the time when the subnet 
> was pulled from Kea to Stork. If it is hard to find in the historic 
> logs, perhaps you could reconfigure your Kea server without changing the 
> effective configuration (e.g., it should suffice to add or remove 

Expanded the pool to include 10.16.0.4 and restarted kea-dhcp4.  The 
only stork related log entries are those mentioned previously.

It feels like stork is not talking to kea at all but it appears to be 
getting data about the original subnets and I can use stork to add a 
host reservation (and delete it) from the kea MariaDB database.



-- 
Apu
-- 
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] Stork does not see new dhcp4 subnet

[Marcin Siodelski]

This log is only an evidence that the new subnet hasn't been pulled from 
the Kea server into the Stork database. The stats periodically returned 
to Stork contain the stats for this subnet but Stork doesn't seem to 
know that this subnet exists, and logs this error.


This is, however, a result rather than the cause of the issue. Without 
looking into the Stork logs from the time when this subnet was added to 
Kea, we don't know what went wrong with it.


The subnet definition snippet below looks correct. I took this snippet 
and put into the local Kea instance configuration on my system. My Stork 
instance correctly pulled the subnet information from Kea.


As I earlier suggested, it would be good to verify that this subnet is 
visible in Stork when you navigate to the Raw JSON configuration view 
for that Kea server. Then, check the logs from the time when the subnet 
was pulled from Kea to Stork. If it is hard to find in the historic 
logs, perhaps you could reconfigure your Kea server without changing the 
effective configuration (e.g., it should suffice to add or remove 
whitespace into the pool definition string "10.16.0.2-10.16.0.3" and 
restart Kea). Stork should treat it as a configuration change and try to 
pull the subnets again. Observe the Stork server logs and check if there 
are any errors or warnings when the subnets are fetched after Kea 
reconfiguration.


Marcin

On 5.09.2023 19:57, Apu wrote:

Stork is reporting

Sep  5 11:42:33 ip1-mc stork-server[1045]: time="2023-09-05 11:42:33" 
level="error" msg="cannot find LocalSubnet for app: 1, local subnet ID: 
16, family: 4" file="  statspuller.go:249  "


Sep  5 11:42:33 ip1-mc stork-server[1045]: time="2023-09-05 11:42:33" 
level="error" msg="Error handling stat-lease4-get response: cannot find 
LocalSubnet for app: 1, local subnet ID: 16, family: 
4\nisc.org/stork/server/apps/kea.(*StatsPuller).storeDaemonStats\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:248\nisc.org/stork/server/apps/kea.(*StatsPuller).processAppResponses\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:374\nisc.org/stork/server/apps/kea.(*StatsPuller).getStatsFromApp\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:348\nisc.org/stork/server/apps/kea.(*StatsPuller).pullStats\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:63\nisc.org/stork/server/agentcomm.NewPeriodicPuller.func1\n\t/builds/isc-projects/stork/backend/server/agentcomm/puller.go:42\nisc.org/stork/util.(*PeriodicExecutor).executorLoop\n\t/builds/isc-projects/stork/backend/util/periodicexecutor.go:167\nruntime.goexit\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/asm_amd64.s:1594" file="  statspuller.go:376  "


Sep  5 11:42:33 ip1-mc stork-server[1045]: time="2023-09-05 11:42:33" 
level="error" msg="Error occurred while getting stats from app 1: cannot 
find LocalSubnet for app: 1, local subnet ID: 16, family: 
4\nisc.org/stork/server/apps/kea.(*StatsPuller).storeDaemonStats\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:248\nisc.org/stork/server/apps/kea.(*StatsPuller).processAppResponses\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:374\nisc.org/stork/server/apps/kea.(*StatsPuller).getStatsFromApp\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:348\nisc.org/stork/server/apps/kea.(*StatsPuller).pullStats\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:63\nisc.org/stork/server/agentcomm.NewPeriodicPuller.func1\n\t/builds/isc-projects/stork/backend/server/agentcomm/puller.go:42\nisc.org/stork/util.(*PeriodicExecutor).executorLoop\n\t/builds/isc-projects/stork/backend/util/periodicexecutor.go:167\nruntime.goexit\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/asm_amd64.s:1594" file="  statspuller.go:66   "


Sep  5 11:42:33 ip1-mc stork-server[1045]: time="2023-09-05 11:42:33" 
level="error" msg="Errors were encountered while pulling data from apps: 
cannot find LocalSubnet for app: 1, local subnet ID: 16, family: 
4\nisc.org/stork/server/apps/kea.(*StatsPuller).storeDaemonStats\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:248\nisc.org/stork/server/apps/kea.(*StatsPuller).processAppResponses\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:374\nisc.org/stork/server/apps/kea.(*StatsPuller).getStatsFromApp\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:348\nisc.org/stork/server/apps/kea.(*StatsPuller).pullStats\n\t/builds/isc-projects/stork/backend/server/apps/kea/statspuller.go:63\nisc.org/stork/server/agentcomm.NewPeriodicPuller.func1\n\t/builds/isc-projects/stork/backend/server/agentcomm/puller.go:42\nisc.org/stork/util.(*PeriodicExecutor).executorLoop\n\t/builds/isc-projects/stork/backend/util/periodicexecutor.go:167\nruntime.goexit\n\t/builds/isc-projects/stork/tools/golang/go/src/runtime/asm_amd64.s:1594" file=" periodicexecutor.go:170  

Re: [Kea-users] Stork does not see new dhcp4 subnet

[Marcin Siodelski]

I don't know your configurations, so I couldn't reproduce your exact 
situation. However, I tried adding a new subnet to Kea after having some 
subnets already populated to Stork. The new subnet appeared in Stork 
without any issues.


I'd start investigating your problem with examining the Stork server 
logs from the time when the Kea configuration has been updated to see if 
it reported any problems with the fetched subnet.


You could also navigate to Services -> Kea Apps, then select the server 
where your subnet is configured in the Status column. Next, click `Raw 
Configuration` and check whether or not the new subnet is visible in the 
JSON tree.


Kind Regards,
Marcin Siodelski
ISC

On 4.09.2023 22:30, Apu wrote:

kea 2.4.0 and stork 1.12.0

kea-dhcp4 -t /etc/kea/kea-dhcp4.conf shows my original six subnets 
(subnet IDs 171, 172, 173, 174, 175 & 176, all of which are /19s taken 
from 10.17.x.x), as well as the new subnet (id 16, the whole 10.16.0.0/24).


Kea is handing out IP addresses in the new subnet and Grafana shows IP 
addresses assigned in that new subnet's pool.


But Stork shows nothing about the subnet.  I've tried restarting each 
service as well as the whole server but still do not see the new subnet 
in Stork.


Thoughts on what I am missing?

Thanks,




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

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

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

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

[Marcin Siodelski]

Kea HA detects partner failures via the control channel in the first 
place. The servers constantly exchange heartbeats and lease updates. If 
this communication is healthy (i.e., servers receive responses to the 
control commands), the counters of unacked clients are set to 0, and the 
servers do not monitor whether their partners respond to DHCP. In other 
words, if the servers can communicate with each other, the 
"max-unacked-clients" setting has no effect.


Partner failure detection in Kea HA always begins with communication 
failure over the control channel. Usually, it is caused by a partner 
process crash or a network failure. The server tries to send heartbeats 
and lease updates to the partner, for which it gets no responses. 
Suppose the "max-response-delay" setting is 6 (1 minute) and the 
"heartbeat-delay" is 1 (10 seconds). In that case, the server sends 
a heartbeat every 10 seconds to the partner. If the partner doesn't 
respond, the server sends the heartbeat again 10 seconds later, and so 
on. It neither counts the unacked clients nor transitions to the 
partner-down state because the communication issue can be temporary. 
Finally, after around six unsuccessful heartbeat attempts (6 * 10 
seconds), the communication interruption becomes longer than 1 minute 
(6ms). In that case, the server assumes there can be an issue with 
the partner. It is when the "max-unacked-clients" setting finally starts 
to matter.


The server begins to analyze the DHCP messages sent to the partner 
server. The "secs" field in DHCPv4 and "Elapsed Time Option" in DHCPv6 
should be set by a client to indicate how long the client has been 
trying to ask for a new lease or rebind an existing lease. Obviously, 
the server can't see if the partner responds to these queries. It only 
gets copies of the DHCP messages sent by the client. The clients must 
bump these values when they retry to obtain a lease. If these values are 
zero, the server suspecting that the partner is down cannot determine 
whether the partner actually responds to DHCP. If these values are 
greater than 0 (and greater than "max-ack-delay") the server can assume 
that the partner hasn't responded to them because the clients are retrying.


For every client who sends a DHCPDISCOVER or DHCPREBIND to the partner 
server and (finally) sets the "secs" field value greater than 
"max-ack-delay", the other server bumps up its internal counter or 
unacked clients. Again, it only does it when it has been unable to 
communicate with the partner server over the control channel longer than 
the configured "max-response-delay". A single successful heartbeat over 
the control channel will clear the counters of the unacked clients and 
make the server believe that the partner is healthy. It will also stop 
looking at the "secs" and "Elapsed Time" values. The 
"max-unacked-clients" no longer matters until the next communication 
issue over the control channel.


If the "max-unacked-clients" value is exceeded, the server can finally 
transition to the partner-down state and handle both the traffic 
directed to itself and the inoperational partner. Since the state 
transitions are only carried after a heartbeat attempt, there may be a 
slight delay between exceeding the "max-unacked-clients" value and 
actually transitioning to the partner-down state.


I looked into our documentation and realized that although all of these 
pieces are described there, it can be confusing because the ARM lacks a 
sequence diagram or an example of how the failover process can look end 
to end. That's something we should address.


Going over the previous emails, I see that users can see different 
failover strategies, depending on the types of failures they are likely 
to experience in their setup. They are interesting cases, and we will 
discuss them internally. We could consider some alternative failure 
detection strategies, selectable with the HA configuration, but we 
should be aware that there is no one-fits-all solution. There is always 
a possibility that the true failure won't be detected or a false failure 
will be detected, leading to a split-brain situation.


It would be useful if you could please open tickets in Gitlab to 
describe your failover scenarios and the desired behavior. Please 
disregard it if you have already opened them.


Kinds Regards,
Marcin Siodelski

Sr. Software Engineer,
ISC

On 10.01.2023 03:07, Eric Graham wrote:
This is my understanding of how the unacked clients functionality works. 
My explanation is based upon the DHCP4 source code and may differ for 
DHCP6. I will include references at the bottom of my email which I 
encourage double-checking for accuracy. I am not a contributor to Kea 
and have not thoroughly tested the conclusions I draw here.


1. The DHCP packet enters Kea. 

Re: [Kea-users] Kea-Lease documentation

[Marcin Siodelski]

On 22.12.2022 10:52, Kraishak Mahtha wrote:

Hi All,

I am trying to understand the kea-lease file format and I came across 
the option state where it decides the lease state

To my understanding, the state 0 indicates an active lease
and 2 indicates the expiry but sometimes I see the binding state as 1 
but not sure what that means, and I am unable to get any official 
documentation regarding this info. Not sure if we have only 0, 1, 2 as 
states, and more.
Does anyone have any idea or any referenced document where I can get 
these options' explanations and validations like what is the max 
value(for other kea-options) that it can take and so on similar things


Any help would be appreciated
Thanks
Kraishak



The lease state of 1 means "declined lease". A client declines the lease 
when it discovers that someone else is using the leased address.


Kea currently defines only three states for leases: "default" (or 
"active"), "declined" and "expired-reclaimed". The last state marks the 
leases that have expired and the server processed them during routine 
reclamation. In particular, a reclaimed lease has DDNS state cleared. 
Such a lease is available for new allocation.


Kind Regards,

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

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

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

Re: [Kea-users] Unable to re-allocate address

[Marcin Siodelski]

  "rebind-timer": 2000,
>     "renew-timer": 1000,
>     "reservation-mode": "all",
>     "sanity-checks": {
>       "lease-checks": "warn"
>     },
>     "server-hostname": "",
>     "server-tag": "",
>     "shared-networks": [ ],
>     "statistic-default-sample-age": 0,
>     "statistic-default-sample-count": 20,
>     "store-extended-info": false,
>     "subnet4": [
>       {
>         "4o6-interface": "",
>         "4o6-interface-id": "",
>         "4o6-subnet": "",
>         "calculate-tee-times": false,
>         "id": 1,
>         "option-data": [ ],
>         "pools": [
>           {
>             "option-data": [ ],
>             "pool": "192.168.0.10-192.168.0.13"
>           }
>         ],
>         "rebind-timer": 2000,
>         "relay": {
>           "ip-addresses": [ ]
>         },
>         "renew-timer": 1000,
>         "reservations": [
>           {
>             "boot-file-name": "",
>             "client-classes": [ ],
>             "hostname": "",
>             "hw-address": "00:50:01:00:01:00",
>             "ip-address": "192.168.0.12",
>             "next-server": "0.0.0.0",
>             "option-data": [ ],
>             "server-hostname": ""
>           }
>         ],
>         "store-extended-info": false,
>         "subnet": "192.168.0.0/24 <http://192.168.0.0/24>",
>         "t1-percent": 0.5,
>         "t2-percent": 0.875,
>         "valid-lifetime": 4000
>       }
>     ],
>     "t1-percent": 0.5,
>     "t2-percent": 0.875,
>     "valid-lifetime": 4000
>   }
> }
> 
> 
> Regards,
> 
> Jerônimo
> 
> 
> 
> 
> Em qua., 7 de jul. de 2021 às 03:42, Gordon Ross  <mailto:gr...@cam.ac.uk>> escreveu:
> 
> My configuration is very simple. There are no hooks, no HA, no
> multi-threading, no fancy commands.
> 
> Postgres version is 12.7
> 
> Gordon.
> 
> On 06/07/2021, 19:27, "Marcin Siodelski"  <mailto:mar...@isc.org>> wrote:
> 
>     Gordon,
> 
>     Thanks for posting your issue to the Kea users list. I will try to
>     replicate your issue tomorrow with the Postgres lease database
> backend.
> 
>     It will be super useful if you send me your Kea configuration
> file. You
>     can sanitize it from any private stuff it may contain. Please
> send it to
>     me privately if it can't be posted to the mail list.
> 
>     If it is not possible, please describe the major parts of the
>     configuration, e.g. is multi threading on or off, are you using any
>     hooks libraries (e.g. lease cmds?), are you sending any commands
> to Kea
>     that can possibly modify the lease information?
> 
>     Finally, please provide your Postgres database version.
> 
>     Kind Regards,
> 
>     Marcin Siodelski
>     DHCP Software Engineer,
>     ISC
> 
> 
>     On 06.07.2021 18:28, Gordon Ross wrote:
>     > On the off chance, I tried an upgrade to Kea 1.9.9 and the
> problem persists.
>     >
>     > Gordon.
>     >
>     > On 05/07/2021, 16:16, "Kea-users on behalf of Gordon Ross"
>  <mailto:kea-users-boun...@lists.isc.org> on behalf of
> gr...@cam.ac.uk <mailto:gr...@cam.ac.uk>> wrote:
>     >
>     >     I'm running Kea 1.8.2 using the Postgres lease database
> backend on Ubuntu 20.04 LTS
>     >
>     >     Devices can get a new IPv4 address fine. But when they try
> to renew their address, it fails and the logs show:
>     >
>     >     ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 00:21:55:02:67:14],
> cid=[01:00:21:55:02:67:14], tid=0x58cd: error during attempt to
> allocate an IPv4 address: unable to update lease for address
> 172.18.5.4 as it does not exist
>     >
>     >     If I delete the entry from the leases table, Kea then
> happily re-issues the address. (I can perform the DELETE as the Kea
> DB user so no permissions problems there)
>     >
&g

Re: [Kea-users] Unable to re-allocate address

[Marcin Siodelski]

Gordon,

Thanks for posting your issue to the Kea users list. I will try to
replicate your issue tomorrow with the Postgres lease database backend.

It will be super useful if you send me your Kea configuration file. You
can sanitize it from any private stuff it may contain. Please send it to
me privately if it can't be posted to the mail list.

If it is not possible, please describe the major parts of the
configuration, e.g. is multi threading on or off, are you using any
hooks libraries (e.g. lease cmds?), are you sending any commands to Kea
that can possibly modify the lease information?

Finally, please provide your Postgres database version.

Kind Regards,

Marcin Siodelski
DHCP Software Engineer,
ISC


On 06.07.2021 18:28, Gordon Ross wrote:
> On the off chance, I tried an upgrade to Kea 1.9.9 and the problem persists.
> 
> Gordon.
> 
> On 05/07/2021, 16:16, "Kea-users on behalf of Gordon Ross" 
>  wrote:
>
> I'm running Kea 1.8.2 using the Postgres lease database backend on Ubuntu 
> 20.04 LTS
> 
> Devices can get a new IPv4 address fine. But when they try to renew their 
> address, it fails and the logs show:
> 
> ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 00:21:55:02:67:14], 
> cid=[01:00:21:55:02:67:14], tid=0x58cd: error during attempt to allocate an 
> IPv4 address: unable to update lease for address 172.18.5.4 as it does not 
> exist
> 
> If I delete the entry from the leases table, Kea then happily re-issues 
> the address. (I can perform the DELETE as the Kea DB user so no permissions 
> problems there)
> 
> I saw an earlier post about an error in Kea 1.8 & HA, but I'm not running 
> HA at the moment - and I'm on a later version of Kea.
> 
> Is this bug still outstanding in 1.8.2?
> 
> Thank you,
> 
> Gordon
> -- 
> Gordon Ross 
> University of Cambridge
> 
> ___
> ISC funds the development of this software with paid support 
> subscriptions. Contact us at 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2Fdata=04%7C01%7Cgr306%40cam.ac.uk%7Cdb98839da5a9408412d308d93fc7e861%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637610950090875745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=GmN8ecBqF1620llzaQCTQZgNTZQDTnbieR%2BofIj5eU0%3Dreserved=0
>  for more information.
> 
> To unsubscribe visit 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fkea-usersdata=04%7C01%7Cgr306%40cam.ac.uk%7Cdb98839da5a9408412d308d93fc7e861%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637610950090885703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TC0iluctEx6aSeyszaI68xpZDoNaXT1%2FocA6J%2BgVAec%3Dreserved=0.
> 
> Kea-users mailing list
> Kea-users@lists.isc.org
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fkea-usersdata=04%7C01%7Cgr306%40cam.ac.uk%7Cdb98839da5a9408412d308d93fc7e861%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637610950090885703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TC0iluctEx6aSeyszaI68xpZDoNaXT1%2FocA6J%2BgVAec%3Dreserved=0
> 
> ___
> 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] HA lease updates not working after upgrade to 1.8

[Marcin Siodelski]

Apologies, it seems I overlooked the fact that you mentioned MariaDB. We
have recently found the issue in Kea 1.8.0 which causes this behavior
when using High Availability. This issue was corrected in the 1.9.1
version and we will be preparing a maintenance 1.8.1 stable release in a
couple of days. This release is tentatively scheduled for November 12th.

One way would be to try 1.9.1, but this is a development release.
Another way is to wait for a fix to come in 1.8.1.

Marcin Siodelski
ISC

W dniu 04.11.2020 o 16:15, Marcin Siodelski pisze:
> Christian,
> 
> Can you please let me know what lease database backend you're currently
> using?
> 
> Marcin Siodelski
> ISC
> 
> W dniu 04.11.2020 o 14:24, Christian Schuldt pisze:
>> Hey,
>>
>> I updated one of our Kea hot-standby HA pairs from 1.6 to 1.8 and now HA
>> lease-updates to the standby server no longer work.
>> The only config change was the required move of the logging section into
>> the dhcp4-server section.
>>
>> Error on primary:
>> 2020-11-04 13:48:48.754 INFO  [kea-dhcp4.leases/3244.139646677208128]
>> DHCP4_LEASE_ALLOC [hwtype=1 00:01:02:81:41:ed], cid=[no info],
>> tid=0x1ec6987e: lease 192.168.100.211 has been allocated for 86400 seconds
>> 2020-11-04 13:48:48.760 WARN  [kea-dhcp4.ha-hooks/3244.139646677208128]
>> HA_LEASE_UPDATE_FAILED [hwtype=1 00:01:02:81:41:ed], cid=[no info],
>> tid=0x1ec6987e: lease update to ns2-kea (http://10.1.0.254:8080/)
>> failed: unable to update lease for address 192.168.100.211 as it does
>> not exist, error code 1
>>
>> Error on standby:
>> 2020-11-04 13:48:48.759 ERROR [kea-dhcp4.callouts/15648.140137833094208]
>> HOOKS_CALLOUT_ERROR error returned by callout on hook 1 registered by
>> library with index $lease4_update (callout address 0x7f74577f0d40)
>> (callout duration 1.262 ms)
>>
>> I already purged both kea and mariadb (leases and reservations) and 
>> thenreinstalled, syncing reservations and then trying again with no change.
>>
>> I previously tried to manually update a lease on the standby with a
>> query extracted from traffic which also doesn't work. The error seems to
>> originate from the lease_commands hooks:
>> curl -XPOST http://localhost:8080 -H  "Content-Type: application/json" \
>>   -d '{ "arguments": { "expire": 1604579347, "force-create": true,
>> "fqdn-fwd": false, "fqdn-rev": false, "hostname": "pc.", "hw-address":
>> "00:01:02:73:93:b7", "ip-address": "192.168.210.148", "state": 0,
>> "subnet-id": 124, "valid-lft": 86400 }, "command": "lease4-update",
>> "service": [ "dhcp4" ] }'
>> [ { "result": 1, "text": "unable to update lease for address
>> 192.168.210.148 as it does not exist" } ]
>>
>> However when immediately trying "lease4-add" instead of update, it fails
>> with "IPv4 lease already exists."
>> A manual update also doesn't work on the primary.
>>
>> When deleting the leases4 table contents on the standby server, initial
>> HA lease synchronization runs without issues, but afterwards updates
>> don't work. Restarting after initial synchronization causes the same
>> lease update errors as during "normal" operation.
>>
>> The servers configuration is the same (synchronised via git) with the
>> necessary exceptions of interfaces and HA config. Subnets have fixed IDs
>> for database reservations.
>> HA config only differs in "this-server-name".
>>
>> Hooks config:
>>
>> "hooks-libraries": [
>>   {
>>     #" lease cmds are required for ha",
>>     "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
>>     "parameters": { }
>>   },
>>   {
>>     "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
>>     "parameters": {
>>   "high-availability": [
>>     {
>>   "this-server-name": "ns2-kea",
>>   "mode": "hot-standby",
>>   "heartbeat-delay": 4000,
>>   "max-response-delay": 15000,
>>   "max-ack-delay": 5000,
>>   "max-unacked-clients": 0,
>>   "sync-page-limit": 5000,
>>   "sync-timeout": 3,
>>   "peers": [
>>     {
>>  

Re: [Kea-users] HA lease updates not working after upgrade to 1.8

[Marcin Siodelski]

Christian,

Can you please let me know what lease database backend you're currently
using?

Marcin Siodelski
ISC

W dniu 04.11.2020 o 14:24, Christian Schuldt pisze:
> Hey,
> 
> I updated one of our Kea hot-standby HA pairs from 1.6 to 1.8 and now HA
> lease-updates to the standby server no longer work.
> The only config change was the required move of the logging section into
> the dhcp4-server section.
> 
> Error on primary:
> 2020-11-04 13:48:48.754 INFO  [kea-dhcp4.leases/3244.139646677208128]
> DHCP4_LEASE_ALLOC [hwtype=1 00:01:02:81:41:ed], cid=[no info],
> tid=0x1ec6987e: lease 192.168.100.211 has been allocated for 86400 seconds
> 2020-11-04 13:48:48.760 WARN  [kea-dhcp4.ha-hooks/3244.139646677208128]
> HA_LEASE_UPDATE_FAILED [hwtype=1 00:01:02:81:41:ed], cid=[no info],
> tid=0x1ec6987e: lease update to ns2-kea (http://10.1.0.254:8080/)
> failed: unable to update lease for address 192.168.100.211 as it does
> not exist, error code 1
> 
> Error on standby:
> 2020-11-04 13:48:48.759 ERROR [kea-dhcp4.callouts/15648.140137833094208]
> HOOKS_CALLOUT_ERROR error returned by callout on hook 1 registered by
> library with index $lease4_update (callout address 0x7f74577f0d40)
> (callout duration 1.262 ms)
> 
> I already purged both kea and mariadb (leases and reservations) and 
> thenreinstalled, syncing reservations and then trying again with no change.
> 
> I previously tried to manually update a lease on the standby with a
> query extracted from traffic which also doesn't work. The error seems to
> originate from the lease_commands hooks:
> curl -XPOST http://localhost:8080 -H  "Content-Type: application/json" \
>   -d '{ "arguments": { "expire": 1604579347, "force-create": true,
> "fqdn-fwd": false, "fqdn-rev": false, "hostname": "pc.", "hw-address":
> "00:01:02:73:93:b7", "ip-address": "192.168.210.148", "state": 0,
> "subnet-id": 124, "valid-lft": 86400 }, "command": "lease4-update",
> "service": [ "dhcp4" ] }'
> [ { "result": 1, "text": "unable to update lease for address
> 192.168.210.148 as it does not exist" } ]
> 
> However when immediately trying "lease4-add" instead of update, it fails
> with "IPv4 lease already exists."
> A manual update also doesn't work on the primary.
> 
> When deleting the leases4 table contents on the standby server, initial
> HA lease synchronization runs without issues, but afterwards updates
> don't work. Restarting after initial synchronization causes the same
> lease update errors as during "normal" operation.
> 
> The servers configuration is the same (synchronised via git) with the
> necessary exceptions of interfaces and HA config. Subnets have fixed IDs
> for database reservations.
> HA config only differs in "this-server-name".
> 
> Hooks config:
> 
> "hooks-libraries": [
>   {
>     #" lease cmds are required for ha",
>     "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
>     "parameters": { }
>   },
>   {
>     "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
>     "parameters": {
>   "high-availability": [
>     {
>   "this-server-name": "ns2-kea",
>   "mode": "hot-standby",
>   "heartbeat-delay": 4000,
>   "max-response-delay": 15000,
>   "max-ack-delay": 5000,
>   "max-unacked-clients": 0,
>   "sync-page-limit": 5000,
>   "sync-timeout": 3,
>   "peers": [
>     {
>   "name": "ns1-kea",
>   "url": "http://10.1.0.253:8080/;,
>   "role": "primary",
>   #"role": "standby",
>   "auto-failover": true
>     },
>     {
>   "name": "ns2-kea",
>   "url": "http://10.1.0.254:8080/;,
>   #"role": "primary",
>   "role": "standby",
>   "auto-failover": true
>     }
>   ]
>     }
>   ]
>     }
>   }
> ]
> 
> Any help would be appreciated.
> 
> Best Regards
> Christian Schuldt
> 
>  
>   <http://www.studiofunk.de>
> 
>   <https://www.instagram.com

Re: [Kea-users] Kea Agent Centos 7

[Marcin Siodelski]

Good. Glad it worked.

Marcin

W dniu 26.08.2020 o 20:52, Jordan Tinsley pisze:
> End user error on my part.  I was trying -
> 
> systemctl enable isc-kea-agent & systemctl start isc-kea-agent
> 
> We are good now.  Appreciate the help!
> 
> Thanks!
> 
> On 8/26/2020 1:46 PM, Marcin Siodelski wrote:
>> Ouch... it seems we have copy paste bug in our doc. It should rather be:
>>
>> $ sudo systemctl enable isc-stork-agent
>> $ sudo systemctl start isc-stork-agent
>>
>> Marcin
>>
>> W dniu 26.08.2020 o 19:53, Jordan Tinsley pisze:
>>> Hello Marcin,
>>>
>>> The reason I ask is because the documentation online says for 2.2.4
>>> Initial Setup of the Stork Agent  -
>>>
>>> With those settings in place, the |Stork Agent| service can be enabled
>>> and started:
>>>
>>> $ sudo systemctl enable isc-stork-server
>>> $ sudo systemctl start isc-stork-server
>>>
>>>
>>> On 8/26/2020 12:49 PM, Marcin Siodelski wrote:
>>>> Hello,
>>>>
>>>> There is no need to setup Stork server on this machine. Typically,
>>>> there
>>>> is one instance of the Stork server connecting to the remote machines
>>>> via the Stork agents running on them.
>>>>
>>>> You should have your stork-agent instance running on the same
>>>> machine as
>>>> Kea. Typically the stork-agent is bound to port 8080. The Kea server
>>>> (Kea control agent) should be bound to some other port, typically 8000.
>>>>
>>>> If the server cannot get the state from the agent I'd recommend
>>>> starting
>>>> from examining the stork-agent logs to see if there is anything
>>>> indicating that the server managed to communicate with it and if the
>>>> agent logged any errors.
>>>>
>>>> Marcin Siodelski
>>>> ISC
>>>>
>>>> W dniu 26.08.2020 o 19:38, Jordan Tinsley pisze:
>>>>> Okay, I have a separate server instance setup with Stork Server
>>>>> working
>>>>> just fine.
>>>>>
>>>>> I installed a new separate server instance with Stork agent (agent.env
>>>>> configured) on a Kea DHCP server and allowed ports 8080 through the
>>>>> firewall.  Do I need to install the stork Server as well on this Kea
>>>>> DHCP Server?  Stork Server says it cannot get state of the new Kea
>>>>> DHCP
>>>>> Server.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 8/26/2020 12:00 PM, Victoria Risk wrote:
>>>>>>> On Aug 26, 2020, at 9:37 AM, Jordan Tinsley >>>>>> <mailto:jtins...@lrecok.coop>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Is Kea Agent available for Centos 7 or do I need to be using
>>>>>>> Centos 8?
>>>>>> With the release of Kea 1.8 today, we have also posted a new set of
>>>>>> Kea packages
>>>>>> at 
>>>>>> https://cloudsmith.io/~isc/repos/kea-1-8/packages/?q=name%3A%27%5Eisc-kea%24%27
>>>>>>
>>>>>> <https://cloudsmith.io/~isc/repos/kea-1-8/packages/?q=name:'^isc-kea$'>
>>>>>>
>>>>>>
>>>>>> These include both Centos 7 and Centos 8. Does that answer your
>>>>>> question??
>>>>>>
>>>>>> 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
>>>>>
>>

___
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 Agent Centos 7

[Marcin Siodelski]

Ouch... it seems we have copy paste bug in our doc. It should rather be:

$ sudo systemctl enable isc-stork-agent
$ sudo systemctl start isc-stork-agent

Marcin

W dniu 26.08.2020 o 19:53, Jordan Tinsley pisze:
> Hello Marcin,
> 
> The reason I ask is because the documentation online says for 2.2.4
> Initial Setup of the Stork Agent  -
> 
> With those settings in place, the |Stork Agent| service can be enabled
> and started:
> 
> $ sudo systemctl enable isc-stork-server
> $ sudo systemctl start isc-stork-server
> 
> 
> On 8/26/2020 12:49 PM, Marcin Siodelski wrote:
>> Hello,
>>
>> There is no need to setup Stork server on this machine. Typically, there
>> is one instance of the Stork server connecting to the remote machines
>> via the Stork agents running on them.
>>
>> You should have your stork-agent instance running on the same machine as
>> Kea. Typically the stork-agent is bound to port 8080. The Kea server
>> (Kea control agent) should be bound to some other port, typically 8000.
>>
>> If the server cannot get the state from the agent I'd recommend starting
>> from examining the stork-agent logs to see if there is anything
>> indicating that the server managed to communicate with it and if the
>> agent logged any errors.
>>
>> Marcin Siodelski
>> ISC
>>
>> W dniu 26.08.2020 o 19:38, Jordan Tinsley pisze:
>>> Okay, I have a separate server instance setup with Stork Server working
>>> just fine.
>>>
>>> I installed a new separate server instance with Stork agent (agent.env
>>> configured) on a Kea DHCP server and allowed ports 8080 through the
>>> firewall.  Do I need to install the stork Server as well on this Kea
>>> DHCP Server?  Stork Server says it cannot get state of the new Kea DHCP
>>> Server.
>>>
>>> Thanks
>>>
>>> On 8/26/2020 12:00 PM, Victoria Risk wrote:
>>>>> On Aug 26, 2020, at 9:37 AM, Jordan Tinsley >>>> <mailto:jtins...@lrecok.coop>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Is Kea Agent available for Centos 7 or do I need to be using Centos 8?
>>>> With the release of Kea 1.8 today, we have also posted a new set of
>>>> Kea packages
>>>> at 
>>>> https://cloudsmith.io/~isc/repos/kea-1-8/packages/?q=name%3A%27%5Eisc-kea%24%27
>>>> <https://cloudsmith.io/~isc/repos/kea-1-8/packages/?q=name:'^isc-kea$'>
>>>>
>>>> These include both Centos 7 and Centos 8. Does that answer your question??
>>>>
>>>> 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
>>>

___
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 Agent Centos 7

[Marcin Siodelski]

Hello,

There is no need to setup Stork server on this machine. Typically, there
is one instance of the Stork server connecting to the remote machines
via the Stork agents running on them.

You should have your stork-agent instance running on the same machine as
Kea. Typically the stork-agent is bound to port 8080. The Kea server
(Kea control agent) should be bound to some other port, typically 8000.

If the server cannot get the state from the agent I'd recommend starting
from examining the stork-agent logs to see if there is anything
indicating that the server managed to communicate with it and if the
agent logged any errors.

Marcin Siodelski
ISC

W dniu 26.08.2020 o 19:38, Jordan Tinsley pisze:
> Okay, I have a separate server instance setup with Stork Server working
> just fine.
> 
> I installed a new separate server instance with Stork agent (agent.env
> configured) on a Kea DHCP server and allowed ports 8080 through the
> firewall.  Do I need to install the stork Server as well on this Kea
> DHCP Server?  Stork Server says it cannot get state of the new Kea DHCP
> Server.
> 
> Thanks
> 
> On 8/26/2020 12:00 PM, Victoria Risk wrote:
>>
>>> On Aug 26, 2020, at 9:37 AM, Jordan Tinsley >> <mailto:jtins...@lrecok.coop>> wrote:
>>>
>>> Hello,
>>>
>>> Is Kea Agent available for Centos 7 or do I need to be using Centos 8?
>>
>> With the release of Kea 1.8 today, we have also posted a new set of
>> Kea packages
>> at 
>> https://cloudsmith.io/~isc/repos/kea-1-8/packages/?q=name%3A%27%5Eisc-kea%24%27
>> <https://cloudsmith.io/~isc/repos/kea-1-8/packages/?q=name:'^isc-kea$'>
>>
>> These include both Centos 7 and Centos 8. Does that answer your question??
>>
>> 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
> 

___
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] MySQL Error

[Marcin Siodelski]

David,

Since you're currently running Kea 1.6.0, I should make it clear that
currently Stork works only with Kea versions 1.7.3 and later. This is
because it makes heavy use of the status-get control command which was
introduced in 1.7.3.

We're aware that it causes trouble for people running stable Kea 1.6.0.
The 1.7.x branch of Kea is a development/experimental branch and is
basically meant for testing rather than running in production. However,
please note that Stork is also on its early version and there are still
many things to be ironed out before we can fully support it. We're still
to make some decisions whether Kea 1.8.0 will be required to run Stork
or we will back port some necessary changes to 1.6.0 to work with Stork.
For now, I can merely recommend testing Stork with the latest Kea 1.7.8
release.

Also, you mentioned that you need Kea with MySQL backend to allow it
running with Stork. Could you clarify? Stork can also run with the Kea
servers using Memfile backend as the lease storage and a regular
configuration file (not neccessarily the Kea Config Backend).

Marcin


W dniu 29.05.2020 o 11:17, Pizu pisze:
> Seems i missed something from the docs :(
> 
> Thanks for your help.
> 
> I need to use mysql as I would like to use stork.
> 
> Regards,
> 
> David
> 
> On Fri, 29 May 2020 at 10:59, Marcin Siodelski  <mailto:mar...@isc.org>> wrote:
> 
> Hello David,
> 
> Thanks for using Kea and reporting your issue. Looking at the
> configuration snippet you provided it seems you didn't provide a name
> for the lease database. Perhaps you intended to use the memfile (rather
> than mysql) lease backend?
> 
> Kind Regards,
> Marcin Siodelski
> Sr. Software Engineer
> ISC
> 
> W dniu 29.05.2020 o 10:54, Pizu pisze:
> > Hi,
> >
> > Am having an issue on the 1.6.0.
> >
> > error:
> >
> > 2020-05-29 10:43:54.629 ERROR [kea-dhcp4.dhcp4/2524]
> > DHCP4_CONFIG_LOAD_FAIL configuration error using file:
> > /usr/local/etc/kea/kea-dhcp4.conf, reason: Unable to open
> database: must
> > specify a name for the database
> > 2020-05-29 10:43:54.630 ERROR [kea-dhcp4.dhcp4/2524] DHCP4_INIT_FAIL
> > failed to initialize Kea server: configuration error using file
> > '/usr/local/etc/kea/kea-dhcp4.conf': Unable to open database: must
> > specify a name for the database
> >
> > database name is set however am having this error :( can someone help?
> > please
> >
> > {
> >
> > "Dhcp4": {
> >     "server-tag": "Zejtun KEA DHCPv4 server",
> >     "config-control": {
> >         "config-databases": [{
> >             "type": "mysql",
> >             "name": "keadbname",
> >             "user": "keadbuser",
> >             "password": "passwordhere",
> >             "host": "localhost",
> >             "port": 3306
> >         }],
> >         "config-fetch-wait-time": 20
> >         },
> >         "interfaces-config": {
> >             "interfaces": [ "ens192"]
> >
> >     },
> >
> >
> >     "lease-database": {
> >         "type": "mysql",
> >         "lfc-interval": 3600
> >     },
> >
> >
> > Regards,
> >
> > 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 <mailto: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] MySQL Error

[Marcin Siodelski]

Hello David,

Thanks for using Kea and reporting your issue. Looking at the
configuration snippet you provided it seems you didn't provide a name
for the lease database. Perhaps you intended to use the memfile (rather
than mysql) lease backend?

Kind Regards,
Marcin Siodelski
Sr. Software Engineer
ISC

W dniu 29.05.2020 o 10:54, Pizu pisze:
> Hi,
> 
> Am having an issue on the 1.6.0.
> 
> error:
> 
> 2020-05-29 10:43:54.629 ERROR [kea-dhcp4.dhcp4/2524]
> DHCP4_CONFIG_LOAD_FAIL configuration error using file:
> /usr/local/etc/kea/kea-dhcp4.conf, reason: Unable to open database: must
> specify a name for the database
> 2020-05-29 10:43:54.630 ERROR [kea-dhcp4.dhcp4/2524] DHCP4_INIT_FAIL
> failed to initialize Kea server: configuration error using file
> '/usr/local/etc/kea/kea-dhcp4.conf': Unable to open database: must
> specify a name for the database
> 
> database name is set however am having this error :( can someone help?
> please
> 
> {
> 
> "Dhcp4": {
>     "server-tag": "Zejtun KEA DHCPv4 server",
>     "config-control": {
>         "config-databases": [{
>             "type": "mysql",
>             "name": "keadbname",
>             "user": "keadbuser",
>             "password": "passwordhere",
>             "host": "localhost",
>             "port": 3306
>         }],
>         "config-fetch-wait-time": 20
>         },
>         "interfaces-config": {
>             "interfaces": [ "ens192"]
> 
>     },
> 
> 
>     "lease-database": {
>         "type": "mysql",
>         "lfc-interval": 3600
>     },
> 
> 
> Regards,
> 
> 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

Re: [Kea-users] KEA HA

[Marcin Siodelski]

Hi Dirk,

Thank you for your interest in Kea. Not sure if this is short how-to per
your standards, but Kea ARM should be a good start to get familiar with
High Availability topic in Kea:

https://kea.readthedocs.io/en/latest/arm/hooks.html#ha-high-availability

Kind Regards,
Marcin Siodelski

Sr. Software Engineer
ISC

W dniu 22.05.2020 o 19:25, Dirk Laurenz pisze:
> Hello $list,
> 
>  
> 
> i joind because i started to deploy kea in my homelab to replace isc-dhcpd.
> 
> I just managed to setup a single server and now i’m keen in make it high
> available.
> 
> Is there a short howto out? I didn’t manage to find one…
> 
>  
> 
> Regards,
> 
>  
> 
> Dirk
> 
> 
> ___
> 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] Failed to Sync lease updates from primary to backup in Hot-standby mode in V1.5.0

[Marcin Siodelski]

Hello,

The issue you're pointing at was merely to improve the logging of the
time skew, partner's time and the local server's time, so you could more
easily diagnose why the server decided to terminate the HA function. As
far as I remember, it doesn't functionally change the server's behavior.
Therefore, I think it must be something else.

If you could provide us with the logs of BOTH DHCP servers it could shed
some more light on the cauase of your problem.

Kind Regards,

Marcin Siodelski
Sr. Software Engineer
ISC

On 03/04/2020 07:21, luckydog xf wrote:
> I corrected both server's datetime and restarted both service of two
> servers.  But it still got the same error.
> 
> https://gitlab.isc.org/isc-projects/kea/-/merge_requests/414 
> 
> Seem a bug of v1.5.0.  
> 
> On Thu, Apr 2, 2020 at 6:34 PM Marcin Siodelski  <mailto:mar...@isc.org>> wrote:
> 
> Hello,
> 
> Thank you for your email. It would be useful to see the log from the
> primary server to see why it went to the "terminated" state. The standby
> server apparently transitioned to the "terminated" state seeing that the
> partner is in that state. Note that the server which transitioned to the
> "terminated" state (e.g. as a result of too high clock skew) will not
> transition out of this state automatically, even if the clocks get
> synchronized. It must be stopped and started again. Perhaps, the primary
> server wasn't restarted after syncing the clocks?
> 
> Marcin Siodelski
> Sr. Software Engineer
> ISC
> 
> On 02/04/2020 10:36, luckydog xf wrote:
> >   Hi, list,
> >
> >   I'm using Kea V1.5.0 and running two dhcp servers in Hot-standby
> mode.
> > My lease database is Memfile. I setup NTP for both servers. 
> >
> >    Here is part of my configuration, 
> > ===
> >               "high-availability": [ {
> >                     "this-server-name": "server2",
> >                     "mode": "hot-standby",
> >                     "heartbeat-delay": 1,
> >                     "max-response-delay": 1,
> >                     "max-ack-delay": 5000,
> >                     "max-unacked-clients": 5,
> >
> >                     "send-lease-updates": true,
> >                     "sync-leases": true,
> >                     "sync-page-limit": 1,
> >                     "sync-timeout": 3,
> >
> >                     "peers": [
> >                         {
> >                             "name": "server1",
> >                             "url": "http://172.16.232.18:8080/;,
> >                             "role": "primary",
> >                             "auto-failover": true
> >                         },
> >                         {
> >                             "name": "server2",
> >                             "url": "http://172.16.232.20:8080/;,
> >                             "role": "standby",
> >                             "auto-failover": true
> >                         }
> > =
> >
> > Yet  on standby server ,it says that,
> > ===
> > 2020-04-02 11:08:19.269 INFO  [kea-dhcp4.ha-hooks/11468]
> > HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the server2
> > is in the WAITING state
> > 2020-04-02 11:08:19.269 INFO  [kea-dhcp4.ha-hooks/11468]
> > HA_SERVICE_STARTED started high availability service in
> hot-standby mode
> > as standby server
> > 2020-04-02 11:08:19.269 INFO  [kea-dhcp4.dhcp4/11468]
> DHCP4_STARTED Kea
> > DHCPv4 server version 1.5.0 started
> > 2020-04-02 11:08:31.283 INFO  [kea-dhcp4.ha-hooks/11468]
> > HA_STATE_TRANSITION server transitions from WAITING to TERMINATED
> state,
> > partner state is TERMINATED
> > 2020-04-02 11:08:31.283 INFO  [kea-dhcp4.ha-hooks/11468]
> > HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the
> partner
> > while in TERMINATED state
> > 2020-04-02 11:08:31.283 INFO  [kea-dhcp4.ha-hooks/11468]
> > HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the
> server2 is
&

Re: [Kea-users] Failed to Sync lease updates from primary to backup in Hot-standby mode in V1.5.0

[Marcin Siodelski]

Hello,

Thank you for your email. It would be useful to see the log from the
primary server to see why it went to the "terminated" state. The standby
server apparently transitioned to the "terminated" state seeing that the
partner is in that state. Note that the server which transitioned to the
"terminated" state (e.g. as a result of too high clock skew) will not
transition out of this state automatically, even if the clocks get
synchronized. It must be stopped and started again. Perhaps, the primary
server wasn't restarted after syncing the clocks?

Marcin Siodelski
Sr. Software Engineer
ISC

On 02/04/2020 10:36, luckydog xf wrote:
>   Hi, list,
> 
>   I'm using Kea V1.5.0 and running two dhcp servers in Hot-standby mode.
> My lease database is Memfile. I setup NTP for both servers. 
> 
>    Here is part of my configuration, 
> ===
>               "high-availability": [ {
>                     "this-server-name": "server2",
>                     "mode": "hot-standby",
>                     "heartbeat-delay": 1,
>                     "max-response-delay": 1,
>                     "max-ack-delay": 5000,
>                     "max-unacked-clients": 5,
> 
>                     "send-lease-updates": true,
>                     "sync-leases": true,
>                     "sync-page-limit": 1,
>                     "sync-timeout": 3,
> 
>                     "peers": [
>                         {
>                             "name": "server1",
>                             "url": "http://172.16.232.18:8080/;,
>                             "role": "primary",
>                             "auto-failover": true
>                         },
>                         {
>                             "name": "server2",
>                             "url": "http://172.16.232.20:8080/;,
>                             "role": "standby",
>                             "auto-failover": true
>                         }
> =
> 
> Yet  on standby server ,it says that,
> ===
> 2020-04-02 11:08:19.269 INFO  [kea-dhcp4.ha-hooks/11468]
> HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the server2
> is in the WAITING state
> 2020-04-02 11:08:19.269 INFO  [kea-dhcp4.ha-hooks/11468]
> HA_SERVICE_STARTED started high availability service in hot-standby mode
> as standby server
> 2020-04-02 11:08:19.269 INFO  [kea-dhcp4.dhcp4/11468] DHCP4_STARTED Kea
> DHCPv4 server version 1.5.0 started
> 2020-04-02 11:08:31.283 INFO  [kea-dhcp4.ha-hooks/11468]
> HA_STATE_TRANSITION server transitions from WAITING to TERMINATED state,
> partner state is TERMINATED
> 2020-04-02 11:08:31.283 INFO  [kea-dhcp4.ha-hooks/11468]
> HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner
> while in TERMINATED state
> 2020-04-02 11:08:31.283 INFO  [kea-dhcp4.ha-hooks/11468]
> HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the server2 is
> in the TERMINATED state
> 2020-04-02 11:08:31.283 ERROR [kea-dhcp4.ha-hooks/11468] HA_TERMINATED
> HA service terminated because of the unacceptable clock skew; fix the
> problem and restart!
> 
> 
> 
> I'm sure two severs get correct date time. So what's the reason ?
> 
> Is it related
> to https://gitlab.isc.org/isc-projects/kea/-/merge_requests/414 ?
> 
> Thanks and take care.
> 
> -hongquan
> 
> 
> ___
> 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 lease4-get-all via kea-ctrl-agent

[Marcin Siodelski]

Peter,

Apparently you configured your Kea Control Agent rather than DHCP server
to load the hooks libraries. Can you please confirm?

The lease-cmds hooks library must be loaded from within the Kea DHCP
server configuration, i.e. kea-dhcp4.conf rather than
kea-ctrl-agent.conf. The "service" parameter must be present in all
commands sent to the DHCP servers.

Marcin Siodelski
Sr. Software Engineer
ISC

On 03/03/2020 09:24, Peter Simm wrote:
> Hello,
> 
> Thanks for the suggestion, unfortunately it doesn't seem to work either :(
> 
>  curl -X POST -H "Content-Type: application/json" -d '{ "command":
> "lease4-get-all", "service": [ "dhcp4" ]}' http://127.0.0.1:8080  | jq
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
>  Current
>                                  Dload  Upload   Total   Spent    Left
>  Speed
> 100   122  100    68  100    54  53042  42121 --:--:-- --:--:-- --:--:--
> 68000
> [
>   {
>     "result": 1,
>     "text": "no current lease manager is available"
>   }
> ]
> 
> 2020-03-03 09:23:09.258 ERROR [kea-ctrl-agent.callouts/26800]
> HOOKS_CALLOUT_ERROR error returned by callout on hook 1 registered by
> library with index
> $lease4_get_all (callout address 0x7f172e322b40) (callout duration 0.086 ms)
> 
> On Tue, 3 Mar 2020 at 08:16, TroYy  <mailto:modo...@gmail.com>> wrote:
> 
> It seems that you must include "service" which you want to be asked
> 
> So
> 
> curl -X POST -H "Content-Type: application/json" -d '{ "command":
> "lease4-get-all", "service": [ "dhcp4" ] }' http://127.0.0.1:8080  | jq
> 
> should work
> 
> 
> 
> --
> Sent from: http://kea-users.7364.n8.nabble.com/
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org <mailto: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] HA: Which server "owns" the lease

[Marcin Siodelski]

Hello Bjørn,

Thank you for your inquiry. Unfortunately, Kea doesn't store the
identifier of the server which allocated the particular lease.
Currently, the only way to find out which server has allocated the lease
is by parsing the logs, as you did.

The feature you're asking for may actually be useful for diagnostics, so
I would like to encourage you to create the Gitlab issue for it and we
will discuss this within the team members on our regular meeting.

See: https://gitlab.isc.org/isc-projects/kea

Kind Regards,

Marcin Siodelski
ISC Engineering

On 09/09/2019 12:51, Bjørn Skovlund wrote:
> Hi,
> 
> Is it possible to query the servers and see who's active for what leases?
> 
> We had a problem with one of two HA servers and we needed to find out
> exactly which clients were hit - I ended up digging through logs, but it
> would be handy if there's an easier way to find out. The results of
> lease4-get is the same from both servers, so this didn't help much.
> 
> Best, Bjørn
> 
> ___
> 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 not send a NAK when request ip is out of scope

[Marcin Siodelski]

Thomas,

Please refer to the following Kea ARM section for the details regarding
authoritative/non-authoritative behavior:

https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#authoritative-dhcpv4-server-behavior

Setting authoritative flag to true should solve your problem.

Marcin Siodelski
ISC Software Engineering

On 29/08/2019 14:29, Thomas Andersen wrote:
> Hi again,
> 
>  
> 
> Sorry for bumping, but I’m sure there must be smart people out there who
> can guide me – you just missed my original email. :)
> 
>  
> 
> But to make it a lot more simple:
> 
> Shouldn’t KEA respond with NAK when client is requesting an IP out of
> configured scope?
> 
>  
> 
> Br,
> 
> Thomas
> 
>  
> 
> *From: *Kea-users  on behalf of Thomas
> Andersen 
> *Date: *Thursday, 22 August 2019 at 10.19
> *To: *"kea-users@lists.isc.org" 
> *Subject: *[Kea-users] KEA not send a NAK when request ip is out of scope
> 
>  
> 
> Hi,
> 
>  
> 
> I got some problems with DHCP requests.
> 
>  
> 
> Expected scenario:
> 
> Computer logs on wifi with host login and is assigned to vlan 200
> (10.28.0.0/23)
> 
> User logs into computer an reauthenticate on wifi and is assigned to
> vlan 201 (10.28.2.0/23)
> 
> Windows 10 sends a DHCP request for the ip address on vlan 200.
> 
> KEA sends a NAK, as the requested ip is not in scope.
> 
> Windows sends DHCP discover and so forth.
> 
>  
> 
> What we see is that KEA never sends the NAK, but sees the REQUEST packet
> as a bad packet, and then discards it.
> 
> How can I get KEA to send a NAK?
> 
> I’ve tried this with 1.3 and 1.5
> 
>  
> 
> Log:
> 
> 2019-08-21 13:40:24.683 DEBUG [kea-dhcp4.packets/41217]
> DHCP4_PACKET_RECEIVED [hwtype=1 a0:51:0b:0c:24:93],
> cid=[01:a0:51:0b:0c:24:93], tid=0xef9810de: DHCPREQUEST (type 3)
> received from 10.28.2.2 to 192.168.30.10 on interface eth0
> 
> 2019-08-21 13:40:24.683 DEBUG [kea-dhcp4.packets/41217] DHCP4_QUERY_DATA
> [hwtype=1 a0:51:0b:0c:24:93], cid=[01:a0:51:0b:0c:24:93],
> tid=0xef9810de, packet details: local_address=192.168.30.10:67,
> remote_address=10.28.2.2:67, msg_type=DHCPREQUEST (3), transid=0xef9810de,
> 
> options:
> 
>   type=012, len=008: "PC622019" (string)
> 
>   type=050, len=004: 10.28.0.172 (ipv4-address)
> 
>   type=053, len=001: 3 (uint8)
> 
>   type=055, len=014: 1(uint8) 3(uint8) 6(uint8) 15(uint8) 31(uint8)
> 33(uint8) 43(uint8) 44(uint8) 46(uint8) 47(uint8) 119(uint8) 121(uint8)
> 249(uint8) 252(uint8)
> 
>   type=060, len=008: "MSFT 5.0" (string)
> 
>   type=061, len=007: 01:a0:51:0b:0c:24:93
> 
>   type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0),
> domain-name='pc622019.itu.local' (partial)
> 
> 2019-08-21 13:40:24.684 DEBUG [*kea-dhcp4.bad-packets*/41217]
> DHCP4_NO_LEASE_INIT_REBOOT [hwtype=1 a0:51:0b:0c:24:93],
> cid=[01:a0:51:0b:0c:24:93], tid=0xef9810de: no lease for address
> 10.28.0.172 requested by INIT-REBOOT client
> 
>  
> 
> -- 
> 
> Med venlig hilsen / With best regards
> 
> Thomas Andersen
> 
>  
> 
> Network Architect
> 
>  
> 
> IT University of Copenhagen
> 
> Rued Langgaards Vej 7
> 
> 2300 København S
> 
>  
> 
> Phone: +45 72185249
> 
>  
> 
> 
> 
>  
> 
> **NEVER DISCLOSE YOUR PASSWORD OR SHOE SIZE - NOT EVEN TO YOUR DENTIST**
> 
>  
> 
> 
> ___
> 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] DHCPv6 vendor-specific options

[Marcin Siodelski]

Hi Laurent,

I missed one important thing in my previous email. In order to have
option FDN included in the response you need to also add the following
parameter:

"always-send": true

to the option data for this option. So something like this:

{
"name": "FND",
"code": 1,
"space": "vendor-26484",
"data": "fd05::4:d",
"always-send": true
}

Please let me know how it went.

Marcin

On 19/07/2019 16:40, Laurent Aubert (laaubert) wrote:
> Hi Marcin,
> 
>  
> 
> Unfortunately it didn't work:
> 
>  
> 
> msgtype=7(REPLY), transid=0xad82a7
> 
> type=1, len=00012: 00:03:00:1b:00:17:3b:07:00:41:00:2c
> 
> type=2, len=00014: 00:01:00:01:24:ba:4e:2e:02:fe:4a:73:d2:48
> 
> type=3(IA_NA), len=00040: iaid=0, t1=60, t2=120,
> 
> options:
> 
>   type=5(IAADDR), len=00024: address=2001:db8:beef::2,
> preferred-lft=2592000, valid-lft=2592000
> 
> type=00014, len=0:
> 
> *type=00017, len=4: 26484 (uint32)*
> 
> type=00025(IA_PD), len=00056: iaid=0, t1=0, t2=0,
> 
> options:
> 
>   type=00013, len=00040: NoPrefixAvail(6) "Sorry, no prefixes could be
> allocated."
> 
> 1 relay(s):
> 
> relay[0]: msg-type=13(RELAY_REPLY), hop-count=0,
> 
> link-address=2001:db8:beef::, peer-address=fe80::217:3b07:41:2c, 1 option(s)
> 
> type=00018, len=4: 00:00:00:16
> 
>  
> 
>  
> 
>  
> 
> # Option 17 definition for CG-Mesh
> 
>   "option-def": [
> 
>     {
> 
>     "name": "FND",
> 
>     "code": 1,
> 
>     "space": "vendor-26484",
> 
>     "type": "ipv6-address",
> 
>     "record-types": "",
> 
>     "array": false,
> 
>     "encapsulate": ""
> 
>     }
> 
>   ],
> 
>  
> 
>   "option-data": [
> 
>     {
> 
>   "name": "vendor-opts",
> 
>  "data": "26484"
> 
>     },
> 
>     {
> 
>  "name": "FND",
> 
>  "code": 1,
> 
>  "space": "vendor-26484",
> 
>  "data": "fd05::4:d"
> 
>     }
> 
>   ],
> 
>  
> 
> Is there anything else I could try ? My last resort plan is to switch
> back to ISC.
> 
>  
> 
> Thanks for your help
> 
> Laurent.
> 
>  
> 
> On 2019-07-19, 3:45 PM, "Marcin Siodelski"  wrote:
> 
>  
> 
>     Hi Laurent,
> 
>    
> 
> Thank you for reporting this issue. It looks like you discovered a bug
> 
>     in our documentation. We're going to improve our tests in this area to
> 
>     verify that the server behaves as expected.
> 
>    
> 
> Meanwhile, can you please check whether replacing the
> 
>     "vendor-opts-space" with the "vendor-26484" in the option definition and
> 
>     option data section would make any difference for you?
> 
>    
> 
> Kind Regards,
> 
>    
> 
> Marcin Siodelski
> 
>     Sr. Software Engineer
> 
>     ISC
> 
>    
> 
> On 19/07/2019 14:06, Laurent Aubert (laaubert) wrote:
> 
>     > HI,
> 
>     >
> 
> > 
> 
> >
> 
> > I’m struggling to configure my DHCP server to send a specific vendor
> 
>     > option. My config is the following:
> 
>     >
> 
> > 
> 
> >
> 
> > 
> 
> >
> 
> > # Option 17 definition for CG-Mesh
> 
>     >
> 
> >   "option-def": [
> 
>     >
> 
> > {
> 
>     >
> 
> > "name": "FND",
> 
>     >
> 
> > "code": 1,
> 
>     >
> 
> > "space": "vendor-opts-space",
> 
>     >
> 
> > "type": "ipv6-address",
> 
>     >
> 
> > "array": false,
> 
>     >
> 
> > "encapsulate": ""
> 
>     >
> 
> > }
> 
>     >
> 
> >   ],
> 
>     >
> 
> > 
> 
> >
> 
> >   "option-data": [
> 
>     >
> 
> > {
> 
>     >
> 
> >  "name": "vendor-

Re: [Kea-users] DHCPv6 vendor-specific options

[Marcin Siodelski]

Hi Laurent,

Thank you for reporting this issue. It looks like you discovered a bug
in our documentation. We're going to improve our tests in this area to
verify that the server behaves as expected.

Meanwhile, can you please check whether replacing the
"vendor-opts-space" with the "vendor-26484" in the option definition and
option data section would make any difference for you?

Kind Regards,

Marcin Siodelski
Sr. Software Engineer
ISC

On 19/07/2019 14:06, Laurent Aubert (laaubert) wrote:
> HI,
> 
>  
> 
> I’m struggling to configure my DHCP server to send a specific vendor
> option. My config is the following:
> 
>  
> 
>  
> 
> # Option 17 definition for CG-Mesh
> 
>   "option-def": [
> 
>     {
> 
>     "name": "FND",
> 
>     "code": 1,
> 
>     "space": "vendor-opts-space",
> 
>     "type": "ipv6-address",
> 
>     "array": false,
> 
>     "encapsulate": ""
> 
>     }
> 
>   ],
> 
>  
> 
>   "option-data": [
> 
>     {
> 
>  "name": "vendor-opts",
> 
>  "data": "26484"
> 
>     },
> 
>     {
> 
>  "name": "FND",
> 
>  "space": "vendor-opts-space",
> 
>      "data": "fd05::4:d"
> 
>     }
> 
>   ],
> 
>  
> 
>  
> 
> Below is what the server is replying to the client with only the
> enterprise-id is in option 17. There is no Data:
> 
>  
> 
> msgtype=7(REPLY), transid=0x6fc166
> 
> type=1, len=00012: 00:03:00:1b:00:17:3b:07:00:41:00:2c
> 
> type=2, len=00014: 00:01:00:01:24:ba:4e:2e:02:fe:4a:73:d2:48
> 
> type=3(IA_NA), len=00040: iaid=0, t1=60, t2=120,
> 
> options:
> 
>   type=5(IAADDR), len=00024: address=2001:db8:beef::2,
> preferred-lft=2592000, valid-lft=2592000
> 
> type=00014, len=0:
> 
> *type=00017, len=4: 26484 (uint32)*
> 
> type=00025(IA_PD), len=00056: iaid=0, t1=0, t2=0,
> 
> options:
> 
>   type=00013, len=00040: NoPrefixAvail(6) "Sorry, no prefixes could be
> allocated."
> 
> 1 relay(s):
> 
> relay[0]: msg-type=13(RELAY_REPLY), hop-count=0,
> 
> link-address=2001:db8:beef::, peer-address=fe80::217:3b07:41:2c, 1 option(s)
> 
> type=00018, len=4: 00:00:00:16
> 
>  
> 
>  
> 
> What am I missing ? I read the user guide a hundred times and my config
> looks the same.
> 
>  
> 
> Any help would be really appreciated !! I’m pulling my hair off on that
> one !!
> 
>  
> 
> Thanks,
> 
> Laurent.
> 
> 
> ___
> 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] Host reservations, bootfilename and client classes

[Marcin Siodelski]

Hello Branimir,

Please see inline.

On 07/05/2019 16:14, brna62petsto wrote:
> Hello Marcin,
> 
> Thanks for your reply. What mkangelo and I are trying to do is to replace
> Microsoft DHCP server which has a feature to create host reservations with
> two option 67 values which are served to the client based on the class
> (type) of the client - for example return undionly.kpxe when client is pxe
> return https://api.example.com/customurl/ when client is gpxe
> 

If they are just two different values for option 67, why do they have to
be stored in the database? Can they be specified in the config file
within the classes definition?

> Client class is extracted from DHCP Discover packets:
> IF Option [77] == gPXE then second value is being returned
> ELSEIF Option [60] == "PXEClient:Arch:0:UNDI:002001" then first value is
> returned
> 
> Let me know if you have any suggestions how to create this logic in Kea.
> 
> Regards,
> Branimir 
> 
> 
> 
> --
> Sent from: http://kea-users.7364.n8.nabble.com/
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> 


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

Re: [Kea-users] Fwd: Memory leak on dhcp6

[Marcin Siodelski]

Nitzan,

I just wanted to let you know that so far we were unable to reproduce
the memory leak with duplicated server-id across the HA pair. Our test
did not include prefix delegation, only IA_NAs. Are your clients
requesting both address assignment and prefix delegation in the single
transaction?

Thanks,

Marcin

On 07/05/2019 10:49, Nitzan Tzelniker wrote:
> Thanks for your support. 
> Unless I miss it in the logs it might also be a good idea to have error
> message if both servers have the same server-id 
> 
> Thanks
> 
> Nitzan
> 
> On Tue, May 7, 2019 at 11:45 AM Marcin Siodelski  <mailto:mar...@isc.org>> wrote:
> 
> Hello Nitzan,
> 
> Thank you for sharing this information. We'll try to reproduce this
> behavior on our end. If the problem occurs, we'll investigate and fix it
> because the duplicate server id is surely not a good reason for leaking
> memory ;-)
> 
> Marcin Siodelski
> 
> DHCP Software Engineer,
> ISC
> 
> On 07/05/2019 10:26, Nitzan Tzelniker wrote:
> > Hi,
> >
> > Just for anybody else that has this issue 
> > The issue was that I had the same server-id on both servers as we
> clone
> > the VM of the first server after it create the server-id
> > I dont know why it cause memory leak.
> >
> > Thenks
> >
> > Nitzan
> >
> >
> > On Mon, May 6, 2019 at 6:56 PM Marcin Siodelski  <mailto:mar...@isc.org>
> > <mailto:mar...@isc.org <mailto:mar...@isc.org>>> wrote:
> >
> >     Hi Nitzan,
> >
> >     We're trying to reproduce this issue using our test tools. If
> the leak
> >     is related to the traffic volume processed by the server, it
> would be
> >     useful for us to know the average number of packets/second
> that your
> >     primary server is receiving.
> >
> >     You say that the memory consumption grows to 28% within an
> hour but I
> >     don't know how many packets the server has received and
> processed to
> >     reach that level. If you can provide the average DHCP traffic
> rate we
> >     can craft the test that best mirrors your situation and
> confirm whether
> >     or not we see the same thing.
> >
> >     Thanks in advance,
> >
> >     Marcin Siodelski
> >     DHCP Software Engineer,
> >     ISC
> >
> >     On 05/05/2019 16:29, Nitzan Tzelniker wrote:
> >     > Hi,
> >     >
> >     > It seems that the issue is related to the HA
> >     > After I commented the HA part the memory consumption is
> stayed low 
> >     > I am adding the relevant configuration if you have any idea
> >     >
> >     > Thanks
> >     >
> >     > Nitzan
> >     >
> >     > Standby server ha configuration part: 
> >     >
> >     >     "hooks-libraries": [
> >     >         {
> >     >             "library":
> "/usr/local/lib/hooks/libdhcp_lease_cmds.so",
> >     >             "parameters": { }
> >     >         },
> >     >         {
> >     >             "library": "/usr/local/lib/hooks/libdhcp_ha.so",
> >     >             "parameters": {
> >     >                 "high-availability": [ {
> >     >                     "this-server-name": "KEA_DHCPv6_2",
> >     >                     "mode": "hot-standby",
> >     >                     "heartbeat-delay": 1,
> >     >                     "max-response-delay": 2,
> >     >                     "max-ack-delay": 1,
> >     >                     "max-unacked-clients": 0,
> >     >                     "peers": [
> >     >                         {
> >     >                             "name": "KEA_DHCPv6_1",
> >     >                             "role": "primary",
> >     >                             "auto-failover": true
> >     >                         },
> >     >                         {
> >     >                             "name": "KEA_DHCPv6_2",
> >     >                      

Re: [Kea-users] Use perfdhcp to test IoT DHCP server?

[Marcin Siodelski]

Right, and such conflict is a usual side effect of making perfdhcp
simulate relayed traffic. The relay operates on port 67 (rather than
68), so it may be in conflict with running DHCP services on the given
machine. I can only suggest shutting down dnsmasq if possible.

Marcin

On 07/05/2019 13:37, Rick Graham wrote:
> Looks like dnsmasq is running on the same host where perfdhcp was
> launched. I'm not sure how/if I can change this at the moment.
> 
> On Tue, May 7, 2019 at 1:23 PM Marcin Siodelski  <mailto:mar...@isc.org>> wrote:
> 
> This seems to indicate that there is some other process bound to the
> address of 10.20.100.12, port 67 on that machine. Most likely a DHCP
> server. Are you running your DHCP server under test on the same machine
> as perfdhcp?
> 
> Marcin
> 
> On 07/05/2019 13:14, Rick Graham wrote:
> > Still no luck.  :-(
> >
> > $ sudo perfdhcp -xaeistT -r1 -n1 -i -l wlp8s0 10.20.100.10
> > Running: perfdhcp -x aeistT -r 1 -n 1 -i -l wlp8s0 10.20.100.10
> > IPv4
> > DISCOVER-OFFER only
> > lease-type=address-only (IA_NA option added to the client's request)
> > rate[1/s]=1
> > num-request[0]=1
> > drop-time[0]=1
> > drop-time[1]=1
> > aggressivity=1
> > elp-offset=-1
> > sid-offset=-1
> > rip-offset=-1
> > diagnostic-selectors=aeistT
> > interface=wlp8s0
> > server=10.20.100.10
> > Set MAC to 00::0c::01::02::03::04
> > Set DUID to 0001000124642485000c01020304
> > Error running perfdhcp: Failed to bind socket 3 to
> 10.20.100.12/port=67 <http://10.20.100.12/port=67>
> > <http://10.20.100.12/port=67>
> >
> >
> > On Tue, May 7, 2019 at 12:44 PM Thomas Markwalder  <mailto:tm...@isc.org>
> > <mailto:tm...@isc.org <mailto:tm...@isc.org>>> wrote:
> >
> >     Try dropping the "-L 6767".
> >
> >     Cheers,
> >
> >     Thomas
> >
> 

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

Re: [Kea-users] Fwd: Memory leak on dhcp6

[Marcin Siodelski]

Hi Nitzan,

We're trying to reproduce this issue using our test tools. If the leak
is related to the traffic volume processed by the server, it would be
useful for us to know the average number of packets/second that your
primary server is receiving.

You say that the memory consumption grows to 28% within an hour but I
don't know how many packets the server has received and processed to
reach that level. If you can provide the average DHCP traffic rate we
can craft the test that best mirrors your situation and confirm whether
or not we see the same thing.

Thanks in advance,

Marcin Siodelski
DHCP Software Engineer,
ISC

On 05/05/2019 16:29, Nitzan Tzelniker wrote:
> Hi,
> 
> It seems that the issue is related to the HA
> After I commented the HA part the memory consumption is stayed low 
> I am adding the relevant configuration if you have any idea
> 
> Thanks
> 
> Nitzan
> 
> Standby server ha configuration part: 
> 
>     "hooks-libraries": [
>         {
>             "library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so",
>             "parameters": { }
>         },
>         {
>             "library": "/usr/local/lib/hooks/libdhcp_ha.so",
>             "parameters": {
>                 "high-availability": [ {
>                     "this-server-name": "KEA_DHCPv6_2",
>                     "mode": "hot-standby",
>                     "heartbeat-delay": 1,
>                     "max-response-delay": 2,
>                     "max-ack-delay": 1,
>                     "max-unacked-clients": 0,
>                     "peers": [
>                         {
>                             "name": "KEA_DHCPv6_1",
>                             "role": "primary",
>                             "auto-failover": true
>                         },
>                         {
>                             "name": "KEA_DHCPv6_2",
>                             "role": "standby",
>                             "auto-failover": true
>                         }
>                     ]
>                 } ]
>             }
>         }
>     ]
> }
> 
> kea-ctrl-agent.conf  from both servers (Only the ip address is different ) 
> 
> {
> 
> "Control-agent": {
>     "http-host": "1.1.1.X",
>     "http-port": 8080,
> 
>     "control-sockets": {
>         "dhcp4": {
>             "socket-type": "unix",
>             "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
>         },
>         "dhcp6": {
>             "socket-type": "unix",
>             "socket-name": "/tmp/kea-dhcp6-ctrl.sock"
>         }
>     },
> 
>     "hooks-libraries": [
>     ]
> },
> 
> "Logging":
> {
>   "loggers": [
>     {
>         "name": "kea-ctrl-agent",
>         "output_options": [
>             {
>                 "output": "/usr/local/var/log/kea-ctrl-agent.log"
>             }
>         ],
>         "severity": "INFO",
> 
>         "debuglevel": 0
>     }
>   ]
> }
> }
> -- Forwarded message -
> From: *Nitzan Tzelniker*  <mailto:nitzan.tzelni...@gmail.com>>
> Date: Fri, May 3, 2019 at 10:13 PM
> Subject: Memory leak on dhcp6
> To: mailto:kea-users@lists.isc.org>>
> 
> 
> Hi,
> 
> I am running two dhcpv6 server with high-availability
> We have about 2500 regular leases and 2500 PD leases
> The setup is working but it look like kea-dhcp6 leak memory 
> When it start (with all of the leases in the file ) it take less then 1%
> of the memory but after two hours it take 28% and if I will give it 8
> hours it will crash 
> 
> I don't see issue on the standby server only on the primary server
> 
> Anybody saw this behavior  
> Any idea how to debug it
> 
>  kea-dhcp6 -V
> 1.5.0
> tarball
> linked with:
> log4cplus 1.1.3
> OpenSSL 1.0.2k-fips  26 Jan 2017
> database:
> Memfile backend 2.1
> 
> Running on CentOS 7.6.1810 VM kernel 3.10.0-957.1.3.el7.x86 with 2 *
> vCPU and 2GB RAM 
> 
> bellow is the dhcp6 config file omitting 102 subsets 
> 
> {
> "Dhcp6": {
>     "interfaces-config": {
>         "interfaces": [ "ens192/:aef:aa77:83::100" ]
>     },
>     "mac-sources": [ &quo

Re: [Kea-users] Subnets in MySQL/MariaDB

[Marcin Siodelski]

Hello Jan,

Thanks for your inquiry. Kea 1.6.0 release will include a new feature,
Config Backend, which will allow for storing global DHCP parameters,
DHCP option definitions, shared networks and subnets in the MySQL
database. This is not yet documented because we're currently working on
the actual code. The Kea 1.6.0 release is expected in the summer.

If you're looking at the Kea 1.5.0 version, it indeed includes many
tables, but those tables are unused by this version.

If you're interested in the Config Backend design, it is available here:

https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration%20in%20db%20design

Marcin Siodelski
DHCP Software Engineer,
ISC


On 05/05/2019 01:45, Jan Sielemann wrote:
> Hello everyone,
> 
> I'm relatively new to KEA. I just wanted to check out the follow-up to
> DHCPD, especially because of the ability to store host-reservations in DB.
> 
> I successfully mastered hosts-definition yet, but my vision is to store
> as much configuration as possible inside the DB. I see, there are a lot
> of tables - also one for subnets.
> 
> Since I only defined "lease-database" and "hosts-database" in my
> kea-dhcp4.conf, I wonder if KEA would also have access to subnets and so on.
> 
> My feeling is, that the MySQL-Part is not documented that detailed I
> would like it to be - it took a little time to get the hosts
> running...but maybe my fault :)
> 
> Can someone give me a hint for further investigation on the MySQL-Topic?
> 
> 
> Best regards,
> 
> Jan
> 

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

Re: [Kea-users] Use perfdhcp to test IoT DHCP server?

[Marcin Siodelski]

The DHCPv4 protocol requires that the server sends packets to the
directly connected clients which don't have an address yet and the
clients without an address should be able to receive the DHCPACK. In
order to simulate directly connected clients, perfdhcp would need to
include extra complexity which doesn't seem to be worth the effort.

In order to overcome this problem, we implemented perfdhcp in such a way
that it simulates relayed traffic (sets giaddr to the IP address of the
local interface via which perfdhcp sends traffic). In relayed
configurations, the traffic is typically unicast to the server.

The perfdhcp tool accepts optional 'server' argument which can be
appended at the end of the command line which defaults to
255.255.255.255. I suggest that you try specifying a unicast address
where the DHCP server can be contacted instead of using the default
broadcast address. If you use the default, perfdhcp may not handle it
very well (depending on what the server sets as the source and
destination IP address in the DHCPACK).

Marcin Siodelski
DHCP Software Engineer,
ISC



On 05/05/2019 00:44, Rick Graham wrote:
> I compiled/installed v1.5 and I need a bit more help using perfdhcp.
> 
> With Wireshark I can see packets going to and from the DHCP server, but
> perfdhcp doesn't seem to see them.  It's very possible that I'm not
> using it correctly or that there is some other configuration that needs
> to be made.  I looked a little bit for a perfdhcp tutorial but didn't
> find one.
> 
> How should I use perfdhcp? Are there any requirements/setups required
> for the host where the command is run? ... or for the DHCP server?
> 
> Your help is greatly appreciated.
> Rick
> 
> [perfdhcp Command and Output]
> $ perfdhcp -xaeistT -r1 -n1 -B -L 6767 -l wlp8s0
> Running: perfdhcp -x aeistT -r 1 -n 1 -B -L 6767 -l wlp8s0
> IPv4
> lease-type=address-only (IA_NA option added to the client's request)
> rate[1/s]=1
> num-request[0]=1
> drop-time[0]=1
> drop-time[1]=1
> aggressivity=1
> local-port=6767
> broadcast
> elp-offset=-1
> sid-offset=-1
> rip-offset=-1
> diagnostic-selectors=aeistT
> interface=wlp8s0
> server=255.255.255.255
> Set MAC to 00::0c::01::02::03::04
> Set DUID to 000100012460cc9e000c01020304
> Reached max requests limit.
> ***Rate statistics***
> Rate: 0 4-way exchanges/second, expected rate: 1
> ***Statistics for: DISCOVER-OFFER***
> sent packets: 1
> received packets: 0
> drops: 1
> min delay: inf ms
> avg delay: Delay summary unavailable! No packets received.
> ***Statistics for: REQUEST-ACK***
> sent packets: 0
> received packets: 0
> drops: 0
> min delay: inf ms
> avg delay: Delay summary unavailable! No packets received.
> Late received packets: 0
> Late sent packets: 2
> Multiple packets receives: 0
> Short waits for packets: 2
> ***Timestamps for packets: DISCOVER-OFFER***
> Unavailable! No packets received.
> ***Timestamps for packets: REQUEST-ACK***
> Unavailable! No packets received.
> Interrupted
> xid-offset=4
> random-offset=35
> contents: 
>    01010601
> 0020   0a14640c000c0102
> 0040   0304
> 0060   
> 0080   
> 00a0   
> 00c0   
> 00e0   
> 0100   
> 0120   
> 0140   
> 0160   
> 0180   
> 01a0   
> 01c0   63825363
> 01e0   3501013707011c02030f060c3d070100
> 0200   0c01020304ff
> xid-offset=4
> random-offset=35
> srvid-offset=54
> time-offset=8
> ip-offset=240
> contents: 
> [Wireshark summary]
>   No.     Time           Source                HW Src Addr         
>  Destination           HW Dst Addr         Protocol Length Info
>        26 6.517873909    10.20.100.12          IntelCor_52:39:7e   
>  255.255.255.255       Broadcast           DHCP     304    DHCP
> Discover - Transaction ID 0x0
>   Frame 26: 304 bytes on wire (2432 bits), 304 bytes captured (2432
> bits) on interface 0
>   Ethernet II, Src: IntelCor_52:39:7e (44:85:00:52:39:7e), Dst:
> Broadcast (ff:ff:ff:ff:ff:ff)
>   Internet Protocol Version 4, Src: 10.20.100

Re: [Kea-users] problem with INIT_REBOOT

[Marcin Siodelski]

Supplementing the answer from Dave, I am sending the link to the documentation 
which clarifies the server's behavior depending on the authoritative flag 
setting:

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-authoritative

Hope that helps.

Marcin Siodelski
DHCP Software Engineer,
ISC

On 04/05/2019 00:40, Dave Swager wrote:
> I believe if you're running kea5 and set authoritative (will send nack
> to client) that will clear this problem
>
> On Fri, May 3, 2019 at 2:29 PM oc  <mailto:objective...@gmail.com>> wrote:
>
>     [new user]
>
>     We have multiple KEA servers hosted in our infrastructure (with
>     shared lease
>     database). Most recently, we noticed that our DHCP clients failed to
>     renew
>     their IP address as the KEA servers are rejecting INIT_REBOOT. It
>     appears to
>     be an expected behavior for a KEA server to ignore INIT_REBOOT if
>     the lease
>     was allocated by another KEA server.
>
>     In this particular case, even though all the KEA servers are running
>     (and
>     are seeing INIT_REBOOT request), none of them respond to INIT_REBOOT
>     requests.
>
>     What could be causing this problem? No changes to KEA servers
>     configuration.
>
>     We have another problem in the form of bad DHCP client implementation.
>     Unfortunately, our DHCP clients are not falling back to 4 way
>     exchange to
>     get a new lease when they see no response to INIT_REBOOT.
>
>     Is it possible for us to configure one of the other KEA servers to
>     respond
>     to "INIT_REBOOT" as they all share the same lease database and have
>     information on the existing lease.
>
>     Thanks
>
>
>
>
>     --
>     Sent from: http://kea-users.7364.n8.nabble.com/
>     ___
>     Kea-users mailing list
>     Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/kea-users
>
>
>
> -- 
> Dave
> m: 408-655-9704
>
> ___
> 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] Host reservations, bootfilename and client classes

[Marcin Siodelski]

Hello,

Your example JSON config didn't seem to make it through the email.

See my comments/questions inline.

On 30/04/2019 16:46, mkangelo wrote:
> Hi guys,
> 
> We are evaluating KEA (premium) as a potential replacement for our current
> DHCP infra, and we have few concerns over the following:
> 
> 1. Is it possible to have a custom bootFilename (option 67) set per host
> reservation while it references to a single client class? (this should not
> be part of the subnets).
> 

So, there is a subset of clients having host reservations, each client
having one of the classes assigned and each class coming with a
different option 67 value? Or it is that each client has its own option
67 value defined as the host reservation within the database?

> 2. Is it possible to prioritise bootFilename from a class (even if there is
> already a bootFilename set in the reservation) based on the matching client
> option (example 60, 77) ?
> 

It depends on the answer to the first question. Generally, options can
be freely ordered between classes. If the host reservation is made for a
class (not an option) and than for this class there is an option 67
value specified in the config file you can build the classes'
dependencies such that one or the other takes precedence. If you're
thinking to specify option 67 in the database (with host reservations),
then it becomes tricky because Kea has no knob to say that client class
specific option takes precedence over the option from the host reservation.

To expand on this, it would be useful to work on a specific example.

> To clarify:
> 
> - We need clients that have option 77 to receive bootFilename from a
> reservation and in case it doesn't have option 77 and matches just option 60
> to receive bootFilename from that class.
> 
> - There will be multiple classes configured, and we'd like the host
> reservations to be stored in a SQL database
> 

What do you mean by reservations? You mean values of the option 67 for
each host?

> 
> I'd appreciate some feedback.
> 
> 
> Example JSON config (classes and reservation - used for testing):
> 
> 
> 
> 
> 
> --
> Sent from: http://kea-users.7364.n8.nabble.com/
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> 

Marcin Siodelski
DHCP Software Engineer,
ISC
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] Kea 1.5 with MySQL Cluster

[Marcin Siodelski]

Fernando,

As it is stated in the Kea 1.5.0 documentation, the tables you have
issues with are unused in this release. They will be used in Kea 1.6.0.
Therefore, as long as you're using Kea 1.5.0, I see no issue with using
the workaround you're proposing.

Please note that I've created a new Kea ticket:
https://gitlab.isc.org/isc-projects/kea/issues/593 to consider the code
and/or schema changes to better facilitate cases like yours and possibly
remove the UPDATE CASCADE, but that has to be discussed between the Kea
developers first.

Marcin Siodelski
DHCP Software Engineer,
ISC



On 29/04/2019 12:41, Fernando Ruza Rodriguez wrote:
> Hi again!
> 
> I've read in the kea 1.5.0 release notes:
> https://ftp.isc.org/isc/kea/1.5.0/Kea150ReleaseNotes.txt the following:
> 
> /**Configuration Backend design** - The Configuration Backend feature is /
> /now planned for Kea 1.6.0. It will provide the ability to use a
> database as /
> /a source of configuration information for the Kea DHCP servers. Even
> though /
> /the Configuration Backend is not functional in the Kea 1.5.0 release, the /
> /design for this feature was created and some basic elements implementing /
> /this design are included in the current version. The most prominent
> change /
> /is the update of the MySQL schema to include new tables, constraints and /
> /indexes to be used by the Configuration Backend feature once it is /
> /implemented. These elements are currently unused, but they will be
> created /
> /in the existing database instances once the MySQL database is upgraded to /
> /the version supported by Kea 1.5.0 release. The design of the
> Configuration /
> /Backend is available at /
> /https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-des/
> /ign./
> 
> 
> And I see in the "Kea Configuration Backend Design:
> https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-design;
> that the both tables what I'm having problems with MySQL NDB cluster are
> for this Configuration Backend feature that it's not used by kea version
> 1.5.0 yet. So, Could I obviate these tables and keep engine to innodb in
> them and still use kea version 1.5.0 in MySQL NDB cluster ?? What do you
> think ??.
> 
> Thanks for any reply.
> 
> Regards, Fernando.
> 
> 
> -Mensaje original-
> *De*: Fernando Ruza Rodriguez  <mailto:fernando%20ruza%20rodriguez%20%3cfernan...@sescam.jccm.es%3e>>
> *Para*: Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org>
> *Asunto*: Re: [Kea-users] Kea 1.6 with MySQL Cluster
> *Fecha*: Mon, 29 Apr 2019 11:53:53 +0200
> 
> Sorry, I said kea version 1.6 and I wanted to say: *kea version 1.5*. It
> is a restriction regarding foreign keys and on update cascade:
> 
> https://dev.mysql.com/doc/mysql-cluster-excerpt/5.7/en/mysql-cluster-limitations-syntax.html
> 
> *Restrictions on foreign keys. * Support for foreign key constraints in
> NDB 7.5 is comparable to that provided by InnoDB
> <https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html>,
> subject to the following restrictions:
> 
>   * ON UPDATE CASCADE is not supported when the reference is to the
> parent table's primary key.
> 
> This is because an update of a primary key is implemented as a
> delete of the old row (containing the old primary key) plus an
> insert of the new row (with a new primary key). This is not visible
> to the NDB kernel, which views these two rows as being the same, and
> thus has no way of knowing that this update should be cascaded.
> 
> I have downloaded and installed kea version 1.4.0-P1 and replaced in
> mysql script the engine from INNODB to NDBCLUSTER and now the database
> is created correctly.
> 
> Thanks and regards,
> 
> Fernando. 
> 
> 
> -Mensaje original-
> *De*: Fernando Ruza Rodriguez  <mailto:fernando%20ruza%20rodriguez%20%3cfernan...@sescam.jccm.es%3e>>
> *Para*: Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org>
> *Asunto*: [Kea-users] Kea 1.6 with MySQL Cluster
> *Fecha*: Fri, 26 Apr 2019 14:55:19 +0200
> 
> Hi, I'm trying to setup kea 1.6 with MySQL NDB Cluster backend. Has
> someone experienced with them?
> 
> I have changed the "ENGINE" in all create tables statements with
> ENGINE=NDBCLUSTER in the script dhcpdb_create.mysql however when I run
> it I get the following errors, I think, when created the tables
> keadhcp.dhcp4_pool and keadhcp.dhcp6_pool for the foreign keys they have:
> 
> ...
> 
> ERROR 1215 (HY000): Cannot add foreign key constraint
> Query OK, 0 rows affected (0,46 sec)
> 
> Query OK, 0 rows affected (1,50 sec)
> Records: 0  Duplicates: 0  Warnings: 0
> 
> Query OK, 0 rows affected (1

Re: [Kea-users] got unexpected keyword "control-socket" in DhcpDdns map.

[Marcin Siodelski]

Hello Ivan,

Thanks for your inquiry. The bottom line is that the Management API is
not supported by the Kea D2 server in the 1.5.0 release.

It seems to be misleading on our web page (https://www.isc.org/kea/)
that the link to the Kea Administrator Reference leads to a bleeding
edge version of the manual, rather than to a version released with 1.5.0.

The 1.5.0 version of the manual can be found here:
https://ftp.isc.org/isc/kea/cur/doc/kea-guide.html

The version of the manual you were referring to contains the
documentation of the changes we have made after 1.5.0 release. Hence the
confusion.

The Management API for the D2 server will be available in the 1.6.0 release.

Marcin Siodelski
Sr. Software Engineer
ISC


On 07/03/2019 09:36, Ivan Sy wrote:
> root@server1:/usr/local/etc/kea # /usr/local/etc/rc.d/kea restart
> INFO/keactrl: Stopping kea-dhcp4...
> INFO/keactrl: Stopping kea-dhcp6...
> INFO/keactrl: kea-dhcp-ddns isn't running.
> INFO/keactrl: Stopping kea-ctrl-agent...
> Starting kea.
> INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c
> /usr/local/etc/kea/kea-dhcp4.conf
> INFO/keactrl: Starting /usr/local/sbin/kea-dhcp6 -c
> /usr/local/etc/kea/kea-dhcp6.conf
> INFO/keactrl: Starting /usr/local/sbin/kea-dhcp-ddns -c
> /usr/local/etc/kea/kea-dhcp-ddns.conf
> INFO/keactrl: Starting /usr/local/sbin/kea-ctrl-agent -c
> /usr/local/etc/kea/kea-ctrl-agent.conf
> root@server1:/usr/local/etc/kea # Service failed: Could Not load
> configuration file: Configuration parsing failed:
> /usr/local/etc/kea/kea-dhcp-ddns.conf:3.8-23: got unexpected keyword
> "control-socket" in DhcpDdns map.
> 
> root@server1:/usr/local/etc/kea # /usr/local/sbin/kea-dhcp-ddns -v
> 1.5.0
> 
> 
> It looks like this section in Kea 1.5 Admin Reference Manual
> 
> 12.3.2. Management API for the D2 Server
> 
> The management API allows the issuing of specific management commands,
> such as configuration retrieval or shutdown. For more details, see
> Chapter 17, /Management API/
> <https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#ctrl-channel>.
> Currently the only supported communication channel type is UNIX stream
> socket. By default there are no sockets open. To instruct Kea to open a
> socket, the following entry in the configuration file can be used:
> 
> "DhcpDdns": {
> "control-socket": {
> "socket-type": "unix",
> "socket-name": *|"/path/to/the/unix/socket"|*
> },
> ...
> }
> 
> 
> is not working for me. what am I missing?
> 
> 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] Kea 1.4.0-P1-3 kea-ctrl-agent crashing on Ubuntu 18.10

[Marcin Siodelski]

Hello Russell,

It seems that you're trying to attach the HA hooks library to the Kea
Ctrl Agent process, while it must be attached to either Kea DHCPv4 or
DHCPv6 process. See:
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#high-availability-library
for the details.

Regarding the example configurations. Did you see the examples in the
doc/examples/kea4/ha-load-balancing-primary.json and the
doc/examples/kea6/ha-hot-standby.json ?

Kind Regards,

Marcin Siodelski
Senior Software Engineer
ISC

On 20/01/2019 13:21, russell aspinwall wrote:
> Hi,
> 
> After fixing my configuration I have found that the kea-ctrl-agent is
> now crashing regularly on Ubuntu 18.10
> 
>> 2019-01-20 11:58:32.282 INFO  [kea-ctrl-agent.dctl/26624]
>> DCTL_STARTING Control-agent starting, pid: 26624, version: 1.4.0-P1
>> 2019-01-20 11:58:32.287 INFO  [kea-ctrl-agent.ha-hooks/26624]
>> HA_CONFIGURATION_SUCCESSFUL HA hook library has been successfully
>> configured
>> 2019-01-20 11:58:32.287 INFO  [kea-ctrl-agent.ha-hooks/26624]
>> HA_INIT_OK loading High Availability hooks library successful
>> 2019-01-20 11:58:32.287 INFO  [kea-ctrl-agent.hooks/26624]
>> HOOKS_LIBRARY_LOADED hooks library
>> /usr/lib/aarch64-linux-gnu/hooks/libdhcp_ha.so successfully loaded
>> 2019-01-20 11:58:32.287 INFO  [kea-ctrl-agent.ctrl-agent/26624]
>> CTRL_AGENT_HTTP_SERVICE_STARTED HTTP service bound to address
>> 192.168.26.248:8080
>> 2019-01-20 11:58:32.288 INFO  [kea-ctrl-agent.dctl/26624]
>> DCTL_CONFIG_COMPLETE server has completed configuration: listening on
>> 192.168.26.248, port 8080, control sockets: dhcp4, 1
>> lib(s):/usr/lib/aarch64-linux-gnu/hooks/libdhcp_ha.so kea-ctrl-agent:
>> /usr/include/boost/smart_ptr/shared_ptr.hpp:734: typename
>> boost::detail::sp_member_access::type
>> boost::shared_ptr::operator->() const [with T = isc::ha::HAService;
>> typename boost::detail::sp_member_access::type =
>> isc::ha::HAService*]: Assertion `px != 0' failed.
> 
> 
> I do think the manuals for Kea could be improved particularly with
> working examples HA configurations.
> 
> 
> 
> 
> ___
> 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 Load Balancing not working

[Marcin Siodelski]

Hello,

First of all, please note that the HA time values, i.e.
"heartbeat-delay", "max-ack-delay" and "max-response-delay" are
specified in milliseconds. Therefore, in your case heartbeat messages
will be sent every 10ms, which is very high frequency potentially
impacting server's performance. Also, "max-ack-delay" being a time after
which the server considers the DHCP packet to not be answered by the
partner is also very low in your case. If these low values are provided
for testing purposes only, this is fine.

I am guessing the problem whereby you don't observe transition of the
surviving server from "load-balancing" to "partner-down" may be caused
by the fact that you don't simulate different clients but only a single
client.

Your setting of "max-unacked-messages" of 10 means that the surviving
server will be watching traffic that should be processed by the offline
partner and it expects at least 10 messages from different clients to
not be answered before it transitions to "partner-down". If you're
sending DHCP messages from a single MAC address it counts as one client.
Try to lower the value of "max-unacked-messages" to 1 or even set it to
0 to disable this mechanism causing the surviving server to transition
to the "partner-down" state when it sees heartbeats to fail.

If your test tool allows for simulating many different clients, that's
even better, but the number of different clients should be at least 20.
That way, 10 should send DHCP queries to the dead server.

Kind Regards,
Marcin Siodelski
ISC DHCP Engineering

On 08.10.2018 15:07, sven.roeh...@web.de wrote:
>  
> 
>  
> 
> Hi,
> 
> i have a setup with 2 KEA servers in load-balancing configuration. Both
> server are working when active but when I shutdown one server to
> simulate an error I do get an OFFER but REQUESTS are not answered.
> 
> Do I have a wrong understanding on how the HA load-balancing works or
> maybe I have  a configuration issue. I expect server1 to enter
> partner-down state but I don´t see anything on logs except “The server
> is likely to be offline, error code 1”.
> 
> Why gets a request parked when a partner state is down “packet is
> parked, because a callout set the next step to PARK”?
> 
>  
> 
> "high-availability": [ {
> 
>    
> "this-server-name": "server1",
> 
>     "mode":
> "load-balancing",
> 
>    
> "heartbeat-delay": 10,
> 
>    
> "max-ack-delay": 10,
> 
>    
> "max-response-delay": 60,
> 
>    
> "max-unacked-messages": 10,
> 
>     "peers": [
> 
>   
>   
> {
> 
>   
>  
> "name": "server1",
> 
>   
>  
> "url": "http://192.168.62.5:8080/;,
> 
> 
>    "role": "primary",
> 
>   
>  
> "auto-failover": true
> 
>   
>  
> },
> 
>    
> {
> 
>   
>  
> "name": "server2",
> 
>   
>  
> "url": "http://192.168.62.6:8080/;,
> 
>   
>  
> "role": "secondary",
> 
>   
>  
> "auto-failover": true
> 
>   
>  }
> 
>     ]
> 
>     } ]
> 
>  
> 
>

Re: [Kea-users] kea and ha modes

[Marcin Siodelski]

Hello Philippe,

Thanks for your inquiry. Please see my answers inline.

Kind Regards,

Marcin Siodelski
ISC DHCP Engineering


On 05.10.2018 09:02, Philippe Maechler wrote:
> hello kea users
> 
>  
> 
> I’m once again looking for a way to make our dhcp setup more stable.
> Currently we use the isc dhcpd without failover. For each active dhcp
> server, there is an inactive one (cold standby?), which gets the
> configuration and lease file every few minutes. If something breaks, we
> have to manually take the broken server offline and activate the second
> one. This setup worked more or less stable for more than 10 years.
> 
>  
> 
> But still this setup has it’s disadvantages that I’d like to get rid of.
> Of we have a maintenance window and have to take the router, where the
> active server is connected to down, we don’t have a running dhcp setup.
> New clients won’t be able to get a lease and existing clients fail to
> renew their lease.
> 
>  
> 
> From the kea-user-guid
> (https://kea.isc.org/docs/kea-guide.html#high-availability-library)
> 
>  
> 
> The Kea HA hook library supports two configurations also known as HA
> modes: *load balancing* and *hot standby*…
> 
>  
> 
> In the *load balancing* mode…
> 
> When one of the servers allocates a lease for a client, it notifies the
> partner server over the control channel (RESTful API), so as the partner
> can save the lease information in its own database. *If the
> communication with the partner is unsuccessful, the DHCP query is
> dropped and the response is not returned to the DHCP client*. If the
> lease update is successful, the response is returned to the DHCP client
> by the server which has allocated the lease.
> 
>  
> 
>  
> 
> In the *hot standby* configuration…
> 
> The secodary server receives lease updates from the primary over the
> control channel…
> 
> When the secondary server detects the failure of the primary, it starts
> responding to all DHCP queries.
> 
>  
> 
> My question is:
> 
> In the load balancing mode, when one server dies, both servers won’t
> hand out leases, because the notification over the control channel
> fails, right?. If so, where is the HA part in here?
> 
> 

The doc describes the case when both servers are in "load-balancing"
state, i.e. both have been so far exchanging lease updates successfully.
When lease updates start to fail and the heartbeat messages start to
fail the surviving server still remains in the "load-balancing" state
until it "assures" that the other server is offline. This can take a
while, depending on the configuration. The surviving server continues to
send heartbeats to the partner and if the heartbeats fail longer than
configured amount of time (e.g. 1 minute) it may already consider the
partner do be down. It may also use additional failure detection
mechanism, which examines 'secs' time in the DHCP messages sent to the
partner. This latter mechanism can be disabled administratively.

When the surviving server eventually "assures" that the partner is down
(heartbeats plus optionally 'secs' values verification) it transitions
to the "partner-down" state, where it is going to respond to ALL DHCP
messages directed to the DHCP system.

So, there is a narrow window of time when the DHCP clients may fail to
get responses from the system when surviving server is verifying whether
the partner is alive or dead. In this case the server drops DHCP
messages for which it fails to send lease updates to the partner (which
is possibly down).

Hope that clarifies a bit.

 
> 
> In a hot standby configuration, what happens when the lease update
> fails? Will the “primary” server hand out the lease or not?
> 
>  

This is the same situation as in the "load-balancing" case described
above. The primary server doesn't respond as long as it remains in the
"hot-standby" state. When the primary sees that lease updates are
unsuccessful and the heartbeats fail etc. it will transition to the
"partner-down" state where it is going to respond to DHCP messages and
will stop sending lease updates to the partner until the partner wakes
up and the primary can see it.

> 
>  
> 
> Prior to 1.4 there were several messages on this list about a setup with
> multiple (two) kea instances accessing both the same database (cluster).
> Is such a setup supported/recommended or not? I guess not, because the
> initial text on the above url states, that “supports two configurations
> also known as HA modes”
> 
> 

The cited text refers to the use of HA hooks library when Kea servers
exchange lease updates directly, without the database being involved. It
is possible to use the database in your setup, even without

Re: [Kea-users] Bug in the leases4_committed hook ?

[Marcin Siodelski]

Hello,

You seem to have the type of the arguments wrong. It should rather be:

Pkt4Ptr query4;
Lease4CollectionPtr leases4;
Lease4CollectionPtr deleted_leases4;

We implemented collection of leases in this hook point for DHCPv4 to
keep parity with DHCPv6. In most cases, these collections will store at
most one lease.

Marcin Siodelski

DHCP Engineering
ISC

On 21.09.2018 14:55, Hreiðar Jóelsson wrote:
> Hi, I’m any of you had problems with the leases4_committed hook? I’m
> getting strange errors using it. If I simply try to log some message
> from it I’m getting the following error.
> 
>  
> 
> 2018-09-21 10:57:04.843 ERROR [kea-dhcp4.callouts/1442]
> HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook 1 registered
> by library with index leases4_committed (callout address
> 0x7f8803d131c3): boost::bad_any_cast: failed conversion using
> boost::any_cast (callout duration: 0.063 ms)
> 
>  
> 
> Here is the hook code I’m currently using:
> 
>  
> 
> int leases4_committed(CalloutHandle& handle) {
> 
>     Pkt4Ptr query;
> 
>     Lease4Ptr leases, deleted_leases;
> 
>     handle.getArgument("query4", query);
> 
>     handle.getArgument("leases4", leases);
> 
>     handle.getArgument("deleted_leases4", deleted_leases);
> 
>  
> 
>     LOG_DEBUG(my_logger,50, "I'm at leases4_committed hook");
> 
>  
> 
>     return 0;
> 
> }
> 
>  
> 
> p.s I’m using this logger in other hooks in the same file without any
> problems.
> 
>  
> 
>  
> 
> Regards, Hreiðar.
> 
>  
> 
> 
> 
> ___
> 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] Enable lease affinity with MySQL backend

[Marcin Siodelski]

Tim,

Kea has a built in support for keeping an expired lease around for a
configurable amount of time, which is driven by
"expired-leases-processing" parameters described in the Kea User's
Guide. In other words, if the lease expires (client does not renew the
lease), the server won't remove this lease from the database
immediately, but will rather wait a configured amount of time before it
removes it. This doesn't preclude other clients from getting the lease
if they request it, but in most cases the expired lease will simply be
re-assigned to the client who had been using it before.

Having said that, this doesn't work for cases when the client sends a
Release to indicate that it stops using the lease. In such cases, the
lease is removed from the database upon receiving the Release. There are
no configuration knobs to keep the lease in the database for the client
after the client releases the lease.

The only possibility I see to address your use case at the moment is to
write a simple hooks library which drops the received Release packets.
The server won't process them and the leases will be left to expire in
the database. When the client reboots it should get the same lease. That
involves C++ coding though.

Kind Regards,

Marcin Siodelski
DHCP Engineering
ISC

On 13.09.2018 23:40, Tim St. Pierre wrote:
> Has anyone been able to get lease affinity to work with a MySQL backend?
> 
> I am using 1.3 for dhcpv4 and dhcpv6, and whenever a client issues a
> release, the entry is immediately removed from the database.  I would
> like the lease to be retained at least until it expires so that the
> customer will get the same address and prefix when their CPE comes back
> up.  Without it, they get a new delegated prefix and public address any
> time their equipment reboots, which causes their whole network to
> renumber.  
> 
> I don't want to go through the trouble of creating a host for each
> customer, I just want them to keep the address they get as long as they
> renew it from time to time.
> 
> I can see lots of references to a remove_lease variable, but I can't
> seem to find the configuration variable to set it to false.
> 
> -Tim
> 
> 
> ___
> 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-dhcp4 1.4.0-P1 HA features

[Marcin Siodelski]

  }
>             ]
> 
>         },
> 
>   "hooks-libraries": [
> {
>             "library": "/opt/kea/usr/lib/hooks/libdhcp_lease_cmds.so",
>             "parameters": { }
>         },
> {
>             "library": "/opt/kea/usr/lib/hooks/libdhcp_ha.so",
>             "parameters": {
>                 "high-availability": [ {
>                     "this-server-name": "dhcp-11",
>                     "mode": "load-balancing",
>                     "heartbeat-delay": 10,
>                     //"max-response-delay": 1,
>                     "max-ack-delay": 5,
>                     "max-unacked-clients": 5,
>                     "peers": [
>                         {
>                             "name": "dhcp-11",
>                             "url": "http://10.58.0.11:8080/;,
>                             "role": "primary",
>                             "auto-failover": true
>                         },
>                         {
>                             "name": "dhcp-12",
>                             "url": "http://10.58.0.12:8080/;,
>                             "role": "secondary",
>                             "auto-failover": true
>                         }
>                     ]
>                 } ]
>             }
>         }
> 
>   ]
> 
> },
> 
> 
> regards
> i
> 
> št 13. 9. 2018 o 13:23 Marcin Siodelski  <mailto:mar...@isc.org>> napísal(a):
> 
> On 13.09.2018 09:03, Ivan Stenda wrote:
> > Hello guys,
> >
> > I am trying to set up HA on $subj with no luck. Managed peers to
> talk in
> > between via kea-ctrl-agent, lease updates send from host to host and
> > vice versa but on simulated failure clients are not served seamless.
> > They are doing whole DORA because working host does not send OFFER
> from
> > failed peer pool ...
> >
> > Maybe I am wrong about networking around KEA. Could someone guide
> me for
> > networking setup in case of UDP socket and relay hosts ?
> >
> > regards
> > i
> >
> >
> > ___
> > Kea-users mailing list
> > Kea-users@lists.isc.org <mailto:Kea-users@lists.isc.org>
> > https://lists.isc.org/mailman/listinfo/kea-users
> >
> 
> Hello Ivan,
> 
> It is hard to say without looking into configurations of both of your HA
> peers.
> 
> I guess the first question is whether the server that takes over the
> traffic from the failed partner sends an OFFER (according to your logs)
> and this OFFER doesn't go through the network, or the OFFER is not
> generated by the server. Also, when you're expecting those offers do you
> observe the server which should send this offer being in the
> "partner-down" state (according to logs)?
> 
> Marcin Siodelski
> ISC DHCP 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] Basic Question: Using the Control Agent

[Marcin Siodelski]

On 17.07.2018 19:27, Phoebe Lee wrote:
> Hi!
> Not sure how to run my CA. When I go to the URL of the CA it just says:
> result: 400
> test: "Bad Request" 
> 
> When I run commands through the kea-shell it works correctly with the
> same host and port parameters. If the CA was running correctly would I
> be able to issue JSON commands for my hooks through this URL?
> 
> Phoebe
> 
> 
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> 

Hi,

I realize that this thread is a bit old, but in case you haven't found
the solution please have a look into Kea User's Guide:

https://kea.isc.org/docs/kea-guide.html#ctrl-channel-client

It includes an example of using curl to generate a proper command. The
bottom line is that the command must include application/json content
type header, must be sent using POST (rather than GET) and the JSON
command must be well formed.

If you go to the URL of the CA with a web browser you're getting Bad
Request because the browser would use GET (not POST) and would likely
use text/html as a content type. Not to mention that it wouldn't send
any command that Kea can understand.

Hope that helps,

Marcin Siodelski
ISC Engineering
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] DHCP4 not starting or writing log file

[Marcin Siodelski]

One of the problems with logging configuration is that until you
successfully configure the server it can't really use the log file
location specified in the Kea configuration file. Instead it will use
default locations.

The following section of the Kea User's Guide:

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#logging-during-startup

describes how to influence where the default logging goes. This may help
you determine why the server is not starting. The location of the
default log file being used before the server configures is
prefix/var/kea/kea.log, where prefix is where Kea server is installed.
After the server is started and configured successfully, the logging
should go to the locations specified in the Kea config files.

Marcin Siodelski
ISC Engineering

On 17.07.2018 16:49, McBride Lawrence wrote:
> Centos 7.4
> 
>  
> 
> *Lawrence McBride*
> 
> Head of Voice and Data Networks
> 
>  
> 
> *NHS Informatics Merseyside*
> 
> *a  *Saturn House, Knowsley Business Park, Liverpool. L34 9GJ
> 
> *t   *0151 296 7668
> 
> *m *07795 370190**
> 
> *e  *lawrence.mcbr...@imerseyside.nhs.uk
> 
>  
> 
> Say helloto us online at www.imerseyside.nhs.uk
> <http://www.imerseyside.nhs.uk>or follow uson twitter @nhsimerseyside
> 
>  
> 
> Exceptionalsize14  
> 
> * *
> 
> Advance Notification of absence:
> 
> 17^th of August to 6^th of September 2018
> 
>  
> 
> *From:*Jason Guy [mailto:j...@cumulusnetworks.com]
> *Sent:* 17 July 2018 15:35
> *To:* McBride Lawrence 
> *Cc:* KEA-Users (kea-users@lists.isc.org) 
> *Subject:* Re: [Kea-users] DHCP4 not starting or writing log file
> 
>  
> 
> Was this installed from the Debian Sid repo, or is this on RHEL/CentOS?
> 
>  
> 
> Thanks,
> Jason
> 
>  
> 
> On Tue, Jul 17, 2018 at 10:18 AM McBride Lawrence
>  <mailto:lawrence.mcbr...@imerseyside.nhs.uk>> wrote:
> 
> Hi,
> 
>  
> 
> Sorry,
> 
>  
> 
> Version 1.4
> 
> File and dir exist
> 
> I am starting the services as root
> 
>  
> 
> *Lawrence McBride*
> 
> Head of Voice and Data Networks
> 
>  
> 
> *NHS Informatics Merseyside*
> 
> *a  *Saturn House, Knowsley Business Park, Liverpool. L34 9GJ
> 
> *t   *0151 296 7668
> 
> *m *07795 370190
> 
> *e  *lawrence.mcbr...@imerseyside.nhs.uk
> <mailto:lawrence.mcbr...@imerseyside.nhs.uk>
> 
>  
> 
> Say helloto us online at www.imerseyside.nhs.uk
> <http://www.imerseyside.nhs.uk>or follow uson twitter @nhsimerseyside
> 
>  
> 
> Exceptionalsize14  
> 
> * *
> 
> Advance Notification of absence:
> 
> 17^th of August to 6^th of September 2018
> 
>  
> 
> *From:*Jason Guy [mailto:j...@cumulusnetworks.com
> <mailto:j...@cumulusnetworks.com>]
> *Sent:* 17 July 2018 14:38
> *To:* McBride Lawrence  <mailto:lawrence.mcbr...@imerseyside.nhs.uk>>
> *Cc:* KEA-Users (kea-users@lists.isc.org
> <mailto:kea-users@lists.isc.org>)  <mailto:kea-users@lists.isc.org>>
> *Subject:* Re: [Kea-users] DHCP4 not starting or writing log file
> 
>  
> 
> Hi Lawrence,
> 
>  
> 
> First, what version of Kea are you using?
> 
> Does the log directory exist? I am not sure if kea will create the
> directory, as well as the file. 
> 
> Finally, make sure to start the service as root or using sudo.
> 
>  
> 
> Jason
> 
>  
> 
> On Tue, Jul 17, 2018 at 6:02 AM McBride Lawrence
>  <mailto:lawrence.mcbr...@imerseyside.nhs.uk>> wrote:
> 
> Hi,
> 
>  
> 
> I am starting just the dhcp4 server with the following command:
> 
>  
> 
> keactrl start -s dhcp4
> 
>  
> 
> I get a corresponding message to say it is starting:
> 
>  
> 
> INFO/keactrl: Starting /opt/kea/sbin/kea-dhcp4 -c
> /opt/kea/etc/kea/kea-dhcp4.conf
> 
>  
> 
> However, it doesn’t start as the status output shows:
> 
>  
> 
> keactrl status
> 
> DHCPv4 server: inactive
> 
> DHCPv6 server: inactive
> 
> DHCP DDNS: inactive
> 
> Control Agent: inactive
> 
> Kea DHCPv4 configuration file: /opt/kea/etc/kea/kea-dhcp4.conf
> 
> Kea DHCPv6 configuration file: /opt/kea/etc/kea/kea-dhcp6.conf
> 
> Kea DHCP DDNS configuration file:
> /opt/kea/etc/kea/kea-dhcp-ddns.conf
> 
> Kea

Re: [Kea-users] UNIX Socket Not Configured

[Marcin Siodelski]

It seems there is a typo in your command line:

kea-shell --host 127.0.0.1 --port 8080 –service dhc4 config-get

It should be "dhcp4" rather than "dhc4".

Marcin Siodelski
ISC Engineering

On 11.07.2018 21:24, Phoebe Lee wrote:
> Hi!
>
> First time configuring a Kea 1.4.0 server and running into an issue with
> the UNIX sockets for the CA.
>
>  
>
> When issuing
>
>     Kea-shell --host 127.0.0.1 --port 8080 –service dhc4
> config-get
>
> I receive this error
>
>     [  {  “result”: 1, “text”: “forwarding socket is not
> configured for the server type dhc4” } ]
>
>  
>
> I have left the path for the socket name the same from the default
> configs and have uncommented the section to attach the hook libraries.
> I'm running this on Ubuntu 16.04. 
>
>  
>
> Thank you,
>
> Phoebe Lee
>
>
>
>
> ___
> 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] issue with INIT-REBOOT

[Marcin Siodelski]

The difficulty with this particular situation is that the capture
doesn't really help determining what happened before the NAK and no
response to Windows client.

The INIT-REBOOT client is the one that remembers its previously assigned
address. If the server doesn't know this lease it can't respond to the
client because it is possible that it was assigned by a different
server. But, this situation should get resolved on its own, because the
client that didn't get a response should eventually try DORA (4-way
exhange) and get the lease.

It seems that the iOS client gets the NAK because the lease he is asking
for is not a valid lease for this client because the client has a lease
for a different address.

So, I presume that the server has a lease for iOS client for some other
address than he is asking and has no lease for the Windows client so it
ignores his request, which all seem to be a valid behavior. But to be
sure we'd need to know what is in the lease database and also how the
clients ended up in the INIT-REBOOT state.

Marcin Siodelski
ISC Engineering



On 04.07.2018 13:08, Hieu Nguyen wrote:
> Please help me
> 
> 2018-07-01 16:08 GMT+07:00 Hieu Nguyen  <mailto:hieu.ntr...@gmail.com>>:
> 
> 2 client (Windows and iOS) in "INIT-REBOOT" state sends a DHCP
> Request to KEA through a relay.
> Requested address (option 50) is its old address. This subnet isn't
> configured in KEA server.
> 
> Kea don't know of this client.
> 
> *+ Observed behavior:*
>  iOS:
> 2018-07-01 15:26:34.892 DEBUG [kea-dhcp4.bad-packets/1553]
> DHCP4_PACKET_NAK_0002 [hwtype=1 6c:4d:73:f3:d4:19],
> cid=[01:6c:4d:73:f3:d4:19], tid=0xb858b700: invalid address
> 10.122.23.24 requested by INIT-REBOOT
> 
> Windows:
> 2018-07-01 15:28:00.290 DEBUG [kea-dhcp4.bad-packets/1553]
> DHCP4_NO_LEASE_INIT_REBOOT [hwtype=1 f0:42:1c:e5:f3:5d],
> cid=[01:f0:42:1c:e5:f3:5d], tid=0x954bf4ee: no lease for address
> 10.122.13.204 requested by INIT-REBOOT client
> 
> Window  client must use the command " ipconfig /release and ipconfig
> /renew " to obtain new ip address.
> 
> *+ Expected behavior:*
> Kea returns a NAK to Windows like iOS. 
> 
> After that I set up other DHCP Server from Microsoft. It properly
> returns DHCP NAK to 2 clients.
> 
> I also attached the capture from kea server. help me this case,plz
> 
> 
> 
> 
> ___
> 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-ctrl-agent not able to get information

[Marcin Siodelski]

Hello,

Did you try to send something like this:

$ curl -X POST -H "Content-Type: application/json" -d '{ "command":
"config-get", "service": [ "dhcp4" ] }' http://ca.example.org:8000/

where "command" denotes what command to send to the server and the
"service" denotes whether the command should be forwarded to the DHCPv4
or DHCPv6 server (the server must be running). If you want to send a
command to be processed by the Control Agent (say, get CA's
configuration), the "service" argument must not be specified.

Some more information can be found here:

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#ctrl-channel-client

Marcin Siodelski
ISC


On 27.05.2018 15:23, mAineAc wrote:
> I have configured kea dhcp and I am getting leases and I can see this is
> working correctly. I can check the /usr/local/var/kea/kea-leases4.csv file
> and see leases in that. I have been trying to use the kea-ctrl-agent web
> interface to be able to view leases or even make changes as I can see that
> there are a bunch of commands. I am not sure how to pass these commands to
> the web interface. I browse to the age for the kea control agent port 8080
> as it is set up to do and all I get is: 
> 
> { "result": 400, "text": "Bad Request" }
> 
> This is all I see on the page. 
> 
> I can see that the hooks library gets loaded:
> 
> 2018-05-27 09:13:50.037 INFO  [kea-dhcp4.lease_cmds_hooks/1789]
> LEASE_CMDS_INIT_OK loading Lease Commands hooks library successful
> 2018-05-27 09:13:50.037 INFO  [kea-dhcp4.hooks/1789] HOOKS_LIBRARY_LOADED
> hooks library /usr/local/lib/hooks/libdhcp_lease_cmds.so successfully loaded
> 
> 
> But a few minutes later I get this message:
> 
>  2018-05-27 09:14:50.736 INFO  [kea-dhcp4.lease_cmds_hooks/1789]
> LEASE_CMDS_DEINIT_OK unloading Lease Commands hooks library successful
> 2018-05-27 09:14:50.736 INFO  [kea-dhcp4.hooks/1789] HOOKS_LIBRARY_UNLOADED
> hooks library /usr/local/lib/hooks/libdhcp_lease_cmds.so successfully
> unloaded
> 
> 
> Should this be unloading the library just after it is loaded? I am loading
> the library in my kea control config as well as my ipv6 and ipv4 config. I
> am also using the same ipv4 unix socket in my ipv4 config and my control
> config and the same iwth the ipv6 unix socket. 
> 
> I found a post that mentions this:
> 
> "I already implemented a web-frontend to the database (mysql) to show all
> the leases and reservations."
> 
> But, I am not sure I have done this step and this may be where I am messing
> up because I am not quite sure what is meant there and I did not see
> anything that tells how to d this in the install instructions. I have gone
> through the database instructions a couple of times. 
> 
> mAineAc
> 
> 
> 
> --
> Sent from: http://kea-users.7364.n8.nabble.com/
> ___
> 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] option 54

[Marcin Siodelski]

Hi,

I recommend upgrading to Kea 1.3 (or 1.4 in a couple of weeks), which
already have this feature:

https://kea.isc.org/docs/kea-guide.html#dhcp4-serverid

Kind Regards,

Marcin Siodelski
ISC

On 11.05.2018 10:58, Itay Rozenberg wrote:
> 
> After the client gets the address from the dhcp server ,its renewing it 
> directly to kea, i need it to renew it via the relay
> 
> 
>  Original message 
> From: "Chaigneau, Nicolas" <nicolas.chaign...@capgemini.com>
> Date: 5/11/18 11:44 (GMT+02:00)
> To: itay cohen <icohen9...@gmail.com>, kea-users@lists.isc.org
> Subject: Re: [Kea-users] option 54
> 
> 
> Option 54 is set automatically by the server (to the IP address on which the 
> packet was received, I think).
> 
> It cannot be an arbitrary value, it is used by clients in DHCPREQUEST 
> messages. The server will ignore such messages with an option 54 that does 
> not match its configuration (even if they are unicast to him) because it 
> indicates that the client is trying to communicate with another server.
> 
> What are you trying to do exactly ?
> 
> 
> Regards,
> Nicolas.
> 
> De : Kea-users [mailto:kea-users-boun...@lists.isc.org] De la part de itay 
> cohen
> Envoyé : vendredi 11 mai 2018 02:35
> À : kea-users@lists.isc.org
> Objet : [Kea-users] option 54
> 
> hi all
> 
> i'm using kea-1.2.0
> 
> i'm trying to set
> "option-data": [
> { "name": "routers", "data": " 10.0.0.1"  },
>  { "name": "dhcp-server-identifier", "data": 
> "10.0.0.1"  }
>  ],
> now, when kea is trying to send the  packet back its being Dropped with this 
> message,
> [kea-dhcp4.bad-packets/19941] DHCP4_PACKET_DROP_0007 [hwtype=1 
> a8:11:fc:98:fe:dd], cid=[ff:fc:98:fe:dd:00:03:00:01:a8:11:fc:98:fe:dd], 
> tid=0x4a68f6e1: failed to process packet: Option 54 already present in this 
> message.
> 
> any thoughts ?
> 
> thank you,
> Itay
> 
> 
> 
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is intended only for the person to 
> whom it is addressed. If you are not the intended recipient, you are not 
> authorized to read, print, retain, copy, disseminate, distribute, or use this 
> message or any part thereof. If you receive this message in error, please 
> notify the sender immediately and delete all copies of this message.
> 
> [Banner]<https://www.partner.co.il/partnerfiber?PartnerCampaignId=191088_source=Signature_medium=Banner_campaign=FiberApril18>
> Powered by U-BTech 
> XTRABANNER<http://www.u-btech.com/products/xtrabanner/poweredby>
> 
> Please do not enrich emails sent to 
> me<mailto:xban...@orange.co.il?subject=Please%20do%20not%20enrich%20emails%20sent%20to%20me%20%5BRemoval%20Code%3A%20DNE42%5D=Please%20do%20not%20enrich%20emails%20sent%20to%20me>
> 
> 
> This message contains information that may be confidential or privileged.
> If you are not the intended recipient, you may not use, copy or disclose
> to anyone any of the information in this message. If you have received
> this message and are not the intended recipient, kindly notify the sender
> and delete this message from your computer.
> 
> 
> 
> ___
> 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] Circuit-ID

[Marcin Siodelski]

On 02.02.2018 09:25, Frode Sætre wrote:
> 
> We want to identify leases with circuit ID, how can we get the circuit
> ID with the lease4-get?
> 
> 
> 
> Vennlig hilsen / Best regards
> 
> 
> Frode Sætre
> 
> 
> 

Frode,

I realize that this is quite an old thread, but from our most recent
correspondence via Kea dev I know that this issue still hasn't been
resolved.

We have created Kea ticket for you https://kea.isc.org/ticket/5592. This
ticket is currently out of scope for the upcoming release as this is
really a broader problem of how to easily associate any custom data with
a lease, without having to update lease database schema every time we
add a new parameter.

As of today, the circuit id is not stored in the lease database and
therefore there is no way to query for leases by circuit id, with one
exception I discuss below.

The only way to achieve what you want is to use 'flex-id' hook library
which is available as part of our premium offering:

https://www.isc.org/kea/

This library allows for specifying a custom expression which constitutes
flexible identifier by which static host reservations can be identified.
In particular, you may define an expression which uses circuit-id from
the received DHCP query as an identifier to lookup host reservations for
the client which sent this query.

This library has one more feature which is going to be useful for your
case. Setting "replace-client-id" to true in the library configuration
will cause the library to replace client identifier option sent by the
client with your custom identifier, e.g. circuit-id and store it in the
lease database instead of the client identifier when the lease is
allocated. The value of the circuit-id will be prefixed with hexadecimal
"00". Assuming that the circuit-id value is "54:64:45:66". If the
"replace-client-id" is set to true, the lease will be stored and the
client-id value stored in the lease database will be "00:54:64:45:66".

Now, you can query for this lease in the following way:

{
"command": "lease4-get",
"arguments": {
"identifier-type": "client-id",
"identifier": "00:54:64:45:66",
"subnet-id": 44
}
}

Note that the identifier type is "client-id", but the value you put
under "identifier" is your circuit-id prefixed with 00.

This exact case is described in the Kea User's Guide:

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#flex-id


This is the expression you may use for your custom identifier:

"identifier-expression": "relay4[1].hex"

which creates it from the relay agent sub option 1.


Hope that helps,

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

Re: [Kea-users] Option 60 vendor class

[Marcin Siodelski]

On 13.04.2018 14:03, Francis Dupont wrote:
> vendor-class-identifier (code 60) is a string so you should dynamic cast
> the result of getOption() with DHO_VENDOR_CLASS_IDENTIFIER to
> an OptionString. There are a lot of examples in unit tests and
> as far as I can remember at least a post in this list as you are not
> the first asking this.
> 
> Regards
> 
> Francis Dupont <fdup...@isc.org>
> 
> PS: look at src/lib/dhcp/std_option_defs.h for definitions of standard
> options. getData works only on unknown options or options which are not
> defined to a specific content type (i.e, binary).
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> 

Francis,

The OptionString actually using data_ member (setData, getData) to
storing string values, so it should not be a reason to crash. I think it
is going to be hard to rootcause the problem without seeing the actual code.

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

Re: [Kea-users] Problems adding the premium package hooks libraries

[Marcin Siodelski]

Hello Dyl,

The hooks libraries should be located in the Kea installation directory
under lib/hooks.

Marcin Siodelski
ISC


On 20.02.2018 21:37, Dylan Masson wrote:
>  Greetings,
>  My company has recently purchased the premium package for Kea 1.3.0, and I 
> have not been able to locate the hooks libraries, so that I can add their 
> path to my config file. Does anyone have the names of the hooks libraries 
> files? If I know the proper names, I can dig them out myself. The one from 
> the example config in the docs doesn’t exist, so I assume that it would be 
> something like the libdhcp_host_cmds.so, but that is in a dot-named 
> directory, so I would guess that it isn’t the one.
> 
> Thanks,
> Dyl
> ___
> 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-ctrl-agent - request by php/curl

[Marcin Siodelski]

I am hoping that the only thing that you have to correct is to do this:

"service" => [ "dhcp4" ]

rather than

"service" => "[ dhcp4 ]"

Marcin Siodelski
ISC

On 08.02.2018 15:35, Zayer, Sebastian wrote:
> Hey there,
> 
>  
> 
> i’m trying to control the kea server by using the control agent.
> 
>  
> 
> I already implemented a web-frontend to the database (mysql) to show all
> the leases and reservations.
> 
> Now I’m trying to get the running configuration by requesting the
> control agent.
> 
>  
> 
> $msg = array("command" => "config-get", "service" => "[ dhcp4 ]");
> 
> $message = json_encode($msg);
> 
>  
> 
> //$message = '{ "command": "config-get", "service": "dhcp4" }';
> 
> $len = strlen($message);
> 
>  
> 
> echo print_r($message, true), "\n";
> 
>  
> 
> $ch = curl_init('http://127.0.0.1:8080/');
> 
> curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
> 
> curl_setopt($ch, CURLOPT_POSTFIELDS, $message);
> 
> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
> 
> curl_setopt($ch, CURLOPT_HTTPHEADER, array(
> 
>  'Content-type: application/json',
> 
>  'Content-Length: '. $len)
> 
> );
> 
> curl_setopt($ch, CURLOPT_TIMEOUT, 10);
> 
> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
> 
>  
> 
> $ret = curl_exec($ch);
> 
> if($ret === false)
> 
> {
> 
>     echo 'Curl error: ' . curl_error($ch);
> 
> }
> 
> else
> 
> {
> 
>  echo print_r($ret, true);
> 
>     echo 'Operation completed without any errors';
> 
> }
> 
>  
> 
> All I receive is the following:
> 
> {"command":"config-get","service":"[ dhcp4 ]"}
> 
> { "result": 400, "text": "Bad Request" }
> 
> Operation completed without any errors
> 
>  
> 
>  
> 
> I tried a lot of things:
> 
> -   dhcp4 with or without brackets
> 
> -   using the documented string
> (http://kea.isc.org/docs/kea-guide.html#ctrl-channel-client)
> 
> -   with and without timeouts
> 
> -   different HTTPHEADER (with, and without Content-Length like in
> the documentation)
> 
>  
> 
> The service is up and running, if i’m using the shell and curl the
> example works.
> 
> I also tried to get a clue by reading the log (DEBUG, Level 99) but
> there is just a lousy message “HTTP_DATA_RECEIVED received 152 bytes
> from 127.0.0.1” and “DEBUG [kea-ctrl-agent.http] HTTP_RESPONSE_SEND
> sending HTTP response HTTP/1.1 400 Bad Request#015#012 to *127.0.0.1*”
> 
>  
> 
> Does anybody have a clue how to successfully connect and receive a
> proper message?
> 
>  
> 
>  
> 
> Thanks in advance
> 
>  
> 
> Sebastian
> 
> 
> 
> ___
> 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 LFC not executed anymore after some time (Kea 1.2.0) + other timers

[Marcin Siodelski]

Are there any additional messages prior to this, indicating what might
have caused it?

Marcin

On 04.12.2017 09:32, Chaigneau, Nicolas wrote:
> Hello,
> 
> 
> Got another occurence of the issue, on 2017 December 1st at 09:12.
> 
> This time I had the server running with debug logs.
> I noticed that, not only did the LFC stopped being executed, but also the 
> lease reclaiming mechanism (both at the same time).
> 
> So I think that the issue is bigger, that all timers stop working. :(
> 
> 
> egrep "DHCPSRV_MEMFILE_LFC_START|DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION" 
> kea1-open-20171202.log
> 
> (...)
> 2017-12-01 09:12:42.376 DEBUG [kea-dhcp4.dhcpsrv/32013] 
> DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: memfile-lfc
> 2017-12-01 09:12:42.376 INFO  [kea-dhcp4.dhcpsrv/32013] 
> DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup
> 2017-12-01 09:12:43.240 DEBUG [kea-dhcp4.dhcpsrv/32013] 
> DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: 
> reclaim-expired-leases
> (...)
> 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.dhcpsrv/32013] 
> DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: 
> reclaim-expired-leases
> 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.dhcpsrv/32013] 
> DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: 
> reclaim-expired-leases
> 
> No more timer-related logs after this point.
> (Note that the server is still processing DHCP packets correctly.)
> 
> 
> 
> 
> Regards,
> Nicolas.
> 
>>
>> OK, thanks for the update!
>>
>> For the record, the issue can appear whether Kea receives DHCP packets or 
>> not.
>> So you can just start the server and wait :)
>>
>>
>>
>>
>>> I've been running Kea with LFC for 2 days, simulating DHCP requests at
>>> the rate of 1 lease/sec with valid lifetime of 60 seconds. I haven't
>>> reproduced the problem so far.
>>>
>>> Marcin
>>>
>>> On 30.11.2017 09:28, Chaigneau, Nicolas wrote:
>>>>
>>>>
>>>>
>>>> I've restarted Kea a week ago with debug logs, in the hope of seeing 
>>>> something when the issue manifests.
>>>>
>>>> No "luck" so far. Still waiting...
>>>>
>>>>
>>>>
>>>>  
>>>>> The worker thread seems to be running.
>>>>> The following command (on the Kea process not executing LFC) shows two 
>>>>> threads:
>>>>>
>>>>> ps -T -p 
>>>>>   PID  SPID TTY  TIME CMD
>>>>> 28268 28268 ?00:00:03 kea-dhcp4
>>>>> 28268 28269 ?00:00:03 kea-dhcp4
>>>>>
>>>>>
>>>>> The issue also happened on our lab, so I could try to upgrade to 1.3.0.
>>>>>
>>>>> But I would really prefer to find out the issue with 1.2.0 and fix this 
>>>>> version.
>>>>> We've just deployed 1.2.0 on production, having to upgrade now would 
>>>>> be... difficult :/
>>>>>
>>>>>
>>>>>
>>>>>> It would be useful to check if the worker thread triggering timers is
>>>>>> still running or died. The kea-dhcp4 process should run main thread and
>>>>>> the second thread for timers. You could use "ps" or "top" to verify this.
>>>>>>
>>>>>> In the Kea 1.3.0, we have removed the worker thread and made several
>>>>>> significant updates to the timers scheduling. It would be useful it you
>>>>>> could verify whether Kea 1.3.0 also has this issue, but if it is
>>>>>> production environment, it is not good for experiments.
>>>>>>
>>>>>> Marcin
>>>>>>
>>>>>> On 20.11.2017 10:21, Chaigneau, Nicolas wrote:
>>>>>>> The Kea server not executing LFC is still running, so if there's 
>>>>>>> something you want me to check...  feel free to ask :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Message d'origine-
>>>>>>> De : Marcin Siodelski [mailto:mar...@isc.org] 
>>>>>>>
>>>>>>> Nicolas,
>>>>>>>
>>>>>>> Thanks for creating the ticket. We'll have a look and see if we can
>>>>>>> reproduce it here.
>>>>>>>
>>>>>>> Marcin Siodelski
>>>>>>> ISC
&

Re: [Kea-users] Adding a lease via the API

[Marcin Siodelski]

Munroe,

We tried to reproduce your problem with very similar configuration but
unsuccessfully. What is the Kea version you're currently using?

Marcin

On 30.11.2017 14:24, Munroe Sollog wrote:
> when I run:
> 
> curl -X POST -H "Content-Type: application/json" -d '{ "command":
> "config-get", "service": ["dhcp4"] }' http://localhost:8000/
> 
> I get:
> 
> https://paste.debian.net/hidden/a5ae1e53/
> 
> It seems to me that subnet-id=1 is configured.  However when I run:
> 
> curl -X POST -H "Content-Type: application/json" -d '{ "command":
> "lease4-add","service": ["dhcp4"], "arguments": { "subnet-id": 1,
> "ip-address": "172.31.32.12", "hw-address": "1a:1b:1c:1d:1e:1f" } }'
> http://localhost:8000/
> [ { "result": 1, "text": "Invalid subnet-id: No IPv4 subnet with
> subnet-id=1 currently configured." } ]
> 
> It says that subnet-id=1 doesn't exist?  What am I missing?
> 
> -- 
> 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] Kea LFC not executed anymore after some time (Kea 1.2.0)

[Marcin Siodelski]

I've been running Kea with LFC for 2 days, simulating DHCP requests at
the rate of 1 lease/sec with valid lifetime of 60 seconds. I haven't
reproduced the problem so far.

Marcin

On 30.11.2017 09:28, Chaigneau, Nicolas wrote:
> 
> 
> 
> I've restarted Kea a week ago with debug logs, in the hope of seeing 
> something when the issue manifests.
> 
> No "luck" so far. Still waiting...
> 
> 
> 
>  
>> The worker thread seems to be running.
>> The following command (on the Kea process not executing LFC) shows two 
>> threads:
>>
>> ps -T -p 
>>   PID  SPID TTY  TIME CMD
>> 28268 28268 ?00:00:03 kea-dhcp4
>> 28268 28269 ?00:00:03 kea-dhcp4
>>
>>
>> The issue also happened on our lab, so I could try to upgrade to 1.3.0.
>>
>> But I would really prefer to find out the issue with 1.2.0 and fix this 
>> version.
>> We've just deployed 1.2.0 on production, having to upgrade now would be... 
>> difficult :/
>>
>>
>>
>>> It would be useful to check if the worker thread triggering timers is
>>> still running or died. The kea-dhcp4 process should run main thread and
>>> the second thread for timers. You could use "ps" or "top" to verify this.
>>>
>>> In the Kea 1.3.0, we have removed the worker thread and made several
>>> significant updates to the timers scheduling. It would be useful it you
>>> could verify whether Kea 1.3.0 also has this issue, but if it is
>>> production environment, it is not good for experiments.
>>>
>>> Marcin
>>>
>>> On 20.11.2017 10:21, Chaigneau, Nicolas wrote:
>>>> The Kea server not executing LFC is still running, so if there's something 
>>>> you want me to check...  feel free to ask :)
>>>>
>>>>
>>>>
>>>> -Message d'origine-
>>>> De : Marcin Siodelski [mailto:mar...@isc.org] 
>>>>
>>>> Nicolas,
>>>>
>>>> Thanks for creating the ticket. We'll have a look and see if we can
>>>> reproduce it here.
>>>>
>>>> Marcin Siodelski
>>>> ISC
>>>>
>>>> On 20.11.2017 09:07, Chaigneau, Nicolas wrote:
>>>>>
>>>>> Observed a 4th occurrence of the issue.
>>>>>
>>>>> Server started on 2017, November 15th at 17:20:47
>>>>> Last time LFC was executed: on November 19th at 04:50:47
>>>>>
>>>>> I'll open a ticket.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Nicolas.
>>>>>  
>>>>>>
>>>>>> So this is confirmed: LFC is really not executed anymore at some point, 
>>>>>> for a reason yet to be determined.
>>>>>>
>>>>>> I'll have a look at the changes between Kea 0.9.1 and 1.2.0.
>>>>>>
>>>>>>
>>>>>> If you think of anything that could help, I'm all ears :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Nicolas.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello Marcin,
>>>>>>>
>>>>>>>
>>>>>>> Thanks for your answer.
>>>>>>>
>>>>>>>
>>>>>>> I was too hasty to suspect the log rotation, this has nothing to do 
>>>>>>> with it. Rotation occurs at night between 3 and 4am, and the last log I 
>>>>>>> have was in the middle of the day.
>>>>>>>
>>>>>>> Furthermore, I think the issue manifesting after 24H is just a 
>>>>>>> coincidence. Before that I've had Kea run for several days before 
>>>>>>> seeing the issue. So it seems random...
>>>>>>>
>>>>>>> I don't think there's an issue with logging either, because when I 
>>>>>>> stopped the server after the LFC issue appeared, then I got the normal 
>>>>>>> shutdown logs.
>>>>>>>
>>>>>>> I think the LFC is not executed because of the two observations:
>>>>>>> - No log from Kea saying that LFC is launched
>>>>>>> - Lease files are not modified anymore (and their last modification 
>>>>>>> date coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea)
>>>&

Re: [Kea-users] Manage leases table via the API

[Marcin Siodelski]

Hello Munroe,

Kea includes an open source hooks library called lease_cmds (see
src/hooks/dhcp/lease_cmds) which can be used to manipulate leases in the
lease database.

Also, see Kea User's Guide:
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#lease-cmds

Marcin Siodelski
ISC

On 29.11.2017 19:35, Munroe Sollog wrote:
> Is there currently a way to add/remove active leases from the leases4|6
> table using the API?
> 
> -- 
> Munroe Sollog
> Senior Network Engineer
> mun...@lehigh.edu <mailto: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] Can't enable the control agent

[Marcin Siodelski]

Control Agent is a separate application that has to be started separately, e.g.

./kea-ctrl-agent -c etc/kea/kea4.conf

or using keactrl.

Starting DHCPv4 server doesn't automatically start the control agent. If I 
understand you correctly, you're only starting kea-dhcp4 server.

Marcin Siodelski
ISC

On 28.11.2017 19:45, Munroe Sollog wrote:
> Using the configuration examples provided, I am trying to configure the
> HTTP control agent on kea 1.3.  Here is a pastebin of my config:
>
> https://paste.debian.net/plainh/45a4da9a
>
> Here is a pastebin of my debug output running kea in the foreground:
>
> https://paste.debian.net/hidden/c4374b48/
>
>
> However with kea running port 8000 on localhost is not open.  I
> purposely have no subnets defined as it is a testing box and I don't
> want to hand out any leases accidentally. 
>
>
> -- 
> Munroe Sollog
> Senior Network Engineer
> mun...@lehigh.edu <mailto: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] [Kea] subnet or shared network selected for multiple relays

[Marcin Siodelski]

Unfortunately, it isn't possible for the shared networks too. The shared
network pretty much derives parameters from the subnet. Or, maybe I
should say a subnet derives from the shared network.

Marcin Siodelski
ISC

On 24.11.2017 18:46, Chaigneau, Nicolas wrote:
> Hello,
> 
>  
> 
>  
> 
> I would like to configure a subnet shared by multiple relays, i.e. that
> would be chosen for several “giaddr” values.
> 
> If I’m not mistaken, this was not possible with the basic “subnet4”
> configuration prior to 1.3.0 (as parameter “relay” does not support a
> list of relays).
> 
>  
> 
> Can I achieve that with a shared network in 1.3.0 ?
> 
>  
> 
> I’ve read Kea admin guide but I’m not sure this is possible just with
> configuration.
> 
> I have the impression that “relay” still can only be one element, either
> for the “shared-networks” or for each of its “subnet4” components.
> 
>  
> 
>  
> 
>  
> 
> Regards,
> 
> Nicolas.
> 
>  
> 
>  
> 
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient,
> you are not authorized to read, print, retain, copy, disseminate,
> distribute, or use this message or any part thereof. If you receive this
> message in error, please notify the sender immediately and delete all
> copies of this message.
> 
> 
> 
> ___
> 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 LFC not executed anymore after some time (Kea 1.2.0)

[Marcin Siodelski]

It would be useful to check if the worker thread triggering timers is
still running or died. The kea-dhcp4 process should run main thread and
the second thread for timers. You could use "ps" or "top" to verify this.

In the Kea 1.3.0, we have removed the worker thread and made several
significant updates to the timers scheduling. It would be useful it you
could verify whether Kea 1.3.0 also has this issue, but if it is
production environment, it is not good for experiments.

Marcin

On 20.11.2017 10:21, Chaigneau, Nicolas wrote:
> The Kea server not executing LFC is still running, so if there's something 
> you want me to check...  feel free to ask :)
> 
> 
> 
> -----Message d'origine-
> De : Marcin Siodelski [mailto:mar...@isc.org] 
> 
> Nicolas,
> 
> Thanks for creating the ticket. We'll have a look and see if we can
> reproduce it here.
> 
> Marcin Siodelski
> ISC
> 
> On 20.11.2017 09:07, Chaigneau, Nicolas wrote:
>>
>> Observed a 4th occurrence of the issue.
>>
>> Server started on 2017, November 15th at 17:20:47
>> Last time LFC was executed: on November 19th at 04:50:47
>>
>> I'll open a ticket.
>>
>>
>> Regards,
>> Nicolas.
>>  
>>>
>>> So this is confirmed: LFC is really not executed anymore at some point, for 
>>> a reason yet to be determined.
>>>
>>> I'll have a look at the changes between Kea 0.9.1 and 1.2.0.
>>>
>>>
>>> If you think of anything that could help, I'm all ears :)
>>>
>>>
>>>
>>> Regards,
>>> Nicolas.
>>>
>>>
>>>
>>>> Hello Marcin,
>>>>
>>>>
>>>> Thanks for your answer.
>>>>
>>>>
>>>> I was too hasty to suspect the log rotation, this has nothing to do with 
>>>> it. Rotation occurs at night between 3 and 4am, and the last log I have 
>>>> was in the middle of the day.
>>>>
>>>> Furthermore, I think the issue manifesting after 24H is just a 
>>>> coincidence. Before that I've had Kea run for several days before seeing 
>>>> the issue. So it seems random...
>>>>
>>>> I don't think there's an issue with logging either, because when I stopped 
>>>> the server after the LFC issue appeared, then I got the normal shutdown 
>>>> logs.
>>>>
>>>> I think the LFC is not executed because of the two observations:
>>>> - No log from Kea saying that LFC is launched
>>>> - Lease files are not modified anymore (and their last modification date 
>>>> coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea)
>>>>
>>>> But you're right, I'm not 100% sure LFC is not executed...
>>>>
>>>>
>>>> So I've launched a little script that does loops over a "ps" to try and 
>>>> catch the LFC process running.
>>>> It's not fully reliable because if LFC has nothing to do, it may start and 
>>>> end so fast that the ps won't see it.
>>>> I tried that with LFC scheduled every 10 seconds. The script catches about 
>>>> 2 LFC executions out of 3.
>>>>
>>>> So on the live system on which the LFC appears to not run anymore, I'll 
>>>> let the script run for an hour. In this time frame LFC is normally 
>>>> executed 6 times.
>>>> If I don't see anything, I'll conclude that LFC is indeed not executed.
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Nicolas.
>>>>
>>>> -Message d'origine-
>>>> De : Marcin Siodelski [mailto:mar...@isc.org] 
>>>>
>>>> Nicolas,
>>>>
>>>> I think we should start from checking if the issue doesn't stem from the
>>>> log rotation. If I understand correctly, you're rotating the log file
>>>> daily. Per your message below, things go weird after around 24 hours
>>>> since server startup. Is it possible to verify that rotating every 12h
>>>> would cause the issue to begin after 12h rather than 24h?
>>>>
>>>> I can't see anything in the Kea code that could prevent periodic
>>>> execution of LFC, other than server reconfiguration. You're saying that
>>>> LFC is not executed because the lease files aren't modified. But, is
>>>> there any other log output present there? Perhaps the LFC is not
>>>> executed because of some trouble with logging being a result of log file
>>>> rotation? We

Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)

[Marcin Siodelski]

On 18.11.2017 17:39, Mike wrote:
> On 11/17/2017 11:58 AM, Chaigneau, Nicolas wrote:
>>
>>
>>
>> So this is confirmed: LFC is really not executed anymore at some point, for 
>> a reason yet to be determined.
>>
>> I'll have a look at the changes between Kea 0.9.1 and 1.2.0.
>>
>>
>> If you think of anything that could help, I'm all ears :)
>>
> 
> 
> I'm not sure if this will help, but I have seen a similar (the same?)
> issue.   LFC has not worked for me in a very long time.  To the point
> that I wrote a script (below) to clean out the old leases, run by cron
> weekly.
> 
> The lfc config portions of kea.conf are:
> 
>   "lease-database": {
>   "type": "memfile",
>   "persist": true,
>   "name": "/var/db/kea/kea-leases4.csv",
>   "lfc-interval": 4000
>   },
> 
> and
> 
>   "lease-database": {
>   "type": "memfile",
>   "persist": true,
>   "name": "/var/db/kea/kea-leases6.csv",
>   "lfc-interval": 4000
>   },
> 
> Maybe I have some simple error in the config that my eyes keep
> overlooking, I don't know.
> 
> In any case, here's the script I run weekly:
> 
> 
> #!/bin/sh
> 
> set -e
> #set -xv
> 
> DBBaseDir=/var/db/kea
> 
> NowSecs=$(date +%s)
> 
> # IPv4 - expire is column 5
> # IPv6 - expire is column 4
> 
> keactrl stop
> 
> for IPFam in 4 6
> do
>   MainFile=${DBBaseDir}/kea-leases${IPFam}.csv
>   TmpFile=${DBBaseDir}/kea-leases${IPFam}.tmp
>   OldFile=${DBBaseDir}/kea-leases${IPFam}.old
> 
>   echo " "
>   echo Processing ${MainFile}
> 
>   test -e ${TmpFile} && rm ${TmpFile}
>   while IFS="," read f1 f2 f3 f4 f5 f6
>   do
>   ExpireSecs=${NowSecs}
>   test ${IPFam} = 4 && ExpireSecs=${f5}
>   test ${IPFam} = 6 && ExpireSecs=${f4}
> 
>   if [ ${f1}x = "addressx" -o  ${ExpireSecs} -gt ${NowSecs} ]
>   then
>   echo "${f1},${f2},${f3},${f4},${f5},${f6}" >> ${TmpFile}
>   fi
> 
>   done < ${MainFile}
> 
>   cp -p ${MainFile} ${OldFile}
>   cp -p ${TmpFile} ${MainFile}
>   test -e ${TmpFile} && rm ${TmpFile}
> 
>   echo "   record count (including header record)"
>   wc -l ${OldFile}
>   wc -l ${MainFile}
> done
> 
> echo " "
> ls -al ${DBBaseDir}
> 
> echo " "
> keactrl start
> 
> exit 0
> 

Mike,

Were you using "logrotate" when you saw the issue with kea not executing
LFC?

Thanks,
Marcin Siodelski
ISC

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

Re: [Kea-users] Performance with many subnets and reservations

[Marcin Siodelski]

Hi Tino,

We appreciate your feedback regarding performance of Kea. We're aware
that there are possible performance optimizations in that area. We may
possibly add it in the 1.4.0 release.

Marcin Siodelski
ISC

On 20.11.2017 09:59, Tino Lehnig wrote:
> We have deployed Kea 1.3 in our environment with ~300 subnets using the
> shared networks capability and I would like to provide some feedback on
> performance. Note: We exclusively use host reservations in a MySQL
> database. There are no dynamic address pools. Leases are stored in a file.
> 
> We are at point where everything is working fine, but I am concerned
> that Kea will probably not scale well with an increasing amount of
> subnets in its current design. When enabling the debug log, I can see
> that Kea queries the database multiple times for each DHCP request.
> There is one query for each configured subnet. This has quite the impact
> on processing time as each request causes 300 database queries in our
> scenario. Queries are small and the query cache keeps disk I/O at a
> minimum, but CPU utilization is fairly high for Kea and MySQL.
> 
> If it is possible at all, it would probably be better to have Kea do
> only one query for the whole hosts table instead of separate queries for
> each subnet. If you any other suggestions for me, I'd appreciate that as
> well.
> 
> Thanks.
> 

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

Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)

[Marcin Siodelski]

Nicolas,

I think we should start from checking if the issue doesn't stem from the
log rotation. If I understand correctly, you're rotating the log file
daily. Per your message below, things go weird after around 24 hours
since server startup. Is it possible to verify that rotating every 12h
would cause the issue to begin after 12h rather than 24h?

I can't see anything in the Kea code that could prevent periodic
execution of LFC, other than server reconfiguration. You're saying that
LFC is not executed because the lease files aren't modified. But, is
there any other log output present there? Perhaps the LFC is not
executed because of some trouble with logging being a result of log file
rotation? We should see if logging generally works fine after log file
rotation in the first place. Could you enable more verbose logging to
see if any log is produced when the LFC starting message is gone?

Marcin Siodelski
ISC

On 17.11.2017 10:41, Chaigneau, Nicolas wrote:
> Hello,
> 
> 
> I've observed the issue again.
> 
> With a Kea server that does not receive any DHCP packet:
> At some point, Kea is still running but LFC is no longer executed.
> 
> In Kea log file we don't have "DHCPSRV_MEMFILE_LFC_START" messages anymore.
> And the lease files are not modified on disk (they would be if LFC was 
> executed, so this is not just a logging issue).
> 
> Kea was started on 2017, November 15th at 16:20:23.
> LFC was first executed 10 minutes later, at 16:30:23.
> And the last execution of LFC: November 16th, at 16:40:23.
> Nothing after that...
> 
> 
> 
> Regards,
> Nicolas.
> 
> 
>> Wait... when I restarted the server, I got logs again... before the shutdown!
>> So logging actually still worked. I just didn't have anything being logged.
>>
>> 2017-11-15 17:20:45.551 INFO  [kea-dhcp4.dhcp4/29754] DHCP4_SHUTDOWN server 
>> shutdown
>> 2017-11-15 17:20:47.603 INFO  [kea-dhcp4.dhcp4/28141] DHCP4_STARTING Kea 
>> DHCPv4 server version 1.2.0 starting
>>
>>
>> The only logs I normally have in Kea logs is LFC execution every 10 minutes:
>>
>> 2017-11-16 02:10:47.617 INFO  [kea-dhcp4.dhcpsrv/28141] 
>> DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup
>> 2017-11-16 02:10:47.617 INFO  [kea-dhcp4.dhcpsrv/28141] 
>> DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup  (...)
>>
>>
>> I don't have these logs anymore after some time.
>> So... either LFC is no longer executed after a while, or Kea stops writing 
>> these log messages ?
>>
>>
>>
>>
>>> A few more detail:
>>>
>>>
>>> This worked fine before (with the same logrotate configuration), with:
>>> - Kea 0.9.1
>>> - RHEL 6.4
>>>
>>> The issue now appears with:
>>> - Kea 1.2.0
>>> - RHEL 7.1
>>>
>>>
>>> Should I open a ticket for this ? (I'm not sure the problem is with Kea, 
>>> maybe it's logrotate...)
>>>
>>>
>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>> I've set up Kea log rotation with logrotate.
>>>> This works for some time, and then it stops working: the new log file 
>>>> stays empty, until the server is restarted.
>>>> I'm not sure what's going on... has anyone else had this issue ?
>>>>
>>>> I'm using the following options for logrotate:
>>>>
>>>> daily
>>>> rotate 30
>>>> missingok
>>>> nocompress
>>>> copytruncate
>>>> dateext
>>>> extension .log
>>>>
>>>>
>>>> I thought "copytruncate" would be good enough, but apparently it is not.
>>>>
>>>> Is it possible to send a signal to Kea so that it reopens its log file ?
>>>>
>>>>
>>>> Regards,
>>>> Nicolas.
>>>>
>>>
>>
> 
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is intended only for the person to 
> whom it is addressed. If you are not the intended recipient, you are not 
> authorized to read, print, retain, copy, disseminate, distribute, or use this 
> message or any part thereof. If you receive this message in error, please 
> notify the sender immediately and delete all copies of this message.
> 
> ___
> 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] ignore the broadcast flag in a discover and response with unicast

[Marcin Siodelski]

Hello,
Any non-standard behavior like this can be implemented using hooks. You'd need 
to create a simple hook library which implements pkt4_send callout.

See:
-https://jenkins.isc.org/job/Kea_doc/doxygen/index.html#hooksFramework
-https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html

Marcin Siodelski
ISC


On 11.11.2017 16:23, Rene Stoutjesdijk wrote:
> Good day,
> i'm new too the list and couldn't find yet an answer to my challenge,
> hopefully you can help.
>
> Is it possible to setup KEA for DHCPv4 in such a way that:
> - if a discover comes in then following items are checked:
>    - if a gi-addr is being used and if the broadcast_flag (0x8000) is set
>         then the response will be set with a unicast flag
>
>
>
> thx in advance for your response
>
>
>
>
>
> ___
> 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] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT - conflicting reservation for address

[Marcin Siodelski]

It looks like the client has declined the lease and thus it can't be
allocated to him. Depending on the logging level, you may find the
DECLINE packet in your log and see who and when sent it. Declined
addresses remain in that state for a configurable amount of time. Nobody
can be assigned those addresses as long as they remain in that state.

Marcin Siodelski
ISC

On 03.11.2017 14:44, Mikael Bjerkeland wrote:
> Hi,
> 
> I'm a new Kea user. Just recently upgraded to 1.3.0 and went into
> production with DHCPv4 and DHCPv6 reservations and leases stored in
> PostgreSQL.
> 
> Upon a reboot or change on a workstation we noticed the user was not
> able to get its IP address anymore:
> 
> 2017-11-03 13:15:26.269 WARN  [kea-dhcp4.alloc-engine/31631]
> ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 f4:6d:04:0f:3f:b6],
> cid=[01:f4:6d:04:0f:3f:b6], tid=0xe1f27234: conflicting reservation for
> address 200.1.246.60 with existing lease Address:       200.1.246.60
> Valid life:    86400
> T1:            0
> T2:            0
> Cltt:          1509711225
> Hardware addr:
> Client id:     (none)
> Subnet ID:     11
> State:         declined
> 
> 2017-11-03 13:15:26.272 WARN  [kea-dhcp4.alloc-engine/31631]
> ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 f4:6d:04:0f:3f:b6],
> cid=[01:f4:6d:04:0f:3f:b6], tid=0xe1f27234: failed to allocate an IPv4
> address after 6 attempt(s)
> 
> To resolve this I had to clear the lease from the lease4 table in the
> database. Can anyone shed some light on this? The user should have
> received its previously assigned address. Is there a config flag to
> allow this? I am using out-of-pool reservations.
> 
> Before deletion lease4 had the following column for this specific lease:
> 
>   address   |     hwaddr     |    client_id     | valid_lifetime |     
>    expire         | subnet_id | fqdn_fwd | fqdn_rev |     hostname     |
> state |    ?column?
>  3355571772 | \x             | \x               |          86400 |
> 2017-11-04 13:13:45+01 |        11 | f        | f        |             
>     |     1 | 2001.1.246.60
> 
> 
> Regards,
> Mikael
> 
> -- 
> Hug a tree before you print this e-mail
> 
> 
> ___
> 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] Question about reservations, subnet limits and lease control.

[Marcin Siodelski]

Joelson,

I recall you were asking about some alternative identifiers by which
client leases could be indexed in the lease database.

In a couple of days we're going to release Kea 1.3.0. Along with that,
we're going to release new package of hooks libraries which include
"flex-id" library. This library allows for defining an expression to be
used to create client identifier out of any piece of information within
the received packet. This identifier can be used to retrieve host
reservations. With the latest version of this library we have added an
ability to also use a value derived from this identifier as a client
identifier in the lease database.

You can read more about this feature in our User's Guide:

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#flex-id

The library is available for support customers and for purchase. Please
consult https://www.isc.org/product/kea-hook-1-2/ for details, but note
that the latest version supporting indexing leases by flex-id will be
available in a couple of days.

Marcin Siodelski
ISC


On 04.10.2017 16:44, Joelson Vendramin wrote:
> Hello Marcin,
> 
> 
> Thank you for your reply!
> 
>> I suggest that you keep an eye on the CPU utilization by the Kea server
>> as you increase the number of resources such as subnets, pools and
>> reservations. If you observe overly increasing CPU utilization while
> 
>> running Kea, please let us know. We can always try to do better if possible.
> +++ OK! I'll do that!
> 
>> What you seem to be looking for is a way to identify a client by some
>> other value (or a collection of values) regardless of the client
>> identifier and MAC address. Such identifier would need to be stored in
>> the lease database apart from client id and MAC address and take
>> precedence over the other two.
> +++ Yes! You got the point!
> Historically the DHCP protocol is MAC-dependent. Nothing wrong with that: 
> it's the RFC and it was its main objective. 
> 
> However, nowadays, ISPs use DHCP as an alternative to PPPoE "plus" Radius 
> address deployment, commonly called IPoE approach. In this scenario, MAC 
> addresses are not important, but the "Options" inserted by relays are!
> 
> So it seems that an ISP-friendly DHCP Server implementation is welcome!
> 
> By the way, congratulations about KEA.
> ISC team are doing a great job!
> 
> Regards,
> --
> Joelson Vendramin
> 
> 
> 
> 
> 
> 
> De: Marcin Siodelski <mar...@isc.org>
> Para: Joelson Vendramin <jtvendra...@yahoo.com.br>; Kea Users List 
> <kea-users@lists.isc.org> 
> Enviadas: Terça-feira, 26 de Setembro de 2017 9:49
> Assunto: Re: [Kea-users] Question about reservations, subnet limits and lease 
> control.
> 
> 
> 
> Hello Joelson,
> 
> See my answers below.
> 
> 
> On 15.09.2017 18:22, Joelson Vendramin wrote:
>> Hello Kea Users!
>>
>> I'm using Kea 1.2.0 in an environment that uses only Option82 (for IPv4) and 
>> Option18 (for IPv6) in order to always provide the same addresses to the 
>> same client (in fact, the same VLAN ID that asks for IPs).
>>
>> Since I don't have the flex-id hook library, I'm implementing IPv4 with the 
>> usual "reservations" based on "circuit-id". But for IPv6 I've defined 
>> several "subnets" based on "interface-id" provided by DHCPv6 relay agent. 
>> Inside each subnet I've declared "pools" (with only one address) and 
>> "pd-pools" (with only one prefix).
>>
>> Considering this implementation, I've two questions:
>>
>>
>> (1) Is there any hard limit on the number of "reservations" (for IPv4) or 
>> "subnets & pools & pd-pools" (for IPv6)? Today I'm running about 260 of 
>> each, but they tend to increase in the future.
>> Note: I'm not using any DB backend, just the default TXT-based memfiles.
>>
> 
> There are no arbitrary limits. Kea uses indexing for reservations so the
> number of reservations should not have a significant impact on the
> server performance. Subnet selection process is slightly more complex
> and you may observe some performance degradation with a growing number
> of subnets. BTW, there is probably some room for improvement on our end
> here.
> 
> I suggest that you keep an eye on the CPU utilization by the Kea server
> as you increase the number of resources such as subnets, pools and
> reservations. If you observe overly increasing CPU utilization while
> running Kea, please let us know. We can always try to do better if possible.
> 
> 
>> (2) I know that my question will be a bit strange, but... Is there a

Re: [Kea-users] 1.3.0-beta keactrl issues?

[Marcin Siodelski]

We have receintly split a default kea.conf configuration file to 4 files: 
kea-dhcp4.conf, kea-dhcp6.conf etc. for respective Kea services. That impacted 
the keactrl.conf which now has to hold locations of these 4 files, instead of 
just one. If you used old version of keactrl.conf it was pointing to an old 
file and not to the new ones, which in turn confused keactrl.

Marcin

On 19.10.2017 13:42, Jason Lixfeld wrote:
> This seems to have been an issue with my kea config files, although I’m 
> unclear what I did to resolve it...
>
> > On Oct 18, 2017, at 2:03 PM, Jason Lixfeld  wrote:
> >
> > Hi,
> >
> > I notice that in 1.3.0-beta, keactrl doesn’t work…  
> >
> > root@kea2:/home/jlixfeld/kea# uname -a
> > Linux kea2 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 
> > GNU/Linux
> > root@kea2:/home/jlixfeld/kea# cat /etc/debian_version
> > 9.1
> > root@kea2:/home/jlixfeld/kea#
> >
> > root@kea2:/home/jlixfeld/kea# more /usr/local/etc/kea/keactrl.conf
> > # This is a configuration file for keactrl script which controls
> > # the startup, shutdown, reconfiguration and gathering the status
> > # of the Kea's processes.
> >
> > # prefix holds the location where the Kea is installed.
> > prefix=/usr/local
> >
> > # Location of Kea configuration file.
> > kea_config_file=${prefix}/etc/kea/kea.conf
> >
> > # Location of Kea binaries.
> > exec_prefix=${prefix}
> > dhcp4_srv=${exec_prefix}/sbin/kea-dhcp4
> > dhcp6_srv=${exec_prefix}/sbin/kea-dhcp6
> > dhcp_ddns_srv=${exec_prefix}/sbin/kea-dhcp-ddns
> > ctrl_agent_srv=${exec_prefix}/sbin/kea-ctrl-agent
> >
> > # Start DHCPv4 server?
> > dhcp4=yes
> >
> > # Start DHCPv6 server?
> > dhcp6=no
> >
> > # Start DHCP DDNS server?
> > dhcp_ddns=no
> >
> > # Start Control Agent?
> > ctrl_agent=yes
> >
> > # Be verbose?
> > kea_verbose=no
> > root@kea2:/home/jlixfeld/kea# ls -al /usr/local/etc/kea/kea.conf
> > -rw-r--r-- 1 root staff 3004 Oct  6 23:11 /usr/local/etc/kea/kea.conf
> > root@kea2:/home/jlixfeld/kea#
> >
> > root@kea2:/home/jlixfeld/kea# keactrl start
> > basename: missing operand
> > Try 'basename --help' for more information.
> > INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c
> > basename: missing operand
> > Try 'basename --help' for more information.
> > INFO/keactrl: Starting /usr/local/sbin/kea-ctrl-agent -c
> > root@kea2:/home/jlixfeld/kea# /usr/local/sbin/kea-dhcp4: option requires an 
> > argument -- 'c'
> > Kea DHCPv4 server, version 1.3.0-beta-git
> >
> > Usage: kea-dhcp4 -[v|V|W] [-d] [-{c|t} cfgfile] [-p number]
> >  -v: print version number and exit
> >  -V: print extended version and exit
> >  -W: display the configuration report and exit
> >  -d: debug mode with extra verbosity (former -v)
> >  -c file: specify configuration file
> >  -t file: check the configuration file syntax and exit
> >  -p number: specify non-standard port number 1-65535 (useful for testing 
> >only)
> > Usage error: unsupported option: [c]
> > Usage: kea-ctrl-agent
> >  -v: print version number and exit
> >  -V: print extended version information and exit
> >  -W: display the configuration report and exit
> >  -d: optional, verbose output
> >  -c  : mandatory, specify name of configuration file
> >  -t  : check the configuration file and exit
> >
> >
> > root@kea2:/home/jlixfeld/kea# keactrl status
> > basename: missing operand
> > Try 'basename --help' for more information.
> > DHCPv4 server: inactive
> > basename: missing operand
> > Try 'basename --help' for more information.
> > DHCPv6 server: inactive
> > basename: missing operand
> > Try 'basename --help' for more information.
> > DHCP DDNS: inactive
> > basename: missing operand
> > Try 'basename --help' for more information.
> > Control Agent: inactive
> > Kea DHCPv4 configuration file:
> > Kea DHCPv6 configuration file:
> > Kea DHCP DDNS configuration file:
> > Kea Control Agent configuration file:
> > keactrl configuration file: /usr/local/etc/kea/keactrl.conf
> > ERROR/keactrl: Configuration file for Kea not specified.
> > root@kea2:/home/jlixfeld/kea#
> >
>
> ___
> 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 beta - Shared Networks Problem?

[Marcin Siodelski]

Hello Duane,

Thank you for beta testing Kea. Feedback from "external" world is
valuable and allows for catching issues early. This is especially
important in case of "shared networks" which is a pretty complex feature.

Getting to the point, though. I haven't done any actual testing and
didn't try to replicate your problem yet, but since I wrote this code I
can make informed guesses. I am providing a small patch for Kea which
may/should correct this problem. If you can give it a shot, it will be
great. If not, I will try to write a test tomorrow and see if it works
for me. However, there are sometimes details of the environment that
matter. Anyhow, let me know if you can test it and if you need any
assistance in applying the patch.

The patch is available here:

https://pastebin.com/L4UCM3he

I also paste it below for convenience but may have odd line wraps.

Thanks,
Marcin Siodelski
ISC


diff --git a/src/lib/dhcpsrv/alloc_engine.cc
b/src/lib/dhcpsrv/alloc_engine.cc
index f75f795..55effd8 100644
--- a/src/lib/dhcpsrv/alloc_engine.cc
+++ b/src/lib/dhcpsrv/alloc_engine.cc
@@ -2443,6 +2443,10 @@ void findClientLease(AllocEngine::ClientContext4&
ctx, Lease4Ptr& client_lease)
 // configured to ignore client identifier).
 if (client_id) {
 client_lease = lease_mgr.getLease4(*client_id,
subnet->getID());
+if (client_lease) {
+ctx.subnet_ = subnet;
+return;
+}
 }

 // If no lease found using the client identifier, try the
lookup using



On 12.10.2017 19:41, Duane Wylie wrote:
> I'm encountering a strange issue with shared-networks in Kea 1.3 beta. 
> I have eMTA devices (embedded in the cable modems) that are able to pull
> IPs from Kea just fine.  They are failing to TFTP their config, which
> causes them to re-init the DHCP process.  This is where the problem occurs.
> 
> 
> Subsequent DHCPDISCOVERs from the eMTA are not issued the same IP
> address they previously had, they are issued new/different IP
> addresses.  Since the eMTA is stuck in a reboot loop, this eventually
> exhausts the ip pool.  This *ONLY* happens when the subnet is part of a
> shared-network *AND* there are multiple subnets in the shared-network.
> 
> 
> If the subnet is defined *OUTSIDE* of a "shared-network", there is not a
> problem.  The eMTA is issued the same IP address it previously had. 
> Similarly, if the subnet is defined in a shared-network and that
> shared-network only has the one subnet defined, the eMTA is issued the
> same IP address again.
> 
> 
> 
> So, this *DOES* work:
> 
> 
>     "shared-networks": [
> 
>     {
> 
>         "name": "Shared Network Test",
> 
>         "interface": "eth0",
> 
>         "option-data": [
> 
>             {
> 
>                 "name": "domain-name-servers",
> 
>                 "data": "209.124.193.100, 209.124.193.101"
> 
>             }
> 
>         ],
> 
>         "relay": {
> 
>             "ip-address": "206.124.198.1"
> 
>         },
> 
>         "subnet4": [
> 
>             {
> 
>                 "id": 13,
> 
>                 "client-class":
> "VENDOR_CLASS_pktc1.5:05360101010201020501010901010a01010b040106090F0d010110010912020007130101140101150101160101170302001F180100190100",
> 
>                 "subnet": "10.0.42.8/29",
> 
>                 "pools": [ { "pool": "10.0.42.10 - 10.0.42.14" } ],
> 
>                  "relay": {
> 
>                     "ip-address": "206.124.198.1"
> 
>                 },
> 
>                 "next-server": "10.40.4.50",
> 
>                 "option-data": [
> 
>                     # omitted for brevity
> 
>                 ]
> 
>             }
> 
>         ]
> 
>     } ],
> 
> 
> Where this does *NOT*:
> 
> 
>     "shared-networks": [
> 
>     {
> 
>         "name": "Shared Network Test",
> 
>         "interface": "eth0",
> 
>         "option-data": [
> 
>             {
> 
>                 "name": "domain-name-servers",
> 
>                 "data": "209.124.193.100, 209.124.193.101"
> 
>             }
> 
>         ],
> 
>         "relay": {
> 
>             "ip-address": "206.124.198.1"
> 
>         },
> 
>         "subnet4": [
> 
>     

Re: [Kea-users] kea answers to relay using giaddr instead of source address. any way to fix?

[Marcin Siodelski]

On 28.09.2017 13:22, Sergey Klusov wrote:
> On Чт 28.09.2017 16:09, Francis Dupont wrote:
>>   "test": "relay4[2].text == '100.101.101.0'"
>>
>> => please try "test": "relay4[2].hex == 100.101.101.0"
>> (.text does not return what you want if the (sub-)option is not a string
>> and IP address litterals are supported).
>>    
>> Regards
>>
>> Francis Dupont 
>>
> Didn't work, because it converts 100.101.101.0 into 4-byte IP address.
> 
> For now it works this way "relay4[2].hex==0x3130302e3130312e3130312e30",
> but it rather clumsy.
> 
> Mikrotik does not allow to specify binary value either.
> 
> Some function like relay4[2].string would be nice.
> 
> 
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users

Perhaps it will be better to specify the "relay" parameter on the subnet
level:

"relay": {
"ip-address": "100.101.101.0"
}

See: http://kea.isc.org/docs/kea-guide.html#dhcp6-relay-override

The classification will be needed for filtering the RAI option values to
more specifically select the subnet but relay parameter should narrow
down the selection for the relay address.

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

Re: [Kea-users] kea answers to relay using giaddr instead of source address. any way to fix?

[Marcin Siodelski]

On 28.09.2017 11:14, Sergey Klusov wrote:
> Hi, i'm using kea-dhcp4 version 1.1.0 from epel repo.
> Here is tcpdump:
>
> 13:35:31.734452 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
> UDP (17), length 335)
>     x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from
> f4:8b:32:a3:79:3f, length 307, hops 1, xid 0x88cd169e, secs 2, Flags
> [none] (0x)
>   Gateway-IP 100.101.101.1
>   Client-Ethernet-Address f4:8b:32:a3:79:3f
>   Vendor-rfc1048 Extensions
>     Magic Cookie 0x63825363
>     DHCP-Message Option 53, length 1: Discover
>     Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
>     MSZ Option 57, length 2: 1500
>     Vendor-Class Option 60, length 18: "android-dhcp-6.0.1"
>     Hostname Option 12, length 17: "MINOTELTE-MiPhone"
>     Parameter-Request Option 55, length 9:
>   Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
>   MTU, BR, Lease-Time, RN
>   RB
> 13:35:31.736533 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto
> UDP (17), length 330)
>     x.x.x.90.67 > 100.101.101.1.67: [udp sum ok] BOOTP/DHCP, Reply,
> length 302, hops 1, xid 0x88cd169e, Flags [none] (0x)
>   Your-IP 100.101.101.132
>   Gateway-IP 100.101.101.1
>   Client-Ethernet-Address f4:8b:32:a3:79:3f
>   Vendor-rfc1048 Extensions
>     Magic Cookie 0x63825363
>     Subnet-Mask Option 1, length 4: 255.255.255.0
>     Default-Gateway Option 3, length 4: 100.101.101.1
>     Domain-Name-Server Option 6, length 4: x.x.x.10
>     Hostname Option 12, length 17: "MINOTELTE-MiPhone"
>     Lease-Time Option 51, length 4: 86400
>     DHCP-Message Option 53, length 1: Offer
>     Server-ID Option 54, length 4: x.x.x.90
>     Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
>
> Agent's giaddr is not reachable by server, why it keeps sending replies
> to it?
> Is there an option to reply to packet's source address?
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users

From RFC2131:

"If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'."

I read this as the server is doing what it is supposed to do.

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

Re: [Kea-users] Question about reservations, subnet limits and lease control.

[Marcin Siodelski]

Hello Joelson,

See my answers below.


On 15.09.2017 18:22, Joelson Vendramin wrote:
> Hello Kea Users!
> 
> I'm using Kea 1.2.0 in an environment that uses only Option82 (for IPv4) and 
> Option18 (for IPv6) in order to always provide the same addresses to the same 
> client (in fact, the same VLAN ID that asks for IPs).
> 
> Since I don't have the flex-id hook library, I'm implementing IPv4 with the 
> usual "reservations" based on "circuit-id". But for IPv6 I've defined several 
> "subnets" based on "interface-id" provided by DHCPv6 relay agent. Inside each 
> subnet I've declared "pools" (with only one address) and "pd-pools" (with 
> only one prefix).
> 
> Considering this implementation, I've two questions:
> 
> 
> (1) Is there any hard limit on the number of "reservations" (for IPv4) or 
> "subnets & pools & pd-pools" (for IPv6)? Today I'm running about 260 of each, 
> but they tend to increase in the future.
> Note: I'm not using any DB backend, just the default TXT-based memfiles.
> 

There are no arbitrary limits. Kea uses indexing for reservations so the
number of reservations should not have a significant impact on the
server performance. Subnet selection process is slightly more complex
and you may observe some performance degradation with a growing number
of subnets. BTW, there is probably some room for improvement on our end
here.

I suggest that you keep an eye on the CPU utilization by the Kea server
as you increase the number of resources such as subnets, pools and
reservations. If you observe overly increasing CPU utilization while
running Kea, please let us know. We can always try to do better if possible.


> (2) I know that my question will be a bit strange, but... Is there a way to 
> disable any kind of lease control in Kea? What I mean is that, in my 
> environment, the DHCP and DHCPv6 servers just have to answer *always* the 
> same IPv4 address and IPv6 address/prefix, based on Options 82 and 18, no 
> matter of *who* (or what MAC/client-ID) is asking for it.
> 

Kea currently relies on client identifier and/or MAC address to identify
the client. Some form of client identification is always required
because the server has to determine whether the client sending a request
to the server is a returning client or a new client. In the first case,
the server returns existing (possibly extended) lease. In the second
case, the server allocates a new lease. So, "disabling" lease checking
is really not an option for the DHCP server.

What you seem to be looking for is a way to identify a client by some
other value (or a collection of values) regardless of the client
identifier and MAC address. Such identifier would need to be stored in
the lease database apart from client id and MAC address and take
precedence over the other two.

Unfortunately, we don't have such capability at the moment and adding
generic support for this would require many code changes, i.e. changes
in the address allocation engine and extending 3 database backends to
facilitate this extra identifier. That's possible but we'd need some
internal discussion about this first.

One possible shortcut for this is to create a hook library which would
dynamically calculate such identifier (using data in the received
packet) and replace client identifier value with it. The server would
treat this computed value to identify leases in the database etc. When
the response is ready, the hook library would need to replace this
client identifier with an original client identifier (known to the client).

That may require some PoC but it should work just fine.

> I ask this because If the client changes it's CPE device (changing MAC 
> address), the DHCP won't provide any addresses until the lease expires. To 
> workaround this I've configured low values to timers (about 10 min.), but 
> this increases "the conversation" between clients and the servers.

Yes, lowering the lease lifetimes and timers is a good workaround for
this. But, I agree there are tradeoffs.


Marcin Siodelski
ISC


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

Re: [Kea-users] debug logging not displaying boot file option in offer

[Marcin Siodelski]

Hi Jason,

Thanks for bringing this issue. Strictly speaking it is not a (DHCP)
option not being logged but a 'file' field (being a part of a BOOTP
message). There are also other fields not being logged such as 'sname'
and 'siaddr'. It is a bug in Kea. Can you please file a bug ticket for it?

Marcin Siodelski
ISC


On 15.09.2017 21:21, Jason Lixfeld wrote:
> Hi,
> 
> For the longest time, I thought I had some odd configuration error because I 
> would never see bootfile in the options output of the Kea debug, despite me 
> having set it in the config:
> 
> 2017-09-15 14:27:24.742 DEBUG [kea-dhcp4.packets/631] DHCP4_RESPONSE_DATA 
> [hwtype=1 00:01:47:e3:2f:60], cid=[00:31:34:38:38:38:38:30], tid=0x4d5: 
> responding with packet DHCPACK (type 5), packet details: 
> local_address=10.219.66.10:67, remote_address=10.219.45.114:67, 
> msg_type=DHCPACK (5), transid=0x4d5,
> options:
>   type=001, len=004: 4294967040 (uint32)
>   type=006, len=008: 66.207.192.4 206.223.173.6
>   type=051, len=004: 60 (uint32)
>   type=053, len=001: 5 (uint8)
>   type=054, len=004: 10.219.66.10
>   type=058, len=004: 900 (uint32)
>   type=059, len=004: 1800 (uint32)
>   type=061, len=008: 00:31:34:38:38:38:38:30
>   type=082, len=058:,
> options:
> type=001, len=006: 00:04:0c:37:02:01
> type=002, len=011: 01:09:72:67:77:30:31:2e:6c:61:62
> type=005, len=004: 0a:3f:ff:00
> type=151, len=023: 
> 00:72:65:73:69:64:65:6e:74:69:61:6c:2d:6d:61:6e:61:67:65:6d:65:6e:74
> type=152, len=004: 0a:3f:ff:01
> 
> But in a recent tcpdump, I in fact do see the option getting sent by Kea:
> 
> 14:27:24.742363 IP (tos 0x0, ttl 64, id 37950, offset 0, flags [DF], proto 
> UDP (17), length 382)
> 10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x86ad -> 0xb5f1!] 
> BOOTP/DHCP, Reply, length 354, hops 1, xid 0x4d5, Flags [none] (0x)
> Client-IP 10.63.255.209
> Your-IP 10.63.255.209
> Gateway-IP 10.219.45.114
> Client-Ethernet-Address 00:01:47:e3:2f:60
> file "foopoo"[|bootp]
> 
> Is there any way to be able to see this in the logs?
> 
> {
>   "Logging": {
>   "loggers": [
>   {
>   "name": "kea-dhcp4",
>   "output_options": [
>   {
>   "output": 
> "/var/log/kea/kea-dhcp4.log"
>   }
>   ],
>   "severity": "DEBUG",
>   "debuglevel": 99
>   },
>   ]
>   }
> }
> 
> Thanks!
> ___
> 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] Shared subnets configuration - input needed

[Marcin Siodelski]

Hello Kea Users,

We are currently working on implementation of a "shared networks"
mechanism in Kea, to provide ability for grouping multiple subnets
belonging to the same link.

This is useful to extend address pools for clients on the same physical
link, i.e. clients located on this link may get addresses from different
subnets. In such case, the DHCP server would allocate addresses from
another subnet (and its pools) if there are no more addresses available
in the first subnet.

It is also useful in cable networks, when a cable modem and a router are
on the same physical link but they should get addresses from different
subnets. Client classification is used in such case.

The ISC engineering team has been working on a design for this feature.
One of the contentious points is how to organize shared networks
configuration within the Kea config file.

We have discussed three different options. Let's call them A, B, C,
which are briefly discussed below. The ISC engineering team is leaning
towards A, but we'd also like to get some input from our Users what they
think might be more convenient.

Proposal A

Sample configuration link:
http://kea.isc.org/wiki/SharedSubnetsDesign#ConfigurationFormat

In this case, the shared-networks list contains a full specification of
each subnet that belongs to shared networks. It is still possible to
define subnets outside of the shared-networks scope. Such subnets will
not be associated with any shared network.

Pros:
- Make use of hierarchical nature of JSON - subnets enclosed within
shared-networks structure belong to shared-networks. Other subnets do
not. No need to refer to subnets from another structure by name or id etc.
- Avoid configuration error whereby a single subnet may belong to
different shared networks.
- Avoid configuration error caused by manual matching of subnets with
networks.
- Is compatible with autogenerated subnet identifiers.
- JSON viewing tools can be used to visualize which subnets belong to
shared network by simply looking at the JSON hierarchy.
- Is similar to other configuration structures we use (except option
definitions).
- Is similar to how it is organized in ISC DHCP.

Cons:
- Moving subnets between shared networks requires copy pasting large
portions of configuration (entire subnet specification has to be
copied), possibly between distant locations in the configuration file.
- Makes it hard to see how many subnets are specified within a shared
network without JSON processing tools that can hide portions of the
configuration.


Proposal B
Sample configuration link:
http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative1

This is the first of the proposals in which all subnets are defined at
the same configuration level (regardless if they belong to shared
networks or not). The shared-networks structure is separate and for each
network it refers to subnet ids that belong to the shared network.

Pros:
- shared-networks structure is much smaller because it only contains
subnet identifiers, rather than full subnet definitions. It may also
contain DHCP options etc.
- It makes it easier to move subnets between shared networks (or remove
them entirely) because it is just a matter of copy pasting subnet ids,
rather than full network specifications.

Cons:
- User error prone: subnet ids specified within shared-networks must
exist. It is easy to specify id of non-existing subnet or id of a wrong
subnet.
- User error prone: it is possible to specify the same id in two
different networks which is not allowed
- If there are many subnets, specifying a subnet and associating it with
a shared network means update to the config file in two different
(possibly distant) locations.
- Removal of a subnet belonging to a shared network requires config
update in two different locations.
- Is incompatible with autogenerated subnet identifiers because these
identifiers may vary between server configurations, e.g. when any subnet
is removed.
- Generic JSON tools can't do matching between subnets and shared
networks because they can't interpret subnet ids as a reference.


Proposal C
Sample configuration link:
http://kea.isc.org/wiki/SharedSubnetsDesign#Alternative2

Pros:
- Has the same pros as proposal B
- It avoids the use of subnet ids, but uses shared network names (subnet
ids autogeneration problem is solved)
- Resolves a problem with proposal B, whereby it was possible to assign
a single subnet to multiple networks.
- Removal of a subnet is easier than in B, because it is enough to
delete subnet declaration.

Cons:
- Comparing to B, it makes it harder to know how many subnets belong to
shared network, because we'd need to search for all subnets that have a
parameter "network" set to a given name.
- Some other unresolved cons from proposal B.


We're planning to close the discussion around Monday/Tuesday next week.
We'd appreciate any input before that time.

Kind Regards,

Marcin Siodelski

Re: [Kea-users] Setting interface name while running

[Marcin Siodelski]

I guess you could simply use the CfgIface object which you retrieve by:

CfgMgr::instance()->getStagingCfg()->getCfgIface() and call

its use() function to set the interface name which you're planning to use.

Marcin Siodelski
ISC

On 24.08.2017 15:59, Gokulakrishnan Gopalakrishnan wrote:
> I have a use case like this. The interface name in which Kea needs to
> listen (eg: eth0) is not known before hand. I can determine only after
> starting Kea Process. Is there any way to set the interface name
> during <int load(LibraryHandle&)> hook?
>
> Thanks
> Gokul
>
>
> ___
> 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] Getting the interface name in hooks

[Marcin Siodelski]

That's because the load() function is called as a result of parsing
server configuration when your hook library is loaded. At this point
there is no committed server configuration yet (because server
configuration is being parsed). What you could try is:

ConstCfgIfacePtr cfg =  CfgMgr::instance().getStagingCfg()->getCfgIface();

instead of

ConstCfgIfacePtr cfg =  CfgMgr::instance().getCurrentCfg()->getCfgIface();

because "staging" configuration should already contain the information
about interfaces (the interfaces parser is launched before the hooks
libs parser).

Give it a try.

Marcin

On 23.08.2017 19:57, Gokulakrishnan Gopalakrishnan wrote:
> Marcin,
> When I placed the code in "load(LibraryHandle&), I'm getting empty
> interface list, whereas if I keep the code in another hook like
> pkt4_send, I'm getting the proper list of interfaces.
> Actually, I'd be needing this info while initializing the Kea Process
> itself. Can we get it somehow?
>
> On Wed, Aug 23, 2017 at 8:02 PM, Gokulakrishnan Gopalakrishnan
> <ggopalakrish...@salesforce.com <mailto:ggopalakrish...@salesforce.com>>
> wrote:
>
>     Thanks Marcin. It worked
>
>     On Wed, Aug 23, 2017 at 4:28 PM, Marcin Siodelski <mar...@isc.org
>     <mailto:mar...@isc.org>> wrote:
>
>     You'd rather need to link with this:
>
>     libdhcp_user_chk_la_LIBADD  +=
>     $(top_builddir)/src/lib/dhcpsrv/libkea-dhcpsrv.la
>     <http://libkea-dhcpsrv.la>
>
>     In most cases you'd also need to link with libkea-dhcpsrv.la
>     <http://libkea-dhcpsrv.la>
>     dependencies which you can find it its Makefile.am.
>
>     As for the automake error it seems to me that you're missing
>     automake-1.14. Perhaps you have some different version?
>     automake-1.15?
>
>     Maybe go to Kea root directory and run autoreconf --install &&
>     ./configure ... && make
>
>     again.
>
>     Marcin
>
>     On 23.08.2017 12:41, Gokulakrishnan Gopalakrishnan wrote:
>     > Thanks Marcin, I just did what you mentioned in the code and
>     > printed *iface_configuation->str()* and it prints an empty array
>     > interface. Probably because I didn't link the hook user_chk
>     > with *libkea-dhcpsrv*.
>     > I tried linking* **libkea-dhcpsrv *by adding
>     >
>     > libdhcp_user_chk_la_LIBADD  +=
>     $(top_builddir)/src/lib/hooks/libkea-dhcpsrv.la
>     <http://libkea-dhcpsrv.la> <http://libkea-dhcpsrv.la>
>     >
>     > in src/hooks/dhcp/user_chk/Makefile.am <http://efile.am> and
> did a make.
>     >
>     > I'm getting automake-1.14: command not found. Every time editing
>     > Makefile.am, I'm getting this error. Am I doing the linking
> correctly?
>     > Am I missing something here? Please correct me if I'm wrong
>     >
>     >
>     >
>     >
>     > On Wed, Aug 23, 2017 at 3:09 PM, Marcin Siodelski
> <mar...@isc.org <mailto:mar...@isc.org>
>     > <mailto:mar...@isc.org <mailto:mar...@isc.org>>> wrote:
>     >
>     >     On 23.08.2017 11:24, Gokulakrishnan Gopalakrishnan wrote:
>     >     > "interfaces-config": {
>     >     >
>     >     >         "interfaces": [ "eth0" ]
>     >     >
>     >     >   }
>     >     >
>     >     > Can we get the list of interface name in hooks code? In
>     the example
>     >     > mentioned above, can we get the value "eth0" in hooks
>     code in
>     >     > <int load(LibraryHandle&)> function?
>     >     >
>     >     >
>     >
>     >     To retrieve server configuration information you'd need to
>     link your
>     >     hook library with libkea-dhcpsrv and do something like this:
>     >
>     >     #include 
>     >
>     >     ConstCfgIfacePtr cfg =
>     >     CfgMgr::instance().getCurrentCfg()->getCfgIface();
>     >     ElementPtr iface_configuation = cfg->toElement();
>     >
>     >     The iface_configuration will now hold the conifguration
>     structure you're
>     >     looking for.
>     >
>     >     Marcin Siodelski
>     >     ISC
>     >
>     >
>
>
>

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

Re: [Kea-users] Getting the interface name in hooks

[Marcin Siodelski]

You'd rather need to link with this:

libdhcp_user_chk_la_LIBADD  +=
$(top_builddir)/src/lib/dhcpsrv/libkea-dhcpsrv.la

In most cases you'd also need to link with libkea-dhcpsrv.la
dependencies which you can find it its Makefile.am.

As for the automake error it seems to me that you're missing
automake-1.14. Perhaps you have some different version? automake-1.15?

Maybe go to Kea root directory and run autoreconf --install &&
./configure ... && make

again.

Marcin

On 23.08.2017 12:41, Gokulakrishnan Gopalakrishnan wrote:
> Thanks Marcin, I just did what you mentioned in the code and
> printed *iface_configuation->str()* and it prints an empty array
> interface. Probably because I didn't link the hook user_chk
> with *libkea-dhcpsrv*. 
> I tried linking* **libkea-dhcpsrv *by adding 
> 
> libdhcp_user_chk_la_LIBADD  += 
> $(top_builddir)/src/lib/hooks/libkea-dhcpsrv.la <http://libkea-dhcpsrv.la>
> 
> in src/hooks/dhcp/user_chk/Makefile.am and did a make.
> 
> I'm getting automake-1.14: command not found. Every time editing
> Makefile.am, I'm getting this error. Am I doing the linking correctly?
> Am I missing something here? Please correct me if I'm wrong
> 
> 
> 
> 
> On Wed, Aug 23, 2017 at 3:09 PM, Marcin Siodelski <mar...@isc.org
> <mailto:mar...@isc.org>> wrote:
> 
> On 23.08.2017 11:24, Gokulakrishnan Gopalakrishnan wrote:
> > "interfaces-config": {
> >
> >         "interfaces": [ "eth0" ]
> >
> >   }
> >
> > Can we get the list of interface name in hooks code? In the example
> > mentioned above, can we get the value "eth0" in hooks code in
> > <int load(LibraryHandle&)> function?
> >
> >
> 
> To retrieve server configuration information you'd need to link your
> hook library with libkea-dhcpsrv and do something like this:
> 
> #include 
> 
> ConstCfgIfacePtr cfg = 
> CfgMgr::instance().getCurrentCfg()->getCfgIface();
> ElementPtr iface_configuation = cfg->toElement();
> 
> The iface_configuration will now hold the conifguration structure you're
> looking for.
> 
> Marcin Siodelski
> ISC
> 
> 

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

Re: [Kea-users] skip timed out requests

[Marcin Siodelski]

On 17.08.2017 14:02, Itay Rozenberg wrote:
>  
> 
> Hello list
> 
>  
> 
> Does someone know a way telling kea to skip requests that are waiting in
> the  queue more then X seconds ?
> 
>  
> 

There is no such functionality in Kea. The server doesn't check the
packets timestamps on arrival.

Marcin

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

Re: [Kea-users] kea dhcp4 libmysqlclient segfault

[Marcin Siodelski]

On 21.07.2017 18:01, Marcin Siodelski wrote:
> On 20.07.2017 19:47, Juan Settecase - Interlink S.R.L. wrote:
> > Hi!
> > I'm having a problem with my kea-dhcp4 server(s) falling over regularly
> > with a segmentation fault (one , the line I'm seeing in the logs is
> this:
> >
> > Jul 19 09:45:00 vmarm kernel: [2429068.963315] kea-dhcp4[5818]: segfault
> > at 451 ip 7f1605d1614c sp 7ffc59c8a030 error 4 in
> > libmysqlclient.so.18.0.0[7f1605ce3000+2b8000]
> >
> > I've seen anothers mails lists with the same problem but no solution or
> > news.
> >
> > This is the current kea-1.2 built on a Debian 8.7 (fully updated)
> > server. Mysql is on the same server. This is our first Kea DHCP Server
> > 1.2 on Lab.
> >
> > Has anyone else seen this? If there's any further debug logging you need
> > just let me know.
> >
> > libmysqlclient18:amd64 5.5.54-0+deb8u1
> > mysql-server-5.5   5.5.54-0+deb8u1
> >
> > Thanks in advanced
> >
> > Juan
>
> Hi Juan,
>
> Thanks for raising your issue. I can hardly tell what it can be without
> additional information. Other issues around MySQL, recently brought to
> our attention, were related to Kea's shutdown when it detects that the
> connection to the MySQL server was broken. This is in fact not the issue
> but the way it is currently intended to be.
>
> Your problem seems to be related to something else. Perhaps some data
> structures that Kea ships to MySQL are not quite right. Or, the MySQL
> client is doing something wrong. A core dump would be useful, as well as
> Kea debug log (severity DEBUG, debuglevel 99) to identify what was the
> last thing that Kea was doing before the crash.
>
> I think there might be additional data needed, but this is a start.
>
> If sending sensitive data is a concern, you're free to send it directly
> to me.
>
> Marcin Siodelski
> ISC
>

What I rather meant is the stack trace from the crash rather than the
entire core dump.

Marcin

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

Re: [Kea-users] kea dhcp4 libmysqlclient segfault

[Marcin Siodelski]

On 20.07.2017 19:47, Juan Settecase - Interlink S.R.L. wrote:
> Hi!
> I'm having a problem with my kea-dhcp4 server(s) falling over regularly
> with a segmentation fault (one , the line I'm seeing in the logs is this:
>
> Jul 19 09:45:00 vmarm kernel: [2429068.963315] kea-dhcp4[5818]: segfault
> at 451 ip 7f1605d1614c sp 7ffc59c8a030 error 4 in
> libmysqlclient.so.18.0.0[7f1605ce3000+2b8000]
>
> I've seen anothers mails lists with the same problem but no solution or
> news.
>
> This is the current kea-1.2 built on a Debian 8.7 (fully updated)
> server. Mysql is on the same server. This is our first Kea DHCP Server
> 1.2 on Lab.
>
> Has anyone else seen this? If there's any further debug logging you need
> just let me know.
>
> libmysqlclient18:amd64 5.5.54-0+deb8u1
> mysql-server-5.5   5.5.54-0+deb8u1
>
> Thanks in advanced
>
> Juan

Hi Juan,

Thanks for raising your issue. I can hardly tell what it can be without
additional information. Other issues around MySQL, recently brought to
our attention, were related to Kea's shutdown when it detects that the
connection to the MySQL server was broken. This is in fact not the issue
but the way it is currently intended to be.

Your problem seems to be related to something else. Perhaps some data
structures that Kea ships to MySQL are not quite right. Or, the MySQL
client is doing something wrong. A core dump would be useful, as well as
Kea debug log (severity DEBUG, debuglevel 99) to identify what was the
last thing that Kea was doing before the crash.

I think there might be additional data needed, but this is a start.

If sending sensitive data is a concern, you're free to send it directly
to me.

Marcin Siodelski
ISC

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

Re: [Kea-users] No answer from kea

[Marcin Siodelski]

net id 2, identified by client-id=0100A012DA26D000
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER_NULL host not found
> > using subnet id 2 and identifier client-id=0100A012DA26D000
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.ddns/13276]
> > DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 00:a0:12:da:26:d0],
> > cid=[01:00:a0:12:da:26:d0:00], tid=0xbdb: processing client's Hostname
> > option
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.dhcpsrv/13276]
> > DHCPSRV_MYSQL_GET_SUBID_CLIENTID obtaining IPv4 lease for subnet ID 2
> > and client ID 01:00:a0:12:da:26:d0:00
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.dhcpsrv/13276]
> > DHCPSRV_MYSQL_GET_HWADDR obtaining IPv4 leases for hardware address
> > hwtype=1 00:a0:12:da:26:d0
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.alloc-engine/13276]
> > ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer
> > new lease to the client [hwtype=1 00:a0:12:da:26:d0],
> > cid=[01:00:a0:12:da:26:d0:00], tid=0xbdb
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for
> > subnet id 2 and IPv4 address 172.20.220.82
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4
> > address 172.20.220.82
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 172.20.220.82, found 0
> > host(s)
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet
> > id 2 and address 172.20.220.82
> >
> > 2017-07-20 12:50:51.347 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate source
> > for host using subnet id 2 and address 172.20.220.82
> >
> > 2017-07-20 12:50:51.348 DEBUG [kea-dhcp4.dhcpsrv/13276]
> > DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 172.20.220.82
> >
> > 2017-07-20 12:50:51.348 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for
> > subnet id 2 and IPv4 address 172.20.220.83
> >
> > 2017-07-20 12:50:51.348 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4
> > address 172.20.220.83
> >
> > 2017-07-20 12:50:51.348 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 172.20.220.83, found 0
> > host(s)
> >
> > 2017-07-20 12:50:51.348 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet
> > id 2 and address 172.20.220.83
> >
> > 2017-07-20 12:50:51.348 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate source
> > for host using subnet id 2 and address 172.20.220.83
> >
> > 2017-07-20 12:50:51.349 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for
> > subnet id 2 and IPv4 address 172.20.220.84
> >
> > 2017-07-20 12:50:51.349 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4
> > address 172.20.220.84
> >
> > 2017-07-20 12:50:51.349 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 172.20.220.84, found 0
> > host(s)
> >
> > 2017-07-20 12:50:51.349 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet
> > id 2 and address 172.20.220.84
> >
> > 2017-07-20 12:50:51.349 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate source
> > for host using subnet id 2 and address 172.20.220.84
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for
> > subnet id 2 and IPv4 address 172.20.220.85
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4
> > address 172.20.220.85
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 172.20.220.85, found 0
> > host(s)
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet
> > id 2 and address 172.20.220.85
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.hosts/13276]
> > HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate source
> > for host using subnet id 2 and address 172.20.220.85
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.dhcpsrv/13276]
> > DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 172.20.220.85
> >
> > 2017-07-20 12:50:51.350 WARN  [kea-dhcp4.alloc-engine/13276]
> > ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 00:a0:12:da:26:d0],
> > cid=[01:00:a0:12:da:26:d0:00], tid=0xbdb: failed to allocate an IPv4
> > address after 4 attempt(s)
> >
> > 2017-07-20 12:50:51.350 DEBUG [kea-dhcp4.bad-packets/13276]
> > DHCP4_PACKET_NAK_0003 [hwtype=1 00:a0:12:da:26:d0],
> > cid=[01:00:a0:12:da:26:d0:00], tid=0xbdb: failed to advertise a lease,
> > client sent ciaddr 0.0.0.0, requested-ip-address (no address)
> >


It looks like you have a short pool of addresses in your address pools
(four) and you have ran out of them, i.e. they have been allocated to
some other clients.

Marcin Siodelski
ISC



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

Re: [Kea-users] Force DHCP option in response

[Marcin Siodelski]

On 06.07.2017 14:24, Arne Baeumler wrote:
> Hi,
>
> is there a way to append non standard dhcp options not explicitly
> requested by the client?
> We use DHCP option 43 to provide ACS URL to our CPE's.
> The majority of our CPEs (AVM Fritz!Box) do not request option 43 in
> their DHCP Request.
>
> In ISC DHCPD we added within the shared-network configuration:
>
>append dhcp-parameter-request-list 43;
>
> Is there anything similar to "append" in Kea?
>

Arne,

This is going to be implemented in Kea 1.3.0 release. See ticket
http://kea.isc.org/ticket/5241.

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

Re: [Kea-users] DHCPv6, anybody got it working?

[Marcin Siodelski]

Ricardo,

Your "subnet6" declaration should be updated to include an "interface"
or "relay" parameter to indicate when this particular subnet should be
selected.

For example:

"relay": {
   "ip-address": "3000::1"
}

or

"interface": "eth0"

In the former case, for DHCP messages received from the particular relay
agent the server will use the given subnet. In the latter case this
subnet will be picked for the messages received on "eth0" interface.

Marcin Siodelski
ISC Engineering


On 19.06.2017 17:51, Ricardo J. Barberis wrote:
> Hi all,
> 
> I've been trying to make kea-dhcp6 work with no luck so far.
> 
> I'm on CentOS 7.3 (client and server), I tried 1.1.0 from EPEL and 1.2.0 
> self-compiled. Client has dhclient-4.2.5-47.el7.
> 
> I started configuring a lot of things (host reservations, hosts and leases in 
> mysql, etc) in a non-default way, so I figured I did something wrong, but 
> last Friday I tried a very basic, mostly default config and stil I can't get 
> an IPv6.
> 
> Clients always get 'IA_NA status code NoAddrsAvail: "Server could not select 
> subnet for this client"'.
> 
> 
> Has anybody made kea-dhcp6 work? Can you share a working config to see what 
> I'm doing wrong?
> 
> 
> Here's my last kea.conf as a reference (dhcp4 always worked fine for me, BTW):
> 
> {
> "Dhcp4": {
>   "interfaces-config": {
> "interfaces": [ "eth0" ]
>   },
>   "lease-database": {
> "type": "memfile"
>   },
>   "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
>   },
>   "valid-lifetime": 4000,
>   "subnet4": [
> {
>   "subnet": "NN.NN.NN.0/24",
>   "pools": [ { "pool": "NN.NN.NN.2-NN.NN.NN.10" } ],
>   "id": 2,
> }
>   ]
> },
> 
> "Dhcp6": {
>   "interfaces-config": {
> "interfaces": [ "eth0" ]
>   },
>   "lease-database": {
> "type": "memfile"
>   },
>   "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
>   },
>   "preferred-lifetime": 3000,
>   "valid-lifetime": 4000,
>   "renew-timer": 1000,
>   "rebind-timer": 2000,
>   "subnet6": [
> {
>   "subnet": "2800:::/64",
>   "pools": [ { "pool": "2800:::/64" } ],
>   "id": 1
> }
>   ]
> },
> 
> "DhcpDdns":
> {
>   "ip-address": "127.0.0.1",
>   "port": 53001,
>   "tsig-keys": [],
>   "forward-ddns" : {},
>   "reverse-ddns" : {}
> },
> 
> "Logging":
> {
>   "loggers": [
> {
>   "name": "kea-dhcp4",
>   "output_options": [
>   {
> "output": "/var/log/kea-dhcp4.log"
>   }
>   ],
>   "severity": "INFO",
>   "debuglevel": 0
> },
> {
>   "name": "kea-dhcp6",
>   "output_options": [
>   {
> "output": "/var/log/kea-dhcp6.log"
>   }
>   ],
>   "severity": "DEBUG",
>   "debuglevel": 99
> },
> {
>   "name": "kea-dhcp-ddns",
>   "output_options": [
>   {
> "output": "/var/log/kea-ddns.log"
>   }
>   ],
>   "severity": "INFO",
>   "debuglevel": 0
> }
>   ]
> }
> }
> 

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

Re: [Kea-users] Cisco Nexus 3048 error

[Marcin Siodelski]

On 15.05.2017 10:56, Olivier Français wrote:
> Hi,
>
> Yes, we use reservation in SQL database with mac address. We also add a
> pool of IPs in the subnet.
>
>

We have recently got similar report from another Kea user and it turned
out to be the issue with a reservation for an option inserted into MySQL
database.

The way it should be done is:

SET @dns_servers_option_code = 5;
-- This option comprises one or multiple IPv4 addresses. --
-- We insert option containing two IPv4 addresses: 192.0.2.1 and --
-- 192.0.2.2 by concatenating hexadecimal representations of these --
-- addresses and then converting the result into binary format. --
SET @dns_servers_option_value =
UNHEX(CONCAT(LPAD(HEX(INET_ATON('10.0.2.1')), 8, 0),
LPAD(HEX(INET_ATON('10.0.2.2')), 8, 0)));

INSERT INTO dhcp4_options (code, value, space, host_id, scope_id)
VALUES (@dns_servers_option_code,
@dns_servers_option_value,
'dhcp4',
@inserted_host_id,
(SELECT scope_id FROM dhcp_option_scope WHERE scope_name =
@scope_name));


You should pay attention to the use of LPAD() MySQL function which, in
this example, guarantees that each IP address (10.0.2.1 and 10.0.2.2) is
padded with a leading zeros  if needed and is exactly 8 digits long. If
you omit the LPAD() function some IP addresses will be truncated and the
overall option length will be shorter. Kea will complain that the
options are invalid.

Please give it a try and let me know if you have further issues.

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

Re: [Kea-users] Kea 1.1.0, MySQL and client-id

[Marcin Siodelski]

On 09.01.2017 17:46, Olivier Français wrote:
> Hi,
>
> I've apply your patch, recompile and install : it doesn't work.
> My device get and IP, but not the reserved IP.
>
> To test my config, I try host reservation with hw-address : it works.
>
> The test config :
>
> {
>   "Dhcp4": {
> "renew-timer": 60,
> "rebind-timer": 120,
> "expired-leases-processing": {
>   "hold-reclaimed-time": 3600,
>   "unwarned-reclaim-cycles": 5,
>   "max-reclaim-time": 250,
>   "max-reclaim-leases": 100,
>   "flush-reclaimed-timer-wait-time": 25,
>   "reclaim-timer-wait-time": 10
> },
> "valid-lifetime": 180,
> "interfaces-config": {
>   "interfaces": [
> "*"
>   ],
>   "dhcp-socket-type": "udp"
> },
> "option-def": [
>   
> ],
> "option-data": [
>   
> ],
> "subnet4": [
>   {
> "pools": [
>   {
> "pool": "192.168.1.5-192.168.1.10"
>   }
> ],
> "next-server": "",
> "id": 1,
> "subnet": "192.168.1.0\/24",
> "option-data": [
>   
> ]
>   }
> ],
> "hosts-database": {
>   "name": "kea",
>   "user": "kea",
>   "type": "postgresql",
>   "password": "***",
>   "host": "db"
> },
> "lease-database": {
>   "name": "kea",
>   "user": "kea",
>   "type": "postgresql",
>   "password": "***",
>   "host": "db"
> }
>   }
> }
>
> Info in database (PG 9.4.10) :
>
> kea=> select * from lease4;
> -[ RECORD 1 ]--+-
> address| 3232235781
> hwaddr | \xc8f9f9f79440
> client_id  | \x0073772d3235373431332d326b
> valid_lifetime | 180
> expire | 2017-01-09 16:25:34+00
> subnet_id  | 1
> fqdn_fwd   | t
> fqdn_rev   | t
> hostname   | sw-257413-2k
> state  | 0
>
> kea=> select * from hosts;
> -[ RECORD 1 ]-+-
> host_id   | 5
> dhcp_identifier   | \x0073772d3235373431332d326b
> dhcp_identifier_type  | 3
> dhcp4_subnet_id   | 1
> dhcp6_subnet_id   |
> ipv4_address  | 3232235802
> hostname  |
> dhcp4_client_classes  |
> dhcp6_client_classes  |
> dhcp4_next_server |
> dhcp4_server_hostname |
> dhcp4_boot_file_name  |
>  
> Maybe I've make a mistake, but I didn't see it.
> If you need more info, feel free
>

Please specify:

"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid",
"client-id" ]

or simply:

"host-reservation-identifiers": [ "client-id" ]

if only using client ids in host reservations.

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

Re: [Kea-users] mysql connection in hooks

[Marcin Siodelski]

On 08.12.2016 09:45, Igor Smitran wrote:
> @Marcin Siodelski:
>
> Can you please share your user_chk hook with mysql connection that you
> used in webinar?
> It would be huge help...
>
> Thank you,
> Igor Smitran
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users

Igor,

Please use my Kea fork on github: https://github.com/msiodelski/kea. The
code is available on the branch "kea-webinar". Remember that this is a
demo code so it lacks docs, unit tests and may be suboptimal.

Still, I hope it is going to help you in what you're doing.

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

Re: [Kea-users] Host reservations in MySQL database

[Marcin Siodelski]

On 09.11.2016 19:19, Christian Garling wrote:
> Hello,
> 
> I am setting up KEA as part of a provisioning system. Therefore I want
> to use host reservations with MySQL to realize PXE boot of my machines.
> My dataset consists of:
> 
> dhcp_identifier=x'ab12cd34ef56' (MAC address of the system in lower case
> letters withouts colons)
> dhcp_identifier_type='0'
> dhcp4_subnet_id='1' (matches my subnet id in kea.conf)
> ipv4_address=INET_ATON('192.168.1.25') (reserved IP for the host to
> install)
> hostname='srv01.example.com'
> dhcp4_next_server=INET_ATON('192.168.1.10') (IP of my tftp server)
> dhcp4_server_hostname=INET_ATON('192.168.1.10') (IP of my tftp server
> again -> not sure if its correct)
> dhcp4_boot_file='pxelinux.0'
> 
> If the machine tries to PXE boot it does not get the reserved IP and it
> does not boot the PXE image. If I configure the same reservation in the
> kea.conf itself PXE boot works fine.
> 
> I did not find any format specification how to store the data above
> correctly in the database. Specially the dhcp_identifier could be wrong
> I think.
> 
> I already enabled the MySQL general log and there I can see a lot of
> queries from the KEA server, so the database connections seems to be fine.
> 
> Can someone help with that?
> 
> Regards, Christian
> 
> 

Christian,

The dhcp4_server_hostname value is a null terminated string per
BOOTP/DHCPv4 specs and thus it should rather be specified as
'192.168.1.25', not as INET_ATON('192.168.1.25'). Though, it may still
not resolve the problem. The major question is whether the server gets
the reservation from the MySQL but what it provides to the PXE client
makes the client unhappy, or the server is unable to obtain a
reservation from the MySQL database. I am not clear about that from your
description. Could you share a log (debug) output from the Kea server?

Also, it would help if you could share the config file, the mysql-dump
of hosts MySQL table and the queries you observe between Kea and MySQL
server.

If you don't feel like sharing it with a list, you're free to send it
privately.

Thanks,

Marcin Siodelski
ISC

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

Re: [Kea-users] Client connectivity problem

[Marcin Siodelski]

Toby,

Kea performs a lookup of the reservations in two places. Firstly, in a
configuration file. If not found, the will use one of the alternative
places: MySQL or PostgreSQL. The log fragments you have provided pertain
to the phase when the reservation is being looked up in the
configuration file. Because you have stored your reservation in the
MySQL database (not config file), it is expected that it returns:

2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.hosts/4695]
HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
hwaddr=001122334455, found 0 host(s)

However, if MySQL hosts database is also used by Kea the most
interesting part would be to see logs from the Kea talking to the
database. Unfortunately, I now found that the function which retrieves
host reservations from MySQL by MAC address lacks some logging
statements and that is probably the reason why we don't see any output
from attempts to retrieve the reservation from MySQL. We'll need to fix
that. But, it doesn't mean that the lookup doesn't take place.

In any case, I don't think I can get any closer to resolving this
problem without Kea configuration file and the entire (debug?) log. The
dump of hosts MySQL table would also be good.

A typical error can be a subnet-id mismatch between the Kea
configuration file and the host entries within the database.

If you're uncomfortable with sending configuration file and a dump of
the hosts table to the list, you're welcome to send it directly to me.

BTW, it should be ok that colons are stripped from the MAC address
because we store hosts in the database without colons.

Marcin

On 12.11.2016 09:20, Toby Walsh wrote:
> I've found what I think is the problem. I decoupled systemd and went
> back to running keactrl myself and turned on verbose mode. In the
> logs, when the client device is trying to obtain an IP from the table,
> it uses the wrong hw-addr. Someone else is having the same problem it
> seems, because google turned up this:
> 
> https://gist.github.com/jefferyharrell/0dc515a2d6a9bf639a5e6f8be03e01eb
> 
> Unlike that guy, I get no message about closing the hosts table. Mine
> looks more like this:
> 
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.packets/4695]
> DHCP4_SUBNET_DATA [hwtype=1 00:11:22:33:44:55], cid=[no info],
> tid=0xfdc54451: the selected subnet details: 10.10.10.10/24
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.hosts/4695]
> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4
> reservation for subnet id 1, identified by hwaddr=001122334455
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.hosts/4695]
> HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
> identifier: hwaddr=001122334455
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.hosts/4695]
> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
> hwaddr=001122334455, found 0 host(s)
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.hosts/4695]
> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using
> subnet id 199 and identifier hwaddr=001122334455
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.bad-packets/4695]
> DHCP4_PACKET_DROP_0007 [hwtype=1 00:11:22:33:44:55],
> cid=[01:00:11:22:33:44:55], tid=0x5f091348: failed to process packet:
> DHCPv4 Option4AddrLst 5 has invalid length=19, must be divisible by 4.
> 2016-07-18 11:19:18.032 DEBUG [kea-dhcp4.packets/3131]
> DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms
> 
> So, it's getting the correct subnet using a colon-separated MAC but
> the next steps (presumably looking up the hosts table?) it's using a
> stripped MAC, without colons, and failing to find any host reservation
> and dropping the packet.
> 
> My hosts table was populated as per the "Tips about Host Reservations
> in Kea 1.1" page, i.e. the dhcp_identifier field had
> UNHEX(REPLACE('00:11:22:33:44:55', ':', '')) inserted in it. The type
> of that field was varbinary(128). I can't unhex leaving the colons in,
> and I'm not sure what format the Kea queries expect other than to go
> off the examples on that page. But that might be the problem?
> 
> On top of my failure and this other guy's on github, there are several
> examples using the HOSTS_CFG_GET keywords of people who did
> successfully perform the lookups with colon-separated MACs. So I'm
> wondering what the github and my config have done differently?
> 
> 
> 
> 
> On 12 November 2016 at 11:13, Toby Walsh  wrote:
>> I have isolated this to something wrong with my database connection. I
>> have strictly followed the instructions from "Tips about Host
>> Reservations in Kea 1.1". I have a hosts table and a dhcp4_options
>> table configured correctly. When I restart the kea-dhcp4 server the
>> logs tell me the server is started correctly. I now have Kea set up to
>> run under systemctl and those logs tell me that on restarting the
>> server the lease database and the hosts database are opened. The lease
>> database is correctly populated by Kea upon obtaining a lease. But the
>> hosts database is not read 

Re: [Kea-users] Host reservations and subnet run-time modification

[Marcin Siodelski]

On 27.09.2016 12:10, Rui Pedro Caldeira wrote:
> Hello guys, I once again ask for your help.
> 
> Is there any way I can (using a hooks library in Kea 1.0.0) add, modify
> and remove both host reservations, subnets, dhcp options and routes?
> 
> Best regards,
> Rui
> 
>  
> -- 
>   

Hello,

Sorry for the delayed response. Can you make it more specific from where
you want to remove subnets, options and routes?

Marcin Siodelski
ISC

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

Re: [Kea-users] kea Issues

[Marcin Siodelski]

Roman,

On 10.10.2016 16:36, Власюк Роман wrote:
> Hello!
>
> While testing kea dhcp server 1.1.0 version I have collected some
> questions about some of the functions.
>
> 1) I can not assign an address pool for subnet that is not included to
> subnet range. It is not very useful for some of our goals. Will it be an
> opportunity to use an address pool, not from the range of configured
> subnet?
>

Currently it is only possible for the DHCPv6 prefix delegation, as we
know the use cases for this.

As for the address assignment case, can you describe the specific use
case for it? It would help us evaluate whether there are any
possibilities to achieve that with a current functionality.


> 2) There is no opportunity to set different lease time, renew time and
> rebind time for different networks, classes or clients. These options
> could be assigned just globally, but there is a strong need to set
> different lease time to different group of clients. The same issue is
> related to subnet mask.
> Will it be fixed in next realizations of kea?
>


It is possible to specify the timers for subnets. It is currently not
possible to specify them for classes or hosts. I believe we could
include timers for classes or hosts in the future but probably post 1.2
release.

> 3) How can I use reserved options for group of clients (subnet, class)
> in MySQL tab? While using entries for options without host_id, it takes
> no effect. Host gets needed option just after setting correct host_id in
> to MySQL entry.
>

There is currently no way to specify subnet specific options or class
specific options in MySQL. We are aiming to migrate most (if not all)
configuration to the database but this is a future.

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

Re: [Kea-users] Missing host parameter in kea-admin

[Marcin Siodelski]

On 17.10.2016 13:53, Thomas Andersen wrote:
> Hi,
> 
>  
> 
> The command ’kea-admin lease-version mysql’ allows the following parameters:
> 
> -u or --user name - specifies username when connecting to a database
> 
> -p or --password pass - specifies a password when connecting to a database
> 
> -n or --name database - specifies a database name to connect to
> 
> -d or --directory - path to upgrade scripts (default:
> /opt/kea-1.1.0/share/kea/scripts)
> 
>  
> 
> This is all fine if the mysql server is on localhost, which mine isn’t.
> 
>  
> 
> Shouldn’t there be a ’-h’ for hostname?
> 
>  
> 
> -- 
> 
> Med venlig hilsen / With best regards
> 
> Thomas Andersen
> 
>  
> 
> Network Architect
> 
>  
> 
> IT University of Copenhagen
> 
> Rued Langgaards Vej 7
> 
> 2300 København S
> 
>  

Thomas,

We do have a ticket http://kea.isc.org/ticket/4520 for this. However, it
is currently not planned for the upcoming release.

Marcin


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

Re: [Kea-users] Build results of kea 1.1.0-beta on OpenBSD

[Marcin Siodelski]

On 17.10.2016 20:38, Patrik Lundin wrote:
> On Tue, Oct 04, 2016 at 10:03:47PM +0200, Patrik Lundin wrote:
> >
> > Am I doing something wrong or is the code just broken currently?
> >
>
> I never got a respones to this, but thinking you are probably busy with
> other stuff I went ahead and created two tickets. The first one is for
> the syslog message format, and the second one is for the facility string
> configuration problem:
> http://kea.isc.org/ticket/5052
> http://kea.isc.org/ticket/5053
>

Patrik,

Thanks for creating the tickets. We will discuss them internally and
update them as needed.

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

Re: [Kea-users] Headers exported by Kea build.

[Marcin Siodelski]

Ilya,

Thanks for your message. In the future please post development specific
issues to the kea-...@lists.isc.org instead.

You're right. We do have any issue there and the Makefile.am needs to be
updated. I'll file a bug ticket for this.

In a mean time I suggest you simply update the file locally.

Let me know if you need some assistance.

Marcin Siodelski
ISC

On 20.10.2016 14:12, Ilya Kruglik wrote:
> Hi there,
>
>
> I'm not sure if Kea developers are following threads here, however:
>
>
> We are developing hooks/callouts and I've recently figured out that Kea
> does not provide all the required headers.
>
>
> Have a look at the src/lib/dhcp/Makefile.am:
>
>
> # Specify the headers for copying into the installation directory tree.
> *User-*
> # *written libraries may need access to all libdhcp++ headers*.
> libkea_dhcp___includedir = $(pkgincludedir)/dhcp
> libkea_dhcp___include_HEADERS = \
> ...
>
> The comment above declares a quite obvious thing that user-written
> libraries may need access to all headers. But only 27 headers out of
> ~43 are listed to be installed. For instance, option6_iaaddr.h gets
> installed while option6_iaprefix.h does not.
> According to my understanding it's a bug and Makefile.am shall be
> updated accordingly.
> Is anybody from design here to comment?
>
> Thanks,
>
>  Ilya.
>
>
>
> ___
> 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] Change in offer packet

[Marcin Siodelski]

Thomas,

This is not configurable, although it could be because RFC2131 says that
server SHOULD send to broadcast address (rather than MUST).

The only thing I can suggest to you is to use a hook library that clears
the broadcast flag in all incoming messages (in the packet4_receive hook
point).

The bad side of things is that you need to create a hook library. The
good thing is that it is trivial.

Marcin

On 20.10.2016 09:31, Thomas Andersen wrote:
> Hi,
> 
>  
> 
> I’m sorry to resend this question, but it is such a big issue that an
> upgrade of KEA is currently not possible.
> 
> I’ve been loking in change log, and I cannot find any note on this
> change, which I would consider a rather large change.
> 
>  
> 
> Can someone elaborate on this and tell me if this is intended behavior
> or if it may be a bug?
> 
>  
> 
> Or even better, if it is possible to configure my way out of it.
> 
>  
> 
> Br,
> 
> Thomas
> 
>  
> 
> *From: *Kea-users  on behalf of Thomas
> Andersen 
> *Date: *Monday, 17 October 2016 at 13.56
> *To: *"kea-users@lists.isc.org" 
> *Subject: *[Kea-users] Change in offer packet
> 
>  
> 
> Hi,
> 
>  
> 
> One of the reasons why I started using kea, is because it replies with
> unicast, despite the client makes a discover with bootp flag broadcast.
> 
> We filter all broadcast packets to wireless clients.
> 
>  
> 
> As far as i can see, this has changed in 1.1.0. Now it replies (OFFER)
> with broadcast instead of unicast.
> 
>  
> 
> Is there a way I can change that with a setting?
> 
>  
> 
> -- 
> 
> Med venlig hilsen / With best regards
> 
> Thomas Andersen
> 
>  
> 
> Network Architect
> 
>  
> 
> IT University of Copenhagen
> 
> Rued Langgaards Vej 7
> 
> 2300 København S
> 
>  
> 
> Phone: +45 72185249
> 
>  
> 

> 
> 
>  
> 
> **NEVER DISCLOSE YOUR PASSWORD OR SHOE SIZE - NOT EVEN TO YOUR DENTIST**
> 
> 
> 
> ___
> 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 results of kea 1.1.0-beta on OpenBSD

[Marcin Siodelski]

On 04.10.2016 00:32, Patrik Lundin wrote:
> On Sun, Sep 25, 2016 at 12:53:44PM +0200, Patrik Lundin wrote:
> > Hello,
> >
> > I have looked at building kea 1.1.0-beta on OpenBSD and here are my
> > results.
> >
>
> [...]
>
> > I did notice that "make test" currently fails when testing LFC.
> > This seems to be a bug in the test code rather than the code being
> > tested. I have created a PR for that:
> > https://github.com/isc-projects/kea/pull/31
> >
>
> Currently waiting on feedback on the above PR.
>
> Another question has surfaced as well: when using "syslog" logging, the
> log messages look a bit strange to me:
> ===
> Oct  3 23:12:21 obsd-amd64-t02 LOCAL0: INFO  [kea-dhcp6.dhcp6]
> DHCP6_STARTED Kea DHCPv6 server version 1.1.0 started
> ===
>
> Note how the "facility" name is used as the message tag ("LOCAL0: ").
> Is this the desired behaviour? I would have expected the "LOCAL0" to be
> replaced with the name of the program that created the message.
>
> I don't have previous experience with the log4cplus framework, but
> looking at the code i see this in createSyslogAppender():
> ===
> log4cplus::SharedAppenderPtr syslogapp(
> new log4cplus::SysLogAppender(opt.facility));
> ===
>
> Comparing this to the documentation over at
> http://log4cplus.sourceforge.net/docs/html/classlog4cplus_1_1SysLogAppender.html
> I get the impression that the first argument is "ident", not the
> facility string.
>
> Am I missing something?
>

Hi Patrik,

Many thanks for testing Kea on OpenBSD. I'll have a look at the PR which
corrects the test behavior.

As for the syslog output, you're correct that the app name is generally
used instead of the facility string. Note however that the logging
messages themselves contain the application name, e.g. "kea-dhcp6.dhcp6"
is a name of the logger which belongs to the "kea-dhcp6" application.

Nevertheless, I don't personally see an issue with changing the LOCAL0
to app name. Can you file a Trac ticket for this?

https://kea.isc.org/

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

Re: [Kea-users] option 82 based class for lease limits

[Marcin Siodelski]

On 25.09.2016 02:38, John Ratliff wrote:
> Can you limit the number of addresses a client is assigned based on option
> 82 (DHCP Relay Agent Information) circuit or remote ID?
>
> I work for a small ISP that is considering using kea in place of isc-dhcp.
> However, we need to limit our customers to a single lease per household.
> Right now, we have a custom class in isc-dhcp which can do this.
>
> class "Internet" {
> spawn with pick-first-value (option agent.circuit-id, option
> agent.remote-id, circuit-id, remote-id);
> if (exists agent.remote-id) { set remote-id = option
> agent.remote-id; }
> if (exists agent.circuit-id) { set circuit-id = option
> agent.circuit-id; }
> lease limit 1;
> }
>
> How could we do something similar using kea?
>

John,

We don't have a generic support for limiting leases based on values from
option 82.

It could be implemented using Kea hooks framework, which would require
writing a hook library and attach it to the lease4_select hook point.

The problematic part, though, is that we don't track circuit-ids and/or
remote-ids in the lease database. The hook library would need to
maintain its own lease storage (perhaps an STL container) associating
the remote-ids/circuit-ids with client-ids. When the client changes its
client identifier or MAC address the hook library could use this
container to search for the recorded client-id using a
circuit-id/remote-id as a key. If the client-id has changed, the lease
is not granted. Instead, it could return an existing lease or no lease,
depending on the desired effect.

More about hooks framework is available in Kea Developer's Guide:
https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/

Marcin Siodelski
ISC


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

Re: [Kea-users] Possible issue with documentation

[Marcin Siodelski]

On 13.09.2016 12:28, Rui Pedro Caldeira wrote:
> Hello all it seems to be a problem with Kea 1.0 regarding hooks.
> 
> I was trying to hook myself to the *lease4_select* function and get the
> *query4 *param as stated in the documentation
> (http://git.kea.isc.org/~tester/kea/doxygen/de/df3/dhcpv4Hooks.html#dhcpv4HooksLeaseSelect)
> 
> 
> I always get an error stating that the param does not exist. However, if
> i hook to the *pkt4_send* function it works alright. Is it just me or it
> is a real issue?
> 
> Best Regards,
>  
> 
>   * name:*query4*, type: isc::dhcp::Pkt4Ptr
> 
> <http://git.kea.isc.org/%7Etester/kea/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#a3f332dc70d05fbe8e0fb453434c22d93>,
> direction: *in*
>   * name: *subnet4*, type: isc::dhcp::Subnet4Ptr
> 
> <http://git.kea.isc.org/%7Etester/kea/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#a17ccc4cfb9f7534dfcedc83ebe0e5d5a>,
> direction: *in*
>   * name: *fake_allocation*, type: bool, direction: *in*
>   * name: *lease4*, type: isc::dhcp::Lease4Ptr
> 
> <http://git.kea.isc.org/%7Etester/kea/doxygen/d5/d8c/namespaceisc_1_1dhcp.html#aec4424838e2e5bb397345cdc32c0ef28>,
> direction: *in/out*
> 
> -- 
>   

Hello,

Did you manage to resolve this problem?

I am willing to help you sort it out, but it would be useful to have the
snippet of the hook library to reproduce it.

The documentation is correct. The "query4" parameter is passed by the
server to a hook.

Marcin Siodelski
ISC



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

Re: [Kea-users] mysql_config program path for kea

[Marcin Siodelski]

You can try to run --with-dhcp-mysql parameter without specifying a
location of the mysql_config program if mysql_config is in one of the
default locations, e.g. ./configure --with-dhcp-mysql . If it isn't
in any default location you should specify a path to mysql_config
program. Don't specify location of mysql or my.cnf!

On my Centos 7 I successfully used 'whereis' to locate it:

$ whereis mysql_config
mysql_config: /usr/bin/mysql_config

Marcin Siodelski
ISC

On 30.09.2016 18:32, luke devon wrote:
> Hi 
> 
> Can somebody help me on identify the correct mysql_config path  ?
> 
> configure: error: --with-dhcp-mysql should point to a mysql_config program
> 
> My OS is : CentOS7
> Installed mysql using yum 
> 
> --with-dhcp-mysql=//usr/bin/mysql --> doesnt work 
> 
> --with-dhcp-mysql=/etc/my.cnf --> doesnt work 
> 
> 
> regards
> Luke
> 
> 
> ___
> 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-dev broken ?

[Marcin Siodelski]

Nicolas,

As far as I can tell, the Kea-dev list is NOT broken. We have been busy
preparing for the upcoming Kea 1.1.0 release (happening today) and we
didn't have much time to go over the posts.

We apologize for not being responsive these days. We'll try to catch up
once the release is out the door.

Marcin Siodelski
ISC


On 30.09.2016 17:51, Chaigneau, Nicolas wrote:
> Hello,
>
>  
>
>  
>
> Is mailing list kea-dev broken ?
>
>  
>
> I didn’t receive anything since the last mail I sent on September 15th.
>
>  
>
>  
>
> I’ve checked the list archive for September :
>
>  
>
> https://lists.isc.org/pipermail/kea-dev/
>
>  
>
> There’s nothing more recent than September 15th…
>
>  
>
>  
>
>  
>
> Regards,
>
> Nicolas.
>
>  
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient,
> you are not authorized to read, print, retain, copy, disseminate,
> distribute, or use this message or any part thereof. If you receive this
> message in error, please notify the sender immediately and delete all
> copies of this message.
>
>
> ___
> 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] Lease database filename is being ignored.

[Marcin Siodelski]

Try "name" instead of the "file".

Marcin Siodelski
ISC


Dnia 9 września 2016 22:01:54 Adam Twardowski <atwardow...@choopa.com> 
napisał(a):



I'm trying to run kea with memfile lease database with persist: true,
but when kea starts up it tries to open the file it was compiled with
instead othe the file specified in the config.  This is on the latest
git branch, 93ab4a4.  This is also on freebsd 10.3.

"lease-database": {
 "type":"memfile",
 "lfc-interval":1800,
 "file": "/var/db/kea/kea-leases4.csv",
 "persist": true
},

016-09-09 15:51:15.145 INFO  [kea-dhcp4.dhcpsrv/84630]
DHCPSRV_MEMFILE_DB opening memory file lease database:
file=/var/db/kea/kea-leases4.csv lfc-interval=1800 persist=true
type=memfile universe=4
2016-09-09 15:51:15.145 INFO  [kea-dhcp4.dhcpsrv/84630]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/usr/local/var/kea/kea-leases4.csv
2016-09-09 15:51:15.145 ERROR [kea-dhcp4.dhcp4/84630]
DHCP4_CONFIG_LOAD_FAIL configuration error using file:
/usr/local/etc/kea/kea.conf, reason: Unable to open database: unable to
open '/usr/local/var/kea/kea-leases4.csv'
2016-09-09 15:51:15.145 ERROR [kea-dhcp4.dhcp4/84630] DHCP4_INIT_FAIL
failed to initialize Kea server: configuration error using file
'/usr/local/etc/kea/kea.conf': Unable to open database: unable to open
'/usr/local/var/kea/kea-leases4.csv'

___
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] Host reservation "hostname"

[Marcin Siodelski]

On 03.09.2016 12:03, Patrik Lundin wrote:
> Hello,
> 
> I have a question regarding the Host reservation "hostname" setting in
> kea.conf.
> 
> I have a host reservation looking like this:
> ===
> {
>   "hw-address": "xx:xx:xx:xx:xx:xx",
>   "ip-address": "192.168.1.14",
>   "hostname": "name"
> },
> ===
> 
> The manual for 1.0.0
> (https://ftp.isc.org/isc/kea/1.0.0/doc/kea-guide.html#reservation4-hostname)
> states that "the server will assign this hostname to the client and send
> it back in the Client FQDN or Hostname option, depending on which of
> them the client has sent to the server."
> 
> There is however no hostname option being set in the DHCPACK, even if the
> DHCPREQUEST contains the Host Name (option 12). Am I misunderstadning the
> manual? I do realize it is not possible to configure actual dhcp option values
> for reservations in kea 1.0.0, but the manual seems to suggest the "hostname"
> setting will create these options (if always or _only_ when the client request
> contains any of the options mentioned I cant tell).
> 
> Am i missing something?
> 

Patrik,

Kea 1.0.0 supports hostname reservations for both DHCPv4 and DHCPv6.
However, the general rule is that the servers won't send back hostname
or client fqdn option back to the client if DNS updates are disabled.

See http://kea.isc.org/docs/kea-guide.html#dhcp4-ddns-config for details.

This rule also applies to statically assigned/reserved hostnames. We may
need to improve the doc to make it more clear. The question is, though,
whether you have some use case when the hostnames need to be returned to
the clients when DNS updates are off?

Marcin Siodelski
ISC

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

Re: [Kea-users] "filename" vs "option bootfile-name"

[Marcin Siodelski]

On 03.09.2016 12:18, Patrik Lundin wrote:
> On Sun, Jul 10, 2016 at 08:26:16PM +0200, Patrik Lundin wrote:
> >
> > Anyway, like I said I will accept the fact that kea considers "file"
> > deprecated in favor of the boot-file-name option. It just means the
> > autoinstall feature of OpenBSD needs to know about it as well.
> >
>
> To follow up on this, the development branch of OpenBSD now has an
> installer that is capable of picking up the filename from options
> rather than the "file" field:
> http://marc.info/?l=openbsd-cvs=147144203513174=2
>
> However, upon reading the kea 1.1.0-beta release notes
> (https://kb.isc.org/article/AA-01417) yesterday I noticed something:
> ===
> - Significantly extends the existing host reservation capabilities to
>include reservations of specific DHCP options, reservations of siaddr,
>sname, and file fields within DHCPv4 messages, and reservations of
>multiple IPv6 addresses/prefixes.
> ===
>
> Does this mean you changed your minds and it is now possible to configure
> "file" without having to write a custom hook lib for it? How come? Is
> it also
> possible to configure "file" on a global level or only for a specific
> host reservation?
>

We consulted that matter with various Kea users and it turned out that
there is still a large base of them which have a strong desire to use
those fields. Therefore, we decided to add generic support for it.

Currently, the siaddr, sname and file can be all defined for a host or
for a class. The siaddr can also be specified on a subnet level. We may
also need to add support for sname and file being specified on a subnet
level. Not sure if global entries for those values are that useful. though.

Marcin Siodelski
ISC



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

Re: [Kea-users] Invalid DHCP Server Identifier: 0.0.0.0

[Marcin Siodelski]

On 30.08.2016 17:42, Adam Twardowski wrote:
> I am running kea on FreeBSD.  I have a cisco router configured as a dhcp
> relay, forwarding requests to Kea.  Kea receives the requests and sends
> out a reply, but the reply has option 54 set to 0.0.0.0, which as far as
> I know doesn't make any sense.  The DHCP client can't continue the
> transaction because it obviously can't send a packet to 0.0.0.0.  Is
> there any way I can tell kea to send a valid server identifier?
> 
> 
> Config:
> 
> {
> "Dhcp4":
> {
>   "interfaces-config": {
> "interfaces": [ "em0" ],
> "dhcp-socket-type": "udp"
>   },
>   "lease-database": {
> "type": "memfile",
> "lfc-interval": 1800
>   },
>   "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
>   },
> 
>   "valid-lifetime": 4000,
> 
>   "subnet4": [
>   {"subnet": "10.128.224.0/20",
>"pools": [ { "pool": "10.128.239.3 - 10.128.239.254" } ],
>"option-data": [
> { "name": "routers", "data": "10.128.224.1" },
> { "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" },
> ]
>   }
>   ]
> },
> 
> 
> 
> Kea Reply:
> 
> Bootstrap Protocol (Offer)
> Message type: Boot Reply (2)
> Hardware type: Ethernet (0x01)
> Hardware address length: 6
> Hops: 1
> Transaction ID: 0xccc2
> Seconds elapsed: 0
> Bootp flags: 0x (Unicast)
> 0...    = Broadcast flag: Unicast
> .000    = Reserved flags: 0x
> Client IP address: 0.0.0.0
> Your (client) IP address: 10.128.239.4
> Next server IP address: 0.0.0.0
> Relay agent IP address: 10.128.224.1
> Client MAC address: -- DELETED ---
> Client hardware address padding: 
> Server host name not given
> Boot file name not given
> Magic cookie: DHCP
> Option: (1) Subnet Mask
> Length: 4
> Subnet Mask: 255.255.240.0
> Option: (3) Router
> Length: 4
> Router: 10.128.224.1
> Option: (6) Domain Name Server
> Length: 8
> Domain Name Server: 8.8.8.8
> Domain Name Server: 8.8.4.4
> Option: (51) IP Address Lease Time
> Length: 4
> IP Address Lease Time: (4000s) 1 hour, 6 minutes, 40 seconds
> Option: (53) DHCP Message Type (Offer)
> Length: 1
> DHCP: Offer (2)
> Option: (54) DHCP Server Identifier
> Length: 4
> DHCP Server Identifier: 0.0.0.0
> Option: (255) End
> Option End: 255
> 

Adam,

Would it be possible for you to send us the dump of the DHCPDISCOVER
which triggers this response, along with the entire Ethernet/IP/UDP stack?

Thanks,
Marcin Siodelski
ISC

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

Re: [Kea-users] Reservations not being assigned

[Marcin Siodelski]

 08:00:27:2c:73:00],
> cid=[70:6f:75:64:72:69:65:72:65], tid=0xae5b3aa3: failed to allocate an
> IPv4 address after 0 attempt(s)
> 
> Any suggestions on how to approach troubleshooting this?
> 
> % kea-dhcp4 -V
> 1.0.0
> tarball
> linked with:
> log4plus 1.1.2
> OpenSSL 0.9.8zh-freebsd 3 Dec 2015
> database:
> PostgreSQL backend 2.0, library 90313
> Memfile backend 2.0
> 
> 
> 

Hi Matthew,

When dealing with non-relayed (direct traffic), the only parameters that
the server can use to select the subnet are: client's source address,
ciaddr, IP address assigned to the interface on which the server
received the packet. In case this is a new allocation, none of the first
two is available for the server. Thus, the server will use the local IP
address assigned to the interface on which it has received the packet to
select the subnet. If that address happens to be the one that matches
subnet with ID 2, it will pick this subnet. Since, there are no pools,
it will fail to allocate any address. Also, because static reservations
are made for another (non-selected) subnet, it will not use those
reservations.

Do you serve both subnets on the same physical interface?

Marcin Siodelski
ISC

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