IPRAN故障案例分析：从告警风暴到根因定位的四步排查法

简介：一份面向通信网络运维与故障排查人员的IPRAN故障案例分析文档，以某站点设备频繁闪断、影响下挂4个3G站点和3个4G站点业务为切入点，完整还原从收到告警、关闭端口临时管控，到逐步排查与最终定位的全过程。文档细致记录了光模块收发功率检查（含show perf-value interface命令输出）、设备温度与风扇状态核查、ZXR10路由器及ZXCTN 6220软件版本确认等关键操作，并结合数据判定高温导致板卡假死是故障主因，随后给出检查散热、待温度恢复后重启板卡等处理思路。资源为单个doc文件，压缩包仅42KB，便于下载后离线阅读；目前已有148人学习。通过该案例可学习设备闪断类故障的分层排查方法，理解临时保护措施对业务连续性的重要性，对提升IPRAN网络维护和应急处理能力具有直接参考价值。

1. IPRAN故障案例分析：为什么一份案例文档比一堆告警更值钱

凌晨两点，网管屏幕上瞬间刷出上百条告警，基站批量退网，领导电话一个接一个。这个时候你对着IPRAN设备，很容易被告警风暴带着走，越看越乱。IPRAN故障案例分析要解决的，正是这种“有告警、没方向”的困境：把散落在设备里的故障现象、配置参数、处理动作整理成可复用的判断路径，让下一次遇到同类问题时，不用再从零开始排查。这份笔记适合一线维护、承载网优化和二线技术支持，也适合刚接手IPRAN网络的网工——先看清故障长什么样，再学怎么动手。

2. 先从IPRAN组网和故障分类说起：分清接入、汇聚、核心的故障域

2.1 IPRAN组网的三层模型：接入环、汇聚环、核心节点

IPRAN这个名词在LTE和5G承载网里出现频率很高，全称是IP Radio Access Network，本质上是为基站回传服务的IP/MPLS网络。常见组网是三层：接入层、汇聚层、核心层。接入层一般由接入环上的接入设备组成，基站侧业务从这里进网；汇聚层负责把多个接入环的流量收拢，再往上送到核心层；核心层则连接核心网设备，完成业务终结和转发。很多人排查时容易忽略一个点：IPRAN的故障范围往往是跟网络层级绑定的，接入层的问题多数只影响某个环上的站点，汇聚层的问题会拖垮多个环，核心层一旦出故障就是大面积业务中断。

所以拿到一个故障，第一步不该急着上设备敲命令，而是先在拓扑里确认故障影响范围落在哪一层。我一般会先登录网管，按“网元—子网—环”的层级展开拓扑，看告警网元和受影响业务的位置。如果只有接入环上的两三个站点告警，优先怀疑接入侧链路和光模块；如果是多个接入环同时异常，问题大概率在汇聚或核心侧。这个判断方向要是不对，后面很容易在接入段反复测试，忽略核心段的黑匣子。

从命令侧也能快速确认设备角色。在华为IPRAN设备上，可以通过接口描述或环网协议状态分辨：

display interface loopback 0 display nni-info

第一条命令查看设备loopback地址，通常loopback地址规划按接入、汇聚、核心分段，地址段能直接对应设备层级。第二条命令查看NNI（Network-to-Network Interface）接口信息，NNI接口数量多的，一般是汇聚或核心设备；接入设备则更多是UNI接口接基站。这个判断在开站维护时非常有用，能避免你在错误的设备上找不属于它的故障。

2.2 故障分类表：链路类、业务类、同步类、设备类的判断特征

IPRAN网络里，故障类型看似五花八门，归纳下来无非四类：链路类、业务类、同步类、设备类。链路类指光纤、光模块、接口物理层异常，表现通常是误码、丢包、接口up/down；业务类指PW（伪线）、LSP（标签交换路径）、隧道等承载通道异常，表现是基站业务断断续续或直接不可达；同步类指频率和时间同步失步，表现是基站切换失败、时延突然变大；设备类则指单板、电源、风扇等硬件故障，表现是设备重启、告警板卡异常。

为了快速判断是哪一个域，我习惯用一张特征表做初步定界：

这张表不是让你直接得到答案，而是帮你把排查范围收窄。比如现象是“基站业务闪断”，但接口up时间正常、误码清零，那链路类可以先放一放，重点查业务类和同步类。反之，如果接口误码持续增长，那就不用急着动隧道配置，先解决物理层，否则改多少配置都是白搭。

