双链路智能切换

在上一期中，我们介绍了非常给力的双链路网吧解决方案，但在实际使用过程中，仍然有很多网吧老板抱怨。

一、     网吧老板的抱怨

这位淡定的网吧老板是这样反馈问题的：

1.      为了构建“妥妥的网吧”，俺花巨资租用了电信、联通两条线路；

2.      在专栏的指点下，俺做了“负载分担双链路”解决方案，俺也专门拔掉电信或者联通线路测试，发现的确可以切换，俺觉得很带感；

3.      俺的双链路妥妥地运行了2个月，直到今天，使用电信线路的客户们说网络断了，而联通线路的PC还妥妥地；

4.      俺也不是菜鸟，Ping了一下电信的出口网关，Ping不通，很纳闷，Ping不通为什么不切换，阿丘在忽悠俺，俺要讨个公道。

二、     阿丘对这个问题的解答

首先，对这位网吧老板充满理性光辉的叙述方式表示赞扬，叙述简单明了，故障现象非常到位。要解决这个问题，首先就要扭转一个先入为主的观点——出口和ICG网关是点到点连接的。我们之前见到的网络拓扑图，感觉ICG网关和互联网出口都是直接（点到点）相连的，只要接口Up，线路就没有问题，互联网出口就可以通，对于接口依然Up，出口却无法访问这种事情简直闻所未闻。那么我们是不是应该怀疑一下我们的ICG网关和互联网出口是直接相连这个命题的正确性。

两家运营商——电信和联通对ICG这种用户网关的部署是海量的，而互联网出口则是以高性能著称，高性能的设备往往端口是有限的，在互联网出口的位置直接连接ICG网关的代价是不可接受的，运营商需要一种节约的方式——汇聚，将若干的ICG网关连接到汇聚交换机，如果汇聚交换机数量也是海量的，还可以对汇聚交换机再进行汇聚，其目的就是尽可能地将大量ICG网关的流量汇合起来，再统一通过高速的线路传输给互联网出口。从图上也可以看出，ICG网关的互联网出口，也就是默认路由的下一跳依然是在互联网出口上，非常给力地证明了我们怀疑的正确性。其实做维护工作就是要“大胆假设，小心求证”，如果要让我再添上一句话，那就是“大胆假设没关系，没有求证一场空”。

三、     既然假设了，我们就要求证

假设是电信汇聚交换机与电信出口的汇聚线路发生中断：

1.      ICG网关的线路依然正常，也就是说端口E0/0的状态依然是Up的；

2.      对于出接口是以太网接口（E0/0就是Ethernet0/0接口的简写）静态路由而言，以太网接口Up，这条静态路由就是Up的；

3.      ICG网关配置到互联网出口的是两条静态默认路由，所以在这种情况中，到电信出口的静态路由依然生效；

4.      由于电信静态路由生效，故有50%的PC选择这条线路，而我们知道由于汇聚线路故障，这50%的PC注定是杯具的。

那么，是不是说，我们的任务是修复汇聚链路呢？那我不得不说，这有点“越俎代庖”了，何解：

1.      ICG以上线路都是运营商维护；

2.      网吧老板是运营商的客户，理论上是享有使用互联网服务、投诉互联网服务的权利；

3.      维修互联网是电信的义务，而不是网吧老板的权利。

所以，网吧老板要做的是：

1.      拿起电话，拨打10000，告诉电信mm线路不通了；

2.      小mm肯定会询问你一些简单的技术问题，以判断网吧老板是真的线路故障还是故意来捣乱聊天的；

3.      那么，网吧老板就可以把刚开始向我反馈问题的方式，如实向小mm反馈一遍；

4.      据我的经验，小mm会喜欢这个理性、淡定的网吧老板的，会很快安排技术人员去检查、维修线路。

事情并没有完，电信只是答应去维修了，什么时候维修好，这就不好说了，网吧老板还营业呢，这段维修真空可不能让网吧业务有大的闪失。

四、     阿丘的解决方案

我们对Ping这个命令肯定很熟悉，我们通常利用Ping来判断线路正常还是不正常，比如在图中：

1.      我们在ICG网关上Ping电信出口地址6.16.5.6；

