[Kea-users] Shared subnets configuration - input needed

Christian Kratzer ck at cksoft.de
Fri Sep 1 17:00:59 UTC 2017


Hi,


On Thu, 31 Aug 2017, Marcin Siodelski wrote:

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

I tend to agree that option A is the most straight forward and I recommend keeping it simple.



Greetings
Christian


-- 
Christian Kratzer                   CK Software GmbH
Email:   ck at cksoft.de               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/



More information about the Kea-users mailing list