我有 2 个使用 dhcpcd 守护进程的 rbpi。第二个使用第一个的克隆映像。
在检测到 DHCP 问题（它们无缘无故长时间断开连接）后，我决定使用 tcpdump 来查明发生了什么。结果发现两者都在 DHCP 请求中发送了 rbpi1 的 MAC 地址，考虑到 rbpi2 使用的是克隆映像，这在某种程度上是有道理的。
因此，我删除了 /var/lib/dhcpcd5 上的文件，以强制守护进程创建新的 duid，重新加载 systemd 守护进程并强制重启系统。但问题仍然存在。
另一方面，我不知道为什么，但 rbpi2 不知何故赢得了“MAC 之战”，并且很少失去连接（这一定与网络拓扑或 DHCP 路由器的缓存有关）。这就是为什么我再次检查文件 /var/lib/dhcpcd5/duid，现在 ID 基于此 rbpi 的 MAC，这是理所当然的。事实上，无论 DHCP 请求如何，发送的每个数据包都使用 rbpi2 的 MAC 地址，这是理所当然的。
为什么 dhcpcd 仍在使用这个旧的 MAC 地址？它从何而来？我找不到任何其他存储此地址的缓存/配置文件。事实上，我用十六进制编辑器打开了 /var/lib/dhcpcd5/eth0.lease，存储在那里的 MAC 是正确的（它是 rbpi2 的 MAC）。
答案1
检查您的交换机。遇到过类似的问题。重启后，交换机问题解决。