Re: [Kea-users] VIVSO and use with client classification

[Francis Dupont]

Jason Guy writes:

> I am not entirely sure why the ONIE documentation shows the IANA and ONIE
> suboptions,

=> the IANA block is a round around for an ISC DHCP bug and is fully
useless for Kea.

> but this is a "real-world" use-case

=> so in fact this is not...

> although I don't know if they are in the same packet.

=> they are (DHCPv6 but not DHCPv4 uses multiple options, one per
vendor, and as it is used by DHCPv4-over-DHCPv6 it is correctly handled
by the code (but not by configs because they are a bit too specialized
for cable labs :-)).

> When you say that "full support of multiple
> vendors", do you mean in the same packet, or in the config?

=> same packet again. When you receive a VIVSO only the first vendor
block is unpacked. If you try to send one (by config or using current
code) only the first vendor block is handled.

> I suppose this is easy enough to do in a hook though.

=> not so easy because the OptionVendor class was not designed to
handle multiple vendors.

> I suppose that makes sense since the substring matching is done in hex.
> Since the client classification I am working with, needs to return a VIVSO
> option
> with additional suboptions populated by the classifier, then defining the
> schema in an option-def is necessary, right?

=> it is not necessary: an unknown (sub)option is considered as being
binary and can be specified only by its code. Not very convenient but
still working.

> > => almost this but hex uses hexadecimal so you have to translate "powerpc"
> > in 0x706f7765727063
> 
> I read in the docs that a substring match with the .hex is compared as
> ASCII to the right operand.

=> you are right.

> I figured there would be an ordering feature... For now it is good to know
> the classes are ordered lexicographically.

=> the ticket fixing this is in the review queue.

