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

Thomas Markwalder Tue, 17 Mar 2020 06:50:23 -0700

Hello:

If the MAC address is the same for both boot stages and that MAC addressmatches your host reservation, than you are always assigning the INODEclass to the client, making the test expression that checks vendor id inclass INODE relevant only for unknown clients. From your log snippet theit is clear that the client is being matched to the reservation and isthus 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:[email protected]]
Sent: Tuesday, March 17, 2020 12:40 PM
To: Stephan Walter <[email protected]>
Cc: Oswald <[email protected]>; [email protected]
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 <[email protected]> 
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' <[email protected]>; Oswald
<[email protected]>; [email protected]
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:[email protected]] On Behalf Of
Stephan Walter
Sent: Wednesday, February 26, 2020 7:32 PM
To: Oswald <[email protected]>;
[email protected]
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:[email protected]] On Behalf Of
Oswald
Sent: Wednesday, February 26, 2020 7:21 PM
To: [email protected]
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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[email protected]
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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users


--
Pavel Zhukov
Software Engineer
IRC: landgraf

_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users


_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users

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

Reply via email to