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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Oswald
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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
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:[hidden email]] On Behalf Of Oswald
Sent: Wednesday, February 26, 2020 7:21 PM
To: [hidden email]
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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
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:[hidden email]] On Behalf Of Stephan Walter
Sent: Wednesday, February 26, 2020 7:32 PM
To: Oswald <[hidden email]>; [hidden email]
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:[hidden email]] On Behalf Of Oswald
Sent: Wednesday, February 26, 2020 7:21 PM
To: [hidden email]
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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
In reply to this post by Stephan_Walter
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' <[hidden email]>; Oswald <[hidden email]>; [hidden email]
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:[hidden email]] On Behalf Of Stephan Walter
Sent: Wednesday, February 26, 2020 7:32 PM
To: Oswald <[hidden email]>; [hidden email]
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:[hidden email]] On Behalf Of Oswald
Sent: Wednesday, February 26, 2020 7:21 PM
To: [hidden email]
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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Pavel Zhukov
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
<[hidden email]> 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' <[hidden email]>; Oswald <[hidden email]>; [hidden email]
> 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:[hidden email]] On Behalf Of Stephan Walter
> Sent: Wednesday, February 26, 2020 7:32 PM
> To: Oswald <[hidden email]>; [hidden email]
> 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:[hidden email]] On Behalf Of Oswald
> Sent: Wednesday, February 26, 2020 7:21 PM
> To: [hidden email]
> 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
> > [hidden email]
> > https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
>


--
Pavel Zhukov
Software Engineer
IRC: landgraf

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
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:[hidden email]]
Sent: Tuesday, March 17, 2020 12:40 PM
To: Stephan Walter <[hidden email]>
Cc: Oswald <[hidden email]>; [hidden email]
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 <[hidden email]> 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' <[hidden email]>; Oswald
> <[hidden email]>; [hidden email]
> 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:[hidden email]] On Behalf Of
> Stephan Walter
> Sent: Wednesday, February 26, 2020 7:32 PM
> To: Oswald <[hidden email]>;
> [hidden email]
> 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:[hidden email]] On Behalf Of
> Oswald
> Sent: Wednesday, February 26, 2020 7:21 PM
> To: [hidden email]
> 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
> > [hidden email]
> > https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> 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
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users
>


--
Pavel Zhukov
Software Engineer
IRC: landgraf

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Thomas Markwalder
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:[hidden email]]
> Sent: Tuesday, March 17, 2020 12:40 PM
> To: Stephan Walter <[hidden email]>
> Cc: Oswald <[hidden email]>; [hidden email]
> 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 <[hidden email]> 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' <[hidden email]>; Oswald
>> <[hidden email]>; [hidden email]
>> 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:[hidden email]] On Behalf Of
>> Stephan Walter
>> Sent: Wednesday, February 26, 2020 7:32 PM
>> To: Oswald <[hidden email]>;
>> [hidden email]
>> 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:[hidden email]] On Behalf Of
>> Oswald
>> Sent: Wednesday, February 26, 2020 7:21 PM
>> To: [hidden email]
>> 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
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>> _______________________________________________
>> Kea-users mailing list
>> [hidden email]
>> 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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/kea-users
>> _______________________________________________
>> Kea-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
>
> --
> Pavel Zhukov
> Software Engineer
> IRC: landgraf
>
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
Dear Thomas,

That seems to be the behavior with kea 1.6, but with kea 1.1 we were able to assign a client class object to a specific client, so that we could use the same test parameter for all clients. This is no longer possible. The question is how to get the same behavior again?

I will attach an example with two nodes, so that it is clear what the problem is.

Best Regards,

Stephan Walter

