DHCP and DHCP failover 扫盲

http://www.netyourlife.net/forum/viewthread.php?tid=4746

http://media.ccidnet.com/media/ciw/1010/b1601.htm

网络中如果应用DHCP，就要考虑DHCP服务器失效的后果，即工作站没了IP地址，无法进行通信，而这仅是DHCP失效所造成的各种损失的开始。因此，DHCP必须有一定的冗余度。

　　如果没有RFC2131，冗余度的实现方式有两种。第一种，部署另一台服务器来提供不重复的IP地址服务，如果一台服务器出了故障，用户可以从另一台服务器接收地址。然而，这种解决方案要求地址范围加倍，并且由于服务器之间没有交流，因此也不能预测从哪一台上指派地址租用。DHCP协议有一种内在的冗余格式：如果IP地址租用12天，那么与服务器的连接每6天验证一次。这样，如果服务器出了故障，客户还有至少6天的时间使设备恢复正常，以保证租用不受影响。故障只会影响新部署工作站的IP地址。

　　第二种冗余实现方式是，安装一台次服务器指派与原服务器范围不重叠的地址。任何添加或迁移只需从次服务器获得地址。当暂时租用时限过半时，将更新到主服务器。为此，也需要增加地址空间来负责暂时服务器所需的地址，而地址空间的增加是种浪费。另外，还必须有一台DHCP备用服务器，它唯一的目的就是在主服务器失效时启动。

　　而RFC 2131是实现DHCP服务器的最新草案，它的一项新功能是多台冗余服务器采用相同的地址空间。另外，一个小组正在从事DHCP故障恢复协议草案7的工作，此草案规定，主服务器和次服务器必须同步，以保证冗余度。

　　RFC 2131允许两台或多台服务器指派相同的地址范围。主服务器分发租用，次服务器监视主服务器的状态。两台服务器在所有时间彼此共享租用信息。为防止复制IP地址的可能性，次服务器有自己的地址库，以备主服务器失效时使用。


　　RFC 2131的工作机制


　　如果冗余的DHCP工作不正常，它们必须能够同步地址租用信息，以便任何签约用户能用任一台服务器更新。为解决这个问题，RFC 2131定义了三种类型的服务器到服务器的信号：服务器租用同步信号、操作状态信号（问候包）及“我回来了”信号（主服务器从死机状态恢复）。冗余DHCP服务器遵循RFC 2131 DHCP故障恢复草案，通过服务器租用同步信号彼此交流租用信息。当两台服务器工作正常时，主、次服务器间会有连续的信息流。用来交流租用信息的信号有三种：添加信号，当主服务器分发出一个新租约时，主服务器发送到次服务器的信号；刷新信号，当租约有变化时（如更新/扩充），每台服务器发送的信号；删除信号，当租约期满，地址又成为可用的了，服务器发送的信号。在所有情况下，接收方服务器以肯定或否定的认可信号来响应。这些信号只有在请求DHCP客户处理完毕后才发送给另一台服务器。

　　除了维护当前的租用信息数据库外，次服务器还必须留意主服务器，以便得知何时取代租用的分发。这一功能由监视两台服务器的TCP连接来实现。次服务器使用三个标准以确定它和主服务器的连接是否满意：一，必须能建立TCP连接；二，必须接收到主服务器发送的连接信号，并以连接认可响应；三，必须接收到主服务器发出的状态信号，用它来确定自己的操作状态。

　　RFC 2131故障恢复草案指定了一种机制，让主服务器出故障后能够恢复。当主服务器复活了，想收回次服务器的控制权，它就启动三个信号序列：控制请求、控制恢复初始和控制恢复完成。

　　主、次服务器之间交换的所有信号都以标准DHCP包编码。包的类型在RFC已定义，但包的约束信息还需要标准化。由于这个草案还没有完全批准，近期还不太可能看到能在多个厂家共同使用的DHCP解决方案出台。


　　部署冗余DHCP


　　目前，Cisco Systems的Cisco Network Registrar(CNR)的3.0版本就采用RFC 2131，能够进行冗余DHCP服务器的部署。但在部署冗余DHCP解决方案之前，必须注意两个问题，以保证它能正常工作。

　　首先，如果路由器使用BOOTP/DHCP中继，那么备份服务器必须也加上BOOTP/DHCP中继，以代替主服务器。BOOTP/DHCP中继是在路由器的以太网接口配置的，它作为此分部的主机或工作站的默认网关。BOOTP中继从分部中取出DHCP广播包，并把它们推给DHCP服务器。当添加了备份服务器时，需要在每个以太网接口再加一个BOOTP中继。如果跳过这一步，得到的是不具容错性的网络。这样，当主服务器失效时，包就不会被推到第二个服务器。

　　其次要注意的问题是需要在主、次服务器间手工同步范围信息。DHCP故障恢复协议是针对租用信息而不是范围信息的。CNR服务器只能同步DHCP租用数据，略去了范围和其他配置数据。如果租用范围有变化，则必须手工改变两台服务器。幸好，Cisco提供了一个程序，它能比较服务器的DHCP配置并对不同之处提出警告。如果网络里的范围多于100个，那么服务器同步的安装和维护将十分困难。然而，Cisco还有一个非常有用的脚本，能够克隆DHCP服务器，在安装次服务器时使用，而在其他情况下禁止使用。
思科DHCP服务解决方案

