摘 要：
关键词：
中图分类号：TP39 文献标识码：A 文章编号：
1. 研究DHCP服务冗余的必要性
随着互联网的普及，人们的工作、学习和生活与网络之间的联系越来越紧密，搭建了许多不同的网络，如企业网、校园网和公众网等。由于采用DHCP(Dynamic Host Configuration Protocal，动态主机设置协议)技术动态地为主机配置参数,可以有效解决目前IP地址资源不足和无线网络用户的移动性等问题，并能极大地减轻大型网络管理员的工作量，减少手工网络配置的错误，有利于快速地搭建一个大型网络或修改其网络配置。因此，网络配置中越来越多地使用了DHCP服务器及技术，随着网络应用的普及和深入，该技术的应用范围会愈来愈广。但是，采用了DHCP技术的企业网、校园网、公众网等的大型企业、院校、ISP(Internet Service Provider，网络接入提供商)也同样面临着DHCP技术带来的安全性问题。网络中如果应用DHCP服务器，就要考虑DHCP服务器失效的后果。一旦DHCP服务器失效，工作站就会因失去IP地址提供者而无法进行通信，这必将导致整个网络的瘫痪，对应用造成重大影响和损失。根据有关机构统计，对关键业务运行要求最高的银行业，每次计算机系统宕机导致的损失平均为一千万美元，同时还会导致对公司声誉无法估量的无形资产损失，而采取灾难恢复方案总共花费平均只有一百万美元。因此，必须保证网络的安全性和系统的正常工作。
考虑到单一DHCP服务器的故障可能带来的严重后果，本文将基于DHCP的原理，探讨多个DHCP服务器提供给服务的可能性，多个服务器之间如何避免冲突，如何冗余，并通过搭建演示环境，对DHCP数据包进行分析，来证明多台路由器提供DHCP服务的可行性以及可靠性。
由于目前的网络设备市场，Cisco(思科)设备占据了数据交换网络的绝大部分，Cisco IOS提供了完善的DHCP服务，使用Cisco设备提供DHCP服务，既能提高DHCP服务的稳定性又能节省搭建DHCP服务器的费用。因此，本文的实验环境使用的硬件设备将采用Cisco的产品。
2. DHCP服务冗余架构
在介绍DHCP服务冗余架构之前，需要对DHCP协议的常用术语进行解释。
DHCP Client：网络上一个节点，它初始化一个需要从DHCP Server(一个或多个)获取配置参数的请求。后文简称DHCP客户端。
DHCP Server：对DHCP客户端的请求作出反应的一个网络节点，此节点可能与客户端在同一个链路，也可能不在同一个链路。后文简称DHCP服务器。
DHCP Discover：请求租约，当DHCP客户端请求IP地址时，向DHCP服务器发送。
DHCP Offer：提供租约，当DHCP服务器接收到DHCP客户端请求IP地址的信息时，就在自己的库中查找是否有合法的IP地址提供给DHCP客户端，如果有 ，将此IP标记，广播一个 DHCP offer 包。
DHCP Request：选择租约，当DHCP客户端接收到第一个DHCP Offer包后，选择IP地址，并再次广播一个DHCP Request包到所有DHCP服务器。
DHCP Acknowledge(DHCP Ack)：服务器确认租约，当DHCP服务器收到DHCP Request包后，以DHCP Ack包向DHCP客户机广播出去，当客户机收到后，就配置了IP地址，完成初始化，就可以在TCP/IP网络上通信了。
DHCP DECLIN：客户发向服务器的消息，告知服务器此地址已被使用。
DHCP RELEAS：客户发向服务器的消息，告知服务器此地址不再使用。
DHCP INFORM：客户发向服务器的消息，要求服务器发送本地配置信息，客户己经配置好了网络地址，不需要再发送网络地址了。
图1描述了多DHCP服务器分配IP地址的过程，包括租约的生成和更新。其中，租约的生成又分为发送请求租约、提供租约、选择租约和确认租约这4个步骤。
图1 多DHCP服务器分配IP地址的过程
2.1租约生成过程
(1) 发送请求租约/消息类型：DHCP Discover。
DHCP客户机首次登陆网络时，它通过广播一个DHCP Discover数据包向DHCP服务器请求IP地址。因为此时客户机还没有IP地址，所以DHCP Discover数据包中的源地址为0.0.0.0。此时，客户机也不知道DHCP服务器的地址，因此数据包中的目的地址为255.255.255.255。这样把消息广播到整个子网。数据包中还包括客户机的MAC地址以及计算机名，因此DHCP服务器可以确定是哪个客户机发来的请求。
(2) 提供租约/消息类型：DHCP Offer
若网络中有多个DHCP服务器，收到DHCP Discover数据包的所有DHCP服务器都用一个DHCP Offer数据包响应请求。DHCP Offer数据包中含有未被租借的IP地址、DHCP服务器的IP地址和其他TCP/IP配置信息。
(3) 选择租约/消息类型：DHCP Request
DHCP客户机收到DHCP Offer数据包后，选择最早接收到的DHCP Offer的数据包，将广播一个DHCP Request数据包作为响应。该数据包中含有最早接收到的DHCP Offer的DHCP服务器的IP地址，因此客户机可以确定接受哪台DHCP的IP地址。
当客户端所在的本地链路范围内存在多个能够提供IP地址的DHCP服务器时，可能会收到多个DHCP Offer报文，但是客户端只能接受一个消息(地址)，并立即向网络广播一个DHCP Request消息作为响应，表示已接受了某一个DHCP服务器的提供，该DHCP Request消息包括已被接受的DHCP服务器的IP地址，这样，其它的服务器收到这个消息后就会收回它们的offer，并随时准备向下一个客户端提供IP地址。
注意：此时未被选择的服务器将把DHCP Request包中的客户端IP地址记录在自身的DHCP Pool中，避免了下次分配此IP地址。后文将通过详细的实验对此过程做详细验证。
(4) 确认租约/消息类型：DHCP Acknowledge(DHCP Ack)
被客户机选定的DHCP服务器通过发送一个DHCP Ack数据包从而确认该IP被客户机使用，当客户机接收到DHCP Ack数据包后TCP/IP即利用DHCP提供的配置信息进行初始化，从而进行网络通信。
2.2 租约更新过程
租约的更新方式有两种，分别是自动更新和手动更新。
(1) 自动更新
DHCP客户机在租约过去一半时自动尝试更新租约，这时该客户机直接向它获取租约的DHCP服务器发送请求，若更新失败在当前租约期限过去87.5%时再次尝试更新租约，这时DHCP客户机将接受来自任何DHCP服务器的租约。
(2) 手动更新
ipconfig /release 释放全部(或指定)客户机的由DHCP分配的动态IP地址。
ipconfig /renew DHCP服务器重新为客户机分配一个IP地址。
3. 实验环境及测试过程
图2为此次实验环境的拓扑示意，在本文采用的测试环境中，
R1、R2设备为Cisco 3750，Switch为Cisco3560， R3为Gateway，Switch、R3与DHCP配置无关。
图2 测试环境拓扑
R1 的相关配置：
ip dhcp excluded-address 192.168.10.1 192.168.10.2
ip dhcp excluded-address 192.168.10.254
!
ip dhcp pool DHCP_Server1
network 192.168.10.0 255.255.255.0
default-router 192.168.10.254
dns-server 192.168.10.1
interface Vlan10
ip address 192.168.10.1 255.255.255.0
R2的相关配置
ip dhcp excluded-address 192.168.10.1 192.168.10.2
ip dhcp excluded-address 192.168.10.254
!
ip dhcp pool DHCP_Sever2
network 192.168.10.0 255.255.255.0
default-router 192.168.10.254
dns-server 192.168.10.2
interface Vlan10
ip address 192.168.10.2 255.255.255.0
对于R1和R2的配置，需要做以下说明：
（1）R1、R2 DHCP配置完全相同，dns-server配置不同是为了方便客户端验证使用了哪个DHCP Server，在实际网络环境中应采用相同的配置。
（2）把DHCP Server 以及网关的IP地址从地址池中排除，避免IP冲突。不排除也不会造成影响，DHCP Server有检测机制，可以排除已使用的IP地址。
下面将通过开启R1和R2的终端监控来查看DHCP server事件，并给出详细的实验数据。开启终端监控的命令如下：
#terminal monitor
#debug ip dhcp server event
第一步：DHCP申请过程(DHCP客户端登陆网络)
当客户端新连接到网络中发起DHCP Discover广播，两台服务器均响应DHCP Offer，客户端使用先提供的DHCP Offer的服务器作为DHCP服务器。DHCP客户端都会试图保留上次获取的IP地址，如果客户端从其他网络中移到现在网络，DHCP Server将不会保留原有IP地址。
测试结果： 客户端最终选择R2为DHCP服务器，获取IP地址192.168.10.9。
debug 输出结果：
R1#
(1) Jun 26 04:58:10.898: DHCPD: Sending notification of DISCOVER:
(2) Jun 26 04:58:10.898: DHCPD: htype 1 chaddr 001d.7282.8ee9
(3) Jun 26 04:58:10.898: DHCPD: interface = Vlan10
(4) Jun 26 04:58:10.898: DHCPD: class id 4d53465420352e30
(5) Jun 26 04:58:10.898:DHCPD: requested address 11.11.11.11 is not on subnet 192.168.10.0.
(6) Jun 26 04:58:17.944: DHCPD: Adding binding to radix tree (192.168.10.9)
(7) Jun 26 04:58:17.944: DHCPD: Adding binding to hash tree
(8) Jun 26 04:58:17.944: DHCPD: assigned IP address 192.168.10.9 to client 0100.1d72.828e.e9. (2078 0)
(9) Jun 26 04:58:17.944:DHCPD: DHCPOFFER notify setup address 192.168.10.9 mask 255.255.255.0
(10) Jun 26 04:58:17.944:DHCPD: DHCPOFFER notify setup address 192.168.10.9 mask 255.255.255.0
(11) Jun 26 04:58:17.944: DHCPD: Sending notification of TERMINATION:
(12) Jun 26 04:58:17.944: DHCPD: address 192.168.10.9 mask 255.255.255.0
(13) Jun 26 04:58:17.944: DHCPD: reason flags: noalloc
(14) Jun 26 04:58:17.944: DHCPD: htype 1 chaddr 001d.7282.8ee9
(15) Jun 26 04:58:17.944: DHCPD: lease time remaining (secs) = 300
(16) Jun 26 04:58:17.944: DHCPD: returned 192.168.10.9 to address pool DHCP_Server1.
(1)---(4)客户端的DHCP Discover包包含其Mac地址、接收的端口等信息；(6)---(9)发送DHCP Offer广播包，为客户端提供IP地址等信息；(10)、(11)接收到客户端的DHCP Request数据包，确定客户端未接收IP地址分配；(12)---(16)IP地址192.168.10.9回收到DHCP_Server1 pool中，下次分配从192.168.10.10开始。这是DHCP协议为多服务器架构做的冗余设计。详见验证DHCP Server状态。
R2#
(1) Jun 26 04:58:15.124: DHCPD: Sending notification of DISCOVER:
(2) Jun 26 04:58:15.124: DHCPD: htype 1 chaddr 001d.7282.8ee9
(3) Jun 26 04:58:15.124: DHCPD: interface = Vlan10
(4) Jun 26 04:58:15.124: DHCPD: class id 4d53465420352e30
(5) Jun 26 04:58:15.124:DHCPD: requested address 11.11.11.11 is not on subnet 192.168.10.0.
(6) Jun 26 04:58:22.171:DHCPD: Adding binding to radix tree (192.168.10.9)
(7) Jun 26 04:58:22.171: DHCPD: Adding binding to hash tree
(8) Jun 26 04:58:22.171:DHCPD: assigned IP address 192.168.10.9 to client 0100.1d72.828e.e9. (2078 0)
(9) Jun 26 04:58:22.171:DHCPD: DHCPOFFER notify setup address 192.168.10.9 mask 255.255.255.0
(10) Jun 26 04:58:22.171: DHCPD: DHCPOFFER notify setup address 192.168.10.9 mask 255.255.255.0
(11) Jun 26 04:58:22.179: DHCPD: Sending notification of ASSIGNMENT:
(12) Jun 26 04:58:22.179: DHCPD: address 192.168.10.9 mask 255.255.255.0
(13) Jun 26 04:58:22.179: DHCPD: htype 1 chaddr 001d.7282.8ee9
(14) Jun 26 04:58:22.179: DHCPD: lease time remaining (secs) = 86400
(15) Jun 26 04:58:22.179: DHCPD: interface = Vlan10
(1)---(4)接收到客户端的DHCP Discover包，包含客户端Mac地址、接收的端口等信息；(5) 客户端试图请求上次获取的IP地址，但是原IP地址不在现有的DHCP pool中，DHCP Server重新分配IP地址；(6)---(9)发送DHCP Offer广播包，提供客户端的IP地址等信息；(10)、(11)接收到客户端的DHCPrequest数据包，确定客户端接收IP地址分配；(12)---(15)广播DHCPack数据包，确实IP分配完成，完成此次DHCP工作。租期为86400秒(默认1天)。
验证DHCPServer状态
R1#show ip dhcp pool
Pool DHCP_Server1 :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 0
Excluded addresses : 3
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
192.168.10.10 192.168.10.1 - 192.168.10.254 0 / 3 / 254
注：current index为下次分配IP的地址，虽然客户端响应R1的DHCP Offer，但R1也将IP地址192.168.10.9跳过。
R2#show ip dhcp pool
Pool DHCP_Sever2 :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 1
Excluded addresses :
3
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
192.168.10.10 192.168.10.1 - 192.168.10.254 1 / 3 / 254
第二步：模拟续约过程
在客户端手动更新租约，观察两台DHCP_Server的debug输出，可以得到以下结果：
R2#
Jun 26 04:59:35.638: DHCPD: Sending notification of ASSIGNMENT:
Jun 26 04:59:35.638: DHCPD: address 192.168.10.9 mask 255.255.255.0
Jun 26 04:59:35.638: DHCPD: htype 1 chaddr 001d.7282.8ee9
Jun 26 04:59:35.638: DHCPD: lease time remaining (secs) = 86400
Jun 26 04:59:35.638: DHCPD: interface = Vlan10
客户端单播DHCP Request数据包到DHCP Server2，DHCP Server2接收后发送DHCP ACK刷新DHCP租期。由于客户端单播到R2，因此R1 无任何debug输出。
第三步：模拟一台DHCP Server故障
中断R2设备，模拟R2 DHCP Server故障。终端后，原来从R2获取IP地址的客户端因为已获取IP地址，在DHCP续约前不受影响。DHCP客户机在租约过去一半时自动尝试更新租约，该客户机向为它提供租约的DHCP服务器发送请求，若更新失败，不采取任何措施。在当前租约期限过去87.5%时，客户机再次尝试更新租约，若更新失败，该客户机将广播DHCP Request包，接受R1服务器的租约。
模拟从R2获取IP地址的客户端重新接入网络时的情况，观察DHCP_Server1的debug输出，可以得到以下结果：
R1#
Jun 26 05:05:27.760: DHCPD: Sending notification of DISCOVER:
Jun 26 05:05:27.760: DHCPD: htype 1 chaddr 001d.7282.8ee9
Jun 26 05:05:27.760: DHCPD: interface = Vlan10
Jun 26 05:05:27.760: DHCPD: class id 4d53465420352e30
Jun 26 05:05:27.760: DHCPD: Sending notification of DISCOVER:
Jun 26 05:05:27.760: DHCPD: htype 1 chaddr 001d.7282.8ee9
Jun 26 05:05:27.760: DHCPD: interface = Vlan10
Jun 26 05:05:27.760: DHCPD: class id 4d53465420352e30
Jun 26 05:05:29.773: DHCPD: client requests 192.168.10.9.
Jun 26 05:05:29.773: DHCPD: Adding binding to radix tree (192.168.10.9)
Jun 26 05:05:29.773: DHCPD: Adding binding to hash tree
Jun 26 05:05:29.773:DHCPD: assigned IP address 192.168.10.9 to client 0100.1d72.828e.e9. (2078 0)
Jun 26 05:05:29.773:DHCPD:DHCPOFFER notify setup address 192.168.10.9 mask 255.255.255.0
Jun 26 05:05:29.773: DHCPD: Sending notification of ASSIGNMENT:
Jun 26 05:05:29.773: DHCPD: address 192.168.10.9 mask 255.255.255.0
Jun 26 05:05:29.773: DHCPD: htype 1 chaddr 001d.7282.8ee9
Jun 26 05:05:29.773: DHCPD: lease time remaining (secs) = 86400
Jun 26 05:05:29.773: DHCPD: interface = Vlan10
由于R2故障，所以只有R1响应客户端的DHCP请求，客户端DHCP Discover包中包含上次获取的IP地址，R1的DHCP Pool中，此IP未分配，因此R1分配原地址给客户端。这种情况客户端IP地址不会发生改变。
4. 独立DHCP Sever组成多DHCP Sever时的冲突检查机制
Windows/linux集群下的DHCP Sever因为集群的机制，可以同步多台DHCP Server之间的数据，而独立DHCP Sever组成多DHCP Sever最大的问题是DHCP Server之间没有数据同步的功能，这就会造成多DHCP Server环境下的IP地址分配混乱。如：其中一台DHCP Server提供给一台客户端的IP地址，已经被另外一台DHCP Server分配给其他客户端了。DHCP协议的自有的冲突检测机制可以避免这样的现象，描述如下：
DHCP Sever提供DHCP Offer包之前都会进行IP冲突检测，若准备分配的IP地址，已经被网络中的某个客户端使用，就跳过这个IP地址，同时记录这个IP地址到冲突池中，直到有不冲突的IP地址被分配。此刻DHCP Sever 会有 %DHCPD-4-PING_CONFLICT: DHCP address conflict: server pinged 192.168.10.xx 这样debug信息。
客户端接收到DHCP Server提供的IP地址后，检测IP冲突，如果IP有冲突，就会向DHCP Server发送DHCP DECLINE数据包，标明放弃这个IP地址，DHCP Server会重新分配新的IP地址。
有这样的双向IP冲突检测机制，就能确保非Windows/linux集群下的多DHCP Server为客户端分配唯一的IP地址。
5. 总结
实际情况中使用WINDOWS或者Linux平台搭建DHCP服务器的情况很多，但是在windows/Linux下搭建DHCP服务器涉及系统集群、服务器数据同步等复杂问题；而且使用Windows/Linux的DHCP服务还需要服务器硬件配合。由于Cisco设备在网络环境中的使用普遍性，使用Cisco IOS来配置DHCP Server，无需服务器硬件的配合，节省了设备的投入，且配置简单、冗余原理清晰、相对WINDOWS或者Linux平台上搭建的DHCP服务器，具有更高的稳定性。若Cisco设备足够多，可以在网络中部署多台DHCP Server来实现多点冗余，在Cisco Virtual Switching System(Cisco虚拟交换系统) 架构中，只需要配置一个DHCP Server服务，即可实现DHCP服务的冗余设计。因此，使用Cisco IOS配置DHCP服务是一个既快捷又安全可靠的方式。
