[kea-dev] Leasing from multiple IPv4 subnets to the same relay
Guido Marelli
guido.marelli at intraway.com
Fri Nov 20 18:56:31 UTC 2015
Hi Marcin, thank you for your response. I'll try to respond to your
questions.
> How does the server determine which subnet it should use to make this
assignment?
The DHCP server selects a subnet according to lease availability (free
leases).
> Couldn't you just define a single subnet and multiple address pools
within the same subnet?
In this configuration scenario, subnets have different prefixes so I
understand that it's not useful to have a subnet with different pools. I
guess that the whole thing has to do with exhaustion of the IPv4 address
space and optimization of address usage. Cable operators most of the times
have: 1 subnet for CM (private addresses), 1 subnet for MTA (private
addresses) and several subnets for CPE (public addresses). And it's common
for cable operators to move subnets between CMTSs to optimize usage; or
adding new subnets to be able to provision new customers on a CMTS.
> 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?
Yes. Obviously that will happen if the CPE moves to another CMTS (e.g. a
cellphone, or notebook). But also, if the lease expires the CPE could
obtain a lease from another subnet.
> Would configuration of these subnets include the same option sets?
As far as I know, the only option that changes is the routers option.
Regards,
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
Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company
On Wed, Nov 18, 2015 at 11:55 AM, Marcin Siodelski <marcin at isc.org> wrote:
> 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
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20151120/76a748f0/attachment-0001.html>
More information about the kea-dev
mailing list