<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-CH" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Hi Darren<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">So, if the client belongs to client-class A and all members of client-class A are restricted to pool B then the client will get an IP address from pool B. Unless, a reservation for
the MAC address of that client is defined. Then, the reservation has precedence. The properties of client-class A still apply to the client.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Is that correct? This is what I observe with the given config example.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Philipp<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">dhcp-users <dhcp-users-bounces@lists.isc.org> on behalf of Darren Ankney <darren.ankney@gmail.com><br>
<b>Date: </b>Tuesday, 7 May 2024 at 08:51<br>
<b>To: </b>Users of ISC DHCP <dhcp-users@lists.isc.org><br>
<b>Subject: </b>Re: kea-dhcp4 behaviour question client-class vs reservations<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Philipp,<br>
<br>
The keyword "client-class" restricts access to the pool to members of<br>
the class. It does not assign members of a class to a pool. See<br>
here: <a href="https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#configuring-pools-with-class-information">
https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#configuring-pools-with-class-information</a><br>
where it says "Similar to subnets, in certain cases access to certain<br>
address or prefix pools must be restricted to only clients that belong<br>
to a given class, using the client-class when defining the pool.".<br>
<br>
Thank you,<br>
Darren Ankney<br>
<br>
On Fri, Apr 26, 2024 at 5:05</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:11.0pt">AM Jan-Philipp Snizek<br>
<jan-philipp.snizek@business.uzh.ch> wrote:<br>
><br>
> Hi<br>
><br>
> I would like to ask a question regarding precedence behavior of kea-dhcp4.<br>
><br>
> Let's take this working config:<br>
><br>
> "client-classes": [<br>
> {<br>
> "name": "pxeclientx64",<br>
> "test": "option[60].text == 'PXEClient:Arch:00007:UNDI:003016'",<br>
> "option-data": [<br>
> { "name": "vendor-encapsulated-options", "always-send": false },<br>
> { "name": "boot-file-name", "data": "SMSBoot\\x64\\wdsmgfw.efi" },<br>
> { "name": "tftp-server-name", "code": 66, "data": "my-tftp-server.domain.local" }<br>
> ]<br>
> }<br>
> ],<br>
> "subnet4": [<br>
> {<br>
> "id": 1,<br>
> "subnet": "172.20.19.0/24",<br>
> "next-server": "172.20.19.1",<br>
> "pools": [<br>
> { "pool": "172.20.19.120 - 172.20.19.129" },<br>
> { "pool": "172.20.19.130 - 172.20.19.139", "client-class": "pxeclientx64" }<br>
> ],<br>
> "reservation-mode": "out-of-pool",<br>
> "reservations": [<br>
> { "hostname": "pxeboot1", "hw-address": "00:e0:4c:68:0a:f1", "ip-address": "172.20.19.150" }<br>
> ],<br>
> "option-data": [<br>
> { "name": "routers", "data": "172.20.19.1" }<br>
> ]<br>
> }<br>
> ],<br>
><br>
> If the client with the reservation executes a PXE boot it gets the reserved IP .19.150 and successfully boots PXE.<br>
> The kea-dhcp4 log looks like this:<br>
> Apr 25 13:53:17 hellbox kea-dhcp4[16858]: INFO EVAL_RESULT Expression pxeclientx64 evaluated to 1<br>
> Apr 25 13:53:17 hellbox kea-dhcp4[16858]: INFO DHCP4_LEASE_ADVERT [hwtype=1 00:e0:4c:68:0a:c1], cid=[no info], tid=0x2223e0e3: lease 172.20.19.150 will be advertised<br>
> Apr 25 13:53:20 hellbox kea-dhcp4[16858]: INFO EVAL_RESULT Expression pxeclientx64 evaluated to 1<br>
> Apr 25 13:53:20 hellbox kea-dhcp4[16858]: INFO DHCP4_LEASE_ALLOC [hwtype=1 00:e0:4c:68:0a:c1], cid=[no info], tid=0x2223e0e3: lease 172.20.19.150 has been allocated for 3600 seconds<br>
> As we can see both matches: pxeclientx64 and the reservation. The client successfully boots pxe.<br>
> I don't understand why the client successfully pxe boots. The client-class "pxeclientx64" is assigned to a pool. It is neither assigned to the subnet4 { id: 1 } subnet declaration nor to the reservation.<br>
> What has precedence over what? How does inheritance work in kea?<br>
><br>
> Thanks,<br>
><br>
> --<br>
><br>
> Philipp<br>
><br>
> --<br>
> ISC funds the development of this software with paid support subscriptions. Contact us at
<a href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.<br>
><br>
> dhcp-users mailing list<br>
> dhcp-users@lists.isc.org<br>
> <a href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
-- <br>
ISC funds the development of this software with paid support subscriptions. Contact us at
<a href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.<br>
<br>
dhcp-users mailing list<br>
dhcp-users@lists.isc.org<br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>