{
    "Dhcp4": {
        "interfaces-config": {
            "interfaces": ["mvlprov"]
        },
        "control-socket": {
            "socket-type": "unix",
            "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
        },
        "lease-database": {
            "type": "memfile",
            "lfc-interval": 1800
        },
        "expired-leases-processing": {
            "reclaim-timer-wait-time": 10,
            "flush-reclaimed-timer-wait-time": 25,
            "hold-reclaimed-time": 3600,
            "max-reclaim-leases": 100,
            "max-reclaim-time": 250,
            "unwarned-reclaim-cycles": 5
        },
        "renew-timer": 900,
        "rebind-timer": 1800,
        "valid-lifetime": 3600,
        "option-data": [ ],
        "client-classes": [


    {
        "name": "INIT_intel01",
        "test": "substring(option[60].hex,0,4) == 'udhcp'",
        "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
    },

    {
        "name": "INIT_intel10",
        "test": "substring(option[60].hex,0,4) == 'udhcp'",
        "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
    },

    {
        "name": "INIT_intel11",
        "test": "substring(option[60].hex,0,4) == 'udhcp'",
        "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
    },

            {
                "name": "bios",
                "test": "option[93].hex == 0x0000",
                "boot-file-name": "/var/lib/tftp/bios/lpxelinux.0"
            },
            {
                "name": "ipxe_efi64",
                "test": "option[93].hex == 0x0007",
                "boot-file-name": "/var/lib/tftp/efi64/ipxe.efi"
            },
            {
                "name": "efi64",
                "test": "option[93].hex == 0x0009",
                "boot-file-name": "/var/lib/tftp/efi64/bootx64.efi"
            }
        ],
        "subnet4": [
            {
                "subnet": "10.10.0.0/16",

                "reservations": [
{ "hw-address": "A4:XX:01:29:YY:3E", "ip-address": "10.10.40.1", "next-server": "10.10.1.11", "hostname": "intel01", "client-classes": ["INIT_intel01"], "server-hostname": "10.10.1.21"},
{ "hw-address": "A4:XX:01:2D:YY:AC", "ip-address": "10.10.40.10", "next-server": "10.10.1.11", "hostname": "intel10", "client-classes": ["INIT_intel10"], "server-hostname": "10.10.1.21"},
{ "hw-address": "A4:xx:01:2D:YY:4C", "ip-address": "10.10.40.11", "next-server": "10.10.1.11", "hostname": "intel11", "client-classes": ["INIT_intel11"], "server-hostname": "10.10.1.21"},

                ]
            }
        ]
    },
    "DhcpDdns": {
        "ip-address": "127.0.0.1",
        "port": 53001,
        "tsig-keys": [],
        "forward-ddns" : {},
        "reverse-ddns" : {}
    },
    "Logging": {
         "loggers": [
             {
                 "name": "kea-dhcp4",
                 "output_options": [
                     {
                         "output": "stdout",
                         "flush": false
                     }
                 ],
                 "severity": "INFO",
                 "debuglevel": 0
             },
             {
                 "name": "kea-dhcp-ddns",
                 "output_options": [
                     {
                         "output": "stdout"
                     }
                 ],
                 "severity": "INFO",
                 "debuglevel": 0
             }
         ]
    }
}

So with this config we are able to provide during the first boot as boo-tfile-name the lpxe, ipxe or bootx files, while afterward we provide the node specific string defined within the client class. This is working, and we have to get the same mechanism with 1.6, but I don't know how we can provide within the reservation the necessary information, what we have to provide to the specific client within the second/third request. The node itself doesn't know anything about this settings. Only kea!


-----Original Message-----
From: Kea-users [mailto:[hidden email]] On Behalf Of Thomas Markwalder
Sent: Tuesday, March 17, 2020 2:49 PM
To: [hidden email]
Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6

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:[hidden email]]
> Sent: Tuesday, March 17, 2020 12:40 PM
> To: Stephan Walter <[hidden email]>
> Cc: Oswald <[hidden email]>;
> [hidden email]
> 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 <[hidden email]> 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' <[hidden email]>; Oswald
>> <[hidden email]>; [hidden email]
>> 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:[hidden email]] On Behalf Of
>> Stephan Walter
>> Sent: Wednesday, February 26, 2020 7:32 PM
>> To: Oswald <[hidden email]>;
>> [hidden email]
>> 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:[hidden email]] On Behalf Of
>> Oswald
>> Sent: Wednesday, February 26, 2020 7:21 PM
>> To: [hidden email]
>> 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
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>> _______________________________________________
>> Kea-users mailing list
>> [hidden email]
>> 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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/kea-users
>> _______________________________________________
>> Kea-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/kea-users
>>
>
> --
> Pavel Zhukov
> Software Engineer
> IRC: landgraf
>
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Stephan_Walter
Yes, they do.

-----Original Message-----
From: Thomas Markwalder [mailto:[hidden email]]
Sent: Tuesday, March 17, 2020 3:53 PM
To: Stephan Walter <[hidden email]>
Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6

Do your clients use the same MAC address throughout the boot process?


On 3/17/20 10:27 AM, Stephan Walter wrote:

