分析演示： RIP動態路由協議引發的HSRP收斂問題
演示目標：
1 動態路由協議在某種程度上可以幫助HSRP收斂無跟蹤的盲點
2 動態路由協議RIP可能引發HSRP收斂的問題
3 爲什麼同一子網的主機，有些收斂快，有些慢？
演示環境：如圖1所示的環境
背景說明：從實踐的角度來講，在需要部署HSRP進行三層冗餘的環境中，通常物理鏈路也是成環的，那麼這種環境中，進行網絡設計時需要特別注意動態路由協議的選擇，以及評估和預測可能引發的各種收斂問題，明確到底是HSRP在爲用戶網絡在實現冗餘，還是三層的動態路由協議在爲用戶實現冗餘，如果發生收斂問題，比如：收斂慢，是什麼原因導致問題的發生，以及如何對這些問題進行修復。
演示步驟：
第一步：在如圖1所示的網絡環境中爲所有的三層設備啓動RIPv2的動態路由協議，具體配置如下所示，確保各個路由器的動態路由學習正常，這是整個演示環境的基礎保障。
路由器R1的RIP配置：
R1(config)#routerrip
R1(config-router)#noauto-summary
R1(config-router)#version2
R1(config-router)#network 192.168.1.0
R1(config-router)#network 192.168.4.0
R1(config-router)#network 172.16.0.0
R1(config-router)#exit
路由器R2的RIP配置：
R2(config)#routerrip
R2(config-router)#version2
R2(config-router)#noauto-summary
R2(config-router)#network 192.168.2.0
R2(config-router)#network 172.16.0.0
R2(config-router)#exit
路由器R3的RIP配置：
R3(config)#routerrip
R3(config-router)#version2
R3(config-router)#noauto-summary
R3(config-router)#network 192.168.1.0
R3(config-router)#network 192.168.4.0
R3(config-router)#network 192.168.2.0
R3(config-router)#network 30.30.30.0
R3(config-router)#exit
完成上述配置後路由器R1的路由器表如圖2所示。
注意：在R1的路由表中有一條暫時沒有顯示，被隱藏的到 30.30.30.0的RIP路由，這條路由器R1通過下一跳是R2的172.16.1.2來到達30.30.30.0的路由，它爲什麼會被隱藏，因爲RIP以跳數來評估路由的度量，通過192.168.4.3和192.168.1.3是1跳，而經過R2的172.16.1.2來到達30.30.30.0的路由是2跳，所以它暫時被隱藏，那麼在一種情況下該路由器會出現，那就是下一跳192.168.4.3和192.168.1.3這兩條路由失效時，到此爲後面的問題做出了預設。
現在將路由器R1和R2的E1/0接口規劃到HSRP熱容組1，虛擬IP地址是172.16.1.254，要求R1爲活動路由器，並配置兩臺路由器的搶佔功能，具體配置如下所示：
注意：暫時不去配置任何接口跟蹤！
路由器R1的HSRP配置：
interface Ethernet1/0
ipaddress 172.16.1.1 255.255.255.0
standby1 ip 172.16.1.254 * 配置HSRP的虛擬IP地址
standby 1 priority 110 * 配置優先級爲110，確保R1成HSRP組中的活動路由器
standby 1 preempt * 配置搶佔功能
路由器R2的HSRP配置：
interface Ethernet1/0
ipaddress 172.16.1.2 255.255.255.0
standby 1 ip 172.16.1.254
standby 1 preempt
爲什麼不爲R2配置優先級？
默認優先級爲100，爲了確保能讓R1（優先級110）成爲活動路由器，所以沒必要去配置R2的優先級，使用保持默認的100。
提出一個問題：現在到第一步的配置爲止，如果路由器的S2/0和E1/1端口出現故障，請問HSRP的活動路由器是否會從R1切換到R2，流量是否會被R2所接管，在主機上能否成功的ping通30.30.30.1?
第二步：在路由器R1上製造故障去shutdown路由器R1的S2/0和E1/1接口
R1(config)#intes2/0
R1(config-if)#shutdown *關閉S2/0
R1(config-if)#exit
R1(config)#intee1/1
R1(config-if)#shutdown *關閉E1/1
R1(config-if)#exit
系統提示：兩個接口的管理屬性爲down！
*Jul 24 11:24:11.047: %LINK-5-CHANGED: InterfaceSerial2/0, changed state to administratively down
*Jul 24 11:24:11.055: %LINEPROTO-5-UPDOWN: Lineprotocol on Interface Serial2/0, changed state to down
當路由器R1的S2/0和E1/1故障後，如圖3所示，故障成功被切換，中間存在幾個丟包是因爲切換故障的延遲所致，但是HSRP冗餘組中的活動路由器還是R1，備份路由器是R2，事實上，HSRP的角色狀態並沒有改變，而是路由協議來幫助用戶完成了故障轉移，並非HSRP的功勞。
具體分析如下：
首先在第一步之後，可以在R1上通過show standby brief查看HSRP的信息，如圖4所示，可看出，R1仍然是活動路由器，即便是R1的S2/0和E1/1關閉，但是由於HSRP並沒有配置track跟蹤接口功能，所以關閉接口的行爲不會造成HSRP的角色轉換。那麼此時的流量是如何被R2接管？那是因爲RIP動態路由協議幫助用戶網絡收斂。
在R1上通過show ip route指令查看路由表，如圖5所示，由於R1的S2/0和E1/1故障，所以通過這兩條鏈路的路由會隨故障的發生而收斂，消失在R1的路由表中，此時，具備2跳度量值的哪條路由（通過R2到30.30.30.1）會出現在路由表中，那麼R1就可以將主機發來的流量轉向投遞到R2，然後由R2發送到R3上的30.30.30.1，具體的證據如圖6所示，如果用戶在主機上跟蹤到30.30.30.1的路徑，不難看出，主機首先仍然將流量轉發給活動路由器R1，然後R1再轉發給R2，R2最後轉給目標。
路由協議去替代HSRP接管故障，切換流量的好處是網絡可以依賴於動態路由協議的收斂來完成故障轉移，其實這也是各大廠商推薦的一種方案，不足之處就是不同的動態路由協議的收斂速度不同，可能會爲網絡造成更大的收斂延遲，關於這一點後面會有實驗來證明；另外它對於HSRP的初學者而言，可能造成對技術知道點的混淆，比如：沒有配置跟蹤track功能，也能收斂那麼跟蹤功能還有什麼意義。
第三步：如果此時不讓路由器R1的E1/0接口從R2學30.30.30.0的路由，那麼動態路由協議RIP將無法替代HSRP幫助用戶去接管故障。先恢復在R1上切斷的兩個接口，等待RIP再次收斂，還原到如圖7所示。
爲了阻止RIP通過R2去替代HSRP的故障接管，在路由器R1上使用路由過濾列表來阻止路由器R1從連接R2的E1/0接口學習到30.30.30.0的路由，具體配置如下：
在路由器R1上配置路由過濾列表：
R1(config)#access-list 1 deny 30.30.30.0 0.0.0.255 *使用ACl拒絕30.30.30.0
R1(config)#access-list 1 permit any * 允許其它網絡
R1(config)#router rip
R1(config-router)#distribute-list 1 in e1/0 * 將ACL列表1應用到RIP進程E1/0的入站上
R1(config-router)#exit
如果此時再次去切斷路由器R1的S2/0和E1/1，動態路由協議RIP再也無法幫助用戶完成收斂，去接管用戶流量，而當前的HSRP並沒有配置track功能，沒有去跟蹤外部接口S2/0和E1/1的狀態，當兩個外部接口關閉後，HSRP狀態不會改變，不會讓R2接管R1成爲活動路由器，所以主機將一直丟包，如圖8所示。
第四步：首先請使用no shut指令再次恢復R1上的兩個接口（S2/0和E1/1），然後配置路由器R1的HSRP去跟蹤S2/0和E1/1。使用HSRP的接口跟蹤功能去替代路由收斂的故障接管行爲，具體配置如下所示：
配置路由器R1的接口跟蹤功能：
R1(config)#intee1/0
R1(config-if)#standby1 track s2/0 5 * 跟蹤S2/0接口，如果故障優先級減5
R1(config-if)#standby1 track e1/1 20 * 跟蹤E1/1接口，如果故障優先級減20
R1(config-if)#exit
從實踐的角度來講爲什麼在跟蹤兩個不同接口時會作出這樣的優先級設計？
從實驗環境不難看出，路由器R1的S2/0是一條低速鏈路，R1和R2的以太網鏈路具備同等的收發速率，就即便是R1的S2/0故障，R1也和R2具備相同的發送速率，所以沒必要S2/0故障後，進行HSRP的角色轉換（將R2活動路由器），所以使用standby 1 track s2/0 5指令申明當S2/0故障後，HSRP的優先級只減少5，那麼R1就會從原來的優先級110，變爲105，仍然高於路由器R2的優先級100，所以R1仍然會是HSRP冗餘組中的活動路由器。
路由器R2是不會接管故障，斷續充當備份路由器的角色，這樣做的最佳實踐是，省去了收斂時發生丟包的可能。
如果R1的E1/1接口故障，效果就完全不同，如果R1的E1/1故障，即便是S2/0仍然存活，如果不將HSRP冗餘組的路由器進行角色轉換（將R2轉爲活動路由器），那麼整個企業網絡的流量都將通過R1的低速鏈路S2/0進行轉發，這樣會導致鏈路的利用率下降，所以使用指令standby 1 track e1/1 20申明，跟蹤R1的E1/1，如果E1/1故障，那麼優先級將下降20，從原來的110變爲90，那麼些時R2的優先級100就高於R1的90，那麼R2將接管故障，成爲HSRP冗餘組中的活動路由器，流量將切換到R2進行轉發。
完成上述的配置後，可以通過指令Show standby來查看R1當前的優先級、各個跟蹤鏈路優先級的遞減值，如圖9所示。
第五步：通過製造R1的E1/1故障的現象來驗證R2接管故障的事實，如下所示的配置，在路由器R1上切斷E1/1接口。
R1(config)#intee1/1
R1(config-if)#shutdown
R1(config-if)#exit
系統提示：跟蹤狀態E1/1從up轉爲down。
*Jul 24 11:43:52.967: %TRACKING-5-STATE: 2 interfaceEt1/1 line-protocol Up->Down
然後在路由器R1上執行show standby查看當前HSRP冗餘組的狀態，如圖10所示，可看到E1/1的狀態爲down，優先級減少20，當前優先級爲90，活動路由器爲R2。然後在主機上執行路由跟蹤，如圖11所示，可看到流量通過R2（172.16.1.2）轉發。
動態路由協議RIP引發HSRP的慢收斂問題：
注意在本實驗環境的第五步中，當路由器R1的E1/1發生故障，172.16.1.0/24子網的主機在做故障切換時，有部分主機可能會很可能會收斂很慢如圖12所示，而另一部則收斂很快，現在需要來理解清楚目標是：
1 哪些主機收斂慢，哪些主機收斂快，這是爲什麼？
2 是什麼原因導致收斂慢？
首先來分析當路由器R1的E1/0故障後，由於HSRP的冗餘跟蹤了該接口所以會立即觸發HSRP的故障切換，此時R2會成爲HSRP組中的活動路由器，172.16.1.0到30.30.30.0的流量將如圖13所示通過R2到達，這是不可質疑的，所以去往30.30.30.0的通信流量很順利。造成長時間（至少180秒）的收斂的原因主要出現在30.30.30.0返回給172.16.1.0網絡的通信過程中。
衆所周知的一個事實，RIP的收斂一直都是一件非常令人頭痛的問題，特別是非本地直連接口故障後，路由表中的相關記錄要守侯invalid（無效定時器）超時，默認情況下180S,這條故障的路由纔會從路由表中消失，以該本環境爲例，當路由器R1的E1/1接口故障，路由器R3的路由表中“172.16.1.0 255.255.255.0 192.168.1.1”這條路由要等待180秒左右，也就是3分鐘纔會從表中消失，如圖15所示，那麼在這3分鐘左右整個網絡將發生什麼樣的事件呢？
如圖14所示，30.30.30.0的返回目標172.16.1.0網絡的通信流量時，在180秒內將在三條路徑上進行負載均衡，已經故障的鏈路R3的E1/0，因爲“172.16.1.0 255.255.255.0192.168.1.1”這條路由沒到180秒，還存在於路由表中，所有只要是通過“172.16.1.0255.255.255.0 192.168.1.1”這條路由返回給目標172.16.1.0的數據都會出現丟包，而且時間在三分鐘左右，收斂慢。
這將進一步引出一個問題:172.16.1.0主機在故障切換的這個過程中，一些主機故障收斂較快，丟包很少，一些主機收斂很慢，會有長達3分鐘左右的丟包，關鍵是哪些主機收斂快，哪些主機收斂慢，這是爲什麼原因？
這被R3的ip cef的負載均衡模式所決定，在R3上RIP沒有收斂的180秒內， 路由表還維繫在如圖15所示的狀態下，30.30.30.1將仍然使用“172.16.1.0 255.255.255.0192.168.1.1”這條路由來返回流量給172.16.1.0，默認情況下R3的ip cef的負載均衡方式是：如果存在多條路徑（本環境中有三條），那麼30.30.30.1將根據不同的目標主機來完成負載均衡，爲了方便理解，舉一實例來說明：如圖16所示，當流量從30.30.30.1返回給172.16.1.0網絡時，172.16.1.0網絡的主機就是目標，那麼R3的ip cef決定根據不同的目標主機使用三條路徑來完成負載均衡，此時的172.16.1.101、172.16.1.100、172.16.1.102三臺主機就是三個不同的目標，如果到目標172.16.1.101使有E1/1返回流量，那麼收斂快；如果到目標172.16.1.100使有S2/0返回流量，收斂也快，因爲這兩條鏈路都是穩定的不需要RIP作收斂，但是到目標172.16.1.102在180S內就會出現持續的丟包，收斂慢，直到故障路由從R3的路由表中消失，如圖17所示，才能順利完成收斂。當然管理員可以在R3上通過clear iproute *來強制初始化R3的路由表，可以提高收斂的速度，但是這個解決方案過於極端，特別是在工業生產環境中，是不建議這樣做的。
通過上述的分析與實驗取證，大家應該能夠體會到一個事實：往往一個網絡現象或者故障並不是某一個技能知識點所引發，它可能是藏於一個知識點的背後，也可能是多個知識點進行集成應用時發生的，建議大家在網絡工程領域始終不要以“一個點”的方式來看待發生的問題，應該進行聯動分析，綜合取證。
以該環境爲例，大家看到了矢量路由協議在實戰應用環境中的確如各個設備生產商所述的收斂是一個很大的問題，那麼在該環境中，來使用靜態路由去替代RIP並接合HSRP來完成冗餘部署是否會有更好的效果，就本人看來問題更嚴重，如果不建立預設分析，那麼用戶將永遠不知道將生什麼，發生的原因，及如何解決？