Re: [Kea-users] Direction on specific IP and prefix for each customer

[Torbjörn Eklöv]

Hi Tim, i think my presentation can give you some hints.

https://www.ripe.net/participate/meetings/regional-meetings/ipv6-day-denmark/presentations/5-torbjorn-ipv6-copenhagen-2017-11-06.pdf

/Tobbe

- Did you enable IPv6 on something today?

29 dec. 2017 kl. 19:07 skrev Tim Howe 
>:

I'm just now starting to set up and play with Kea, but I'm having some
trouble finding exactly how to do what I want in the docs..

What I hope to do is specify an IPv6 address for each user out of a /64
pool that is specific to them (based on data /hopefully/ send by the
TA5000 they are connected to) and then delegate a specific prefix to
each of those customers as well.

I also want them to be able to statically configure the same data, so
the IP and PD would always be the same for the customer.

I should also say that I'm not entirely clear on how else you would do
it...  If you just assign a prefix from a pool, how is it expected that
you are correctly routing that prefix to the customer?  Anyway...


   Can someone point me to an example of the PD and the IP being
in the reservation?  How are other people handling pulling the PD from
a pool (as far as routing goes)?

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

[Kea-users] Direction on specific IP and prefix for each customer

[Tim Howe]

I'm just now starting to set up and play with Kea, but I'm having some
trouble finding exactly how to do what I want in the docs..

What I hope to do is specify an IPv6 address for each user out of a /64
pool that is specific to them (based on data /hopefully/ send by the
TA5000 they are connected to) and then delegate a specific prefix to
each of those customers as well.

I also want them to be able to statically configure the same data, so
the IP and PD would always be the same for the customer.

I should also say that I'm not entirely clear on how else you would do
it...  If you just assign a prefix from a pool, how is it expected that
you are correctly routing that prefix to the customer?  Anyway...


Can someone point me to an example of the PD and the IP being
in the reservation?  How are other people handling pulling the PD from
a pool (as far as routing goes)?

--TimH
___
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": [
> >{
> >