业务类的判断要特别注意“群故障”和“单点故障”的区别。单站点不通，大概率是接入环节点本身或末端链路问题；整环、整汇聚域不通，往往是隧道或路由层面的问题。我遇到过不少新手，单个站点不通非要去查核心路由，结果绕了一大圈，最后发现是接入环上一根尾纤被老鼠咬断。所以分类表里的“优先排查方向”，优先级应该按物理层、业务层、时钟层、硬件层这个顺序走。

3. 用标准排查流程定位IPRAN故障：从告警到根因的四步法

3.1 告警过滤与故障定界：先看链路还是先看业务

告警风暴是IPRAN故障排查的第一道坎。一次光模块劣化可能触发几十条衍生告警，比如业务丢失告警、时钟源降级告警、邻居不可达告警。如果一个个看，时间全浪费了。标准做法是四步法：收集、过滤、分层、验证。先收集全网当前告警，按网元和告警产生时间排序；然后过滤掉已经被其他告警覆盖的衍生告警，只保留根因类告警；再按第2章的分类表分层定界；最后通过业务测试验证判断。

实际操作中，我一般用网管告警过滤功能，先只看紧急级别和主要告警，再把同一网元上因同一根因产生的告警合并。华为设备上可以用命令行查看活动告警：

display alarm active display alarm history

第一条看当前活动告警，第二条看历史告警。注意活动告警里，越早产生的告警越有可能是根因，后面跟着的一串大概率是衍生。比如先出现了ETH_BWMGR告警，接着出现业务LSP down，那LSP down大概率是拥塞或链路质量差导致的，而不是MPLS配置本身错了。

定界时还要做一次双向业务测试。在接入侧设备上ping核心侧地址，然后在核心侧ping回接入侧，对比双向丢包率。如果双向都丢包，重点查中间链路；如果单向丢包严重，优先怀疑光模块或光纤收发不一致。这个动作虽然简单，但能很快把问题从“业务不可达”定界成“链路质量问题”。

3.2 常用诊断命令组合：ping、traceroute、display 与抓包要点

IPRAN设备上命令不少，但真正高频用到的是下面这组组合。先看链路质量，不管业务能不能通，都要测物理层：

ping -c 100 -s 1000 10.10.1.254

-c指定发包数，-s指定包大小，1000字节能让微小的误码更快暴露。如果只是默认ping几个包，大包和持续测试往往更能暴露问题。判断标准是丢包率和最大时延，最大时延超过廊值且不规律，就有链路弱化嫌疑。

通了之后，再看路由和隧道：

display ip routing-table 10.10.1.254 display mpls lsp verbose

第一条看业务路由是否可达，第二条看MPLS LSP建立情况。很多IPRAN业务走的是TE隧道或LSP，路由能通不代表隧道能通。display mpls lsp verbose可以看到隧道状态、入标签、出标签、下一跳。如果状态是down或degraded，就需要进一步看协商失败原因。

跨多跳排查时用traceroute：

tracert -a 10.10.1.1 -t 100 -w 1000 10.10.1.254

-a指定源地址，-t设置TTL上限，-w设置超时时间。IPRAN设备默认可能不开ICMP不可达报文的回包权限，所以tracert有时候会在中间节点“卡住”，这时不要急着认为网络不通，先到卡住的那一跳上用display interface查看接口状态，往往能看到错包计数在涨。

抓包是最后一步，通常只在业务极难定位时才做。在汇聚和接入侧接口做镜像或用acl匹配业务流，抓双向报文，关注MAC地址变化、VLAN标签变化和MPLS label是否一致。抓包不要在整个网里乱抓，先在故障边界两侧抓。比如接入环内不通，就在接入设备上抓上行口和下行口，以此判断报文是在入方向丢还是出方向丢。

4. 三个高频IPRAN故障案例拆解：从现象到参数级修复

4.1 接入环光模块劣化导致丢包：案例参数与更换策略

某次割接后第三天，一个接入环上三个5G基站出现间歇性业务劣化，网管上有光模块Degrade告警和少量CRC误码。初步ping测试，接入设备到汇聚设备丢包约2%，但业务还能通，所以一开始没太当回事。问题在于，误码是间歇性的，白天几乎不明显，晚上温度上来后误码率快速上升，最终引发基站IP链路闪断。

定位过程并不复杂，接入设备上查看物理接口：

display interface phy 1/0/1 display transceiver 1/0/1 verbose

