[kea-dev] Thoughts on reading the ARM documents

Marcin Siodelski marcin at isc.org
Fri Oct 24 11:09:24 UTC 2014


Thanks for sharing this. Please find my responses below. I am sure,
others will also be able to clarify more on specific topics.


On 10/24/14 05:14, Shawn Routhier wrote:
> While reading through the ARM document I
> cleaned up some minor typos (trac ticket 3620)
> and had some questions and comments.
> For those of you on this list that don't know me I'm the lead
> engineer on the current ISC DHCP code.  When I talk about
> what the current code does this should not be viewed as
> a requirement or even a strong suggestion that Kea should
> follow along.  I'm trying to describe what the current code
> does and what users may be using - we may decide that Kea
> should do the same thing, or have a similar feature but done
> in a different way or that it isn't necessary for Kea for some reason.
> There were three sections in the original document but I've
> removed one section - that one was for changes I had made to
> the ARM document that seemed like issues but for which I wasn't
> completely sure.  They are on the trac ticket.
> For the other two the first is for the general thoughts I had while 
> reading the docs.  This covers things that the current code does 
> that Kea may want to do, areas where Kea may distinguish itself from
> the current code, ideas for futures etc.
> The second is for more changes to the docs and some questions about 
> the code that may require changes to the docs.  In some cases this is 
> simply a step farther than 2 - there seems to be something a bit iffy and 
> I think I understand it, but I'm not sure enough to make changes.
> In other cases we may want to add more text to either be more clear or to be different than
> ISC DHCP.  And there are some that may be feature requests in disguise.
> I imagine that after some discussion a number of these may turn into tickets
> for future work.  The priority will need to be evaluated over time.
> I currently plan to do some more work on the ARM document and so as I understand
> things better or get somebody to explain some of the items in the second section
> to me I can open another ticket and do more work on the document.
> I haven't tried to polish the text of these so some of the descriptions
> may need some re-working but they should be sufficient to start the discussion.
> ************
> General thoughts about the documentation and the code
> 1) Many users use something like nagios to watch over their dhcp servers
> it would be useful to either work well with those tools or provide our own
> that does similar nannying.
> 2) Can there be more than one configuration file for the keactrl?  It appears as if there
> can be only one for both v4 and v6 - if I want two files (say two diffeernt groups run the
> v4 and v6 stuff) can I do so?

To clarify this, there are two configuration files: keactrl.conf and
kea.conf. The former controls the behavior of the keactrl script. It in
fact also specifies whether kea.conf is called kea.conf or has a
different name. The latter is a configuration file for the servers:
DHCPv4, DHCPv6 and DHCP-DDNS and can be used to run any of them without

There is a command line switch for keactrl that allows for specifying an
alternate configuration file for keactrl. However, if you want to use
two different files simultaneously you need to be careful because some
keactrl commands (e.g. keactrl stop) will by default shut-off all the
running servers (at this point they don't use any pid files). So if you
run v4 with one call to keactrl, and v6 with another call to keactrl.
Then, you run keactrl stop with any of these configuration files, it
will stop both v4 and v6 servers, unless you specify with a command line
which one you want to shut-off.

So, I think you can do what you want but you need to be careful with the
command line options you use.

There is also a point about the DHCP-DDNS module which will not start if
there is another instance already running. So, you can't run DHCPv4 with
DDNS and DHCPv6 with DDNS using two keactrl configuration files.

> 3) I have some concerns about the reload option.  In general what people have been asking
> for in ISC DHCP is the ability to change a running system (via OMAPI mostly).  I think those
> that have asked for a reload capability want to change the config but not go through the full
> startup sequence.  If Kea is quicker to start (quite likely as it doesn't have the same
> issues in building the database) this may not be an issue.  But the example is that an
> admin wants to add a new pool to a server without having to stop and restart the server.

The "reload" command will not restart the process but will rather send a
SIGHUP to the process and the process will reload configuration from the
file. However, it is true that the server will reload (including
parsing) whole the configuration from the scratch which may be an
expensive operation. I think that one of the options (for the future) is
to load the configuration in background while still serving clients with
an old configuration. But, this is not how it works now and it would
require some multi-threaded features.

Please note that keactrl was meant to be a *simple* tool for managing
the startup and reconfiguration of the servers. And, it was a quick
replacement for the bindctl tool from BIND10. We know that we need some
more sophisticated management tools and actually a simple management
tool is in scope for 0.9.1 (IIRC), but for now keactrl should be good
enough as a first step.

> In the current code we have the options to test the lease and config files, is the
> reload command part of the replacment for that feature?  If not will we get such a feature
> in the future?

