So when booting a guest from PXE, it's ipxe sending the DHCP requests, while during normal boot, it's the guest's DHCP client sending requests. So IIUC, you're complaining that the two requests do not use the same form of client identification. Well, I'm afraid libvirt can't fix anything here. Moving to ipxe for further analysis.

If Jiri's analysis in comment 1 is correct, then doesn't this problem also happen on bare metal hardware?  Why is it valid to assume that both clients, from different levels of the software stack will use the same identifier?

I have not seen this problem happen on bare metal, and am using both bare metal with 6.6 and 7.0 and KVM virtualization on top of 7.0 running 6.6 and 7.0 guests. I'm also using VMware Fusion 7.0, Parallels 9 and VirtualBox 10 on top of Mac OS X 10, and VMware Workstation 11 on top of Windows 8.1, all running 6.6 and 7.0 guests. In most such cases, I'm sending DHCP requests to my Cisco 3560 switch which is acting as DHCP server. In some cases (NAT inside VMware, I'm using the built-in VMware DHCP server with DHCP reservations.

In ALL such cases, I get the same type of request for a client for both PXE boot and the normal boot which follows it. My Linux VMs or hardware like GigaByte BRIX where I'm running Linux on bare metal almost exclusively use hardware-address. Many Wireless APs, AppleTVs, Windows VMs, Macs, Windows laptops use client-identifier. 

In no other case than this one does the type change between PXE boot and normal boot. I have only seen this happen when using PXE boot within libvirt to boot a new Linux VM, where during PXE boot I get the client-identifier, then when PXE boot is done and the host reboots, I then get the normal hardware-address. Cisco routers can not handle both types of identifier - I can have one or the other. Until this is fixed, it creates a real problem for me, in that I have to manually switch the config to client-identifier before PXE boot, then back after PXE boot. This is find for the cloud computing testing I'm doing, but would be unacceptable at scale.

I think your comment "Why is it valid..." comes across as flippant at best. We don't live in "bizarro world" - when I drive down the street, I expect every red light to work the same way. I expect the controls on every instance of the same made/model/year of car to behave identically, even if I expect slight differences between different models. You're trying to shift the burden of proof as to why this behavior is incorrect to me - I'm just the reporter. And as a 30-year systems architect, I think 99%+ of users would expect the same identifier type to be requested from the same host regardless of how it boots, as anything else would create massive pain and confusion and interoperability problems over time. And, as pointed out above, I challenge you to find another case other than this where they're different - this shouldn't be allowed to exist as the only exception.

I think it's easiest for the libVirt implementation of PXE boot for KVM hosts to use the hardware-address, as this is what is offered for bare metal linux hosts, and what is offered for KVM hosts booting outside of PXE. 

What's there now may have been put there to better support Windows guests - so the best solution is probably to have some additional attribute within the interface/mac section of the XML, such as:

    <interface type='bridge'>
      <mac address='00:50:56:01:23:45' type='hardware-address'/>
      <source bridge='br14'/>
      <target dev='appserver01'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Or, this might be on the os/boot section, such as:

  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
    <boot dev='hd'/>
    <boot dev='network' type='hardware-address'/>
  </os>

Or, to have logic which uses the os/type machine field to automatically snd the type of identifier which the guest OS normally sends (i.e. client-identifier for Windows or Mac, hardware-address for Linux)

I just don't think it's correct as currently implemented, with no way (I'm aware of) to override and get a consistent identifier during PXE and normal boot phases.

I apologize if my reply seemed flippant, the problem is that we use a mostly unmodified version of iPXE for the guest, which is the same as used by a number of hardware vendors for their PXE boot ROM.  Therefore if there's a mismatch, I expect we're not alone in seeing it.  The iPXE ROM is also completely unaware of the guest OS to be booted and there is no mechanism in the current code to pass options from QEMU into iPXE.

In my PXE environment, I use dnsmasq and pxelinux to network boot my bare metal and VM systems.  In that setup I also use an "01" prefix as documented in by pxelinux:

http://www.syslinux.org/wiki/index.php/PXELINUX#Configuration

Here the prefix is indicated to be the ARP type code where 01 indicates Ethernet.  Is this the same as the client-identifier you're seeing?

Here's what I see in three different scenarios:

a) iPXE DHCP boot request:

19:15:10.373627 IP (tos 0x0, ttl 64, id 512, offset 0, flags [none], proto UDP (17), length 423)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:4b:3a:6c, length 395, xid 0x63b2361b, secs 8, Flags [none] (0x0000)
	  Client-Ethernet-Address 52:54:00:4b:3a:6c
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 1472
	    ARCH Option 93, length 2: 0
	    NDI Option 94, length 3: 1.2.1
	    Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
	    CLASS Option 77, length 4: "iPXE"
	    Parameter-Request Option 55, length 21: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, LOG
	      Hostname, Domain-Name, RP, Vendor-Option
	      Vendor-Class, TFTP, BF, Option 128
	      Option 129, Option 130, Option 131, Option 132
	      Option 133, Option 134, Option 135, Option 175
	      Option 203
	    T175 Option 175, length 45: 177.5.1.16.236.129.57.24.1.1.34.1.1.25.1.1.33.1.1.235.3.1.0.0.17.1.1.19.1.1.23.1.1.21.1.1.39.1.1.16.1.2.18.1.1
	    Client-ID Option 61, length 7: ether 52:54:00:4b:3a:6c
	    GUID Option 97, length 17: 0.14.243.82.69.27.232.111.69.133.32.61.199.124.155.71.182
	0x0000:  4500 01a7 0200 0000 4011 7747 0000 0000
	0x0010:  ffff ffff 0044 0043 0193 a01a 0101 0600
	0x0020:  63b2 361b 0008 0000 0000 0000 0000 0000
	0x0030:  0000 0000 0000 0000 5254 004b 3a6c 0000
	0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0070:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0080:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0090:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0100:  0000 0000 0000 0000 6382 5363 3501 0139
	0x0110:  0205 c05d 0200 005e 0301 0201 3c20 5058
	0x0120:  4543 6c69 656e 743a 4172 6368 3a30 3030
	0x0130:  3030 3a55 4e44 493a 3030 3230 3031 4d04
	0x0140:  6950 5845 3715 0103 0607 0c0f 112b 3c42
	0x0150:  4380 8182 8384 8586 87af cbaf 2db1 0501
	0x0160:  10ec 8139 1801 0122 0101 1901 0121 0101
	0x0170:  eb03 0100 0011 0101 1301 0117 0101 1501
	0x0180:  0127 0101 1001 0212 0101 3d07 0152 5400
	0x0190:  4b3a 6c61 1100 0ef3 5245 1be8 6f45 8520
	0x01a0:  3dc7 7c9b 47b6 ff

b) Install DHCP request from anaconda:

