分析演示：靜態路由和CEF的方式導致HSRP接管故障後丟失通信
分析目標：
1 靜態路由的問題導致HSRP接管故障後丟失通信
2 分析靜態路由造成的流量接管問題
3 CEF的模式導致有些主機丟包，有些主機正常的原因
演示環境： 如圖1所示的演示環境
背景說明：首先實施路由器R1、R2、R3的靜態路由配置，具體配置如下所示，不需要在路由器R1和R2去配置，相互通過彼此到30.30.30.0的路由，讓它們都通過R3到達30.30.30.0。然後去實施HSRP冗餘組，要求R1爲活動路由器，然後測試和分析如果R1的E1/0接口故障後，R2是否能成功接管HSRP冗餘組中活動路由器的角色，流量是否能從R1切換到R2，再到達30.30.30.0，如果出現問題請分析原因。
路由器R1上到30.30.30.0的靜態路由配置：
R1(config)#ip route 30.30.30.0255.255.255.0 192.168.1.3
R1(config)#ip route 30.30.30.0255.255.255.0 192.168.4.3
路由器R2上到30.30.30.0的靜態路由配置：
R2(config)#ip route 30.30.30.0255.255.255.0 192.168.2.3
路由器R3上到172.16.1.0的靜態路由配置：
R3(config)#ip route 172.16.1.0255.255.255.0 192.168.1.1
R3(config)#ip route 172.16.1.0255.255.255.0 192.168.4.1
R3(config)#iproute 172.16.1.0 255.255.255.0 192.168.2.2
演示步驟：
第一步：爲路由器R1和R2配置HSRP冗餘組具體配置如下所示：
路由器R1的HSRP配置：
R1(config)#intee1/0
R1(config-if)#standby 1 ip 172.16.1.254
R1(config-if)#standby 1 priority 110 *配置優先級使R1成爲活動路由器
R1(config-if)#standby 1 preempt * 配置搶佔功能
R1(config-if)#exit
路由器R2的HSRP配置：
R2(config)#intee1/0
R2(config-if)#standby 1 ip 172.16.1.254
R2(config-if)#standby 1 preempt
R2(config-if)#exit
注意：R2爲什麼不需要配置優先級？因爲背景要求R1成爲活動路由器，並將優先級配置爲110，而R2使用默認的優先級100，所以R2不需配置優先級，這樣就可以保證R1成爲HSRP組中的活動路由器。
完成上述配置後，可以分別在R1和R2上使用show standby brief指令查看HSRP的角色信息，如圖2和3所示，如預期所評估的那樣，R1成爲HSRP組中的活動路由器，R2爲備份路由器。然後此時，在172.16.1.0網絡的主機上執行一次到30.30.30.1的路由跟蹤，發現當前的路徑是通過R1（活動路由器）進行轉發的。如圖4所示。至此爲止，爲後面的故障分析完成了所需要的基礎配置。
第二步：此時，如果R1的E1/0接口（啓動HSRP功能的接口），發生網絡故障或者是被關閉，HSRP組會正常收斂嗎？路由器R2會接管R1活動路由器的角色嗎？如果發生有些主機能正常收斂，有些主機確不能，這是爲什麼？
製造R1的E1/0故障：
R1(config)#intee1/0
R1(config-if)#shutdown
R1(config-if)#exit
當製造R1的E1/0接口故障時（手工關閉該接口），事實上網絡上有一部分主機，對的錯只是一部分主機，出現如圖5所示的現象，流量中斷，丟包；而另一部分主機卻可以連接通信，這是什麼原因所致呢？下面開始進行詳細的分析。
按照一般思路：路由器R1的E1/0（啓動HSRP）的接口故障，R2應該快速收斂，接替活動路由器的角色，而且R1的E1/0接口那是啓動HSRP的接口，屬於HSRP的冗餘的組內接口，按常理這種收斂應該是最快的，可現在爲什麼會出現這樣的情況？
首先需要確定：當R1的E1/0接口故障後，R2是否能順利接管，可以通過在路由器R2上執行show standby brief指令查看HSRP的角色信息，然後再到主機上跟蹤一次到30.30.30.1的所有路徑，會發現，R2是成功的接管了R1的活動路由器角色，如圖6所示，爲什麼這樣講呢？從跟蹤的結果可以看出，主機到30.30.30.1的流量是通過R2(172.16.1.2)在轉發，所以HSRP冗餘組中的R2在R1故障後，成功的接管R1活動路由器這個角色是沒有問題的，只是流量到達R2(172.16.1.2)後才產生的丟包，所以至此爲止，不用再去思考HSRP的狀態切換，因爲它很正常。
然後需要思考的是：爲什麼流量到達R2(172.16.1.2)後丟包，難到是R2沒有到30.30.30.1的可達性路由？經過認真思索後，可以肯定的講，不是這個原因，理由可以通過兩方面的取證來分析：一、從根據的結果上來分析，是Request time out（請求超時），根據筆者以前所著的《思科CCNA認證詳解與實驗指南（200-120）》對ICMP的分解，所謂Request time out（請求超時）一般發生在數據包可以從信源（源主機）成功的發送到信宿（目標主機），只是目標主機不能返回數據包給源主機，而源主機一直等待，以至於超時。二、在本實驗前面的背景說明中就可以看出，在R2上是成功的配置了到30.30.30.0的靜態路由的，所以綜合上述兩個理由，排障人員有理由懷疑是R3（30.30.30.1）返回給172.16.1.0網絡主機的流量出現問題。
爲了進一步確定懷疑的問題，需要在R3上對返回172.16.1.0的數據流量的路徑進行取證：
如圖7所示，在路由器R3上執行可擴展的路由跟蹤指令，跟蹤的目標是172.168.1.100;以源IP地址30.30.30.1發起路由跟蹤。不難發現，跟蹤的事實是：當前R3以源30.30.30.1發送數據包到172.16.1.1.100,它正在通過三條路徑做發送，這三和路徑的下一跳分別是192.168.1.1、192.168.2.2、192.168.4.1，可以看到只有通過下一跳192.168.2.2的數據包能成功的到達172.16.1.100，當數據通過下一跳192.168.1.1和192.168.4.1時出現了問題，現在可以確定懷疑的問題了，那麼接下來要做的分析工作就是分析這個問題是如何產生的。
確定故障問題，發析問題的產生原由：現在確定的問題是當數據通過下一跳192.168.1.1和192.168.4.1時出現了問題，產生這個故障的原因是：路由器R1的E1/0接口故障，並不會影響R1的E1/1和S2/0，更不至於影響R3的E1/0和S2/0鏈路，所以R3的E1/0和S2/0接口狀態爲up ,那麼R3路由表如圖8所示，具備三條路徑到172.16.1.0。默認情況下路由器R3會使用使用這三條鏈路來完成對172.16.1.0數據轉發的負載均衡，如圖9所示，只要有數據通過下一跳192.168.4.1和192.168.1.1轉發，那就必不可達，雖然數據包能到達R1上，但是R1的內側接口E1/0是故障的，故不能轉發到172.16.1.100，這會造成路由黑洞，唯一可達的就是通過下一跳192.168.2.2轉發。可以更直白的講：“如果同時從R3上發3個包到172.16.1.100，那麼只有一個包能到達，另外兩個包必丟棄，也就是“通一斷二”的現象。
此時用戶可能產生一個疑問（一些主機丟包，一些主機不丟包）：
在自己做測試時，並不是“通一斷二”的現象。而是有些主機全丟包，有些主機不丟包，這是爲什麼？這是因爲R3默認是啓動了ip cef功能，如果有三條路徑到同一目標172.16.1.0，那麼路由器默認將基於不同的目標來進行負載均衡，以三臺不同的目標主機172.16.1.100、172.16.1.101、172.16.1.102爲例，其行爲是：假設到172.16.1.100爲第一個目標主機，那麼所有到這一個目標的數據都會通過同一個路徑轉發，如果此時通過下一跳爲192.168.1.1轉發，結果是必丟包，而且全丟棄；同理172.16.1.101爲第二個目標主機，那麼所有到這第二個目標的數據都會通過同一個路徑轉發，如果此時通過下一跳爲192.168.4.1轉發，結果是必丟包，而且全丟棄；如果172.16.1.102爲第三個目標主機，那麼所有到這第三個目標的數據都會通過同一個路徑轉發，如果此時通過下一跳爲192.168.2.2轉發，結果是不丟包，全部可達。再次強調：造成這種現像的是CEF通過不同目標進行負載均衡的原則所造成的，事實上，你的“整個網絡”在遵守“通一斷二”的現象，只有三分之一的主機可達。這種論斷正確嗎？如果希望在同一個目標主機上看到“通一斷二”的現象，該怎麼辦？
如何在單一主機上看到“通一斷二”的現象？
只要在路由器R3(config)#no ip cef暫時關閉ip cef，那麼R3就不在執行基於不同目標的負載均衡，而是將數據包平均的通過三條路徑轉發，此時在單一主機上做連繼的ping，就可以看到如圖10所示的“通一斷二”的現象。
在這個環境中的其它注意事項：
如果現在到路由器R1將E1/0接口恢復，然後其它配置保持本實驗前面的配置不變，現在請問：如果R1的E1/1和S2/0接口故障，HSRP冗餘組中的R2能成爲活動路由器，然後接管R1的轉發工作嗎？
不能，因爲整個網絡使用的靜態路由，而路由器R1和R2之間沒有相關的靜態路由，並且在R1上沒有配置接口跟蹤功能，所以R1的E1/1和S2/0故障後，R2無法成爲活動路由器，接管R1的故障。