<div dir="ltr">Hi Francis,<div><br></div><div>Thanks again for explaining things in detail...<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 20, 2017 at 7:11 PM, Francis Dupont <span dir="ltr"><<a href="mailto:fdupont@isc.org" target="_blank">fdupont@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">Jason Guy writes:<br>
> Hi. We are using Kea in our lab and I am trying to figure out how to use<br>
> complex client classification with custom options. This pertains to booting<br>
> open networking switches from the network using ONIE (references config<br>
> options using VIVSO<br>
<br>
</span>=> VIVSO uses "vendor options". The only thing missing in Kea is the<br>
full support of multiple vendors (BTW real world cases with multiple vendors<br>
in the same packet are very uncommon).<br></blockquote><div> </div><div>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? </div><div>I suppose this is easy enough to do in a hook though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> *Questions on VIVSO with client classification:*<br>
<span class="gmail-m_7179843103996579856gmail-">> I was not entirely sure about this, but I assumed I have to first create<br>
> the option definition for the nested option structure of the VIVSO, before<br>
> a client class can parse it.<br>
<br>
</span>=> not for parsing them: unknown options are just considered as binary<br>
so it is less a problem than to set them where a human friendly format<br>
is a big improvement.<br></blockquote><div> </div><div>I suppose that makes sense since the substring matching is done in hex. </div><div>Since the client classification I am working with, needs to return a VIVSO option </div><div>with additional suboptions populated by the classifier, then defining the schema in </div><div>an option-def is necessary, right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> Regarding the use of VIVSO suboptions in client classification<br>
<br>
</span>=> you have the same tools (and limits) than for options.<br>
<span class="gmail-m_7179843103996579856gmail-"><br>
> but I think it is like this:<br>
><br>
> substring(vendor[42623].option<wbr>[4].hex) == "powerpc"<br>
<br>
</span>=> almost this but hex uses hexadecimal so you have to translate "powerpc"<br>
in 0x706f7765727063<br></blockquote><div> </div><div>I read in the docs that a substring match with the .hex is compared as ASCII to the right operand.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Section 13.4 (below the table), first note reads:<br><span style="color:rgb(51,51,51);font-family:ArialMT,Verdana,Arial,Helvetica,sans-serif;font-size:14px">"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."</span></blockquote><div>Is this not true for vendor options?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I assume the *vendor[42623]* is essentially "option[125].suboption[42623]"<wbr>.<br>
> Then the final "*.option[4].hex*" will reference the suboption value?<br>
<br>
=> yes (cf TokenVendor::evaluate code)<br>
<span class="gmail-m_7179843103996579856gmail-"><br>
> Since the vivso options and sub-option codes are defined, can the option<br>
> name be used in the brackets instead of the option code number?<br>
<br>
</span>=> the parser uses enterprise_id (integer or *) and option_code rules.<br>
The second (option_code) accepts an integer (and checks it is in the<br>
right range) or a name. Unfortunately it tries to resove the name into<br>
a code only in the dhcp4 or dhcp6 spaces. So it does not work even<br>
the information is available and an intermediate action in the bison<br>
rule in theory should be able to do that.<br></blockquote><div> </div><div>Understood, I was just curious for making the configuration easier to read. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> Finally, I wanted to create multiple classifiers to build some logic<br>
> deciding what option values to send back to the client.<br>
> Does the classification code process all classifications before returning<br>
> the final answer? Or does it match in a specific order and return on first<br>
> successful match?<br>
<br>
</span>=> all classifications: each matching class is added to the packet.<br>
Note if currently classes are matched following the lexicographic order<br>
of their names this will be fixed to follow the definition order<br>
(there are other improvements to come).<br></blockquote><div> </div><div>I figured there would be an ordering feature... For now it is good to know the classes are </div><div>ordered lexicographically.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> For example, if a client sent the onie.arch = powerpc, and the onie.machine<br>
> = dell_switch, would the first class here return the installer_url option,<br>
> or will it fall through to the second class which is more specific?<br>
<br>
</span>=> both are added in the packet but when both add the same option the<br>
first one wins (an option is added only when it is not present, and<br>
of course if it was requests (in the PRL / ORO) or marked as always-send).<br>
Now I believe you understand my statement about classification order...<br></blockquote><div><br></div><div>Yes, this is clear. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> "option-data": [<br>
> {<br>
> "code": 125,<br>
> "csv-format": true,<br>
> "data": "42623,0",<br>
<br>
</span>=> I don't believe this data works (at least it didn't when I created<br>
a ticket to fix it some years ago :-).<br></blockquote><div><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> "name": "vivso-suboptions"<br>
> "space": 'dhcp4"<br>
> }<br>
> ],<br>
> "option-def": [<br>
> {<br>
> "code": 1,<br>
> "name": "installer_url",<br>
> "space": "onie",<br>
<br>
</span>=> the space must be "vendor-42623" (and please open a ticket because<br>
the doc fails to give this information (search vendor-4491 string to find<br>
it) at the place users should look at).<br></blockquote><div><br></div><div>I will file this as soon as I can register and login to the bug tool. It thinks I am spam. :(</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> "type": "string"<br>
> },<br>
> {<br>
> "code": 42623,<br>
<br>
</span>=> it will bug. In fact you don't need this definition.<br>
<span class="gmail-m_7179843103996579856gmail-"><br>
> "encapsulate": "onie",<br>
> "name": "vivso-onie",<br>
> "space": "dhcp4",<br>
> "type": "empty"<br>
> },<br>
> {<br>
> "code": 0,<br>
<br>
</span>=> if it does not bug it should!<br></blockquote><div> </div><div>Hmm...the configuration was accepted. I can look in the logs, hopefully it was gracefully handled and ignored.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_7179843103996579856gmail-">
> "name": "vivso-iana",<br>
> "space": "dhcp4",<br>
> "type": "string"<br>
> }<br><br></span></blockquote><div><br></div><div>Cheers,<br>Jason</div></div></div></div></div>