Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Can DHCPv6 option content be changed at runtime, e.g.
triggered by vendor class ? ([email protected])
2. Re: Leasing from multiple IPv4 subnets to the same relay
(Guido Marelli)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 Nov 2015 14:31:59 +0100
From: <[email protected]>
To: <[email protected]>
Subject: [kea-dev] Can DHCPv6 option content be changed at runtime,
e.g. triggered by vendor class ?
Message-ID:
<62aa760926a38745aaf06ad7319065fd605a48c...@he113456.emea1.cds.t-internal.com>
Content-Type: text/plain; charset="us-ascii"
Hi Marcin et al,
I have been digging into what I could do in KEA based on variation of content
in DHCPv6 Vendor Class option (16) as described in section 22.16 of RFC3315.
While DHCPv6 option (16) is obviously implemented [1],[2], I fail to understand
the scope and extent by which triggering events and/or actions based on content
based on this option is supported (or planned or already discussed and
discarded to be supported).
EXAMPLE:
Set service related option = "A"
# IF vendor class is 1
service related option = "B"
# ELSE
do nothing
# FI
Quick questions:
- How to do that?
- How well can "hooks" support configuration of runtime per-request changes in
KEA ?
Thanks and Best regards,
Normen Kowalewski
[1]
https://ftp.isc.org/isc/kea/0.9-beta1/doc/kea-guide.html#dhcp6-client-classifier
[2]
http://git.kea.isc.org/~tester/kea/doxygen/d6/d00/classisc_1_1dhcp_1_1OptionVendorClass.html
------------------------------
Message: 2
Date: Fri, 13 Nov 2015 11:58:49 -0300
From: Guido Marelli <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Leasing from multiple IPv4 subnets to the same
relay
Message-ID:
<CA+rsa=p24prkcluyrgnw6wct-kys4tvmuuhm3qqf+0puxuh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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: [email protected]
Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company
On Thu, Nov 12, 2015 at 6:25 AM, Marcin Siodelski <[email protected]> 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: [email protected] <mailto:[email protected]>
> >
> >
> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20151113/93283b0f/attachment-0001.html>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 6
**************************************
