[Kea-users] full set of option82 agent options for v4, flex-id extension

Tomek Mrugalski tomasz at isc.org
Tue Jun 6 14:16:03 UTC 2017


On 06/06/17 13:43, Christian Kratzer wrote:
> Hi,
> 
> another thing turned up in my quest in evaluation the move from isc to
> kea dhcp.
> 
> I currently have all of the following options for identifying host
> reservations in isc dhcp:
> 
>   host-identifier option agent.circuit-id "lineid-1001";
>   host-identifier option agent.remote-id "/lineid-1002/";
>   host-identifier option agent.subscriber-id "lineid-1003";
> 
> We have older zyxel dslam that only have configurable remote-id.
> 
> We also have newer zyxel gear where the dhcp snooping agent can insert
> both circuit-id and remote-id
> 
> We also have cisco4506 switches that only do circuit-id.
> 
> In another setup I have a vlan per customer where the cisco l3 gateway
> only supports inserting a subscriber-id.
Interesting case. But in general you control the values of those
options, so you can ensure they all are unique within your network,
right? You could try the following expression:

concat(concat(relay4[1].hex, relay4[2].hex),relay4[6].hex)

This would take RAI suboption 1 (circuit-id), RAI suboption 2
(remote-id) and RAI suboption 6 (subscriber-id) and join them together.
If an option is not present, empty string would be used. I have not
tested it, but it should work in principle.

On a related note, we should probably extend concat() command to be able
to provide arbitrary number of parameters.

> As you see the zyxel cpe we have also require strange quoting with /
> around the remote-id value.
Speaking of strange quoting, you can use "'whatevah'" if the expression
evaluates to something printable or use hex encoding, e.g. "01afbeef",
to quote arbitrary values (in case the options have non-printable
characters).

There's also a UTF-8 encoding (\u00xx) if the value is generally
printable, but you want to escape one or two weird characters. The code
is supposed to handle codes from \u0000 to \u00ff. I admit that the utf
encoding has only been tested very briefly, though.

> No comibinations like recently requested on the list, just alternatives.
Would the solution I described above work for you? If not, how about we
introduce a new operator first_of. You would specify a number of
parameters and the operator would take the first that is present:

first_of(relay4[1].hex, relay4[2].hex, relay4[6].hex)

If there's sub-option 1, its value would be used. If not, the code would
try to use sub-option 2, if present. If not, value of sub-option 6 would
be used.

Alternatively, we could think about an extension to flex-id. Currently
you can specify one global expression that is used everywhere. We could
extend the code to be able to use different expressions in different
subnets. Would that solve your problem?

> The design paper on I found here
> https://kea.isc.org/wiki/HostReservationDesign says kea 1.1 would
> support all 3 circuit-id, remote-id, subscriber-id for the host identifier.

> 
> The postgresql db schema only has circuit-id:
> 
>     ck at kea1:/usr/local/share/kea/scripts/pgsql$ grep
> host_identifier_type dhcpdb_create.pgsql  | grep ^INSERT
>     INSERT INTO host_identifier_type VALUES (0, 'hw-address');
>     INSERT INTO host_identifier_type VALUES (1, 'duid');
>     INSERT INTO host_identifier_type VALUES (2, 'circuit-id');
>     INSERT INTO host_identifier_type VALUES (3, 'client-id');
>     INSERT INTO host_identifier_type VALUES (4, 'flex-id');
>     ck at kea1:/usr/local/share/kea/scripts/pgsql$
> 
> Any reason remote-id and subscriber-id were left out.  Or is this just
> missing in the db schema ?
When we were implementing 1.1, there were new use cases coming up with
different identifiers. At certain point we decided that we are not going
to implement all of them, because people simply coming with more and
more exotic identifiers. This is why some identifiers were left out.

Some time has passed and I came up with the idea of flexible identifier,
where you can define what will be used as the identifier. When flex-id
became available, it can support anything, so there's no point in
implementing dedicated identifiers anymore.

> A related issue would turn up when using flex-id.  As we neeed different
> identifiers depending on the access technology we might also need
> different flex-id instances.   Currently we would be fine with ipv4 when
> remote-id and subscriber-id are added.  Also in ipv6 we currently have
> all the ldra set to option 18 interface-id.  Still a situation might
> turn up in the future where we might need multiple variations of flex-id.
Sure. Existing implementation of flex-id is just a first iteration. We
could certainly improve it. See my two proposals above. Your proposal
below is a third one. It has couple issues, but I'm sure those could be
worked out.

To be more specific, the two issues I have with this approach are:
1. it would be difficult to store this a database. In general, the DB
uses subnet-id, identifier-type (integer) and indentifier-value
(arbitrary byte string) to pick a reservation. The proposal below would
have to fit into this somehow. It currently have 4 pieces of information
(type: subnet-id, interface-type set to a value of interface-id, flex-id
as a type, flex-id value) which is one too many.
It's a solvable problem, though.

2. the whole reservation system queries database (be it proper SQL or
our own in memory db) by calling get4(subnet-id, identifier-type,
identifier-value) query. If you define multiple expressions, there would
be multiple queries for each incoming packet. This is not a
deal-breaker, just a performance penalty for having too many
expressions. With two or three of them you'd probably be ok, though.

> A possible design for supporting this would be to have named flex-id
> instances that you preconfigure in the config file and then reference by
> name.  I am thinking of something like the following:
> 
>     "Dhcp6": {
>         "reservations": [
>         {
>             "identifier-type":"interface-id",
>             "flex-id": "'foo'",
>             "ip-addresses": [ "2001:db8::1" ]
>         },
>         {
>             "identifier-type":"remote-id",
>             "flex-id": "'bar'",
>             "ip-addresses": [ "2001:db8::2" ]
>         },
>         ],
>         "hooks-libraries": [
>         {
>             "library": "/path/libdhcp_flex_id.so",
>             "parameters": [
>             {
>                 "name": "interface-id",
>                 "identifier-type": "
>                 "identifier-expression": "relay6[2].option[18].hex"
>             },
>             {
>                 "name": "remote-id",
>                 "identifier-expression": "relay6[2].option[37].hex"
>             }
>             [
>         },
>         ...
>     ],

Thanks for sharing this. It's a definitely interesting use case.

Tomek




More information about the Kea-users mailing list