对于有近千个信息点的内网来说，如果采用手工的地址分配方案将带有巨大的管理负担和维护成本，尤其是在网络实施用户身份认证及动态VLAN划分时，静态地址分配更不可行，因此大型的局域网一般采用DHCP动态地址分配方案，但传统的DHCP地址分配方案在安全性、可靠性、负载均衡能力等方面存在诸多问题，思科创新的DHCP地址分配方案CNR(Cisco Network Register)可很好地解决上述问题，并支持TFTP和DNS等其它服务。
1 )  DHCP Server分布式设计
在网络的两台核心交换机部署两个Cisco DHCP CNR Server, 这两台DHCP Server 通过双网卡连接上来，此外Cisco DHCP CNR Server可以实现负载分担和故障切换，将整个IP地址池的80%由这两个Server负责，20%的地址池由另外楼层的2个DHCP  Server负责。
DHCP  分配的80/20规则：
为了避免重复地址分配，通常采用了80/20的规则，本地部署一台DHCP Server , 负责某一地址范围的80%，远程部署另外一台DHCP Server负责某一地址范围的20%。
假如分给某网段的地址范围是10.1.1.0/24, 则10.1.1.1-10.1.1.200 由本地的DHCP Server负责，10.1.1.201-10.1.1.253 由远程的DHCP Server负责
80/20规则的前提基于如下假设：
当本地的DHCP  Server 发生故障时，因两组DHCP服务器地址分配数据库的实时同步操作，很多已经得到IP 地址的主机的租期并没有过期，无需申请地址，只有少数新连接的主机需要申请IP地址，由远程DHCP Server赋予。
2）  DHCP Server的 冗余与负载分担
传统方式的 简单DHCP冗余措施
通常的设计的情况时在中心放置2个DHCP Server, 两个DHCP Server没有任何冗余协议，为了防止不同的Client得到重复的IP地址，为这两个Server分配不同的地址池。

简单的DHCP冗余存在的问题：
上述的简单的DHCP冗余存在如下问题：
• IP地址空间不足
当有一个 DHCP Server 发生故障时，只有另外一个Server的地址空间提供服务，但是为了防止IP 地址冲突，两个Server地址池一定不一样，因此另外一个地址空间只能分配给一个网段的一半。
• PC的连接不能永远提供在线连接，可能会中断后在连接
当有一个 DHCP Server 发生故障后，当从此Server获的client的IP地址到期时，它不能得到新的IP地址续用，它就会中断连接，重启动DISCOVERY 过程，引起网络连接中断一段时间。
Cisco DHCP Failover 协议
为了解决上述不足，Cisco 向IETF提交了一份草案并申请IETF考虑作为标准，目前Cisco’s failover protocol  已经成为IETF DHCP工作组构建标准DHCP Redundcy 协议的基础。
草案draft-ietf-dhc-failover-12.txt  的作者Cisco Syetems的杰出工程师，他目前是IETF DHCP工作组主席。
在此工作组模型中，分为Primary DHCP Server和Secondary DHCP Server,Primary DHCP Server和Secondary Server存在协议交互，Secondary Server平时轮询Primary Server以确认其是否工作，如果工作正常，Seconday Server并不对Client发出的DHCP请求作出响应，Primary Server会将它的DHCP 数据库同步更新给Secondary Server.

Cisco Network Registrar 6.2 软件采用了Cisco DHCP Safe Failover Protocol 实现了DHCP Server的冗余。
DHCP Server的 负载均衡
RFC 3074定义了根据MAC地址实现一种DHCP Server负载分担的算法，它能够将不同的MAC地址的DHCP 请求发送给不同的DHCP Server, 因此实现了DHCP Server的负载分担，Cisco DHCP Server支持RFC3074, 因此能够实现在冗余切换和负载分担。
3)  DHCP  Server安全性设计
DHCP 安全性面临三个问题：
A) DHCP Server 冒用
当某一个恶意用户再同一网段内也放一个DHCP 服务器时，PC很容易得到这个DHCP server的分配的IP地址而导致不能上网。
B) 恶意客户端发起大量DHCP请求的DDos 攻击
恶意客户端发起大量DHCP请求的DDos 攻击，则会使DHCP Server性能耗尽、CPU利用率升高。
C)  恶意客户端伪造大量的MAC地址恶意耗尽IP地址池
解决方案：
防DHCP Server 冒用
Cisco Switch 可采用DHCP Snooping VACL, 只允许指定DHCP Server的服务通过，其它的DHCP Server的服务不能通过Switch。
VACL是应用于一个 Vlan  的 ACL,它的配置很简单，但是实际上已经将ACL应用到VLAN内的所有端口上了，它能够对DHCP 的协议进行分析，因此只允许有效的 DHCP Server的信息通过。
假定正式目标DHCP服务器的IP地址为1.2.3.4。VACL配置将仅允许目标服务器的响应被交换到客户机。
当和不是真正的dhcp Server 同一网段的PC通过DHCP 获得IP地址时，Cisco Catlyst Switch的VACL功能将只能让合法的DHCP Server  的 DHCP-offer、ACK通过，非法的DHCP Server的信息将被过滤掉，因此保证了PC  能够从真实的DHCP Server获得地址

防止恶意客户端发起大量DHCP请求的DDos 攻击
Cisco Switch能够对DHCP请求作流量限速，因此能够防止恶意客户端发起大量DHCP请求的DDos 攻击，防止DHCP Server的CPU利用率升高。

恶意客户端伪造大量的MAC地址恶意耗尽IP地址池
RFC 3046  定义了使用DHCP option 82 来防止恶意客户端伪造大量的MAC地址恶意耗尽IP地址池，其基本原理是：
• Switch截断DHCP的请求，插入交换机的标识,接口的标识等发送给DHCP Server
• DHCP Server接到后，根据标识制定策略，如针对此标识来的请求只分配1-2个 IP地址等。
Cisco 交换机支持DHCP option 82, Cisco DHCP Server CNR支持DHCPoption 82,因此可以防止此种恶意攻击。