上一期文我們簡單的扯了點生成樹（STP）的幾個坑點，這一期來聊聊關于DHCP的故事。動态主機配置協議（Dynamic Host Configuration Protocol）工作在UDP層端口号67 68 ，這是一個另廣大網管、工程師都喜歡的協議，但我個人覺得這東西，成也蕭何敗蕭何。成在于它的方便性，服務一開，準備下班。敗在他的單一性。設想一個場景，兩台核心交換機組網，由于各種原因，沒能跑CSS等集群協議。為了保證網絡和設備使用，必然會使用VRRP\GVRP\HSRP等網關冗餘協議。假設主機故障，備機接管協議。備機DHCP服務起來之後開始分配地址，部分客戶端從主機獲取到的地址租期還未過期，此時新的服務開始分配地址。這麼一來内網可就混亂的跟什麼似的。

DHCP他的工作機制有點類似小時候記憶中走街串巷的磨刀匠，邊推車邊吆喝着“磨剪子哎，镗菜刀”當有人與之回應後，則停止吆喝，詳細詢問客人需要幹什麼，什麼價錢等。

如下我們将磨刀匠比喻成DHCP的客戶端，需要磨刀的人比喻成DHCP服務器。

同理DHCP的建立也如同磨刀匠的吆喝，磨刀匠走街串巷的漫無目的的吆喝，誰要磨剪刀，（DHCP client 上電，誰能給我分配的地址。廣播發送DHCP discover）

居民應答，我這要磨剪子。（dhcp服務器響應客戶端，發送offer報文）

磨刀匠支聲應答來到居民家中。（DHCP客戶端，響應請求，發送request報文）

磨刀匠來到居民家中，居民覺得價錢合理，磨刀匠看上去老實本分，随即開始了交易。（DHCP服務端收到request報文，給客戶端發送ACK報文）

如上比喻是一個正常的客戶端請求DHCP，服務器響應請求的過程。那麼回到本文最初的場景，兩台核心交換機跑了網關冗餘協議，開啟了DHCP服務。某一天主機宕機，備機接管業務轉發，DHCP經常起來，這時候剛剛有客戶端上線請求地址，由于備機和主機直接的DHCP狀态并未同步，備機不知道哪些地址的主機已經分配完的，可能會分配之前主機分配過的地址，從而導緻下遊客戶端發送地址沖突故障。

這樣的組網方式，在很多政企單位中使用，由于種種原因，沒跑CSS等集群協議，隻是跑了VRRP\GVRP等網關冗餘協議。出現單機故障後雖然網絡不會中斷，但是如果結合了DHCP服務，那麼就一定會出現如上描述的狀況。那麼最簡單有效的做法則對DHCP地址池也做一個冗餘，即為兩台主機上都建立相同的DHCP地址池，主機有效分配地址範圍為前一半，備機有效有效分配地址範圍為後一半。

命令：ip dhcp server exclude：

DHCP option 82: DHCP中繼代理信息選項（Relay Agent Information Option），是DHCP報文中的一個選項；來賓可以在不安裝認證客戶端的情況下，直接訪問Internet資源，但是不能訪問學校、企業、政府單位的内網。

這東西随着現在連鎖企業和雲計算的崛起，算是蹭了一波熱度，誇三層注冊的場景越來越多，如AP和瘦客戶需要跨網段和控制器、控制器通信獲取配置等等。

下一期文我們結合實際工作項目來盤一盤這個小玩意。歡迎大家一起來唠唠叨！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!