[Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Marek Hajduczenia
mxhajduczenia at gmail.com
Tue Apr 23 16:34:45 UTC 2024
An update after a short test with the attached configuration. I have a class for rpd-10 defined
{
"name": "rpd-10",
"test": "substring(relay6[1].option[18].hex,-1,10) == 'Md10:0/0.0'"
},
The test DOCSIS CM does come from RPD-10 as expected, as shiwn below
[cid:image003.png at 01DA9569.53B29C50]
but it gets response indicating that no addresses were allocated.
[cid:image004.png at 01DA9569.80A76650]
Since there are no custom log messages supported yet, I am not sure how I can troubleshoot this scenario. Is there a way to display which of the client classes was triggered by the incoming message? I have logs set to DEBUG but this information does not seem to be making into the logs
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: msgtype=2(ADVERTISE), transid=0x358d58
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00001, len=00010: 00:03:00:01:a8:70:5d:d0:da:5d
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00002, len=00014: 00:01:00:01:2d:b5:42:67:bc:24:11:c9:17:2f
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00003(IA_NA), len=00055: iaid=1573968477, t1=0, t2=0,
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: options:
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00013, len=00039: NoAddrsAvail(2) "Sorry, no address could be allocated."
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00017, len=00129: 4491 (uint32),
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: options:
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00032, len=00016: 2600:6ce1:0:801a::78
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00033, len=00053: "WBDocCfg166.cfg" (string)
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00034, len=00016: 2600:6ce4:0:4::169
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00037, len=00016: 2600:6ce1:0:801a::78
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00038, len=00004: 0 (int32)
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00023, len=00016: 2600:6ce4:40:12c:8000::3
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: 2 relay(s):
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: relay[0]: msg-type=13(RELAY_REPLY), hop-count=1,
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: link-address=2600:6ce4:0:3e::1, peer-address=fe80::aa70:5dff:fed0:da5d, 0 option(s)
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: relay[1]: msg-type=13(RELAY_REPLY), hop-count=0,
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: link-address=::, peer-address=fe80::aa70:5dff:fed0:da5d, 1 option(s)
Apr 23 16:32:50 server-kea-node1 kea-dhcp6[2059]: type=00018, len=00017: 4d:64:31:30:3a:30:2f:30:2e:30:00:a8:70:5d:d0:da:5d
Regards
Marek
From: Marek Hajduczenia <mxhajduczenia at gmail.com>
Date: Tuesday, April 23, 2024 at 7:48 AM
To: 'Kea user's list' <kea-users at lists.isc.org>
Subject: RE: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Darren,
Thanks for the feedback.
I did run a packet capture from a lab device and it is attached. I hope it comes through - this is a DHCPv6 traffic from a DOCSIS CM running in IPv6 mode only, two relay level deep, i.e., inner relay is a vCMTS and outer relay is the first hop router. I hope clarify some of the questions I have been asking
Packet 11 is a relayed Solicit with Option 17, containing CableLabs specific sub-option (4491) and then inside of it, there is sub-option 2 (Device Type), which is what I need access to classify packets correctly.
[cid:image001.png at 01DA9551.AA65AA50]
The very same device, just EROUTER requesting address (packet 21) and again I will need access to the very same sub-option 2 (Device Type)
[cid:image002.png at 01DA9552.51A4C260]
I will build a configuration pool on a Kea test node next and attempt to use your syntax suggestion, i.e., "test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'" but even if that works, I still dislike the fact that I cannot use option definitions that already exist in the very same configuration file. They are there, the parser should be able to reference them internally as part of the vendor-specific option space.
I will report back when I am done with a test
Thank you !
Marek
-----Original Message-----
From: Kea-users <kea-users-bounces at lists.isc.org<mailto:kea-users-bounces at lists.isc.org>> On Behalf Of Darren Ankney
Sent: Tuesday, April 23, 2024 3:32 AM
To: Kea user's list <kea-users at lists.isc.org<mailto:kea-users at lists.isc.org>>
Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
I failed to notice that this was DHCPv6. I was talking about option
125 which is DHCPv4 vendor options. Option 17 is covered in the manual here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcpv6-vendor-specific-options
I am not clear regarding the presence of option 17 in the inbound packet (Solicit / request). Is option 17 in the packet? If so, then you may be able to use a test line like this:
"test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'"
Though again, I've not tested it. But my understanding is that option
17 is something the server sets to send back to the client, not the reverse. So I'm not sure this option will be present in the inbound packets to be tested. You can easily find out what is there by taking a packet capture, however.
Thank you,
Darren Ankney
On Sun, Apr 21, 2024 at 10:00 AM <mxhajduczenia at gmail.com<mailto:mxhajduczenia at gmail.com>> wrote:
>
> 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.ankney at gmail.com<mailto:darren.ankney at gmail.com>>
> Sent: Sunday, April 21, 2024 4:39 AM
> To: mxhajduczenia at gmail.com<mailto:mxhajduczenia at gmail.com>; Kea user's list <kea-users at lists.isc.org<mailto:kea-users at 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 <mxhajduczenia at gmail.com<mailto:mxhajduczenia at 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-bounces at lists.isc.org<mailto:kea-users-bounces at lists.isc.org>> On Behalf Of
> > Darren Ankney
> > Sent: Friday, April 19, 2024 3:08 PM
> > To: Kea user's list <kea-users at lists.isc.org<mailto:kea-users at 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 <mxhajduczenia at gmail.com<mailto:mxhajduczenia at 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 at lists.isc.org<mailto:Kea-users at 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 at lists.isc.org<mailto:Kea-users at 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 at lists.isc.org<mailto:Kea-users at 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 at lists.isc.org<mailto:Kea-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/kea-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240423/3cfc9e5a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 193077 bytes
Desc: image001.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240423/3cfc9e5a/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 153705 bytes
Desc: image002.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240423/3cfc9e5a/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 63483 bytes
Desc: image003.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240423/3cfc9e5a/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 88478 bytes
Desc: image004.png
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240423/3cfc9e5a/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keav6.rev1.json
Type: application/json
Size: 9006 bytes
Desc: keav6.rev1.json
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240423/3cfc9e5a/attachment-0001.json>
More information about the Kea-users
mailing list