19:33:23.614228 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 329)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:4b:3a:6c, length 301, xid 0x495be20e, Flags [none] (0x0000)
	  Client-Ethernet-Address 52:54:00:4b:3a:6c
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Parameter-Request Option 55, length 10: 
	      Subnet-Mask, BR, Time-Zone, Default-Gateway
	      Domain-Name, Domain-Name-Server, Option 119, Hostname
	      RP, MTU
	    Vendor-Class Option 60, length 43: "anaconda-Linux 3.10.0-123.el7.x86_64 x86_64"
	0x0000:  4510 0149 0000 0000 8011 3995 0000 0000
	0x0010:  ffff ffff 0044 0043 0135 906e 0101 0600
	0x0020:  495b e20e 0000 0000 0000 0000 0000 0000
	0x0030:  0000 0000 0000 0000 5254 004b 3a6c 0000
	0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0070:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0080:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0090:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0100:  0000 0000 0000 0000 6382 5363 3501 0137
	0x0110:  0a01 1c02 030f 0677 0c11 1a3c 2b61 6e61
	0x0120:  636f 6e64 612d 4c69 6e75 7820 332e 3130
	0x0130:  2e30 2d31 3233 2e65 6c37 2e78 3836 5f36
	0x0140:  3420 7838 365f 3634 ff

c) Installed system DHCP request (different VM, different MAC)

