[kea-dev] Options and Relay Agent information

[Marcin Siodelski]

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