[kea-dev] Leasing from multiple IPv4 subnets to the same relay
Marcin Siodelski
marcin at isc.org
Wed Nov 18 14:55:54 UTC 2015
Guido,
Kea treats "subnet" as a client's point of attachment and hence it
assumed that the particular client (on the particular link) belongs to
one subnet.
Together with fully fledged "client classification" (planned for Kea 1.1
release) Kea will get some more flexibility. In particular, it will be
possible to use expressions defining additional conditions for subnet
selection. In other words, it will be possible to select different
subnet, depending on what options the client has sent. This is to better
facilitate the case that I described in my first email to you, and also
other use cases like PXE boot etc.
Whether "client classification" will be suitable for the multi-network
scenario you're describing, it is up for consideration. I'd like to
understand this use case a bit more.
Suppose there is a single DHCPv4 server, single CMTS (relay) and a
single CPE. It probably doesn't matter from the server perspective
whether we're talking about the CM or router part of CPE trying to
obtain its DHCP configuration. The CPE initiates a DHCP exchange via
CMTS. The server receives message from the CPE. The server has three
networks (subnets and pools) configured, from which it could assign an
address and options to this CPE. The question is, how does the server
determine which subnet it should use to make this assignment? Relay
agent address doesn't appear to be sufficient because all networks are
associated with the same CMTS. I guess the server would need to look
into some specific options or fixed fields of the DHCPv4 message to make
this determination? Which fields and options?
I also wonder why multiple networks are needed for a single CPE? You say
that these networks are "the same". I am not sure I understand what it
means. They should at least have different (non-overlapping) address
pools? If this is the case, couldn't you just define a single subnet and
multiple address pools within the same subnet? Of course, that wouldn't
be feasible if they use a different address prefix. But, that I don't
know from your description.
Also, if the client has obtained an address from a given network/subnet,
is it possible for this client to move onto another network/subnet under
some conditions?
Another question about the matter of many networks. Would configuration
of these subnets include the same option sets? In other words, if the
client A obtains configuration from subnet/network X and the client B
obtains configuration from subnet/network Y, would they get the same
options, e.g. the same dns servers list etc?
I believe that client classification will support many, if not all, use
cases. However, there is always a possibility to write a custom hook
library which will customize server's behavior with respect to many
things, including subnet selection. If you decide to go down that path,
we can serve with advice.
Marcin
On 13.11.2015 15:58, Guido Marelli wrote:
> Hi Marcin, thank you for clarifying.
>
> On the other hand, a scenario that I have observed in many deployments
> with DHCPv4, is the existence of multiple networks configured in the
> same relay/CMTS that are eligible for leasing to the same type of
> device. This is: there is no difference between networks A, B and C but
> any of these networks can be use to assign addresses, for example, to
> CPEs.
>
> From your comments, I understand that this is now not possible with Kea:
> Do you plan to include this type of functionality?
>
>
> 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
>
>
> On Thu, Nov 12, 2015 at 6:25 AM, Marcin Siodelski <marcin at isc.org
> <mailto:marcin at isc.org>> wrote:
>
>
> 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>
> <mailto: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 <http://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
>
>
>
More information about the kea-dev
mailing list