[kea-dev] Leasing from multiple IPv4 subnets to the same relay

[Marcin Siodelski]

On 10.11.2015 17:00, Guido Marelli wrote:
> Hi,
>
> I'm analyzing the feasibility of using Kea in DOCSIS networks. However,
> I didn't managed to configure Kea to use more than one IPv4 subnet with
> the same relay/giaddr.
>
> What I observed is that Kea depletes leases from the first subnet and
> that the other subnets, which were configured with the same relay, are
> ignored. I think this behavior is due to the method "CfgSubnets4 ::
> selectSubnet" which iterates subnets until it finds the first subnet
> that matches the giaddr, but it doesn't check lease availability.
>
> Any thoughts on this?
>
>
> Regards,
> Guido
>
>
> Guido Marelli
> Intraway Corp.
> Project Leader
> AR Office: +54 (11) 6040 4000 x4033
> US Office: +1 (516) 620 3890 X4033  
>
> Mobile: +54 (911) 5424 9574
> Email: guido.marelli at intraway.com <mailto:guido.marelli at intraway.com>
>
>
> Visit our website at http://www.intraway.com <http://www.intraway.com/>
> Proud to be an ISO 9001:2008 certified company
>
>
>

Hi Guido,

Thanks for your email and your interest in Kea.

We have implemented "limited" support for DOCSIS in 2013 and
successfully tested it with one cable network. This limited support
facilitates the case when devices connected to the same link obtain
addresses from different subnets. The devices are differentiated by the
contents of the Vendor Class Identifier. It is assumed that that a
device is a CM if the identifier is "docsis3.0". It is assumed that the
device is a router if the identifier is "eRouter1.0".

As per the Kea User's Guide:
http://kea.isc.org/docs/kea-guide.html#dhcp4-client-classifier

you can create a subnet with address pools dedicated exclusively for CMs
with a configuration similar to this:

"Dhcp4": {
    "subnet4": [
        {
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "relay": {
                "ip-address": "10.0.0.1"
            },
            "client-class": "VENDOR_CLASS_docsis3.0"
        }
    ],
    ...
}

Note that the "docsis3.0" is an identifier sent in the Vendor Class
Identifier option by CM. If your CMs send different identifier, the
class name is "VENDOR_CLASS_<your-cm-identifier>".

One final note. The "proper" implementation of DOCSIS requires full
support for client classification, i.e. the server must be able to
extract arbitrary expressions from various DHCP options and use them to
assign a client to a particular class or set of classes. Then, classes
are used to assign subnets, options etc according to the configuration.
The first part of this generic client classification will be available
with the Kea1.0 release (December 2015). The next release (Kea1.1) is
fully devoted to finish up client classification. So, if the current
"limited" support for DOCSIS is not sufficient for your deployment, you
may wish to monitor the progress on client classification for 1.0 and
1.1 releases to make sure it would address your needs.

I should also note that Kea has a built-in mechanism of "hooks" which
allows for customizing packet processing at various stages. The server
calls out to custom/user-defined C++ library to perform common tasks
like subnet selection, options assignment etc. It is possible for you to
create a simple C++ library which replaces standard subnet selection
mechanism with customized one, required in your deployment.

More about writing your own hooks can be found in Kea Developer's Guide:
http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html

Marcin Siodelski
DHCP Software Engineer
ISC