ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Cisco路由器打环测试详解:链路故障定位与排查实战

Cisco路由器打环测试详解:链路故障定位与排查实战 搞网络的人谁没经历过这种时刻一条专线断了两边的工程师对着甩锅你说你设备没问题他说他设备没告警中间运营商说链路都是好的结果问题悬在空中没人管。这时候最该做的不是跟人争论而是先跑一轮打环测试用数据把故障边界切出来。Cisco路由器上的打环测试是我这几年处理链路故障时最常用也最有效的手段今天把这套思路和实操步骤完整写出来希望能帮到正在被类似问题折磨的朋友。这篇文章适合谁看不管是做企业网运维、ISP接入维护还是刚入行不久还不太敢在现网设备上敲命令的网工新兵都能从里面拿到一套可直接复用的排查流程。打环测试本身不复杂真正难的是理解每一步操作在验证什么以及拿到结果之后该怎么判断。我会把原理、命令、判断逻辑和踩过的坑都展开聊。1. 打环测试到底在测什么1.1 打环测试的核心逻辑打环测试英文叫loopback test核心逻辑就是一句话把设备发送出去的数据信号在链路的某一个物理点或逻辑点上直接折返回来。这样一来本端设备发出的数据如果能够原路收回来就说明从本端设备接口到打环点之间的这一段链路是完好的。这个概念可以用一个特别生活化的例子来解释。想象你站在一段走廊里前面拐了个弯看不见走廊那头有没有人。你想确认走廊是不是通的最简单的方法不是走过去而是喊一嗓子如果听到回声说明前方没有完全堵死至少声音能弹回来。打环测试本质上就是这个操作——设备喊一嗓子如果数据能转个圈回来链路就是通畅的。在实际的链路故障排查中我们通常把整条物理链路拆成三段来看本端设备接口、中间传输链路光缆、线缆、运营商网络、对端设备接口。打环测试的价值就在于它能帮你精准定位问题到底出在哪一段而不是整个链路一起拍脑袋猜。1.2 打环测试适用的场景与链路类型打环测试最常出现在两类场景里。第一类是专线业务开通验收无论是运营商的MSTP专线、SDH专线还是企业自建的光纤直连交付验收时打一遍环两边设备接口状态和协议都能正常起来这条链路才算真正可用。第二类是现网运行中的突发故障排查比如某条链路昨天还好好的今天接口突然down了或者业务时通时断这时候打环能快速把责任边界切出来。适用的链路类型也比较集中。最常见的是以太网链路包括光口和电口其次是老一些的同步串口比如V.35、RS-232这类接口尽管现在新设备上不太常见了但某些专网和工业场景里仍然大量存在还有E1/T1控制器线路这类在运营商接入侧依然很活跃。不同链路类型的打环方式有差异但判断思路是一致的。2. 动手前的准备清单2.1 工具准备与登录方式打环测试看似就是插个光纤、敲几条命令但准备工作做好能省掉很多不必要的折腾。先说物理工具如果是光口打环需要准备一条光纤跳线最好是单模对单模、多模对多模另外要看清接口类型是LC、SC还是其他别到了现场才发现跳线头子对不上。如果是电口打环需要做一对环回头就是把RJ45头的1、2脚和3、6脚分别短接起来这种环回头在某宝上几块钱一个也可以自己用网线钳压一个非常方便。登录设备这一块console线是必须带的。为什么强调console因为打环测试经常会把接口状态弄到反复up/down如果走带内管理SSH、Telnet极有可能在操作过程中因为接口震荡导致管理会话中断。用console线登录物理链路再怎么折腾你的管理通道都不受影响。我早期就吃过这个亏远程登录设备做完打环测试接口一shutdown自己跟设备的连接也断了人在办公室设备在机房叫天天不应。2.2 识读接口状态与关键计数器正式打环之前先要把设备的当前状态看清楚不然打环之后得到的结论是不完整的。最基础的是看接口状态和协议状态在Cisco IOS设备上。Router# show interfaces GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Hardware is C9300-1P, address is 001c.5841.9a80 Internet address is 192.168.10.1/30 MTU 1500 bytes, BW 1000000 Kbit/sec Reliability 255/255, TXload 1/255, RXload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full Duplex, 1000Mbps, link type is auto ... Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 ... 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 103456 packets input, 84562310 bytes Received 234 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 98765 packets output, 76543210 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets ...这里有几个关键信息要养成扫一眼就记住的习惯。第一行就说明了接口状态和协议状态这是最直接的结果。其次要看CRC错误计数如果CRC一直在涨说明链路上有误码物理层质量堪忧。还要看input errors、interface resets这类计数器它们能反映接口层面的异常。另外如果你的设备有光模块一定要看一下光模块的数字诊断信息。Router# show interface transceiver GigabitEthernet0/0 transceiver is present type is SFP-GE-SX-MM850 name is FINISAR CORP. part number is FTRJ8519P1BNL-C8 ... Laser bias current: 6.142 mA Laser output power: 0.3235 mW (-4.90 dBm) Module temperature: 41.20 C Module voltage: 3.3040 V Rx optical power: 0.0943 mW (-10.25 dBm)光模块的收发光功率很直观。如果接收光功率在灵敏度临界值附近哪怕接口状态是up的业务也会间歇性出问题这种隐患光看接口状态是发现不了的。2.3 分清物理环回与逻辑环回打环测试刚入门的人最容易混淆的就是物理环回和逻辑环回。物理环回就是用跳线或环回头在物理层面上把收发信号接通比如光口用一根光纤跳线把TX和RX连起来电口用环回头把收发脚对接。这种环回方式最真实它验证的是从接口芯片到物理介质这一段完整通路。逻辑环回则是通过设备软件命令直接把接口的发送数据在芯片内部返回给接收方向不经过物理线路。这种方式适合在设备侧单独验证接口硬件和驱动是否正常。在实际排查中两种方式经常配合使用先做逻辑环回验证设备本身没问题再做物理环回验证线路问题一步步缩小范围。3. 实操Cisco路由器打环测试全流程3.1 光口与电口的物理打环操作步骤物理打环的操作看着简单但细节上容易翻车。先说光口。把光纤跳线一端拔下来直接插到同一个光模块的接收口上相当于把该接口发出的光信号又送回到自己的接收端。这里有个容易忽略的点光模块的TX和RX口一定要分清楚通常收发口是并排的一个是发射一个是接收。如果跳线两端都插同一个模块是没办法完成的正确做法是用一根跳线的两个头分别接同一个模块的TX和RX形成一个回路。操作路径是这样的在设备端把GigabitEthernet0/0的接口先shutdown然后拔掉连接对端设备的光纤插入环回跳线再重新no shutdown观察接口状态变化。电口打环的思路一样用环回头插到RJ45电口上把发送线对和接收线对短接。以百兆电口为例1、2脚是发送3、6脚是接收环回头内部把这四根线对应短接信号就构成了回路。物理打环之后接口状态一般会出现两种情况。如果接口状态和协议状态都变成up说明本端设备接口、光模块/电口、物理线路这一段都没有问题问题大概率出在对端设备或者远端链路上。如果打环后接口还是down说明问题在本端接口或光模块上可以尝试更换光模块、检查接口配置再继续排查。3.2 利用接口命令进行逻辑环回Cisco路由器上某些类型的接口支持直接配置环回模式这样就不用物理插线了。最常见的是一些串行接口和E1/T1控制器接口。以同步串口为例。Router(config)# interface Serial0/0/0 Router(config-if)# loopback Router(config-if)# no shutdown配置了loopback之后串口发出的数据会在设备内部直接返回到接收路径接口的协议状态也会变为up。这种模式下本端设备可以自己对自己做完整的协议协商测试非常方便。测试完之后记得把loopback关掉。Router(config-if)# no loopback对于E1/T1控制器Cisco设备上的环回设置更精细一些分为线路环回和负载环回。Router(config)# controller E1 0/0/0 Router(config-controller)# loopback {line | payload | network} Router(config-controller)# no loopbackline模式是把远端发来的信号直接环回发送方向payload模式是把净荷数据做环回network模式则是在网络侧接口做环回。这些模式在运营商链路对接测试时非常常用因为可以和运营商测线路的人配合两端各打一次环就能快速判断故障在哪一段。普通以太网接口在Cisco IOS上一般没有直接配置环回的命令这类接口要打环基本靠物理跳线。不过有些交换机平台上有专门的诊断命令可以模拟环回测试这个后面会提到。3.3 使用扩展ping与traceroute验证转发路径打环测试不只是测物理层很多时候还要验证数据平面转发路径是否正常。这时候扩展ping就是最强工具它能精确控制源地址、目的地址、报文大小、发送次数等参数。Router# ping Protocol [ip]: Target IP address: 192.168.10.2 Repeat count [5]: 100 Datagram size [100]: 1400 Timeout in seconds [2]: 2 Extended commands [n]: y Source address or interface: Loopback0 ... Sending 100, 1400-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max 1/2/4 ms为什么建议用大报文、多数量ping因为很多间歇性丢包问题在默认的5个64字节小包测试里根本暴露不出来只有用大包配上一定数量才能触发误码导致的丢包。另外指定源接口也很重要特别是在验证多路由场景时不指定源接口的话设备可能选了一条你意料之外的路径去ping。traceroute在验证路径时也有独特价值。打环测试如果只做物理层你只能知道链路通不通但不知道流量实际走了哪条路。用traceroute可以看到从本端到远端每一跳的延迟情况一旦某一段延迟异常高问题点就比较明显了。Router# traceroute 192.168.10.2 Type escape sequence to abort. Tracing the route to 192.168.10.2 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.10.2 1 msec 1 msec 1 msec3.4 打环测试完成后的收尾工作打环测试最容易被忽略的环节就是收尾。测试完了跳线不拔环回头不取直接接入业务结果整个网络就出现环路异常这种低级错误在行业内已经反复出现太多次了。我个人的习惯是一定要形成完整的操作闭环测试开始前记录当前接口状态和所有计数器数值测试过程中每一步操作都对应记录结果测试结束后先确认所有环回物理连接都已拆除、所有loopback命令都已执行no loopback然后再次查看接口状态确认恢复到正常业务状态。还有个细节拆掉环回后接口可能不会立刻恢复up需要观察一段时间特别是光口可能要等链路重新协商完成。如果几分钟后接口还是down就要检查光纤连接是不是恢复到位了。4. 常见故障现象与排查思路4.1 打环后接口依旧down问题锁定在本端设备如果在本端接口做了物理打环接口依然无法up这种结果至少能说明两个方向的问题。一是本端接口硬件故障包括接口芯片损伤、光模块烧毁、电口变压器损坏等另一个可能是接口被软件层面强制down了比如配置了shutdown或者被err-disable机制关闭了。排查动作也很明确。先用show interface查看接口的当前状态描述如果显示为administratively down那就是配置层面被关了执行no shutdown即可。如果显示为err-disabled查看具体原因常见的有udld、bpduguard、transceiver mismatch等根据原因做恢复处理。如果接口状态是down而且不是因为配置导致的那大概率就是硬件问题了。可以尝试把这条跳线换到设备上另一个确认正常的接口上再打环如果还是down基本可以判定跳线或模块有问题如果另一个接口正常up那问题就在原来的接口上。4.2 接口up但路由协议起不来二层协商异常还有一种常见的现象是物理打环之后接口状态显示up但line protocol是down。这说明物理层的信号已经通了但在二层协商阶段出了问题。最常见的原因是keepalive机制Cisco设备默认在串口和某些以太口上开了keepalive如果打环点到本端之间的链路不能正确返回keepalive报文协议状态就会始终down。以太网接口的协商问题也很典型特别是自协商。如果本端或对端强制配置了双工和速率和另一端不支持或配置不一致就会出现接口up但协议down或者能通但大量CRC错误。排查的时候可以先强制关闭自协商把速率和双工模式固定下来看看是否恢复正常。Router(config)# interface GigabitEthernet0/0 Router(config-if)# speed 1000 Router(config-if)# duplex full4.3 CRC错误与误码率过高光路质量才是真凶很多故障场景里接口是up的业务也能跑但就是间歇性丢包延迟忽高忽低。这类问题在打环测试里最容易看到的现象就是CRC错误数不断上涨。所谓CRC错误就是接收端对收到的数据帧做循环冗余校验时发现不匹配说明数据在传输过程中发生了比特错误。打环测试在解决这类问题时能做两件事。第一通过物理打环确认误码是否来自中间链路如果本端打环后CRC停止增长说明中间链路或对端有问题如果CRC还在涨说明本端接口或光模块自身有问题。第二通过光模块的DDM信息查看接收光功率如果接收功率低于模块的接收灵敏度光路就需要检查了。常见的处理手段包括用光功率计逐段测量、清洁光纤接头、更换尾纤、检查法兰盘连接质量。4.4 一不留神打出广播风暴环路与打环的区别这里必须专门提醒一个容易踩的大坑打环测试只能做在点对点链路上绝对不能随便在接入业务网络的交换端口上做物理打环。原理很简单如果这个接口所在网络里有二层交换路径打环会把本端发出的广播帧在接口处又送回来同时交换机还会把收到的报文从其他端口转发出去一旦网络里存在多条路径就可能形成二层环路进而引发广播风暴导致整个网络瘫痪。在我见过的事故案例里有人为了测试一条接入链路直接在接入交换机端口上插了环回头。结果这个接口的VLAN里挂了几十台终端广播报文在交换机内部来回转发CPU占用率直接飙升到接近100%网络卡到完全不可用。所以打环之前一定要想清楚这个接口是三层路由口还是二层交换口接口所在的VLAN里还有没有其他路径5. 跨厂商操作对比与经验总结5.1 Cisco、华为、华三打环操作的小差异虽然我主要用的是Cisco设备但实际运维中经常要跟华为、华三的设备打交道这里顺便把打环操作的差异点提一下。华为的设备叫法不同接口环回可以在以太接口下配置loopback也可以指定internal和external分别对应内部环回和外部环回。[Huawei-GigabitEthernet0/0/0] loopback internal [Huawei-GigabitEthernet0/0/0] loopback external华三的设备操作风格更接近Cisco接口下配置loopback的模式比较直观同时支持对光模块做光功率检测。跨厂商配置逻辑大同小异核心思路都没变通过环回把链路分段逐段排除。真正需要留意的不是命令差异而是每个厂商对接口状态的表达方式不太一样判断结论时要结合各自设备的输出格式来理解。5.2 个人踩坑经验与几条建议写了这么多最后分享几个我实际工作中积累的小经验。第一个建议是打环测试必须做记录最好用表格记录每一步操作的时间、操作内容、接口状态结果。这不是形式主义而是当测试链路过长时回头整理结论的时候你会发现没有记录的工作等于白做。第二个建议是打环用的跳线和环回头一定要单独收纳、贴上标签跟正常业务用的跳线区分开。我见过机房运维人员随手把一根打环跳线留在配线架上两个月后另一拨人排查故障时被这根跳线干扰判断浪费了整整半天时间。第三个建议是测试前后都截取一份show interfaces和show interface transceiver的输出。截图比人脑记忆可靠太多尤其到了下午排查了七八个接口之后哪个接口原来有多少CRC错误已经完全记不清了有截图对比会轻松很多。打环测试这套方法论说到底是把复杂的链路故障拆解成一个一个可验证的小环节。它不需要什么高深的理论但确实是网工手里最可靠的一把尺子。以后遇到链路类疑难杂症别急着甩锅先打环用数据说话。
返回列表