写在前面：
在之前的一篇文章中，我们已经讲过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为故障。
我们可以通过查看历史信息的方式，查看线路故障时的具体情况。