第一条看接口误码和up/down次数，第二条看光模块收发功率、温度、电压。当时看到的参数是：光模块温度62℃，接收功率-24.5dBm，已经低于模块的接收灵敏度阈值，而发送功率-2.1dBm基本正常。这说明问题是收光太弱，不是发光不够。结合现场尾纤弯曲半径大、法兰盘老化，判断是光链路线路损耗过大导致。

处理方式是更换尾纤并重新熔接，同时调整了光模块的位置，让接收口避开弯曲位置。更换后接收功率恢复到-15dBm左右，误码清零。这个案例给我的参数级经验是：IPRAN光模块接收功率不要等到低于灵敏度才处理，低于灵敏度3dB左右就要列入观察；尤其是有Degrade告警出现时，基本已经到临界状态了。新开站点验收时，记录每个光口的收发功率、模块温度、误码基线，后续故障对比基线就能快速发现劣化趋势。

4.2 PW/LSP不同步引发的业务中断：协商机制与重置命令

有一次汇聚设备升级后，下面接入环上所有站点业务中断，但链路层全部正常。检查路由，发现业务地址能ping通，但基站IMS业务就是加载不上来。查看隧道状态，发现接入到汇聚的LSP是up，但PW状态是down，业务报文已经封装进隧道却被PW丢弃。

问题根源是升级过程中配置文件里的PW参数与对端不一致，常见的是PW ID配置错位或控制字使能不一致。IPRAN的PW协商依赖标签分发协议，两端参数不匹配时，PW会处于standby或down状态，业务自然不通。

排查命令组合：

display mpls lsp verbose display pw interface

第二条命令专门看PW状态。当时看到PW状态为down，原因值提示“local/remote mismatch”。确认是对端配置不一致后，修正PW ID和控制字参数，再执行：

reset pw interface

让PW重新协商。这条命令会删除当前PW状态重新建立，不需要重启设备。执行后PW状态变为up，基站业务几分钟内恢复。

这个案例的教训是：升级和割接后必须做“配置一致性校验”，不要只测路由通不通。很多IPRAN故障是配置“半套生效”造成的，路由协议可以协商，但PW、隧道参数必须两端完全一致。我后来固定动作是：每次割接后对比两端的PW ID、control word、MTU、隧道目的地址。把这些参数编成检查表，比事后逐条命令查询快得多。

4.3 时钟失步引发误码：同步源选择与SSM配置

时钟同步故障是最容易误判为链路故障的IPRAN问题。某个校区站点长期存在偶发丢包，时延在20ms到60ms之间抖动，误码监测却一直为零。查光功率正常、接口up时间很长，链路层完全健康。后来发现基站侧上报失步告警，才把方向转到时钟同步。

IPRAN回传通常用1588v2做时间同步，频率同步用SyncE或线路时钟。查看同步状态：

display ptp status display clock source

第一条命令看1588v2时间同步状态，第二条看频率同步源选择结果。当时看到的结果是：ptp状态为faulty，clock source显示参考源品质降低，从外时钟（BITS）自动切换到了线路时钟，而线路时钟又因为上游端口误码产生了微小的频率偏移，导致基站时延抖动。

解决步骤是：检查外部时钟源是否正常，然后在设备上手动锁定优先级更高的同步源：

clock source bits0 priority 1

再查看是否锁定。SSM级别是另一个常见坑，当上游SSM级别是DNU时，下游设备会认为该参考源不可用，自动跳到线路时钟。所以排查同步故障时，不要只看延迟，还要沿线查看每一跳的SSM级别和ptp状态。处理完成后，时延抖动立即消失。这个案例提醒我，凡是有“时延抖却不丢包、基站切频异常”现象，先看时钟，再看链路，顺序反了会浪费大量现场时间。

5. IPRAN故障排查避坑手册：5个让老手也翻车的细节

5.1 配置类坑：先改配置还是先查物理层

现象：某接入环业务不通，工程师怀疑OSPF邻居震荡，连续改了三次cost值和接口优先级，故障反而扩散到相邻站点。原因：物理层尾纤法兰头松动，导致接口间歇性down，OSPF邻居震荡只是物理层的“症状”。解决方案：先查display interface phy，确认up/down次数、误码、光功率。物理层干净前，任何协议层调整都是给网络加风险。我的习惯是，故障处理第一分钟必须看物理层，哪怕之前已经看过一次，也要再看一遍，因为物理层可能正在劣化。

5.2 业务类坑：被网管隐瞒的收发光功率

