[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 <fdupont at isc.org> 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": [
> >    {
> >        "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).
>

I will file this as soon as I can register and login to the bug tool. It
thinks I am spam. :(


> >        "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!
>

Hmm...the configuration was accepted. I can look in the logs, hopefully it
was gracefully handled and ignored.

>        "name": "vivso-iana",
> >        "space": "dhcp4",
> >        "type": "string"
> >    }
>
>
Cheers,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171229/a1c78355/attachment.htm>