19:37:26.049649 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:70:a9:c8, length 300, xid 0x3a2bf10d, Flags [none] (0x0000)
	  Client-Ethernet-Address 52:54:00:70:a9:c8
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Requested-IP Option 50, length 4: 192.168.1.236
	    Parameter-Request Option 55, length 18: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Static-Route
	      Option 252, NTP
	0x0000:  4510 0148 0000 0000 8011 3996 0000 0000
	0x0010:  ffff ffff 0044 0043 0134 08cc 0101 0600
	0x0020:  3a2b f10d 0000 0000 0000 0000 0000 0000
	0x0030:  0000 0000 0000 0000 5254 0070 a9c8 0000
	0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0070:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0080:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0090:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0100:  0000 0000 0000 0000 6382 5363 3501 0332
	0x0110:  04c0 a801 ec37 1201 1c02 790f 060c 2829
	0x0120:  2a1a 7703 79f9 21fc 2aff 0000 0000 0000
	0x0130:  0000 0000 0000 0000 0000 0000 0000 0000
	0x0140:  0000 0000 0000 0000

We can see that a) is the only one that sends a Client-ID by default.  The raw part of the dump maybe shows the 01 embedded there at offset 0x18c.  All of the requests of course include the Client-Ethernet-Address and it matches the MAC of the NIC, so I'm confused why this isn't the default option you're using in the server configuration or if you've tried, why it doesn't work.

If we look at RFC2132 (https://www.ietf.org/rfc/rfc2132.txt) we get this definition for option 61, identified above as Client-ID:

9.14. Client-identifier

   This option is used by DHCP clients to specify their unique
   identifier.  DHCP servers use this value to index their database of
   address bindings.  This value is expected to be unique for all
   clients in an administrative domain.

   Identifiers SHOULD be treated as opaque objects by DHCP servers.

   The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
   hardware type of 0 (zero) should be used when the value field
   contains an identifier other than a hardware address (e.g. a fully
   qualified domain name).

   For correct identification of clients, each client's client-
   identifier MUST be unique among the client-identifiers used on the
   subnet to which the client is attached.  Vendors and system
   administrators are responsible for choosing client-identifiers that
   meet this requirement for uniqueness.

   The code for this option is 61, and its minimum length is 2.

   Code   Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

So this does seem to match offset 0x18a in a) as well as the pxelinux information above where 01 is Ethernet (http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2).  The iPXE boot request is therefore following the recommendation of the RFC for the client-identifier, which explains why it's different from the hardware-address, but it's still an optional part of the request.

The OS level DHCP client, dhclient, does have support for sending a client-identifier.  Documentation for this exists in the dhclient.conf man page.  In the most simple case, creating a /etc/dhcp/dhclient.conf file with an entry:

send dhcp-client-identifier 01:52:54:00:70:a9:c8;

will cause the OS level DHCP client to also send this optional field.  The man page indicates how this can be configured to use different configuration stanzas per interface.

If there's still an issue, can you provide logs or other information that indicate why Client-Ethernet-Address is not a viable option for you?  Is it a limitation of the Cisco DHCP server that it's unable to use the hardware-address in the presence of a client-identifier?  As I indicate, we don't have a mechanism to configure the iPXE DHCP client from the hypervisor or the VM, it's loaded as a PCI option ROM just as it would be loaded on bare metal hardware.  Removing the client-identifier would therefore potentially require multiple ROMs or a configuration interface to be enabled in the ROM client.  Thanks.

Michael, does the information in the previous comment provide you with a solution?

Sorry for the late response. Busy at work, plus I switched how I was bootstrapping my KVM guests to no longer go through the PXE boot process based on earlier comments here where I thought this would not likely be solved in a way which would work with Cisco equipment. Basically using virt-install with --initrd-inject to add a kickstart which can be reached as a local file.

I don't have the time now to really walk through your comprehensive but complex response to fully understand how this might address the problem. From a quick read, it seems you're arguing that this is how the RFC indicates it will work, and I'm still left with wondering how can two sets of code that should be using the PXE protocol to obtain the same information provide different identifiers, but you can still call both correct behavior?

No matter how much support you provide for this behavior, it looks and acts broken to me when I can't use PXE boot from within libvirt to install an OS with a kickstart on a guest, then boot the same guest via DHCP once the install is done.