现象：网管上光功率显示正常，但业务丢包严重，现场测试却不通。原因：网管采集周期是15分钟，而光模块接收功率在劣化时可能在一个小时内慢慢下降到灵敏度以下，网管采样点之间的变化被“平均”掉了。解决方案：一定要在设备命令行执行display transceiver verbose，看实时值、模块温度和电压。另一个坑是不同端口的光模块类型不一样，100km模块和40km模块的灵敏度不同，不能用同一个阈值判断。所以验收时要把模块型号、额定功率范围记录在案，排查时才有参考。

5.3 环境类坑：光纤纤序和标签不一致

现象：两个站点间链路频繁闪断，ping测试有时通有时不通。现场人员按标签重新拔插光纤后，故障反馈“更严重了”。原因：光纤标签本身就是错的，施工时把收发两条纤序交叉了，但设备的自动协商功能一直在“硬撑”。一旦有人按标签动纤，问题立刻暴露。解决方案：不要轻易相信标签，先看光模块收发光功率，判断收光和发光是否匹配。如果TX功率正常、RX功率极低，大概率是纤序交叉。可以用一根测试跳线直接在ODF架上短接，确认纤序再恢复。这类坑在工程割接现场非常常见，凡是光纤物理操作后出现的故障，第一件事是检查纤序。

5.4 同步类坑：SSM级别被上游覆盖

现象：基站反复上报时间失步，查看本机clock source是正常的，但业务侧依然报错。原因：上游汇聚设备给接入设备下发的SSM级别是DNU，导致接入设备认为该参考源不可用，自动回退到内部振荡器。问题出在上游设备配置，不在本端。解决方案：沿线逐跳检查SSM级别，不只查故障站点本地。重点看上游只有一条同步路径时，是否误配了“hold-off”或“DNU”标志位。同步配置属于“越界故障”，本端看到的现象往往不是本端的配置问题，必须沿时钟链路向上追到源头。

5.5 升级类坑：版本回退时配置文件丢失

现象：设备升级失败后回退到旧版本，业务大面积中断。原因：新版本自动备份的配置文件格式与旧版本不完全兼容，回退后部分接口和隧道配置被“跳过”。常见的是新增接口速配、隧道policy的条目丢失。解决方案：升级前必须在命令行导出完整配置，并单独备份一份文本文件。回退后不要直接加载旧版本备份，而是diff对比回退前后的配置差异。这个坑最隐蔽的原因是IPRAN设备升级时，MPLS和PW参数可能在备份时被新版本“翻译”过，回退后参数含义已经不同。我现在的原则是：升级包和回退包一起验证，回退前写一个“配置对比清单”，逐项核对接口、LSP、PW、时钟源和路由协议。

6. 从故障案例到巡检脚本：把经验固化成可验证的动作

故障案例分析的价值，不是写进doc就完事了，而是要把经验转化成每天能自动跑的巡检脚本。比如光模块劣化这个案例，我后来在网管侧用脚本每天采集一遍所有核心光口的收发光功率、模块温度和误码率，形成一个基线表。当某个光口的接收功率比基线低3dB时，自动生成工单；低5dB时直接短信告警。这样很多半失效的模块，在影响业务前就被处理掉了。

墙裂推荐你自己也写一个小脚本，把第4章和第5章的命令组合固化起来。一个简单的bash脚本，自动登录设备执行关键检查：

#!/bin/bash # 检查接入环关键端口的光功率和误码 for device in R1 R2 R3; do echo "=== $device ===" ssh admin@$device "display transceiver verbose | include RX|TX|Temperature" done

脚本只是起点，更重要的是你把故障案例里的“阈值”变成脚本里的判断条件。比如光口RX功率低于-20dBm报警告，接口错误计数持续增长报警告，PW状态不是up报警告。这些阈值来自真实故障案例的统计，而不是凭感觉拍脑袋。

我现在的习惯是，每处理完一个故障，都在案例文档末尾补一段“固化动作”，明确哪条命令能提前发现这个问题、阈值设在多少、脚本怎么改。半年下来，脚本里积累的检查项越来越多，故障响应时间从小时级压到了分钟级。遇到特别奇怪的故障，我也会回到案例库翻一翻，查相似现象和当时的处理路径，这比重新从告警开始推要快得多。

IPRAN故障分析这件事，本质上是把网路经验沉淀成可执行的动作。你踩过的每一个坑，只要及时固化，就能变成下一次排查的指路牌。希望我的这些踩坑心得能帮到你，让你的值守夜里少一点手忙脚乱。

本文还有配套的精品资源，点击获取