寫在前面：
在之前的一篇文章中，我們已經講過Eigrp是如何計算重分佈路由的metric值的過程。在實際生產環境中，我們常常會針對重要的外聯單位，部署兩條運營商線路以保障業務的連續性。由於對端外聯單位的特殊情況，常常不允許我們配置動態路由協議，以實現線路的自動切換，我們可能只能通過配置靜態路由實現與對方網絡的路由可達。在這樣的情況下，我們往往需要使用靜態路由結合Track，在通過track結合SLA，以實現線路的自動切換。
下面我們來看具體的例子。
實驗環境：
VPC：10.1.2.2
在7206VXR上面起環回口 loopback 100：10.1.1.1
7206VXR1、7206VXR2、7206VXR3、7206VXR4配置EIGRP動態路由協議。
在7206VXR1上，重分佈直連路由。
在7206VXR3和7206VXR4上，將10.1.1.0的路由指向7206VXR，並重分佈靜態路由。
通過重分佈靜態路由Metric的設置，實現在7206VXR1上看，到達10.1.1.0的路由，優先走R4，其次走R2。
在VXR1上看，路由如下圖：
也就是主線路在7206VXR4，備線路在7206VXR3。
經驗證，VPC可以ping同VXR上的環回口loopback 100.
初步使用：
首先講一下上述環境中靜態路由結合Track和SLA的初步使用方法
實現思路：在主線路的設備上，靜態路由上配置Track，實現當Track Down的時候，靜態路由失效，從而去往10.1.1.0的路由，不會在VXR4上重分佈成功，使得在VXR1上看到去往10.1.1.0的路由指向R2，使得路由走備線。同樣，最好在VXR上，針對10.1.2.0的也配置Track，實現數據包的來回路徑一致。如果數據包來回路徑不一致，可能導致穿越防火牆時無法正常轉發的情況存在。
下面開始進行配置：
ip route 10.1.1.0 255.255.255.0 172.16.1.2 track 10
track 10 ip sla 10 reachability
ip sla 10
icmp-echo 172.16.1.2
ip sla schedule 10 life forever start-time now
!
我們可以查看當前Track的狀態
我們在VXR上，也進行相似的配置，如下：
ip route 10.1.1.0 255.255.255.0 172.16.1.2 track 10
track 10 ip sla 10 reachability
ip sla 10
icmp-echo 172.16.1.2
ip sla schedule 10 life forever start-time now
!
這裏，我們配置兩條靜態路由，通過配置不同的管理距離，實現去往10.1.2.0的路由主走主線路，當主線路失效時，走備線路。
首先，我們在VPC上ping測試，在R4上抓包確認去包與回包，都走主線路。
可以看到，去包與回包路由，都走的主線路。
下面，我們在VXR上，將主線路接口down掉，測試是否能夠主備線路切換成功。
（這裏由於是模擬器環境，對端接口down，本段接口並不會down，這於通過運營商mstp線路連接兩端的現象剛好一致）
在等待了一段時間後，重新ping通，線路切換成功。
優化使用：
然而，這裏我們看到，在丟了26個包後，才ping通。這個切換速度，在生產環境中顯然是不可忍受的
查看抓包情況
在71秒後，去往VPC去往10.1.1.1的ping包依然從VXR4的接口上發出，但由於對端接口down了（這裏由於模擬器的原因，本端接口沒有down）。對端根本不會收到該ping包，自然也不會迴應。
直到122秒後，由於線路切換完成，在VXR4上抓包再看不到VPC的ping包，從該路由器發出。
這說明，業務大約中斷了51秒，這顯然是生產環境中不可接受的。那麼是什麼導致了線路切換花費了這麼長的時間呢。
通過仔細查看抓包可以看到，在第55秒，VXR4剛發送了SLA的探測包，得到了對端的響應。
之後，直到115秒，VXR4才發出第二個SLA探測包。
也就是說，直到這時，VXR4才知道，對端不可達，將Track的狀態置爲Down.
之後，在VXR4上的靜態路由纔會失效，經過約7秒時間，去往10.1.1.1的ping包，不再從VXR4發出。
這個時間爲路由收斂的時間，是由於在VXR1中並沒有可行後繼，我們在VXR3上，設置了靜態路由管理距離爲200，這大於Eigrp外部路由170，靜態路由並沒有被提交路由表。也就是說此時，在VXR3上靜態路由根本沒有被重分佈進來。所以當VXR4告知，本地靜態路由失效，重分佈失效時。要等到VXR3收到這一消息，路由表中Eigrp重分佈路由失效，靜態路由生效時，VXR3上靜態路由才重分佈成功。之後再將此路有消息進行更新。所以這一過程，同樣消耗了較長的時間。
通過上述的分析，我們可以看到這是由於VXR4上SLA的探測包發送的間隔爲60秒，這導致當線路發生中斷時，VXR4上最長可能需要60秒，等到下一次探測包發出時，才知道對端不可達。
這裏我們可以通過優化SLA發送探測包的間隔時間，加快收斂速度。
加快收斂速度：
配製方法如下，在VXR4上
ip sla 10
icmp-echo 172.16.1.2
frequency 10
同樣，在VXR上，也需要進行相似的配置，否則仍然會導致切換時間較長。在這裏不再重複了
配置之後，我們進行切換測試
我們可以看到，切換速度明顯加快了。
通過抓包我們也可以看到，此時SLA探測的時間爲10秒
這裏，我們知道，通過修改sla的探測間隔時間，可以有效提高線路切換的速度，進而提高業務連續性。
特殊情況的處理：
在一些特殊情況下，可能出現線路質量不穩定的情況。具體表現爲時通時不通，在這樣的情況下，可能導致線路的頻繁切換，嚴重影響業務。
面對這樣的情況，我們可以延遲Track Down和 UP的時間，減少線路質量較差頻繁的對業務連續性造成影響。
延遲Track Down可以用來避免，一旦檢測到主線路丟包，就立即切換的情況發生。因爲一次sla icmp檢測只ping一個包，這存在一定的偶然性
配製方法如下：
ip sla 10
icmp-echo 172.16.1.2
frequency 10
延遲Track UP可以用來避免，主線路其實還未恢復至穩定，就導致回切，影響業務的情況。
配製方法如下：
!
track 10 ip sla 10 reachability
delay up 30
!
經實際驗證，該配置會在SLA檢測後，延遲對Track狀態的改變。以減緩線路質量抖動，造成線路頻繁切換，而對業務造成影響。
其他：
查看Track與SLA狀態的方法
show track
show ip sla summary
show ip sla history
其中需要注意的是，要想查看SLA歷史信息，需要在配置SLA時，開啓記錄歷史信息和設置過濾器，設置方法如下：
R4(config)#ip sla 10
R4(config-ip-sla-echo)#history lives-kept 2
R4(config-ip-sla-echo)#history filter all
這樣便可以看到SLA的歷史信息了
其中，CompT代表測試包來回所花費的時間，Sense代表返回碼，1爲正常，4爲故障。
我們可以通過查看歷史信息的方式，查看線路故障時的具體情況。