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. Re: Options and Relay Agent information (Marcin Siodelski)
2. Re: Options and Relay Agent information (Vadim Fedorenko)
3. Re: Leasing from multiple IPv4 subnets to the same relay
(Marcin Siodelski)
4. Re: Options and Relay Agent information (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Nov 2015 09:37:25 +0100
From: Marcin Siodelski <[email protected]>
To: ????????? ????? <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Options and Relay Agent information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 10.11.2015 23:27, Vadim Fedorenko wrote:
> Found strange behavior of Cisco switches acting as DHCP Relay Agents.
> All options, that are placed after Option 82, are stripped from
> DHCPACK packet. So, because OptionCollection is std::multimap, an
> ordered by the option type container, all options with codes higher
> than 82 (like tftp server and so on) are stripped and the client
> cannot receive them.
>
> Is it possible to change OptionCollection to std::unordered_multimap
> and make Option 82 to be the last option in the packet?
>
Hi Vadim,
Is this the behavior you have observed on Cisco switches for Kea server,
or you observe the same behavior for other DHCP server implementations too?
Marcin
------------------------------
Message: 2
Date: Thu, 12 Nov 2015 12:06:03 +0300
From: Vadim Fedorenko <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Options and Relay Agent information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Thursday, November 12, 2015, 11:37:25 AM, you wrote:
> On 10.11.2015 23:27, Vadim Fedorenko wrote:
>> Found strange behavior of Cisco switches acting as DHCP Relay Agents.
>> All options, that are placed after Option 82, are stripped from
>> DHCPACK packet. So, because OptionCollection is std::multimap, an
>> ordered by the option type container, all options with codes higher
>> than 82 (like tftp server and so on) are stripped and the client
>> cannot receive them.
>> Is it possible to change OptionCollection to std::unordered_multimap
>> and make Option 82 to be the last option in the packet?
> Hi Vadim,
> Is this the behavior you have observed on Cisco switches for Kea server,
> or you observe the same behavior for other DHCP server implementations too?
> Marcin
Hi Marcin,
I could not produce such things on other DHCP servers (ISC-DHCP and Cisco's
built-in DHCP), because in another servers' replies Option 82 is always the
last option in the DHCPACK packet and options are not sorted by type (code).
So, that behavior seems to be for Kea server only. And, also I found that
behavior on other vendor's switches (tested on DLink DGS-3612 and DGS-3627 and
QTech QSW-8300).
--
Best regards,
Vadim
------------------------------
Message: 3
Date: Thu, 12 Nov 2015 10:25:50 +0100
From: Marcin Siodelski <[email protected]>
To: Guido Marelli <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Leasing from multiple IPv4 subnets to the same
relay
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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
------------------------------
Message: 4
Date: Thu, 12 Nov 2015 10:37:20 +0100
From: Marcin Siodelski <[email protected]>
To: Vadim Fedorenko <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Options and Relay Agent information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 12.11.2015 10:06, Vadim Fedorenko wrote:
> Thursday, November 12, 2015, 11:37:25 AM, you wrote:
>
> > On 10.11.2015 23:27, Vadim Fedorenko wrote:
> >> Found strange behavior of Cisco switches acting as DHCP Relay Agents.
> >> All options, that are placed after Option 82, are stripped from
> >> DHCPACK packet. So, because OptionCollection is std::multimap, an
> >> ordered by the option type container, all options with codes higher
> >> than 82 (like tftp server and so on) are stripped and the client
> >> cannot receive them.
>
> >> Is it possible to change OptionCollection to std::unordered_multimap
> >> and make Option 82 to be the last option in the packet?
>
>
> > Hi Vadim,
>
> > Is this the behavior you have observed on Cisco switches for Kea server,
> > or you observe the same behavior for other DHCP server
> implementations too?
>
> > Marcin
>
> Hi Marcin,
>
>
> I could not produce such things on other DHCP servers (ISC-DHCP and
> Cisco's built-in DHCP), because in another servers' replies Option 82
> is always the last option in the DHCPACK packet and options are not
> sorted by type (code). So, that behavior seems to be for Kea server
> only. And, also I found that behavior on other vendor's switches
> (tested on DLink DGS-3612 and DGS-3627 and QTech QSW-8300).
>
>
I see. So, maybe these servers do it to overcome this strange behavior
of the Cisco switches. One never knows until it is properly documented.
Anyhow, can you please submit a Kea ticket (kea.isc.org) and describe
this issue in the ticket? We will try to figure out some clean way of
dealing with this problem. Unfortunately, using the std::unordered_map
is not viable because it is C++11 specific feature and Kea doesn't use
C++11 to keep compatibility with older systems.
I guess one could think about writing a hook that moves the option 82 to
the end of the rendered packet and not pollute the main code with hacks
for non-conforming devices. However, if it turns out to be an issue with
some wider spread, putting it into the main code can actually be a
better idea.
We will also check in the isc-dhcp code if there is a historic sign of
this issue there.
BTW, it would be useful to have a traffic capture with a Kea response
that gets truncated by the relay. Can you provide such traffic capture
(may be privately sent to me rather to the list if you wish).
Marcin
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 4
**************************************
