[Kea-users] Kea 1.1-epel conf no longer work with kea 1.6

Thomas Markwalder tmark at isc.org
Tue Mar 17 13:49:24 UTC 2020


Hello:

If the MAC address is the same for both boot stages and that MAC address 
matches your host reservation, than you are always assigning the INODE 
class to the client, making the test expression that checks vendor id in 
class INODE relevant only for unknown clients. From your log snippet the 
it is clear that the client is being matched to the reservation and is 
thus being assigned to your class.

If you want the class assignment to only occur on vendor-id (option 60), 
then remove client-classes from your reservation.

Hope that helps,

Thomas
ISC Software Engineering

On 3/17/20 9:27 AM, Stephan Walter wrote:
> Hi Pavel,
>
> Yes I have had checked this already and have modified the logging. All the other topics are not used by us. The problem we face is related to the way how kea evaluates the client classes. I have checked all release notes from 1.1 to 1.6 but haven't found any solution for this problem.
>
> The only thing I have found was with 1.4(?) the evaluation order of client classes has changed from definition order to alphabetic, but even if I consider this modification the same problem occurs. And by even if I don't consider this, with respect to the test statement, there shouldn't be any difference on the result.
>
> Best Regards,
>
> Stephan
>
> -----Original Message-----
> From: Pavel Zhukov [mailto:pzhukov at redhat.com]
> Sent: Tuesday, March 17, 2020 12:40 PM
> To: Stephan Walter <Stephan.Walter at EMEA.NEC.COM>
> Cc: Oswald <oswald.cornwallis.thake at gmail.com>; kea-users at lists.isc.org
> Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6
>
> Hi Stephan,
>
> Have you checked this article https://kb.isc.org/docs/upgrading-to-kea-16 out?
>
> incompatible change has been introduced in kea so manual intervention and config changes are required.
>
> On Tue, Mar 17, 2020 at 10:16 AM Stephan Walter <Stephan.Walter at emea.nec.com> wrote:
>> Hi,
>>
>> We have still the problem with the no longer working kea config. In the meantime, the epel repo was update from kea 1.1 to 1.6 so we will see now the same problem for all new installations.
>>
>> It would be great to get some hints how we can fix this problem. If I can provide any further details, just ask for them.
>>
>> Best Regards,
>>
>> Stephan
>>
>>
>> -----Original Message-----
>> From: Stephan Walter
>> Sent: Wednesday, February 26, 2020 8:42 PM
>> To: 'Stephan Walter' <Stephan.Walter at emea.nec.com>; Oswald
>> <oswald.cornwallis.thake at gmail.com>; kea-users at lists.isc.org
>> Subject: RE: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6
>>
>> Btw if it helps, I can provide the debug output of the kea 1.1 and 1.6
>>
>> The strange thing is, that I see within the output two different type=60 queries. One match the (I)NODE test and the other doesn't.
>>
>> But as explained the boot-file-name is set always to the content of the (I)NODE client-class...
>>
>> Below the output of the working 1.1
>>
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to
>> 255.255.255.255:67 over interface eno0
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.options/103]
>> DHCP4_BUFFER_UNPACK parsing buffer received from 0.0.0.0 to
>> 255.255.255.255 over interface eno0
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.options/103] EVAL_RESULT
>> Expression NODE evaluated to 0
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION
>> Pushing option 60 with value
>> 0x505845436C69656E743A417263683A30303030303A554E44493A303032303031
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING Pushing text string '0'
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING Pushing text string '4'
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103]
>> EVAL_DEBUG_SUBSTRING Popping length 4, start 0, string
>> 0x505845436C69656E743A417263683A30303030303A554E44493A303032303031
>> pushing result 0x50584543
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING Pushing text string 'udhcp'
>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping 0x7564686370 and 0x50584543 pushing result 'false'
>> 2020-02-26 20:06:07.672 INFO  [kea-dhcp4.options/103] EVAL_RESULT
>> Expression bios evaluated to 1
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION
>> Pushing option 93 with value 0x0000
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103]
>> EVAL_DEBUG_HEXSTRING Pushing hex string 0x0009
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping 0x0009 and 0x0000 pushing result 'false'
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] EVAL_RESULT
>> Expression efi64 evaluated to 0
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION
>> Pushing option 93 with value 0x0000
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103]
>> EVAL_DEBUG_HEXSTRING Pushing hex string 0x0007
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping 0x0007 and 0x0000 pushing result 'false'
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] EVAL_RESULT
>> Expression ipxe_efi64 evaluated to 0
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.1/16 for packet
>> received by matching address 10.0.103.1
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_SUBNET_SELECTED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>> tid=0x99XXXXXX: the subnet with ID 1 was selected for client
>> assignments
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_SUBNET_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>> tid=0x99XXXXXX: the selected subnet details: 10.0.0.1/16
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_PACKET_RECEIVED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>> tid=0x99XXXXXX: DHCPDISCOVER (type 1) received from 0.0.0.0 to
>> 255.255.255.255 on interface mvlprov
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_QUERY_DATA
>> [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX, packet
>> details: local_address=255.255.255.255:67, remote_adress=0.0.0.0:68,
>> msg_type=DHCPDISCOVER (1), transid=0x99XXXXXX,
>> options:
>>    type=053, len=001: 1 (uint8)
>>    type=055, len=036: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 11(uint8) 12(uint8) 13(uint8) 15(uint8) 16(uint8) 17(uint8) 18(uint8) 22(uint8) 23(uint8) 28(uint8) 40(uint8) 41(uint8) 42(uint8) 43(uint8) 50(uint8) 51(uint8) 54(uint8) 58(uint8) 59(uint8) 60(uint8) 66(uint8) 67(uint8) 128(uint8) 129(uint8) 130(uint8) 131(uint8) 132(uint8) 133(uint8) 134(uint8) 135(uint8)
>>    type=057, len=002: 1260 (uint16)
>>    type=060, len=032: "PXEClient:Arch:00000:UNDI:002001" (string)
>>    type=093, len=002: 0(uint16)
>>    type=094, len=003: 1 (uint8) 2 (uint8) 1 (uint8)
>>    type=097, len=017: 0 (uint8) YYYYYYYYYYYYYYYYYYYYYYYYYY (binary)
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.1/16 for packet
>> received by matching address 10.0.103.1
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_SUBNET_SELECTED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>> tid=0x99XXXXXX: the subnet with ID 1 was selected for client
>> assignments
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_SUBNET_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>> tid=0x99XXXXXX: the selected subnet details: 10.0.0.1/16
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4
>> reservation for subnet id 1, identified by hwaddr=B42E99XXXXXX
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>> HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
>> identifier: hwaddr=B42E99XXXXXX
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>> HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier:
>> hwaddr=B42E99XXXXXX, found host: hwaddr=B42E99XXXXXX ipv4_subnet_id=1
>> hostname=my_NODE ipv4_reservation=10.0.7.1 siaddr=10.0.103.25
>> sname=10.0.103.45 file=(empty) ipv6_reservations=(none)
>> dhcp4_class0=NODE
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
>> hwaddr=B42E99XXXXXX, found 1 host(s)
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 1 and
>> identifier hwaddr=B42E99XXXXXX, found host: hwaddr=B42E99XXXXXX
>> ipv4_subnet_id=1 hostname=my_NODE ipv4_reservation=10.0.7.1
>> siaddr=10.0.103.25 sname=10.0.103.45 file=(empty)
>> ipv6_reservations=(none) dhcp4_class0=NODE
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcp4/103]
>> DHCP4_CLASS_ASSIGNED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>> tid=0x99XXXXXX: client packet has been assigned to the following
>> class(es): INIT_n0701, VENDOR_CLASS_PXEClient:Arch:00000:UNDI:002001,
>> bios
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.ddns/103]
>> DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no
>> info], tid=0x99XXXXXX: processing client's Hostname option
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.ddns/103]
>> DHCP4_RESERVED_HOSTNAME_ASSIGNED [hwtype=1 b4:2e:99:XXXXXX], cid=[no
>> info], tid=0x99XXXXXX: server assigned reserved hostname my_NODE
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>> DHCPSRV_MEMFILE_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID 1
>> and hardware address hwtype=1 b4:2e:99:XXXXXX
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.alloc-engine/103]
>> ALLOC_ENGINE_V4_DISCOVER_HR client [hwtype=1 b4:2e:99:XXXXXX], cid=[no
>> info], tid=0x99XXXXXX sending DHCPDISCOVER has reservation for the
>> address 10.0.7.1
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>> DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.7.1
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>> DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.7.1
>> 2020-02-26 20:06:07.672 INFO  [kea-dhcp4.leases/103]
>> DHCP4_LEASE_ADVERT [hwtype=1 b4:2e:99:XXXXXX], cid=[no info],
>> tid=0x99XXXXXXX: lease 10.0.7.1 will be advertised
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103]
>> DHCP4_PACKET_PACK [hwtype=1 b4:2e:99:XXXXXX], cid=[no info],
>> tid=0x99XXXXXXX: preparing on-wire format of the packet to be sent
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_PACKET_SEND [hwtype=1 b4:2e:99:XXXXXXX], cid=[no info],
>> tid=0x99XXXXXXXX: trying to send packet DHCPOFFER (type 2) from
>> 10.0.103.1:67 to 255.255.255.255:68 on interface mvlprov
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_RESPONSE_DATA [hwtype=1 b4:2e:99:XXXXXXX], cid=[no info],
>> tid=0x99XXXXXXXX: responding with packet DHCPOFFER (type 2), packet
>> details: local_address=10.0.103.1:67,
>> remote_adress=255.255.255.255:68, msg_type=DHCPOFFER (2),
>> transid=0x99XXXXXXX,
>> options:
>>    type=001, len=004: 4294901760 (uint32)
>>    type=012, len=005: "my_NODE" (string)
>>    type=051, len=004: 3600 (uint32)
>>    type=053, len=001: 2 (uint8)
>>    type=054, len=004: 10.0.103.1
>>    type=058, len=004: 900 (uint32)
>>    type=059, len=004: 1800 (uint32)
>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>> DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms
>>
>> I hope this is the full data that is required.
>>
>>
>> -----Original Message-----
>> From: Kea-users [mailto:kea-users-bounces at lists.isc.org] On Behalf Of
>> Stephan Walter
>> Sent: Wednesday, February 26, 2020 7:32 PM
>> To: Oswald <oswald.cornwallis.thake at gmail.com>;
>> kea-users at lists.isc.org
>> Subject: [** SUSPICIOUS EMAIL **] Re: [Kea-users] Kea 1.1-epel conf no
>> longer work with kea 1.6
>>
>> Sorry, I tested INODE as well as NODE with the same result.
>>
>> So it is the SAME within the config, not NODE and INODE within the
>> same file
>>
>>
>> -----Original Message-----
>> From: Kea-users [mailto:kea-users-bounces at lists.isc.org] On Behalf Of
>> Oswald
>> Sent: Wednesday, February 26, 2020 7:21 PM
>> To: kea-users at lists.isc.org
>> Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6
>>
>> Hie Stephan,
>>
>> Is the client-class "INODE" or "NODE"
>>
>> /Os
>>
>> On 26/02/2020 18:07, Stephan_Walter wrote:
>>> Hi,
>>>
>>> I moved from the kea 1.1 server, provided through the epel repo of
>>> CentOS7, to a kea 1.6 server compiled on CentOS8 from srpm.
>>>
>>> The new kea worked from the beginning, but when I tried to boot
>>> nodes, they received the wrong boot-file from the kea. Let me show
>>> the relevant part of the kea config.
>>>
>>>
>>> {
>>>    "Dhcp4": {
>>>   ...
>>>          "option-data": [ ],
>>>          "client-classes": [
>>>          {
>>>            "name": "INODE",
>>>            "test": "substring(option[60].hex,0,4) == 'udhcp'",
>>>            "boot-file-name": "somefancy\n\\,string=now"
>>>          },
>>>              {
>>>                  "name": "bios",
>>>                  "test": "option[93].hex == 0x0000",
>>>                  "boot-file-name": "/tftp/bios/lpxelinux.0"
>>>              },
>>>              {
>>>                  "name": "ipxe_efi64",
>>>                  "test": "option[93].hex == 0x0007",
>>>                  "boot-file-name": "/tftp/efi64/ipxe.efi"
>>>              },
>>>              {
>>>                  "name": "efi64",
>>>                  "test": "option[93].hex == 0x0009",
>>>                  "boot-file-name": "/tftp/efi64/bootx64.efi"
>>>              }
>>>           ],
>>>          "subnet4": [
>>>              {
>>>                  "subnet": "10.0.0.1/16",
>>>                  "reservations": [
>>> { "hw-address": "XX:XX:XX:XX:XX:XX", "ip-address": "10.0.2.1",
>>> "next-server": "10.0.103.22", "hostname": "some_node", "client-classes":
>>> ["NODE"], "server-hostname": "10.0.103.42"},
>>>                  ]
>>>     ....
>>>
>>> }
>>>
>>>
>>> So with kea 1.1 the behavior is, that the system boots through PXE
>>> and get "/tftp/..." as boot-file-name. Afterward, the system make
>>> again a DHCP request and now get the "somefancy.." string as
>>> boot-file-name, that it use to fetch additional data for a two stage
>>> boot
>>>
>>> With kea 1.6 already in the first response the "somefancy..." string
>>> is replied as boot-file-name, what lead to a non working PXE boot.
>>>
>>> I tried now for several days without success to figure out what has changed.
>>>
>>> What I have found is:
>>>
>>>
>>> But even after a reordering of the client class definition, so that
>>> the pxe boot is at the top, the problem still occurs.
>>>
>>> Anybody an idea how I can get with kea 1.6 the same behavior as with 1.1?
>>>
>>>
>>>
>>> --
>>> Sent from: http://kea-users.7364.n8.nabble.com/
>>> _______________________________________________
>>> Kea-users mailing list
>>> Kea-users at lists.isc.org
>>> 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
>>
>>
>>   Click https://www.mailcontrol.com/sr/TA4wI8ajHdrGX2PQPOmvUpFBc4ZD8M8Usm8CQOShYRk3_VbzlmlReMMFBOEtnguvZn5f4yhWRYpAlVq5uz6AOA==  to report this email as spam.
>> _______________________________________________
>> Kea-users mailing list
>> Kea-users at lists.isc.org
>> 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
>>
>
> --
> Pavel Zhukov
> Software Engineer
> IRC: landgraf
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users




More information about the Kea-users mailing list