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: RSOO bug in 0.9.1 (Templin, Fred L)
2. Re: Statistics design proposal for 0.9.2 (Shawn Routhier)
3. Re: RSOO bug in 0.9.1 (Wlodek Wencel)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Apr 2015 16:12:47 +0000
From: "Templin, Fred L" <[email protected]>
To: Wlodek Wencel <[email protected]>, "[email protected]"
<[email protected]>
Cc: Tomek Mrugalski <[email protected]>
Subject: Re: [kea-dev] RSOO bug in 0.9.1
Message-ID:
<2134f8430051b64f815c691a62d9831832e4d...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"
Hello Wlodek,
Have you had a chance to look into this yet?
Thanks - Fred
[email protected]
> -----Original Message-----
> From: Templin, Fred L
> Sent: Tuesday, April 14, 2015 12:09 PM
> To: 'Wlodek Wencel'; [email protected]
> Subject: RE: [kea-dev] RSOO bug in 0.9.1
>
> Hello Wlodek,
>
> See attached for the kea server configuration file plus a tcpdump packet
> capture
> of the Relay-forward and Relay-reply messages. The packet captures show that
> the Relay-forward includes a Vendor-Specific Information option with length
> 26, while the Relay-reply produced by the kea server only includes a VSIO with
> length 4. Let me know if you need any further information.
>
> Thanks - Fred
> [email protected]
>
> > -----Original Message-----
> > From: Wlodek Wencel [mailto:[email protected]]
> > Sent: Monday, April 13, 2015 8:08 AM
> > To: [email protected]
> > Cc: Templin, Fred L
> > Subject: Re: [kea-dev] RSOO bug in 0.9.1
> >
> > Hello,
> > Thank you for your email. I checked again RSOO feature in Kea (sending
> > Vendor-Specific Information Option with multiple sub-options, what I
> > assume you do) and unfortunately I could not reproduce error you described.
> >
> > Can you provide more details? Like kea config file and capture from
> > wireshark? Or details about Vendor-Specific Information Option you are
> > including to message?
> >
> > Regards,
> > Wlodek Wencel
> >
> > On 04/11/2015 12:44 AM, Templin, Fred L wrote:
> > > Hello,
> > >
> > > I am trying to use the new RFC6422 Relay Supplied Options Option (RSOO)
> > > facility.
> > > My RFC6221 relay inserts a Vendor-Specific Information Option (option
> > > #17) in the
> > > Relay-forward message that will be sent to the kea server. The option has
> > > length
> > > 26 decimal. But, when the kea server does the RFC6422 transformation it
> > > truncates
> > > the VSIO to only include the option header and the 4-byte enterprise
> > > number. The
> > > VSIO is then inserted into the DHCPv6 Reply message, but loses the 22
> > > bytes that
> > > follow the enterprise number.
> > >
> > > See attached for the kea log. It does not show anything about the
> > > Relay-forward
> > > or Relay-reply messages, but does show how the server inserts the VSIO
> > > with
> > > length 4. Please let me know if any further information is needed.
> > >
> > > Fred Templin
> > >
> > >
> > >
> > > _______________________________________________
> > > kea-dev mailing list
> > > [email protected]
> > > https://lists.isc.org/mailman/listinfo/kea-dev
> > >
------------------------------
Message: 2
Date: Mon, 20 Apr 2015 19:31:47 -0700
From: Shawn Routhier <[email protected]>
To: Kea Dev List <[email protected]>
Subject: Re: [kea-dev] Statistics design proposal for 0.9.2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
I continue to have some concerns about the possible performance impact
of the design. But I agree that we should go forward with the current design
and get some experience with how the code performs and how people may
want to use it before trying to optimize it.
As with Marcin I had questions about the way the subnets were being named,
clearly stating in the document that the naming won?t change if a subnet is
added or removed might be useful.
In the description of data types the text shows keeping the packet received
statistics
for the last 5 minutes. Later the text shows an example of the return with 3
instances
of the received-packets. This needs to be well documented, especially if we are
capable of processing some 5k requests / second. By default I would assume that
saying ?save 5 minutes of packets? would get me say 300 instances (1 per
second).
not potentially millions.
Should there be a way for the requestor to restrict what instances they get?
Continuing the example - I may want to be keeping the last 5 minutes of packets
received for some reason but most of the time will only want to get the current
number and if it is not what I expect then to look backwards and see when
something
happened?
One area I?m unclear on is if the requestor can ask for some related group
of statistics - for example all the stats for a single context or all of the
stats
for packet processing (packets received, packets sent, different types of packet
errors etc) - easily or if one would need to have a separate item in the request
for each of the desired stats.
In a cross between the performance issues and getting groups of statistics
I also wonder if we will eventually want to return something more like an array
or structure, something without the names and with the data all in the same
places. Again this is probably something we can defer for now, but we probably
don?t want to rule it out. (SNMP eventually needed to add the bulk command
in order to reduce the number of round trips it took to extract some tables.)
One item I don?t see is how the requestor determines the statistics that
are available. Is this something that you expect to be compiled in to the
requestor? or should there be a way for it to ask for the names of the various
objects (maybe the requestor can do a get-all?)
Following on that idea will there be a way for the requestor to determine what
the stat represents? Or is it assumed they know from something else such as
reading the documentation?
And I suppose that also bring up the question of if there is or should be some
sort of versioning information available. I can see a possible use for the
version
of Kea, the stats collector, and the stats extraction protocol. As with the
performance
discussion I?m not sure if any of those are truly useful and they may be
something
we can defer.
------------------------------
Message: 3
Date: Tue, 21 Apr 2015 11:11:16 +0200
From: Wlodek Wencel <[email protected]>
To: "Templin, Fred L" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] RSOO bug in 0.9.1
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Hello,
Yes I had some time but in future could you send captures from tcpdump
in .pcap file not txt? That saves a lot of time.
I managed to convert you message and that is what I got:
###[ DHCP6 Relay-Supplied Options Option ]###
optcode= OPTION_RELAY_SUPPLIED_OPTIONS
optlen= 30
\relaysupplied\
|###[ DHCP6 Vendor-specific Information Option ]###
| optcode= VENDOR_OPTS
| optlen= 26
| enterprisenum= 45282
| \vso\
| |###[ vendor specific option data ]###
| | optcode= 256
| | optlen= 33
| | optdata=
'|\x1f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x14\x00\x00\n'
Message with such option can be classified as 'malformed'. We have here
three values "optlen". Going from the end of the message:
vendor specific option data - optlen= 33
Vendor-specific Information Option - optlen = 26 but should be 41
(enterprise number + option data) if you want vendor specific option
data to be part of the Vendor-specific Information Option.
And length of Relay-Supplied Options Option is 30... but should be 45
because you are sending Vendor-specific Information Option in it.
Could you fix those values and check if your message exchange will be
then correct?
Regards,
W?odek Wencel
On 04/20/2015 06:12 PM, Templin, Fred L wrote:
> Hello Wlodek,
>
> Have you had a chance to look into this yet?
>
> Thanks - Fred
> [email protected]
>
>> -----Original Message-----
>> From: Templin, Fred L
>> Sent: Tuesday, April 14, 2015 12:09 PM
>> To: 'Wlodek Wencel'; [email protected]
>> Subject: RE: [kea-dev] RSOO bug in 0.9.1
>>
>> Hello Wlodek,
>>
>> See attached for the kea server configuration file plus a tcpdump packet
>> capture
>> of the Relay-forward and Relay-reply messages. The packet captures show that
>> the Relay-forward includes a Vendor-Specific Information option with length
>> 26, while the Relay-reply produced by the kea server only includes a VSIO
>> with
>> length 4. Let me know if you need any further information.
>>
>> Thanks - Fred
>> [email protected]
>>
>>> -----Original Message-----
>>> From: Wlodek Wencel [mailto:[email protected]]
>>> Sent: Monday, April 13, 2015 8:08 AM
>>> To: [email protected]
>>> Cc: Templin, Fred L
>>> Subject: Re: [kea-dev] RSOO bug in 0.9.1
>>>
>>> Hello,
>>> Thank you for your email. I checked again RSOO feature in Kea (sending
>>> Vendor-Specific Information Option with multiple sub-options, what I
>>> assume you do) and unfortunately I could not reproduce error you described.
>>>
>>> Can you provide more details? Like kea config file and capture from
>>> wireshark? Or details about Vendor-Specific Information Option you are
>>> including to message?
>>>
>>> Regards,
>>> Wlodek Wencel
>>>
>>> On 04/11/2015 12:44 AM, Templin, Fred L wrote:
>>>> Hello,
>>>>
>>>> I am trying to use the new RFC6422 Relay Supplied Options Option (RSOO)
>>>> facility.
>>>> My RFC6221 relay inserts a Vendor-Specific Information Option (option #17)
>>>> in the
>>>> Relay-forward message that will be sent to the kea server. The option has
>>>> length
>>>> 26 decimal. But, when the kea server does the RFC6422 transformation it
>>>> truncates
>>>> the VSIO to only include the option header and the 4-byte enterprise
>>>> number. The
>>>> VSIO is then inserted into the DHCPv6 Reply message, but loses the 22
>>>> bytes that
>>>> follow the enterprise number.
>>>>
>>>> See attached for the kea log. It does not show anything about the
>>>> Relay-forward
>>>> or Relay-reply messages, but does show how the server inserts the VSIO with
>>>> length 4. Please let me know if any further information is needed.
>>>>
>>>> Fred Templin
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> kea-dev mailing list
>>>> [email protected]
>>>> https://lists.isc.org/mailman/listinfo/kea-dev
>>>>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 13, Issue 11
***************************************
