一个网络上可以有多个DHCP服务器吗?


84

这是关于冗余DHCP服务器的规范问题

同一局域网上是否可以有多个DHCP服务器?这样做的含义是什么?

  1. 如果有多个DHCP服务器可用怎么办?我的客户如何知道要使用哪个客户?
  2. 如何让DHCP服务器为多个子网/网段提供地址?
  3. 如何配置多个DHCP服务器为同一子网提供地址。

1
该问题背后的想法是为所有“使我如何拥有一个以上的DHCP服务器”问题给出一个明确的答案,这些问题使我们的普通用户发疯。希望这将成为我们的规范答案之一(meta.serverfault.com/questions/1986/...
罗布·莫伊尔

2
RTFM?tools.ietf.org/html/draft-ietf-dhc-failover-12#section-5.3(和RFC 3074)已经定义了此行为,而Linux dhcpd则实现了此操作manpages.ubuntu.com/manpages/precise/en/man5/ …
Dani_l 2014年

2
@Dani_l也许您应该点击问题中的“规范问题”链接,并在告诉我需要RTFM之前,在这里查看我问题的答案的作者。
罗伯·摩尔

2
我不是要您阅读手册。我只是指出有手册。这个问题是规范的,但在适用的情况下,我认为它应该包括对“官方”程序的引用,如果存在的话。在这种情况下,存在一个IETF / RFC,而且它是正式的。
Dani_l 2014年

Answers:


95

我假设基本的知识是DHCP的作用以及如何在此答案中配置您选择的DHCP服务器,但是在我们讨论同一网络上的多个DHCP服务器之前,首先让我们快速回顾一下客户端如何接收IP地址从DHCP最基本的级别。

简单网络上的DHCP使用DORA原理工作。

  • 发现-客户端在与其连接的本地网段上广播消息,以发现可用的DHCP服务器。

  • 提供-适当配置的DHCP服务器接收来自客户端的请求,并从其可用地址池中为其提供地址。

  • 请求-客户答复要约,请求要约中收到的地址。

  • 确认-服务器确认请求,将地址标记为在其地址池中使用,并通知客户端该地址租约有效的时间以及所需的任何其他信息。

网段中的任何设备都可以是DHCP服务器。它不必是路由器,域控制器或网络上的任何其他“特殊”设备。

当您网络上的设备首次请求IP地址或达到其租约期满时(或您强迫它们检查其租约仍然有效),它们只会广播对DHCP服务器的请求,并会接受一个DHCP服务器的报价。DHCP服务器回复。记住这一点很重要,因为我们在下面查看多个DHCP服务器的选项。

多个DHCP服务器PT 1:跨越多个子网。

如果您有几个划分为不同子网的VLAN或物理网段,并且想为所有这些子网中的设备提供DHCP服务,则有两种方法可以实现。

  1. 如果分隔它们的路由器/第3层交换机可以充当BOOTP / DHCP中继代理,那么您可以继续将所有DHCP服务器保留在网络的一个或两个中央部分,并将DHCP服务器配置为支持多个地址范围。为了支持此功能,您的路由器或第3层交换机必须支持RFC 1542的第4节中涵盖的BOOTP中继代理规范。

  2. 如果您的路由器不支持RFC 1542 BOOTP中继代理,或者某些网段在地理位置上分散在慢速链路上,那么您将需要在每个子网中放置一个或多个DHCP服务器。此“本地” DHCP服务器将仅满足其自己的本地网段的要求,并且它与其他DHCP服务器之间没有交互。如果这是您想要的,则只需将每个DHCP服务器配置为独立服务器,并为其自己的子网提供地址池的详细信息,而不必担心网络其他部分上的任何其他DHCP服务器。这是在同一网络上具有多个DHCP服务器的最基本示例。

多个DHCP服务器PT 2:服务于同一网段的DHCP服务器。

当大多数人询问“同一网络上的多个DHCP服务器”时,他们通常会问的是:他们希望不止一台DHCP服务器向客户端发出相同范围的网络地址,以在多台服务器之间分配负载,或者在一台服务器脱机时提供冗余。

这是完全有可能的,尽管它需要一些思考和计划。

从“网络流量”的角度来看,此答案开头概述的DORA流程说明了在一个网段中可以有多于一个DHCP服务器。客户端只是广播发现请求,而第一个响应要约的DHCP服务器就是“获胜者”。

从服务器的角度来看,每台服务器都有一个可发布给客户端的地址池,已知其地址范围。服务于同一子网的DHCP服务器不应具有单个“共享”范围,而应具有“拆分”范围。

换句话说,如果要发送给客户端的DHCP地址范围从192.168.1.100到192.168.1.200,则两个服务器都应配置为服务于该范围的单独部分,因此第一台服务器可能会使用该范围的一部分192.168.1.100到192.168.1.150,第二台服务器将发布192.168.1.151到192.168.1.200。

拆分DHCP作用域,显示排除项

Microsoft最新的DHCP实现中有一个向导可以像这样轻松地拆分您的范围,这在Technet文章中进行了描述,即使您不使用Microsoft DHCP实现,也可能值得一看,因为它说明了所讨论的原理在这里很好,这个答案已经足够长了。

划分范围–最佳做法

您将听到的作为最佳实践的一件事是拆分DHCP作用域的80/20规则,这意味着一台服务器将为该作用域提供80%的地址,而另一台DHCP服务器将“保留”为有效将投放20%的地址。

拆分地址80/20的想法是,因为希望80%的可用地址应该足以满足子网中所有所需的地址,并且DHCP租期通常为数天。因此,如果您的主DHCP服务器宕机了几个小时,则该子网上的20%以上的计算机不太可能需要在停机期间更新其地址,从而使20%的地址池足够。

这仍然是合理的建议,但是它假设两件事:

  1. 您可以足够快地解决“主” DHCP服务器的任何问题,从而避免耗尽备用DHCP服务器上的一小部分地址。
  2. 您对负载平衡不感兴趣。

这些天(从我的示例中可以看到),我倾向于50/50的分割,我认为这是对上述几点的更现实的回答。

在DHCP服务器上创建范围时,要考虑的另一件事是将整个范围配置到每个服务器中,并排除其他DHCP服务器给出的范围。这具有“自动记录”每个DHCP服务器上整个子网的DHCP信息的优势,这将提高其他任何试图了解正在发生的情况的人的清晰度,并且在您的其中一个DHCP服务器处于脱机状态时,一段时间后,您可以临时在另一台服务器上重新配置排除范围,以允许其获取空闲时间。

结合这些想法

最后,值得记住的是,您可以结合上面讨论的原理-您可以将所有DHCP服务器放置到一个或多个“中央服务器” VLAN中,并在所有路由器上使用BOOTP中继代理来发送来自非常大且分段的所有DHCP请求网络到集中式DHCP服务(这是我的工作,请参阅下文)。或者,您可以在整个网络中分布DHCP服务器,在其本地子网中具有“主” DHCP服务器,而在“附近”网段中具有“保留” DHCP服务器,从而提供少量地址作为备份-您甚至可以拥有他们自己的网段中的两个DHCP服务器配置为彼此提供80/20的地址范围。最明智的选择取决于您的物理和逻辑网络如何相互映射。

为分割范围提供服务的DHCP服务器到多个子网


3
如果划分范围:请记住,应在两个部分上都设置DHCP保留。如果您需要经常进行更新,则保持同步非常麻烦。
Tonny 2012年

4
您能否详细说明确保主DHCP服务器正在运行时不击中备用DHCP服务器的技术?据我了解,如果从任何一台服务器获得响应的可能性均等,则一旦租约的总数超过预留池大小的两倍,备用服务器就会统计出地址不足。当主DHCP服务器关闭时,这可能会使备用服务器对新客户端毫无价值。
Niels B.

3
@NielsB。如果您正在执行类似80/20拆分的操作,则可以设置备用服务器的响应延迟(blogs.technet.com/b/teamdhcp/archive/2009/01/22/…)。我自己也不用打扰,因为我自己使用了50/50分割,但是它可以工作。
罗伯·摩尔

13

几年前,我对中小型(500个用户)网络采用了这种方法,并获得了很多好处。DHCP不再是单点故障。通过永久地关联MAC和IP地址,我们确保两个DHCP服务器对每个DHCP请求给出相同的响应。知道每个网络资产的IP地址也可以简化网络管理,并且DNS可以在同一数据库上运行。该系统使用Internet Software Corporation的BIND和DNS,并且相关的脚本可以从以下网址下载:https://web.archive.org/web/20121031051901/http://www.pearbright.com/index.php/download/25- dns-dhcp-download

另一种选择是使用真正的ISC DHCPD故障转移:https ://kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html


2
OP专门要求对此问题提供解释性答案。您可能需要修改答案以扩大答案。
布伦特·帕布斯特

3
稍后,虽然这个答案很短,并且我永远都不会拒绝规范问答集中的更多细节,但是我认为它很好,因为它提到了进行DHCP冗余的方法略有不同。
罗伯·摩尔

1
@DJ Pon3我同意:我运行与大型多站点DHCP(尽管VLAN较少)类似的设置,并且对其中的3/4 VLAN使用与Peter Talbot相同的方法。
Tonny 2012年

1
现在链接已断开:(
谢尔盖·弗拉索夫
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.