keactrl will try to use the configuration file when reload is issued,
and if it fails the server will continue to use an old configuration.
Also, we are working on some refactoring of the code in this area to
avoid using dead or partial configurations. There is no standalone tool
to verify that the semantics of the config or lease file is correct.

> 4) Is there a background option for starting a server directly?

No, if you want to run in background you'd use keactrl.

> 5) Note for failover support - the state of the lease will need to be stored in the
> lease database. (Free, backup and active at least, possibly others for transition states).

There are more features, e.g. MAC address extraction for v6, where we
need to add new fields to the lease database. Extending the lease
database with new fields is not a big deal, but we will need tools to
upgrade existing instalations (e.g. upgrade database and preserve the
data). There are some tickets for this in 0.9.1.

> 6) 6.2.3 Inteface selection - can the wildcard be used as part of a string such as
> "eth*" or "eth1.*"?  can the interface code deal with "funny" intefaces (vlans, bonded,
> fractionals etc).  Doing a better job than the current code would be a selling point
> so if it does so making that clear is probably worthwhile.

No, it doesn't deal with wildcard names like "eth*". But, not that it
couldn't. It is just a matter of, how important would it be?

We already have some requests to improve the handling of multiple IPv4
addresses on the same interfaces. We will start there. But, I think
there will be more cases to cover, as we haven't really tested all the
"funny interfaces".

> 7) Table 6.3 - is there an option for a FQDN that will be looked up via DNS and then
> the ip address sent out in the option?

I don't understand this question.

> 8) 6.2.8 - for the vendor encapsulated space, can we pick and choose which one to send based
> on something in the request?

I don't have we have any means to define "something" in the
configuration file. We are planning to implement client classification
and for specific client classes you'd be able to define specific options.

So, are you asking if you can pick sub-options based on "something" in
the configuration file? What that would be?

> 9) 6.3 - note that we don't implement server id checks in the ISC DHCP server by default.
> I don't know if this is an issue for many clients.
> 9) 7.1 (and maybe for v4 as well) do we plan to allow a default config file at some time?
> We do so now for ISC DHCP, I'm not sure if people like that.  I think the distros kind of like
> having very little on the command line.  But maybe they will mostly use the keactrl?

Yes, there are default configuration files installed with kea: kea.conf
and keactrl.conf as I mentioned above.

> 10) In ISC DHCP we currently do different things for hosts vs pools.  In v4 we don't check
> to see if an address is in both and can hand it out twice if the configuration is incorrect.
> In v6 we claim to check and won't hand out addresses from a pool that are also static.
> (Just an FYI for when static entries are handled)

Please read this: http://kea.isc.org/wiki/HostReservationDesign. There
is a discussion in the "In-pool vs Out-of-pool Reservations" section
about it.

> 11) 7.2.7 in the current code we can have issues with prefix lengths.  If we can allocate
> a /56 but somebody asks for a /60 we won't give them anything.
> 12) I'm looking at the option-defs - can we format something that is a value followed
> by an array of items?  

No. But, if you really want to do it, you can create a record with
multiple fields of the same type. But, we should actually consider some
generic support for this.

> 13) Are we using the same "vendor-encapsulated-options-space" for both v4 and v6?  Or
> maybe it is "vendor-opts-space" in v6 as the text says in 7.2.10?

I think this text needs to be revised. I think we also use "vendor-1234"
for vendor id 1234 etc.

> 14) In using client classification if a client has a class but the config doesn't include
> a subnet for that class but does include an unclassified subnet will the client get an
> address from the unclassified subnet?  Or if it has a class does there have to be a matching
> subnet?

I think, I'll leave it for Tomek.

> 15) 8.2.1 - is there a default value for the dns_server_timeout?  The example shows 100
> (milliseconds) which seems a bit low but I haven't checked to see if the specs provide any guidance.
> For comparison 4.1 allows for 1 second while 4.2 & 4.3 are up to the Bind9 code but I
> believe are in the multiple second range.

There is. It is 100 ms. But it probably should have been documented.

> 16) 8.2.2 - We may wish to provide or ask the Bind9 folks to provide a mechanism to
> produce the proper tsig_key structure such that an admin can cut and paste from the
> output into the config file.
> 17) 8.2.4.x - We allow the admin to set the suffix for the reverse zone name for v4
> and have a request to do the same for v6.
> ****************
> Items that I have questions about but didn't change.
> 1) I note that the copyright years in share/kea/dhcpdb_create.* are 2013
> should these be updated to 2014?  (In Bind they update all of the copyrights
> every year in ISC DHCP we only do so when we touch a file.  If Kea wants to
> do it every year (I think it should) we should probably have a script to do so).

We update copyright year when we touch the file. But it is annoying
because we tend to forget. I am not sure what would be a right way to go.

> 2) 3.4.4 - mentions "prepare the Python scripts", we don't use python anymore do we?

