上周帮一家做在线教育的客户做路由调优,他们刚上了双链路BGP,想验证主备切换是否真能扛住故障。结果一提“做冗余测试”,运维同事立马皱眉:“得凌晨两点停课两小时?”——其实真没必要。
冗余测试≠断网演练
很多人把“测冗余”默认等同于“拔光纤”“关主设备”,这容易误入歧途。真正的网络冗余能力,核心是看流量能否在毫秒级内自动绕行,而不是靠人工制造中断来倒逼故障。
比如你用的是双上联交换机+OSPF动态路由,只要配置了合理的cost值和快速收敛参数(如timers spf 1 4),主链路出问题时,流量几秒钟就切到备用路径,用户刷课件、传作业根本没感知。
不中断业务的几种实测方法
① 模拟链路劣化,不切断
用Linux的tc命令给主出口加丢包或高延时,观察BFD会话是否超时、路由表是否刷新:
tc qdisc add dev eth0 root netem loss 90% delay 500ms等30秒再恢复:tc qdisc del dev eth0 root整个过程业务照跑,还能看到路由协议怎么一步步降级、切换。② 切换控制面,不动转发面
在核心路由器上临时修改OSPF的Router ID或优先级,触发LSA重泛洪和SPF重计算,但数据平面仍在正常转发。这时候看监控里的BGP邻居状态、ARP表更新延迟、TCP重传率有没有异常飙升。
③ 利用现网流量做探针
不用额外发包,直接抓取业务服务器出口的镜像流量,用Wireshark过滤ICMP或TCP SYN包,对比主备路径上的TTL、RTT、分片情况。如果主链路突然出现大量TTL=63(说明经过了一跳新设备),基本就是已触发切换。
哪些情况确实得停业务?
只有一种:你的冗余架构本身就不支持热切换。比如老式双机热备防火墙用的是主-从模式,备机不处理任何流量,连心跳都靠串口;或者H3C某款旧交换机的VRRP不支持track接口联动,只能靠手工shutdown接口来触发倒换。这种不是测不出来,而是架构决定了它本来就不能在线切换——该升级设备了,别硬测。
说到底,冗余测试的目的不是“证明我能断一次”,而是“确认我不断也能稳”。测之前先翻翻设备手册里BFD检测间隔、路由收敛时间、ECMP哈希算法这些参数,比半夜拔线靠谱得多。