Hi Francis, Thanks again for explaining things in detail...
On Wed, Dec 20, 2017 at 7:11 PM, Francis Dupont <fdup...@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
_______________________________________________ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users