You did hit the nail on the head, Darren,
I have three device "classes" to deal with her:
- DOCSIS CM, which will have Option 17 with sub-option 2 equal to "ECM",
- DOCSIS embedded router (eROUTER), which will have Option 17 with sub-option 2
equal to "EROUTER", and
- all devices connected to the DOCSIS CM, which will not have Option 17
(likely) - I do not control these, and these are just a random bag of devices.
My train of through in here is simple: classify incoming DHCP packets
(Solicits, since I am dealing with IPv6 only for now), and (a) match on ECM and
give them addresses from a specific target pool, (b) then match on EROUTER and
give them addresses from a specific target pool, and (c) whatever does not
match on either condition, get an address from the "client" pool.
In ISC, I was able to do that with "match if" statements, which work fine for
my purposes. In Kea, I am struggling with logic here, since the parser does not
seem to support locally defined vendor-specific class space.
I am not sure whether your example below would work for me, since Option 17
(DHCPv6) will have to have Vendor 4491 (CableLabs) defined wrapper, and only
then option 2 inside of it. That is what the " match if (option
docsis.device-type) = > 'EROUTER'" in ISC syntax was achieving as far as I
know. In Kea, it would be similar to
"test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'" but parser
does not like it, obviously. It does seem like it is one of the missing Kea
features?
Marek
-----Original Message-----
From: Darren Ankney <darren.ank...@gmail.com>
Sent: Sunday, April 21, 2024 4:39 AM
To: mxhajducze...@gmail.com; Kea user's list <kea-users@lists.isc.org>
Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
I don't think you can use vendor option space like that. This MIGHT work:
"test": "substring(option[125].option[2].hex,-1,7) == 'EROUTER'"
But would option 125 exist in the inbound packet? I don't think class testing
occurs on the outbound packets... It might help to understand what you are
trying to achieve there as there might be a better way.
Thank you,
Darren Ankney
On Fri, Apr 19, 2024 at 5:22 PM Marek Hajduczenia <mxhajducze...@gmail.com>
wrote:
>
> Thank you, Darren,
>
> That does indeed at least pass the parser stage (actual device testing will
> have to wait). It is a pity that a regex is not yet available. I saw it was
> planned for 2.6 release?
>
> If I can build on the previous request, this part is more challenging,
> since it relays on a custom vendor address space, specifically,
> DOCSIS-specific sub-options in Option 17. Assume I have a
> "device-type" sub-option defined as follows
>
> "option-def": [
> {
> "space": "vendor-4491",
> "name": "device-type",
> "code": 2,
> "type": "string"
> }]
>
> and then I would like to classify based on it to translate the ISC
> compare statement of " match if (option docsis.device-type) =
> 'EROUTER'". Following your example below
>
> "test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'"
>
> Should be theoretically possible, but I do not think the parser likes
> it much: [substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER']
> error: <string>:1.17-21: syntax error, unexpected integer, expecting [
> or . at (/etc/kea/kea-dhcp6.conf:141:17)
>
> Regards
>
> Marek
>
> -----Original Message-----
> From: Kea-users <kea-users-boun...@lists.isc.org> On Behalf Of Darren
> Ankney
> Sent: Friday, April 19, 2024 3:08 PM
> To: Kea user's list <kea-users@lists.isc.org>
> Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to
> Kea syntax
>
> Hi Marek,
>
> That is pseudo code generated by KeaMA as Kea doesn't support regex
> statements like ISC DHCP did. There was probably an additional line output
> that linked to some GL issue explaining. Something like this might work
> (I've not tested it):
>
> "client-classes": [
> {
> "name": "rpd-1",
> "test": "substring(relay6[1].option[18].hex,-1,9) == 'Md1:0/0.0'"
> }
> ]
>
> Thank you,
> Darren Ankney
>
> On Fri, Apr 19, 2024 at 4:27 PM Marek Hajduczenia <mxhajducze...@gmail.com>
> wrote:
> >
> > Dear colleagues,
> >
> >
> >
> > I ran into a bit of a challenge with the conversion of the config from ISC
> > to Kea, namely this little class definition gem:
> >
> >
> >
> > class "rpd-1" { match if v6relay( 1, option dhcp6.interface-id ) ~=
> > "Md1:0/0.0$"; }
> >
> >
> >
> > What it does, as you can tell, it matches on the inner relay interface-id
> > field in the DHCPv6 messages. Nothing fancy, it does work as tested.
> >
> >
> >
> > I have been looking at the available options and nothing comes to
> > mind so I used keama for automatic conversion and it generated
> > something pretty complex, as follows. Additionally, it is commented
> > out, so I assume this is a non-working configuration element (?)
> >
> >
> >
> > "client-classes": [
> >
> > {
> >
> > "name": "rpd-1"
> >
> > // /// match if (v6relay(1, option dhcp6.interface-id)) ~= 'Md1:0/0.0$'
> >
> > // "match-if": {
> >
> > // "regex-match": {
> >
> > // "left": {
> >
> > // "v6relay": {
> >
> > // "relay": 1,
> >
> > // "relay-option": {
> >
> > // "option": {
> >
> > // "universe": "dhcp6",
> >
> > // "name": "interface-id",
> >
> > // "code": 18
> >
> > // }
> >
> > // }
> >
> > // }
> >
> > // },
> >
> > // "right": "Md1:0/0.0$"
> >
> > // }
> >
> > // }
> >
> > }]
> >
> >
> >
> > If I try to remove the comment markup and apply it with Kea 2.4.1, the
> > parser does not like the “match-if” statement for some reason. I cannot
> > locate it in the list of Kea statements, so not sure why it would be
> > generated by keama. However, the bigger question is on how to build a
> > Kea-compatible match on such embedded message. Any help here would be
> > really appreciated.
> >
> >
> >
> > Apr 19 18:54:20 server-kea-node1 systemd[1]: Started Kea DHCPv6 Service.
> >
> > Apr 19 18:54:20 server-kea-node1 kea-dhcp6[2099]: 2024-04-19
> > 18:54:20.202 ERROR [kea-dhcp6.dhcp6/2099.841038976] DHCP6_INIT_FAIL
> > failed to initialize Kea server: configuration error using file
> > '/etc/kea/kea-dhcp6.conf': /etc/kea/kea-dhcp6.conf:118.9-18: syntax
> > error, unexpected constant string, expecting }
> >
> > Apr 19 18:54:20 server-kea-node1 systemd[1]:
> > isc-kea-dhcp6-server.service: Main process exited, code=exited,
> > status=1/FAILURE
> >
> > Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service:
> > Failed with result 'exit-code'.
> >
> >
> >
> > Regards
> >
> >
> >
> > Marek
> >
> > --
> > ISC funds the development of this software with paid support subscriptions.
> > Contact us at https://www.isc.org/contact/ for more information.
> >
> > To unsubscribe visit 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
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit 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
>
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit 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
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit 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
