在假期周末,我们的一位客户遭遇了停电。当一切恢复正常时,大多数设备似乎都正常,但有些设备(我们的一台 ESXi 主机和一些 VDI)无法获取正确的 IP 地址。它们从 Windows 获取了 169 APIPA。我查看了 DHCP 日志,从停电发生时起,租约或续订次数为 0。DHCP 好像整个周末都处于闲置状态。
我将其退回,突然之间,所有租约都开始涌入,所有获得 APIPA 的东西都获得了正常地址,一切都恢复正常。
我的问题是:DHCP 中是否存在某种设置导致其出现这种情况?我觉得硬中断不会破坏 DHCP,尤其是在重新启动时。
我想弄清楚发生了什么,以便如果再次发生停电,我们不会遇到同样的问题。
日志时间线:
11/25 晚上 11:15,服务器中断后启动:
00,11/25/20,23:12:23,Started,,,,,0,6,,,,,,,,,0
64,11/25/20,23:12:23,No static IP address bound to DHCP server,,,,,0,6,,,,,,,,,0
大约一小时后,设备开始丢失其地址:
24,11/26/20,00:00:19,Database Cleanup Begin,,,,,0,6,,,,,,,,,0
18,11/26/20,00:00:19,Expired,10.x.x.16,,,,0,6,,,,,,,,,0
18,11/26/20,00:00:19,Expired,10.x.x.18,,,,0,6,,,,,,,,,0
18,11/26/20,00:00:19,Expired,10.x.x.19,,,,0,6,,,,,,,,,0
etc...
几个小时后,这些条目开始被删除
24,11/26/20,03:12:24,Database Cleanup Begin,,,,,0,6,,,,,,,,,0
16,11/26/20,03:12:24,Deleted,10.x.x.16,,,,0,6,,,,,,,,,0
16,11/26/20,03:12:24,Deleted,10.x.x.18,,,,0,6,,,,,,,,,0
16,11/26/20,03:12:24,Deleted,10.x.x.19,,,,0,6,,,,,,,,,0
etc...
此后,除数据库清理之外没有任何活动:
24,11/26/20,21:12:29,Database Cleanup Begin,,,,,0,6,,,,,,,,,0
25,11/26/20,21:12:29,0 leases expired and 0 leases deleted,,,,,0,6,,,,,,,,,0
25,11/26/20,21:12:29,0 leases expired and 0 leases deleted,,,,,0,6,,,,,,,,,0
24,11/26/20,22:12:29,Database Cleanup Begin,,,,,0,6,,,,,,,,,0
etc... (until reboot)
今天,当我重新启动时,一切都开始再次获取地址
01,11/30/20,05:17:21,Stopped,,,,,0,6,,,,,,,,,0
00,11/30/20,05:17:26,Started,,,,,0,6,,,,,,,,,0
55,11/30/20,05:17:26,Authorized(servicing),,<redacted>.net,,,0,6,,,,,,,,,0
10,11/30/20,05:17:26,Assign,10.x.x.16,<redacted>
10,11/30/20,05:17:26,Assign,10.x.x.18,<redacted>
10,11/30/20,05:17:26,Assign,10.x.x.74,<redacted>
etc...
答案1
这不是对你问题的回答,因为我觉得没有足够的信息来真正确定发生了什么。
为了防止 DHCP 服务器出现问题,许多系统管理员倾向于为他们的服务器提供固定 IP 地址。话虽如此,我还是希望为尽可能多的设备提供 DHCP 租约,以便拥有一个 IP 地址信息的中央数据库。
对于笔记本电脑来说,较短的租约时间(例如 2-4 小时)是可以的。DHCP 客户端将在租约时间的一半(即 1-2 小时)后刷新其租约,这对于不在同一地点工作 8 小时的人来说是理想的选择。您也可以设置更长的租约时间,例如 8 小时。
但是,对于服务器和打印机,以及一般情况下的任何 DHCP 预留,您可以大大增加租约时间,因为它们无论如何都不会获得不同的 IP 地址。如果您将其设置为 30 天,它将在 15 天后要求续订,如果您的 DHCP 服务器停机超过 15 天,那么您遇到的问题会比您的其他服务器无法获得 IP 地址的问题更大。
答案2
我现在不认为这是“解决方案”,因为自从上次发生后,我们还没有看到另一次全面中断,但我们正在测试这样一种想法:(无论出于何种原因)当 DHCP 服务启动时,NIC 尚未完成启动。我们已将 DHCP 服务设置为延迟启动。
这是我们能想到的唯一可以解释这种奇怪行为的事情。
如果事实证明有效,我会更新它,但可能还需要一段时间,因为这种程度的中断并不经常发生。