来自 Ubuntu 18.04 上的 DHCP 客户端的错误 IP 地址

Question

我遇到了一个奇怪的问题，我的 Ubuntu 18.04（服务器）框在从 DHCP 服务器启动期间获得了错误的 IP 地址。在接口上启动后运行 dhclient 会导致将正确的 IP 添加到接口。

DHCP 服务器是一个 Windows 框，其中使用ip addrubuntu 中显示的 MAC 地址手动配置保留（不带冒号）：

5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:26:b9:82:44:27 brd ff:ff:ff:ff:ff:ff
    inet 10.10.11.162/23 brd 10.10.11.255 scope global dynamic eno4
       valid_lft 689861sec preferred_lft 689861sec
    inet6 fe80::226:b9ff:fe82:4427/64 scope link
       valid_lft forever preferred_lft forever

我的50-courtin-networking.cfg(cloud-init cfg)

network:
  version: 2
  ethernets:

    bcm:
      match:
        name: eno*
      dhcp4: true
      dhcp6: false

DHCP 的 Journalctl 条目：

#journalctl | grep -Ei 'dhcp'`
Jul 12 10:10:56 skprov2 systemd-networkd[1160]: eno1: DHCP lease lost
Jul 12 10:10:57 skprov2 systemd-networkd[1160]: eno4: DHCP lease lost
Jul 12 10:11:00 skprov2 systemd-networkd[1160]: eno1: DHCPv4 address 10.10.11.157/23 via 10.10.10.254
Jul 12 10:11:02 skprov2 systemd-networkd[1160]: eno4: DHCPv4 address 10.10.11.162/23 via 10.10.10.254

登录后手动调用 dhclient（详细）：

# dhclient -v eno4
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno4/00:26:b9:82:44:27
Sending on   LPF/eno4/00:26:b9:82:44:27
Sending on   Socket/fallback
DHCPREQUEST of 10.10.10.40 on eno4 to 255.255.255.255 port 67 (xid=0x4cb8a62d)
DHCPACK of 10.10.10.40 from 10.10.10.10
bound to 10.10.10.40 -- renewal in 294538 seconds.

10.10.10.10是正确的 DHCP 服务器，并且10.10.10.40是在其上配置的 IP。在 Windows DHCP 上，错误的租约 (.162) 显示一个长的“唯一 ID”，其中不包含 ubuntu 框上的任何 MAC 地址：032e827c00020000ab11d0fc617dced58a43

避免这种情况的正确方法是什么？拒绝长 UID 的租用？这个 UID 首先来自哪里？NIC 内置在 Dell PowerEdge R710 服务器中。

Answer 1

问题的原因是 Ubuntu 18.04 的内置网络配置不再使用 NIC Mac 地址作为 DHCP 请求的默认 id。

可以通过添加dhcp-identifier: mac到 /etc/netplan/xxx.yaml (cloud-init) 文件中的配置来恢复传统的（我相信“明智的”）行为 ，如下所示：

network:
    renderer: networkd
    version: 2
    ethernets:
        nicdevicename:
            dhcp4: true
            dhcp-identifier: mac

其中“nicdevicename”是您的网络设备的名称

用

sudo netplan apply

尝试新配置。如果您遇到任何错误，请注意精确缩进在 .yaml 文件中非常重要。

Answer 2

拒绝租约是行不通的。网络无法知道为什么它被拒绝，因此如果您这样做，它不会神奇地切换到不同的 ID 类型。您必须手动执行此操作。

如果您的 systemd 版本足够新，并且您可以直接控制由 cloud-init 写出的配置文件，您可以告诉 systemd-networkd 通过该*.network文件发送基于 MAC 地址的客户端 ID ：

[DHCP]
ClientIdentifier=mac

但是，如果您知道 systemd-networkd 将始终被使用，您只需将正确的租约分配给 client ID 032e827c00020000ab11d0fc617dced58a43，因为这就是 systemd-networkd 将始终为该机器发送的内容。（它根据 生成 ID /etc/machine-id。）

Mos DHCP 客户端，包括 dhclient，提供类型为“01”（基于 MAC）的客户端 ID 字段。另一种常见类型是“00”（域名）。然而，默认情况下，systemd-networkd 提供一个“不透明”的客户端 ID，它是从 /etc/machine-id 的内容生成的。

根据 DHCP 协议，租用首先由客户端 ID 选择（只要客户端提供“客户端 ID”选项，该选项可能基于也可能不基于 MAC），然后仅在客户端没有时才通过 MAC 地址选择发送身份证。

因此，当您配置保留时，所有良好的 DHCP 服务器都将允许您输入客户端 ID或MAC 地址。如果您只输入 MAC 地址，那么我想会自动隐含类型为“01”（基于 MAC）的客户端 ID。可能有一个名为“忽略客户端 ID”的复选框，这对您来说很方便，但在技术上违反了 DHCP 规范。

（例如，我有两个具有不同 MAC 的 Wi-Fi 适配器，但我已将操作系统配置为无论连接哪个适配器都发送相同的客户端 ID。这样我就可以通过两者获得相同的地址。）

Answer 3

在 vSphere 上，值得注意的是，如果模板包含计算机 ID，则从该模板克隆的任何虚拟机都会获得与 DHCP 相同的 IP，并使用计算机 ID，而不是 MAC 地址。解决方案是从模板中的文件 /etc/machine-id 中删除 machine-id，以便在克隆过程中生成新的 machine-id。

echo -n > /etc/machine-id