双链路智能切换 - IP技术专栏 - 技术甜甜圈 - 新华三集团-H3C
有两种方案:
方案一(不推荐):
将原有线路和新增线路进行链路聚合,可实现流量负载和备份,由于是广域网线路,不推荐进行链路聚合,可能存在极端情况线路故障不能切换问题。
方案二(推荐):
将新增线路设置成三层路由模式,可通过新增加一条等价路由的方式实现流量负载,路由协议可以选用静态路由或者动态路由(ospf等)当其中一条链路故障时,流量会自动切换至另一条线路,同时建议在两条广域网线路上增加NQA检测配置,并绑定至路由上,用于实现流量自动切换。
一、 网吧老板的抱怨
这位淡定的网吧老板是这样反馈问题的:
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就完成了动作,网吧老板有丰富的时间去和电信反馈故障,同时网吧并未遭受到太多投诉。线路恢复,路由也自动恢复,相当省心给力。