Thank you, Darren I did not notice that - it is buried pretty deep in the list of options.
A general question, and I know I am an interested party here - would it make sense to add to documentation to cover DOCSIS-specific examples? There is going to be a lot of interest from this industry and I know the questions that will be asked, over and over again likely. Marek -----Original Message----- From: Kea-users <kea-users-boun...@lists.isc.org> On Behalf Of Darren Ankney Sent: Saturday, April 27, 2024 9:21 AM 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, I recently found out that you can use syntax like: 'vendor[<some vendor number>].option[<some option number>].hex' in class test lines to match instead of 'option[17].option[2].hex' as noted in the table here: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#id3 Though it isn't exalty what you were asking for, perhaps it helps in some way? Thank you, Darren Ankney On Wed, Apr 24, 2024 at 8:51 AM Marek Hajduczenia <mxhajducze...@gmail.com> wrote: > > Thank you, Darren, > > > > If these custom-defined options are outbound only, it would be great if that > was mentioned in the documentation somewhere. In all my reading I did not > find a single reference to that – perhaps I just missed it. I was treating it > as any internally defined variable name, and since it can be used to specify > outbound options, I figured they should also work the same way in ingress > parser. Clearly, a wrong assumption on my part. > > > > Regards > > > > Marek > > > > From: Darren Ankney <darren.ank...@gmail.com> > Sent: Wednesday, April 24, 2024 3:51 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 > > > > Understood Marek, > > > > > 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 understand this statement too. However, I feel it necessary to point out > that those option definitions are so that you can fill option data in the > defined option for outbound packets not so that you can use names to classify > inbound packets. > > > > Thank you, > > Darren Ankney > > > > On Tue, Apr 23, 2024 at 9:50 AM Marek Hajduczenia <mxhajducze...@gmail.com> > wrote: > > 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. > > > > > > 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) > > > > > > 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-boun...@lists.isc.org> On Behalf Of Darren > Ankney > Sent: Tuesday, April 23, 2024 3:32 AM > 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, > > > > 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-vend > or-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 <mxhajducze...@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.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 > > -- > 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
