[Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Darren Ankney
darren.ankney at gmail.com
Wed Apr 24 09:50:55 UTC 2024
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 <mxhajduczenia at 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-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>
> 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> 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>
>
> > Sent: Sunday, April 21, 2024 4:39 AM
>
> > To: mxhajduczenia at gmail.com; Kea user's list <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> 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> On Behalf Of
>
> > > Darren Ankney
>
> > > Sent: Friday, April 19, 2024 3:08 PM
>
> > > 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 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> 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
>
> > > > 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
>
> > > 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
>
> > > 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
>
> 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
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240424/af4a3401/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 193077 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240424/af4a3401/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 153705 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240424/af4a3401/attachment-0003.png>
More information about the Kea-users
mailing list