2.      Ping的过程分为两部分，首先是ICG网关发送回声探测请求给6.16.5.5（电信出口地址）；

3.      电信出口收到回声探测请求后，会进行回声探测响应，返回给ICG网关6.16.5.6。

如果ICG网关收到回声探测响应，我们就认为这次Ping成功了。

如果是因为任意一条线路故障，有如下2种可能：

1.      电信网关收不到回声探测请求，也就是说ICG网关发出去的任何数据都到达不了电信出口；

2.      电信网关收到了回声探测请求，但是回声探测响应在前往ICG网关的途中丢失，意味着电信网关发出的任何数据无法到达ICG网关；

3.      无论哪种情况，Ping的结果就是失败，更直接地说，就是上不了网。

因此，我们通常都是在怀疑线路存在故障的时候Ping一下，根据Ping的结果来判断线路正常与否。

现在的问题是，网吧老板必须在知道有人上不去网了，才去Ping，Ping完再去拨打10000，然后再进行线路切换，这估计会损失20分钟，20分钟对于网游玩家、视频聊天的情侣来说，是不可接受的，会给网吧带来很严重的损失，我们在想是不是有个自动的机制替网吧老板做这种事情。

下面有情NQA出场，NQA的全名叫网络质量分析（Network Quality Analysis），是用于测量端到端网络质量的，它的原理很简单：

1.      根据用户设置，定期执行一些操作，最简单的操作就是Ping（回声探测机制）；

2.      自动记录每次探测的结果，如Ping成功就是OK，失败就是FAILED；

3.      根据用户设置，自动根据结果采取动作，如连续3次FAILED，那么就触发机关；

4.      触发机关可以和一些特性关联，比如静态路由，机关一旦被触发，静态路由自动失效；

5.      有失效就有生效，也就是线路备份机制也被启发了，所有数据切换到备用线路。

从这里我们可以得知NQA相当于一个自动代理，执行探测、联动功能。这么带感的东东，你是不是很感兴趣呢，我们来看一下举例的配置吧：

#

// 创建NQA探测实体telecom，序号1

nqa entry telecom 1

 // 探测类型是ICMP-Echo，Echo翻译成中文叫回声

 type icmp-echo

  // 探测的目的IP地址是电信出口地址6.16.5.5

  destination ip 6.16.5.5

  // 设置next-hop也为6.16.5.5，防止从联通线路探测电信出口

  next-hop 6.16.5.5

  // 探测间隔为500ms

  frequency 500

  // 每个周期连续探测10次

  probe count 10

  // 探测超时时间2s，即探测发送后2s仍未收到响应，即认为探测失败

  probe timeout 2000

  // reaction意思是对探测结果的反应，下行配置翻译成中文就是如果连续3次探测失败将触发机关trigger

  reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only

  // 探测源接口是连接电信线路的Ethernet 0/0

  source interface Ethernet 0/0

  // 设置ttl为1，防止从联通线路探测电信出口

  ttl 1

#

 // 设置机关联动组track，联动组关联NQA探测实体telecom 1的反应1

 track 1 nqa entry telecom 1 reaction 1

#

 // 调度NQA探测实体telecom 1，从现在开始，永远探测

 nqa schedule telecom 1 start-time now lifetime forever

#

 // 将通往电信的默认路由和机关联动组track绑定

 ip route-static 0.0.0.0 0.0.0.0 6.16.5.5 track 1 description telecom

#

以上配置在实际过程中是这么操作的：

1.      线路正常情况下，NQA探测结果一直OK，所以不会触发机关；

2.      一旦线路故障了，NQA可以在3.5s内连续检测到3次FAILED，立即触发机关；

3.      机关被触发，立即联动电信静态路由失效；

4.      电信静态路由失效，联通线路立刻全权接管，整个过程在5s以内完成；

5.      如果NQA探测成功，机关触发取消，电信出口默认路由自动恢复。

这下网吧老板应该开心了，自己亲力亲为30分钟未必能解决问题，使用NQA机器人，5s就完成了动作，网吧老板有丰富的时间去和电信反馈故障，同时网吧并未遭受到太多投诉。线路恢复，路由也自动恢复，相当省心给力。