> > "option-data": [
> > >{
> > >"code": 125,
> > >"csv-format": true,
> > >"data": "42623,0",
> >
> > => I don't believe this data works (at least it didn't when I created
> > a ticket to fix it some years ago :-).

=> according to what I read from the code the ",0" is simply ignored.

> This raises an interesting question in general. If I wanted to use vendor
> options from multiple vendor enterprise-ids (not in the same packet), this
> may not work?

=> with the "not in the same packet" it should be possible to find
a way to have different option-data entries and to control which one
will be used.

> Would this be the proper syntax to define/support multiple VIVSO options?

=> there is none for the same option-data. For different option-data
entries it is like other options.

> > >{
> > >"code": 0,
> >
> > => if it does not bug it should!
> >
> 
> Hmm...the configuration was accepted. I can look in the logs, hopefully it
> was gracefully handled and ignored.

=> I have to see how code 0 is handled. It is forbiden in most of spaces
but not in VIVSO suboptions according to the standard.

Thanks

Francis Dupont 
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] VIVSO and use with client classification

[Jason Guy]

Hi Francis,

Thanks again for explaining things in detail...

On Wed, Dec 20, 2017 at 7:11 PM, Francis Dupont  wrote:

> Jason Guy writes:
> > Hi. We are using Kea in our lab and I am trying to figure out how to use
> > complex client classification with custom options. This pertains to
> booting
> > open networking switches from the network using ONIE (references config
> > options using VIVSO
>
> => VIVSO uses "vendor options". The only thing missing in Kea is the
> full support of multiple vendors (BTW real world cases with multiple
> vendors
> in the same packet are very uncommon).
>

I am not entirely sure why the ONIE documentation shows the IANA and ONIE
suboptions, but this is a "real-world" use-case, although I don't know if
they are in the same packet. When you say that "full support of multiple
vendors", do you mean in the same packet, or in the config?
I suppose this is easy enough to do in a hook though.

> *Questions on VIVSO with client classification:*
> > I was not entirely sure about this, but I assumed I have to first create
> > the option definition for the nested option structure of the VIVSO,
> before
> > a client class can parse it.
>
> => not for parsing them: unknown options are just considered as binary
> so it is less a problem than to set them where a human friendly format
> is a big improvement.
>

I suppose that makes sense since the substring matching is done in hex.
Since the client classification I am working with, needs to return a VIVSO
option
with additional suboptions populated by the classifier, then defining the
schema in
an option-def is necessary, right?

> Regarding the use of VIVSO suboptions in client classification
>
> => you have the same tools (and limits) than for options.
>
> > but I think it is like this:
> >
> > substring(vendor[42623].option[4].hex) == "powerpc"
>
> => almost this but hex uses hexadecimal so you have to translate "powerpc"
> in 0x706f7765727063
>

I read in the docs that a substring match with the .hex is compared as
ASCII to the right operand.

> Section 13.4 (below the table), first note reads:
> "Hexadecimal strings are converted into a string as expected. The starting
> "0X" or "0x" is removed and if the string is an odd number of characters a
> "0" is prepended to it."

Is this not true for vendor options?

> I assume the *vendor[42623]* is essentially "option[125].suboption[42623]"
> .
> > Then the final "*.option[4].hex*" will reference the suboption value?
>
> => yes (cf TokenVendor::evaluate code)
>
> > Since the vivso options and sub-option codes are defined, can the option
> > name be used in the brackets instead of the option code number?
>
> => the parser uses enterprise_id (integer or *) and option_code rules.
> The second (option_code) accepts an integer (and checks it is in the
> right range) or a name. Unfortunately it tries to resove the name into
> a code only in the dhcp4 or dhcp6 spaces. So it does not work even
> the information is available and an intermediate action in the bison
> rule in theory should be able to do that.
>

Understood, I was just curious for making the configuration easier to read.
:)

> Finally, I wanted to create multiple classifiers to build some logic
> > deciding what option values to send back to the client.
> > Does the classification code process all classifications before returning
> > the final answer? Or does it match in a specific order and return on
> first
> > successful match?
>
> => all classifications: each matching class is added to the packet.
> Note if currently classes are matched following the lexicographic order
> of their names this will be fixed to follow the definition order
> (there are other improvements to come).
>

I figured there would be an ordering feature... For now it is good to know
the classes are
ordered lexicographically.

> For example, if a client sent the onie.arch = powerpc, and the
> onie.machine
> > = dell_switch, would the first class here return the installer_url
> option,
> > or will it fall through to the second class which is more specific?
>
> => both are added in the packet but when both add the same option the
> first one wins (an option is added only when it is not present, and
> of course if it was requests (in the PRL / ORO) or marked as always-send).
>  Now I believe you understand my statement about classification order...
>

Yes, this is clear.

> "option-data": [
> >{
> >"code": 125,
> >"csv-format": true,
> >"data": "42623,0",
>
> => I don't believe this data works (at least it didn't when I created
> a ticket to fix it some years ago :-).
>

This raises an interesting question in general. If I wanted to use vendor
options from multiple vendor enterprise-ids (not in the same packet), this
may not work? Would this be the proper syntax to define/support multiple
VIVSO options?


> >"name": "vivso-suboptions"
> >"space": 'dhcp4"
> >}
> > ],
> > "option-def": [
> >{
> >

Re: [Kea-users] VIVSO and use with client classification

[Francis Dupont]

Jason Guy writes:
> Hi. We are using Kea in our lab and I am trying to figure out how to use
> complex client classification with custom options. This pertains to booting
> open networking switches from the network using ONIE (references config
> options using VIVSO

=> VIVSO uses "vendor options". The only thing missing in Kea is the
full support of multiple vendors (BTW real world cases with multiple vendors
in the same packet are very uncommon).

> *Questions on VIVSO with client classification:*
> I was not entirely sure about this, but I assumed I have to first create
> the option definition for the nested option structure of the VIVSO, before
> a client class can parse it.

=> not for parsing them: unknown options are just considered as binary
so it is less a problem than to set them where a human friendly format
is a big improvement.

> Regarding the use of VIVSO suboptions in client classification

=> you have the same tools (and limits) than for options.

> but I think it is like this:
> 
> substring(vendor[42623].option[4].hex) == "powerpc"

=> almost this but hex uses hexadecimal so you have to translate "powerpc"
in 0x706f7765727063

> I assume the *vendor[42623]* is essentially "option[125].suboption[42623]".
> Then the final "*.option[4].hex*" will reference the suboption value?

=> yes (cf TokenVendor::evaluate code)

> Since the vivso options and sub-option codes are defined, can the option
> name be used in the brackets instead of the option code number?

=> the parser uses enterprise_id (integer or *) and option_code rules.
The second (option_code) accepts an integer (and checks it is in the
right range) or a name. Unfortunately it tries to resove the name into
a code only in the dhcp4 or dhcp6 spaces. So it does not work even
the information is available and an intermediate action in the bison
rule in theory should be able to do that.

> Finally, I wanted to create multiple classifiers to build some logic
> deciding what option values to send back to the client.
> Does the classification code process all classifications before returning
> the final answer? Or does it match in a specific order and return on first
> successful match?

=> all classifications: each matching class is added to the packet.
Note if currently classes are matched following the lexicographic order
of their names this will be fixed to follow the definition order
(there are other improvements to come).

> For example, if a client sent the onie.arch = powerpc, and the onie.machine
> = dell_switch, would the first class here return the installer_url option,
> or will it fall through to the second class which is more specific?

=> both are added in the packet but when both add the same option the
first one wins (an option is added only when it is not present, and
of course if it was requests (in the PRL / ORO) or marked as always-send).
 Now I believe you understand my statement about classification order...

> "option-data": [
>{
>"code": 125,
>"csv-format": true,
>"data": "42623,0",

=> I don't believe this data works (at least it didn't when I created
a ticket to fix it some years ago :-).

>"name": "vivso-suboptions"
>"space": 'dhcp4"
>}
> ],
> "option-def": [
>{
>"code": 1,
>"name": "installer_url",
>"space": "onie",

=> the space must be "vendor-42623" (and please open a ticket because
the doc fails to give this information (search vendor-4491 string to find
it) at the place users should look at).

>"type": "string"
>},
>{
>"code": 42623,

=> it will bug. In fact you don't need this definition.

>"encapsulate": "onie",
>"name": "vivso-onie",
>"space": "dhcp4",
>"type": "empty"
>},
>{
>"code": 0,

=> if it does not bug it should!

>"name": "vivso-iana",
>"space": "dhcp4",
>"type": "string"
>}

Thanks

Francis Dupont 
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users