Since I've found a way to no longer be blocked by this behavior, I don't have the time to go into the minutia of the solution - I'm OK with any way you want to make this work, as long as it't transparent to me, and "just works as I'd intuitively expect it to work" (without having to dig deep into the RFCs and protocols to understand what's going on). 

To answer your last question: "Is it a limitation of the Cisco DHCP server that it's unable to use the hardware-address in the presence of a client-identifier?" AFAIK, yes, I'm not able to specify both for a DHCP reservation. So, to use PXE boot for the OS install, i had to specify the client-identifier as the PXE boot process presented ONLY the client-identifer, and I could boot the OS and install with the kickstart. But, once the boot finished, when the host rebooted, it could not get an address as then the normal boot process presented ONLY the hardware-address. The reason I think presenting the client-identifier is incorrect, was simply by comparing the behavior of my virtual hosts with those of my physical hosts. With the physical hosts, the host presents the hardware-address during both PXE boot and the normal boot which follows, at least for the hardware I'm using (i.e. Linux servers such as GigaByte BRIX). There is other hardware, such as mac, windows laptop, printers, Apple Wireless, which present the client-identifier. To get Cisco DHCP reservations working, I always have to try client-identifier or hardware-address to see which one works, one always does. This problem is the first time one or the other doesn't work all the time, as each only works during a certain phase, PXE or normal DHCP boot, and I can't go in and modify my Cisco configuration before and after I re-PXE a host.

Again, I don't know which party is doing something wrong here, I'm just pointing out that this situation is ridiculous - the integration doesn't work as it exists currently. I don't know who's responsible for fixing this, but I can certainly see that it's a mess unlikely to be fixed soon, and I'm glad this problem no longer affects me.

Please don't request additional information from me on this - you can close this if you want, but I won't consider this problem solved unless there's some way to have a virtual guest consistently use either hardware-address OR client-identifier during both PXE and normal DHCP boot. If there's some way to change what the normal DHCP process sends, which can be set by the kickstart in a post script, so that the host doesn't switch methods when it reboots at the end of the kickstart process, that's acceptable, just needs to be documented.

Moving this to dhcp, the issue is not with iPXE, but with the incompatibility that the ROM-based PXE client uses a client-identifier, but the OS-based DHCP client does not.  Certain broken hardware like the Cisco switch discussed in the bz appear to ignore the hardware-address when a client-identifier is provided, presenting conflicting requirements between the various clients.

It appears to be possible to make dhclient include a client-identifier in the request, presumably NM can be made to do the same.  I believe the remaining request from the reporter is to provide kickstart documentation and examples for customers in such environments to automatically enable client-identifier support.

(In reply to Alex Williamson from comment #8)
> Certain broken hardware like the Cisco
> switch discussed in the bz appear to ignore the hardware-address when a
> client-identifier is provided

I wouldn't call it broken per se, but for example ISC DHCP server works OK in this case.

> It appears to be possible to make dhclient include a client-identifier in
> the request, presumably NM can be made to do the same.

As noticed in comment #0, there's a bug #560361 (Fedora) where I had already experimented with sending client-identifier the same way ROM-based PXE client does, i.e. by adding
send dhcp-client-identifier = hardware;
into /etc/dhcp/dhclient.conf
but it turned out that it breaks IPoIB (which requires specific client-identifier format - RFC4361 compatible)

> I believe the
> remaining request from the reporter is to provide kickstart documentation
> and examples for customers in such environments to automatically enable
> client-identifier support.

Truly said, I have no idea where such documentation resides - anybody ?

I sort of lost track of this, just noticed the latest response.

Three things:

1. It's amazing to me that this problem continues to exist without a fix, given that I've not only hit it in this rather specific physical/virtual use case, but also recently when setting up year old high-end HP servers using DHCP on a Cisco 6509 Enterprise-class switch: I could PXE boot, where HP hardware sends client-identifier, and with the switch configured to expect it, I'd get to the PXE server and start Anaconda. But then once that hit the Anaconda installer, it would again request a DHCP address, this time sending hardware-address, so I would not get the same address used to PXE boot. While I did test adding "send dhcp-client-identifier = hardware;" to /etc/dhcp/dhclient.conf, this would fix the behavior only after the reboot at the end of Anaconda - DHCP was still sending a different value and getting a different address while Anaconda was running.

My point here is that this affects new hardware running against large commercial Cisco switches - it's not some edge case.

2. It's additionally amazing to me that Cisco's DHCP implementation is dismissed as "broken" - true or not, like that means this issue can't be fixed by any method on RedHat's side, and Cisco needs to do something to fix this or customers are SOL. That comment shows a shocking lack of real-world pragmatism - I can't in a million years imagine Microsoft accepting that as a reason to do nothing. They'd find some way to make this work, because - uh, hey, isn't Cisco the largest and most commonly deployed network gear in large corporations? You think that would justify bending the rules, or at least figuring out why Windows seems to work just fine with these switches so what's special about Linux that it can't work there too?

At least with some boot parameter which allows those of us who have hit this problem to ask for it to work, through PXE, anaconda boot, and after the installer reboots. 

3. Last one, it wasn't until I hit this problem again last week with relatively new HP hardware that I looked into this more, and although I'm no expert, it seems like a system using DHCP is SUPPOSED to send the client-identifier, and a system using BOOTP is supposed to send the hardware-address. But, in the RedHat implementation of DHCP, documented in the kickstart, and in /etc/sysconfig/network-scripts, it notes that there's no difference between BOOTPROTO=DHCP and =BOOTP - they're treated the same. This seems to me to be the root of the problem. They should not be treated the same, based on my limited understanding. It seems Linux is sending hardware-address at all times, when BOOTPROTO=DHCP, when it should only send that if BOOTPROTO=BOOTP, and it should send client-identifier when BOOTPROTO=DHCP. That seems to be the behavior that Cisco expects, and we have no way to make that happen.

Before those with the power to fix this dismiss this problem with "Cisco is broken", I'd like to see why my last point does not apply here - why are BOOTP and DHCP sending the same value, when it seems they should not be?

(In reply to Michael Crawford from comment #11)
> it seems like a system using DHCP is SUPPOSED to send the
> client-identifier, and a system using BOOTP is supposed to send the
> hardware-address.

I agree with the BOOTP part because AFAIK there's no client-identifier in BOOTP, but I can't agree that DHCP is supposed to send client-identifier.
It's up to dhcp client whether and how formed (the only requirement is that it needs to be unique) client-identifier it sends.

> But, in the RedHat implementation of DHCP, documented in
> the kickstart, and in /etc/sysconfig/network-scripts, it notes that there's
> no difference between BOOTPROTO=DHCP and =BOOTP - they're treated the same.

Because it basically is the same, bootp is predecessor and subset of dhcp.
I think the 'bootp' value in networks-scripts has been there only from historical reasons and yes, it equals 'dhcp', because we don't have any special bootp client.

> This seems to me to be the root of the problem. They should not be treated
> the same, based on my limited understanding. It seems Linux is sending
> hardware-address at all times, when BOOTPROTO=DHCP, when it should only send
> that if BOOTPROTO=BOOTP, and it should send client-identifier when
> BOOTPROTO=DHCP.

With all due respect, bootp and dhcp are considered synonyms nowadays and I don't think it's related to (not) sending client-identifier.

> Before those with the power to fix this dismiss this problem with "Cisco is
> broken"

If you read my previous comment you'll see that I don't consider it broken.

> I'd like to see why my last point does not apply here - why are
> BOOTP and DHCP sending the same value, when it seems they should not be?

see above

Hi,

could you please describe the status quo of client-identifier in RHEL and Fedora and especially conflicts of each configuration. I would like to know advantages and disadvantages of each configuration and the relation between boot/install/run configurations as well.

Also how is the cisco equipment different that it requires different approach. I will be glad for any clarification.

Cheers,

Pavel

Replying to Pavel's private :-) comment

RHEL: dhclient does not send any client-identifier, user has to put 'send dhcp-client-identifier' statement into /etc/dhcp/dhclient.conf to send one.
In this case dhcp server (or other agents) identify client according to the chaddr field of DHCP packet.

Fedora: On Fedora 24 it's the other way round, i.e. dhclient by default sends a client-identifier option with DUID-UUID (per RFC 4361 and RFC 6355).
If user does not want to send it, he needs to put a
send dhcp-client-identifier = "";
into /etc/dhcp/dhclient.conf
Previously I was trying also other ways, like sending client-id based on LL or LLT, see bug #1154200, comment #25 for summary.

Some servers/switches have issues with clients who send client-identifier based on something else then LL only (like DUID-LLT or DUID-UUID), see
bug #1154200 or
bug #1357469 or
https://fedoraproject.org/wiki/Common_F21_bugs#IP_address_discovery_via_DHCP_does_not_work
I think this ticket is the same case.

Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

This bug has been reviewed by Support and Engineering representative and does not meet the inclusion criteria for Maintenance Support 1 Phase. If this issue still exists in newer major version of Red Hat Enterprise Linux, it has been cloned there and work will continue in the cloned bug.

For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata/

Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto