[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 <fdupont at isc.org>