IIRC, there was one tool for which we still used python? But, I forgot
the details.

> 3) 3.4.5 - when would ldconfig be required
> 4) 6.2 and 7.2 the description of the lease database in the v4 and v6 sections doesn't match the example.
> The example has multiple paramaters (type, persist and name) while the description claims
> only one paramater.  Or perhaps there is a missing example block right next to the lease
> database description?

Good catch. I think it may be because initially it was only a type and
other were left at defaults, but they were added later.

> 5) 6.2.4 it sounds as if auto-generated ids always start from 1 and increase.  They won't
> start from the id of a defined subnet?  And if they overlap what happens?  I have 5 subents
> 1-4 and number five specifies
>  "id": 2,
> Does the answer change if the first one is specified as 2?

If they happen to overlap the configuration of the server will fail.

> 6) 6.2.6 when using hex strings which formats do we allow "xx yy", "xx:yy" "xxyy".  It would
> probably be good to allow all of them if possible (eventually).

For DUIDs and MACs I think we allow all of them. For the options, we
probably would need to allow "xx:yy" as I think we don't allow this at
this point.

> 7) I see we use both option-data and option-def - it might be useful to mention that explicitly
> people glancing through the examples may miss that difference.


> 8), the text says we will alwayss do a remove and add in case 2 and remove in case 3
> are those also gated by the FQDN flag bits?  Do we attempt a removal if we haven't attempted
> an addition?

We keep an information about the attempted updates in the lease
database. So, if we get the new message from the client and something
changes (e.g. FQDN) we perform an update. Otherwise, we do not.

> 9) - The text says that N=1, S=1 packets will be dropped.  Will they be completely
> dropped (no address allocated) or will the DDNS step be dropped?

It will be completely dropped.

> 10) 6.2.12 - generated names, it appears as if the leading hyphen always required
> is that true?  or if one sets the generated prefix to "" will it be left out?

Why do you think the hyphen is always required?

> 11) 6.2.14 - is echo-client-id a global or can it be more specific?

It is global.

> 12) 6.4.1 - can there be only one relay and ip address?  or can there be multiple of either?

One at the time. But, this could be easily extended to a list.

> 13) in 7.2.6 we mention there is no danger when using gigantic address pools.  
> I assume the danger would be to allocating large amounts of memory which would
> seem to be true for pre-allocation.  But as we aren't doing clean up yet don't we
> have a potential for usng large amounts of resources over time?  should we mention
> that?

The lease information is stored in memory (for memfile backend) so if
there are many addresses allocated, the memory usage will grow. I think,
the text could mention this. Yes.

> 14) 7.2.8 the comment mentions numbers in the first column, but I don't see any?

Oops, this may have been an internal comment in the xml which should not
pop-up in the text. Good catch.

> 15) In general there seems to be some confusion over ". " or ".  " to end a sentence,
> that is should a period at the end of a sentence be followed by 1 or 2 spaces.
> I typically do the second and I think there were some uses of that before my edits
> but I also see a lot of the first.  We should probably pick one and be consistent.
> 16) - we may wish to make clear if the server-ip can be v4 or v6 for both dhcp4
> and dhcp6.  In this text we describe the loop back as a v4 address ( and the
> example as a v6 address.

The description of server-ip in does mention it could be both
v4 and v6 address.

> 17) 7.2 - we should probably allow for two options in the name creation area.  I can
> see people wanting either what is there or a fully spelled out address (no zero compression
> on v6 addresses) to make sure the names are all the same length for other processing.

I am not sure I understand this point in the context of 7.2. But, we
generally do allow for fully spelled out addresses.

> 18) D2 - we currently don't support finding the appropriate DNS server via queries.
> We may want to make this explicit and to indicate our plans in this area.  I believe
> that some customers may want this feature.
> 19) 8.2 - the v4 and v6 configuration sections start by showing the appropriate block
> within the entire config file (mostly this means and extra pair of braces outside of
> the block).  I'm wondering if D2 should do the same.

Yes. I think it should.

> 20) - What happens if i include a hostname paramenter?  What is the planned
> response in the future if an entry has both a hostname and ip_address?  (I'm curious
> about what will happen if I try and prepare for when hostname is available.)

I am not sure what Tom's plans were for this.

> 21) 9.1 - perhaps expand a bit on the use of raw sockets?  Mostly that they are necessary
> for (more or less) directly connected clients and not so much for relays that use IP?

Yes. It should maybe also be mentioned that when you don't need to
handle directly connected clients, it would be better to use IP/UDP
sockets as you don't have to deal with the issues with bypassing IP
firewalls. But, the switch to disable the use of raw sockets is not
implemented yet.


More information about the kea-dev mailing list