寫在前面：

在之前的一篇文章中，我們已經講過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為故障。

我們可以通過檢視歷史資訊的方式，檢視線路故障時的具體情況。