網絡中如果應用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,因此可以防止此種惡意攻擊。