> Dear Thomas,
>
> That seems to be the behavior with kea 1.6, but with kea 1.1 we were able to assign a client class object to a specific client, so that we could use the same test parameter for all clients. This is no longer possible. The question is how to get the same behavior again?
>
> I will attach an example with two nodes, so that it is clear what the problem is.
>
> Best Regards,
>
> Stephan Walter
>
> {
>      "Dhcp4": {
>          "interfaces-config": {
>              "interfaces": ["mvlprov"]
>          },
>          "control-socket": {
>              "socket-type": "unix",
>              "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
>          },
>          "lease-database": {
>              "type": "memfile",
>              "lfc-interval": 1800
>          },
>          "expired-leases-processing": {
>              "reclaim-timer-wait-time": 10,
>              "flush-reclaimed-timer-wait-time": 25,
>              "hold-reclaimed-time": 3600,
>              "max-reclaim-leases": 100,
>              "max-reclaim-time": 250,
>              "unwarned-reclaim-cycles": 5
>          },
>          "renew-timer": 900,
>          "rebind-timer": 1800,
>          "valid-lifetime": 3600,
>          "option-data": [ ],
>          "client-classes": [
>
>
>      {
>          "name": "INIT_intel01",
>          "test": "substring(option[60].hex,0,4) == 'udhcp'",
>          "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
>      },
>
>      {
>          "name": "INIT_intel10",
>          "test": "substring(option[60].hex,0,4) == 'udhcp'",
>          "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
>      },
>
>      {
>          "name": "INIT_intel11",
>          "test": "substring(option[60].hex,0,4) == 'udhcp'",
>          "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
>      },
>
>              {
>                  "name": "bios",
>                  "test": "option[93].hex == 0x0000",
>                  "boot-file-name": "/var/lib/tftp/bios/lpxelinux.0"
>              },
>              {
>                  "name": "ipxe_efi64",
>                  "test": "option[93].hex == 0x0007",
>                  "boot-file-name": "/var/lib/tftp/efi64/ipxe.efi"
>              },
>              {
>                  "name": "efi64",
>                  "test": "option[93].hex == 0x0009",
>                  "boot-file-name": "/var/lib/tftp/efi64/bootx64.efi"
>              }
>          ],
>          "subnet4": [
>              {
>                  "subnet": "10.10.0.0/16",
>
>                  "reservations": [
> { "hw-address": "A4:XX:01:29:YY:3E", "ip-address": "10.10.40.1",
> "next-server": "10.10.1.11", "hostname": "intel01", "client-classes":
> ["INIT_intel01"], "server-hostname": "10.10.1.21"}, { "hw-address":
> "A4:XX:01:2D:YY:AC", "ip-address": "10.10.40.10", "next-server":
> "10.10.1.11", "hostname": "intel10", "client-classes":
> ["INIT_intel10"], "server-hostname": "10.10.1.21"}, { "hw-address":
> "A4:xx:01:2D:YY:4C", "ip-address": "10.10.40.11", "next-server":
> "10.10.1.11", "hostname": "intel11", "client-classes":
> ["INIT_intel11"], "server-hostname": "10.10.1.21"},
>
>                  ]
>              }
>          ]
>      },
>      "DhcpDdns": {
>          "ip-address": "127.0.0.1",
>          "port": 53001,
>          "tsig-keys": [],
>          "forward-ddns" : {},
>          "reverse-ddns" : {}
>      },
>      "Logging": {
>           "loggers": [
>               {
>                   "name": "kea-dhcp4",
>                   "output_options": [
>                       {
>                           "output": "stdout",
>                           "flush": false
>                       }
>                   ],
>                   "severity": "INFO",
>                   "debuglevel": 0
>               },
>               {
>                   "name": "kea-dhcp-ddns",
>                   "output_options": [
>                       {
>                           "output": "stdout"
>                       }
>                   ],
>                   "severity": "INFO",
>                   "debuglevel": 0
>               }
>           ]
>      }
> }
>
> So with this config we are able to provide during the first boot as boo-tfile-name the lpxe, ipxe or bootx files, while afterward we provide the node specific string defined within the client class. This is working, and we have to get the same mechanism with 1.6, but I don't know how we can provide within the reservation the necessary information, what we have to provide to the specific client within the second/third request. The node itself doesn't know anything about this settings. Only kea!
>
>
> -----Original Message-----
> From: Kea-users [mailto:[hidden email]] On Behalf Of
> Thomas Markwalder
> Sent: Tuesday, March 17, 2020 2:49 PM
> To: [hidden email]
> Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6
>
> 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:[hidden email]]
>> Sent: Tuesday, March 17, 2020 12:40 PM
>> To: Stephan Walter <[hidden email]>
>> Cc: Oswald <[hidden email]>;
>> [hidden email]
>> 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 <[hidden email]> 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' <[hidden email]>; Oswald
>>> <[hidden email]>; [hidden email]
>>> 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:[hidden email]] On Behalf
>>> Of Stephan Walter
>>> Sent: Wednesday, February 26, 2020 7:32 PM
>>> To: Oswald <[hidden email]>;
>>> [hidden email]
>>> 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:[hidden email]] On Behalf
>>> Of Oswald
>>> Sent: Wednesday, February 26, 2020 7:21 PM
>>> To: [hidden email]
>>> 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
>>>> [hidden email]
>>>> https://lists.isc.org/mailman/listinfo/kea-users
>>> _______________________________________________
>>> Kea-users mailing list
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>>> _______________________________________________
>>> Kea-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>>>
>> --
>> Pavel Zhukov
>> Software Engineer
>> IRC: landgraf
>>
>> _______________________________________________
>> Kea-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users

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