简介面向接入网运维人员与一线装维工程师的中兴OLT排障SOP手册聚焦ZXA10 C300/C320设备的日常巡检、命令查询与故障定位适合希望从设备面板认知进阶到独立处理疑难故障的初、中级网络从业者。内容以设备面板、常用命令、故障分类、案例介绍四大模块展开既讲解主控、上联卡、业务板卡与电源风扇等硬件组成及光网络连接架构也演示show card、show version、show interface等命令的输出判读可据此识别INSERVICE、NOPOWER、HWONLINE、OFFLINE、TYPEMISMATCH等板卡状态。故障部分覆盖ONU注册异常、上联口无信号或丢包、光猫注册与地址分配错误、机顶盒获取错误地址、流氓光猫引发的不稳定、测速不达标及专线卡顿并给出网元断链处置、信息收集与多方位定位思路。包内为1个pptx约7.17MB以图示化幻灯片串联设备架构、命令截图与案例分析便于培训宣讲和现场查阅。已有2800人学习。1. 从一次PON口批量掉线说起这套OLT命令与故障处理手册要解决什么凌晨两点某个小区的宽带和IPTV同时报障值班的人打开网管只看到一片红灯第一反应是重启主控板——这个动作在多数情况下只会把现场证据一起清掉。OLT排障真正的难点从来不是命令多而是不知道先敲哪一条show card看板卡、show pon onu uncfg看未注册、show processor看CPU六七个维度的输出摆在一起没有一条主线把它们串起来新人只能凭感觉试。这套OLT常用命令与故障解析处理手册要解决的就是这个问题把设备面板认知、命令语义、故障分类、典型案例按排查顺序重新编排让值班人员在十分钟内把现象收敛到一个可执行的检查动作上。适合刚接手PON网络运维的工程师、需要交付运维文档的项目人员以及把OLT排障当作课设或毕设课题的学生。2. 设备与板卡认知C300与C320的槽位结构决定排障起点排障的第一步不是敲命令而是知道这台设备的物理边界。同一套命令在C300和C320上输出结构一样但槽位编号、上联板形态、主控冗余方式完全不同照着别人的经验套用很容易在第几个槽是上联口这种问题上翻车。2.1 面板与槽位哪些板卡能混插哪些位置天生不能插PON板以C300这个大容量机架为例整机是典型的纵向分区结构。通用公共接口板负责BITS时钟输入输出、1PPSTOD接口和环境监控接口它的位置在物理上就不承载PON业务往这类槽位插PON板只会得到一个类型不匹配的结果。电源板高度4.5U采用双路-48V冗余供电两路都要接只接一路时设备能起来但掉一路电就是整机断电。风扇插箱高度1U内含3组风扇走的是温度控制策略。主控交换板高度9U必须成对配置才能形成冗余保护单主控的设备在升级或倒换时没有后悔药。上联卡占4.5U、共2个槽位常见形态是4口千兆以太网光口板、4口千兆光电混合接口板、2口10GE加2口GE混合接口板。业务板卡高度9U最多14个槽位覆盖8口和16口EPON板、8口和16口GPON板、8口10G-EPON板、8口10G-GPON板。C320是紧凑型设备主控与上联合一槽位数量少排障时更要记清上联口在业务槽位之外。这里有个高频翻车点万兆上联主控板上标注为XGE的端口物理上可以插千兆光模块但速率必须显式设置成GE不改速率端口就是起不来。通常的做法是配置完先看一眼端口物理状态和协商速率再往下查业务。部件高度关键约束排障含义通用公共接口板按机型只做时钟与环境监控不承载PON业务此槽位插PON板必报类型不匹配电源板4.5U双路-48V冗余单路供电时不影响运行但失去冗余风扇插箱1U3组风扇温度控制调速单组故障会触发转速拉满噪声先变大主控交换板9U成对配置一主一备备用板状态应显示为STANDBY上联卡4.5U2个槽位多种形态上联断链优先查这里业务板卡9U最多14槽位PON口故障的定位起点记住这张表的现实意义在于当用户报整个PON口下所有光猫都不通而同一块板上的其他PON口正常时问题大概率在板卡或PON口本身当整块板下所有PON口全断才需要往上查主控和上联。这个判断顺序能省掉大量无效操作。2.2 板卡六种状态值从show card输出里读出在位、在线、在服务三件事show card是整套手册里出现频率最高的一条命令它一次给出机架、机框、槽位、配置类型、实际类型、端口数、硬件版本、软件版本和状态九个字段。真正需要读懂的是最后那个状态列以及配置类型和实际类型之间的差异。# 查看整机单板运行状态重点关注 Status 与 CfgType/RealType 的对应关系 C300# show card Rack Shelf Slot CfgType RealType Port HardVer SoftVer Status -------------------------------------------------------------------------- 1 1 0 PRWG PRWG 0 V1.0.0 INSERVICE # 电源板正常服务 1 1 1 PRWG PRWG 0 V1.0.0 NOPOWER # 在位但未通电 1 1 2 GTGO GTGOG 8 V1.0.0 V2.1.0 HWONLINE # 在位不在线 1 1 3 GTGO GTGOG 8 V1.0.0 V2.1.0 INSERVICE 1 1 4 GTGH OFFLINE # 槽位无板卡 1 1 10 SCXM SCXM 0 V1.0.0 V2.1.0 INSERVICE # 主用主控 1 1 11 SCXM SCXM 0 V1.0.0 V2.1.0 STANDBY # 备用主控 1 1 13 ETGO V1.0.0 V2.1.0 TYPEMISMATCH # 添加类型与实际不符 1 1 14 GTGH GTGHG 16 V1.0.0 V2.1.0 CONFIGING # 配置同步中这段输出的解读顺序应该是先看状态列再看 CfgType 与 RealType 是否成对出现。示例中的版本号仅作样例实际版本以现场为准。状态值语义常见成因现场动作INSERVICE板卡已进入服务状态正常无需处理继续查业务STANDBY备用主控板冗余配置正常确认主备倒换能力即可NOPOWER板卡在位但未通电电源板故障、背板供电异常、槽位接触不良先查电源板状态与告警再考虑换槽验证HWONLINE板卡在位但不在线无版本文件、单板未添加、单板损坏先确认是否已添加该板卡再查版本文件加载OFFLINE板卡不在位空槽或板卡被拔出与资产台账核对排除误拔TYPEMISMATCH添加的板卡类型与实际插的不符配置里加错类型或板卡插错槽位删除错误配置后按实际类型重新添加CONFIGING配置同步中主备同步、板卡刚上线等一至两分钟复看长时间不变要查主备通道这里需要强调一个容易被忽略的区别HWONLINE 和 OFFLINE 是两种完全不同的故障。前者板子插着、电通着但系统没把它拉起来处理方向是软件侧版本文件、添加动作、单板自检后者是物理上根本不在处理方向是硬件侧是否被拔、是否插到位。把这两个状态混为一谈就会出现跑到机房重新插板卡结果板卡本来就没插这种白跑一趟的情况。提示主备两块主控板的状态必须一个是 INSERVICE、一个是 STANDBY。如果两块都显示 INSERVICE 或者备用板长期不在位冗余已经失效这时做任何配置变更都是在裸奔。3. 常用命令分层从设备健康度查到ONU业务配置的六类查询命令不是背得越多越好而是要知道在什么阶段查什么。按设备级健康 → 用户侧注册 → 业务侧配置三层往上查能把大部分故障挡在前两层。3.1 设备级健康四查运行时间、风扇、温度与CPU负荷设备级健康检查是排障的第一道筛子四条命令覆盖四个维度全部执行一遍不超过一分钟。show system-group给出系统描述、版本、ObjectId、启动时长、联系信息、设备名和位置。启动时长这一项的价值在于判断设备最近是否掉过电用户报早上网络全断过一次如果启动时长显示只有几小时那基本可以认定是断电重启导致的业务中断不用再往协议层查。# 查看设备运行时间与基础信息Started before 是判断是否异常重启的关键字段 C300# show system-group System Description: C300 Version V2.1.0 Software System ObjectId: .1.3.6.1.4.1.xxxx.xxxx.1001.300.2.1 Started before: 5 days, 16 hours, 15 minutes # 设备已连续运行 5 天 16 小时 System name: 某小区-C300 Location: 某机房show fan输出的是风扇插箱的温控策略和实际转速。示例中温度阈值分四档 10/30/38/46 摄氏度对应风扇转速档位 20%/35%/50%/75%另有临界温度 160、高温门限 60、低温门限 -20。环境温度 23 度时三组风扇实际转速都在 2100 RPM 左右、档位为 2。这组数据要横向看如果环境温度只有 20 度出头某组风扇却长期跑在高档位说明该风扇或对应风道有问题如果三组转速一致但整体偏高那是环境温度或滤网堵塞的问题。show card-temperature给出每块单板的当前温度、5分钟均值、1小时均值和光模块温度。单板温度最好不要超过 55 摄氏度超过这个值业务稳定性会明显下降典型现象是误码率上升、光猫随机掉线。看这条命令有个窍门当前温度正常但1小时均值明显偏高说明刚刚有过一段高温多半是风扇或空调的间歇性故障比只看当前值更容易发现问题。# 查看单板温度当前值、5 分钟均值、1 小时均值要一起看 C300# show card-temperature All cards temperature(deg c): Rack Shelf Slot Temperature Temperature(5m) Temperature(1h) Optical-Temp -------------------------------------------------------------------------- 1 1 2 44 43 43 N/A. 1 1 6 41 41 41 N/A. 1 1 14 38 38 38 N/A.show processor输出每块板卡的 CPU 5秒、1分钟、5分钟利用率和物理内存、内存占用。判读标准很明确CPU 利用率长时间大于 60% 就要核查原因长时间趴在 99% 基本可以判定是协议报文冲击多半来自某个异常终端在疯狂发报文。这里要区分瞬时尖峰和持续高位5秒值冲到 40% 而5分钟值还在 12%那是正常波动三个时间维度全部走高才是真问题。# 查看各板卡 CPU 与内存占用三个时间维度要对比看 C300# show processor Rack Shelf Slot CPU(5s) CPU(1m) CPU(5m) PhyMem(MB) Memory -------------------------------------------------------------------------- 1 1 10 12% 16% 13% 510 66% # 主控板内存偏高需关注 1 1 12 19% 12% 12% 512 26% 1 1 14 15% 17% 17% 1024 19%3.2 用户侧反查未注册ONU清单与按SN/LOID定点定位用户报上不了网第一件事是确认这台光猫到底注册上了没有。show pon onu uncfg列出所有未配置的ONU字段包括OltIndex、SN、LOID。这张表是排障的主战场但它也是最容易被误读的一张表。# 查看未注册的 ONU注意区分 GPON 与 EPON 的识别方式差异 C300# show pon onu uncfg OltIndex SN LOID ------------------------------------------------------------------------- gpon-olt_1/1/6 FHTT56075A10 9980991636C gpon-olt_1/2/10 HWTC33C854A3 N/A # LOID 为空 epon-olt_1/2/6 N/A N/A # EPON 用 MAC 识别专线光猫 epon-olt_1/3/2 N/A 9980260532C gpon-olt_1/14/8 YHTCE88A12C3 useradmin读这张表要先分清技术制式GPON 侧靠 SN 加 LOID 识别EPON 侧靠 MAC 地址识别所以 EPON 行里 SN 列出现 N/A 是正常的不代表数据缺失。反过来GPON 行里 LOID 为空示例中的 N/A意味着这台光猫只上报了 SN如果业务是按 LOID 认证的它永远注册不上。专线光猫出现在未注册表里也属于正常现象因为它们的认证方式与家宽不同。EPON 侧另有一条show onu unauthentication专门列认证失败的 ONU输出里包含 Onu Model、MAC 地址、SN、LOID、Online State如 authentication deny、软件版本、硬件版本和注册尝试时间。这条命令的杀伤力在于它能直接给出这个时间点它在尝试注册配合用户报障时间就能迅速锁定。确认了是注册问题下一步是定点定位。show gpon onu by loid和show gpon onu by sn用来反查一台光猫落在哪个 PON 口、哪个 ONU 编号上EPON 侧对应show epon onu by loid。# 按 LOID 或 SN 反查已注册光猫的位置 C320# show gpon onu by loid 9980599382C Search result ----------------- gpon-onu_1/1/1:1 # 命中1框1槽1口第1个ONU C300# show gpon onu by sn FHTT57D2AEF0 Search result ----------------- gpon-onu_1/1/1:2查不到的时候会返回明确的错误码比如%Code 62310-GPONSRV : No related information to show.含义就是系统里没有这台光猫的数据。这一步的意义是排除其实已经注册了、只是用户记错账号这类误报查不到说明确实没注册要考虑光路、光猫或者认证参数的问题查得到但用户仍然不通问题就转移到业务配置或上层网络。3.3 配置侧核对GPON与EPON光猫的T-CONT、GEM Port与VLAN落地到了配置层排障对象从光猫有没有上线变成上线了但业务通不通。这一步要分两次看先看OLT侧为这台光猫下发了什么配置再看光猫内部收到的配置是什么。OLT侧的入口是show running-config interface gpon-olt_x/x/x输出该PON口下所有注册光猫的类型和LOID绑定关系再往下是show running-config interface gpon-onu_x/x/x:x输出这台光猫的完整业务配置包括T-CONT、GEM Port和业务端口。这段配置是整个手册里最需要看懂的部分因为它决定了业务能不能通。# OLT 侧为单台 GPON 光猫下发的业务配置 C320# show running-config interface gpon-onu_1/1/2:1 interface gpon-onu_1/1/2:1 sn-bind disable # 不绑定 SN换机可不改配置 tcont 1 name ITMS allocid 256 profile ITMS # 管理通道承载 tcont 2 name HSI allocid 257 profile HSI # 宽带承载 tcont 3 name ITV allocid 258 profile ITV # 组播/点播承载 tcont 4 name VOIP allocid 259 profile VOIP # 语音承载 gemport 1 name ITMS portid 129 tcont 1 gemport 2 name HSI portid 130 tcont 2 gemport 3 name ITV portid 131 tcont 3 gemport 4 name VOIP portid 132 tcont 4 service-port 1 vport 1 user-vlan 46 vlan 46 # ITMS 单层 VLAN service-port 2 vport 2 user-vlan 41 vlan 877 # 宽带单层 VLAN service-port 3 vport 3 user-vlan 45 vlan 45 # IPTV 单层 VLAN service-port 4 vport 4 user-vlan 43 vlan 43 # 语音单层 VLAN service-port 5 vport 3 user-vlan 50 vlan 50 # 组播 VLAN igmp fast-leave enable vport 3 # 快速离开减少切台卡顿这段配置里有三层映射关系需要说清。第一层是业务到 T-CONTT-CONT 是带宽承载单元每个业务一个 T-CONTallocid 与 profile 决定它能拿多少带宽。第二层是 GEM Port 到 T-CONTGEM Port 是业务封装的颗粒portid 是它在PON口内的编号必须与光猫侧对应。第三层是 service-port 的 VLAN 转换用户侧 VLAN 和网络侧 VLAN 可以相同也可以不同这就是单层 VLAN 的写法。另一处现场常见的是双层 VLAN 场景。区别在于 service-port 里多了一个 svlan 参数service-port 2 vport 2 user-vlan 41 vlan 312 svlan 270用户报文进来打上内层 312、外层 270两层都配齐业务才通。只配了 svlan 忘了 vlan或者反过来表现都是光猫在线、拨号不通光看注册状态永远查不出来。配置核对的第二段是光猫侧。show onu running config gpon-onu_x/x/x:x输出的是通过OMCI或OAM通道远程下发到光猫内部的配置它才是光猫真正执行的规则。这里有两种风格简化命令和传统命令。简化命令用service 业务名 gemport 编号 vlan vlan一句话完成GEM Port 与光猫内 VLAN 一一对应可读性好传统命令则需要显式写flow 1 pri 7 vlan 46这类流分类规则再用gemport 1 flow 1把 flow 绑到 GEM Port 上多业务、多优先级、组播混跑的场景用它更灵活。# 光猫侧通过远程管理通道下发的配置传统命令风格 pon-onu-mng gpon-onu_1/7/9:12 flow 2 switch switch_0/1 # 业务流绑定到电口 flow 3 switch switch_0/1 flow mode 2 tag-filter vlan-filter untag-filter transparent flow 2 pri 0 vlan 41 # 宽带 VLAN 41 flow 3 pri 5 vlan 45 # IPTV VLAN 45 flow 3 pri 5 vlan 50 # 组播 VLAN 50与 IPTV 同 flow gemport 2 flow 2 # GEM Port 与 flow 一一对应 gemport 3 flow 3这段配置的关键在于 flow 与 gemport 的对应关系必须是双向一致的OLT 侧 gemport 3 承载 IPTV光猫侧 gemport 3 就必须绑到包含 VLAN 45 和 50 的 flow 3 上。任何一侧写错编号业务都是通不了的但光猫照样显示在线。EPON 侧的对应写法略有不同用sla-profile做全局带宽模板service-port里直接带ingress、egress参数标注上下行模板名MAC 绑定则在光猫接口下用mac-bind disable控制。注意配置里的sn-bind disable和mac-bind disable能让换机时不用改配置运维上很方便代价是同一PON口下换一台同型号光猫也可能直接拿到原用户的业务串号风险要自己评估。4. 故障分类与定位路径四层模型把现象收敛到可执行动作命令会用之后真正的差距体现在故障定位的顺序上。同一个上不了网有人查了二十分钟还在纠结光猫有人三分钟就锁定在上联口的VLAN没放通区别就是有没有一套固定的收敛路径。4.1 四层定位模型与现场信息收集清单把PON网络从用户往上层剥可以分成四层终端层机顶盒、路由器、光猫内部配置、光路层光纤、分光器、光功率、配置层VLAN、T-CONT、GEM Port、业务端口、设备层板卡、主控、上联、电源风扇。定位原则只有一个自下而上每层用一个确定的判据确认这层没问题再往上走。层级关键判据对应检查项终端层光猫是否在线、LAN口是否有报文光猫指示灯、show onu running config光路层收发光功率是否在正常区间光模块光功率、分光器端口、跳线清洁配置层业务VLAN与GEM Port是否一一对应show running-config interface gpon-onu_x/x/x:x设备层板卡状态、CPU、上联端口状态show card、show processor、上联口物理状态信息收集是这套模型能不能跑起来的前提。现场反馈如果只有一句网断了四层模型一层都走不动。通常要求收集六项故障类型全断还是部分业务中断、业务范围单用户、单PON口、整台设备、整个片区、具体现象拨号失败、能拨通但打不开网页、IPTV黑屏、测速只有几十兆、触发条件是否刚割接、刚换机、刚下过雨、是否固定在某个时段、已做过的操作、以及反馈人的联系方式。这六项齐了八成故障在电话里就能给出方向。举个实际的收敛例子如果故障范围是单个PON口下的所有用户那终端层基本可以排除直接查这块业务板的PON口光功率和该PON口的配置如果范围是整台设备下所有用户那要先看show card和show processor再查上联口状态。范围判断错了后面全部白做。4.2 六类高频故障的处置动作与判定依据板卡类故障。判据来自show card的状态列。出现 NOPOWER先看电源板和整机告警排除供电后换槽验证出现 HWONLINE先确认这块板卡在配置里是否已经添加未添加就补添加已添加但仍不上线则查版本文件是否完整加载出现 TYPEMISMATCH删掉错误配置后按实际类型重新添加。板卡类故障最忌讳一上来就重启重启会把版本加载失败、自检报错这些线索清掉。ONU注册异常。分三种情况处理。查show pon onu uncfg能看到这台光猫说明光路是通的问题在认证参数核对 SN 与 LOID 是否与实际一致GPON 场景下 LOID 为空但业务按 LOID 认证必然注册失败。看不到光猫说明光路或光猫本身有问题查PON口发光功率、查分光器、换一根跳线试。还有一种情况是能查到但状态是authentication deny那是认证被拒通常是白名单里没有这条记录或者绑定了别的端口。网元断链。网管上整台设备失联处理顺序是先确认设备是否掉电show system-group的启动时长在现场能登上去的前提下才有意义登不上就靠机房侧确认再确认上联口物理状态和上联链路对端最后才怀疑管理VLAN和网管通道。上联状态检查通常看端口物理up/down、协商速率、收发光功率三项千兆光模块插在万兆端口上而速率没设成GE表现就是端口永远起不来。机顶盒获取错误地址。现象是机顶盒能起来但拿到的地址段不对或者一直停在获取地址界面。判据是先把机顶盒的地址与正确的地址池段做比对地址段错查业务VLAN和DHCP中继配置通常是把IPTV的VLAN错放成了宽带VLAN地址段对但拿不到查组播VLAN和IGMP配置igmp fast-leave enable没配会导致切台慢但不至于拿不到地址两件事要分开查。流氓ONU。现象是同一PON口下大量用户随机掉线、误码率异常升高但单台光猫看起来都正常。成因是某台光猫发光异常持续往PON口注入光信号把上行时隙搅乱。处置方法是逐台排查先看PON口整体光功率是否异常再按分光器分支逐路断开缩小范围定位到具体光猫后关端口或换机。这类故障没有捷径只能靠分段隔离所以台账清晰、分光器端口标注规范的分光箱处理时间能差出好几倍。测速不达标与专线卡顿。测速不达标要先分层排除单机直连光猫测、换测速节点测、看T-CONT的带宽模板是否与套餐匹配。测速正常但用户感知卡顿重点查光功率和误码光功率偏低会导致重传增加表现为带宽够但用起来卡。专线卡顿还要额外看上联口的流量和丢包专线通常走独立VLANVLAN配错或者上联口拥塞都会表现为间歇性卡顿靠ping测不出来要看端口流量曲线。提示处理流氓ONU和间歇性卡顿这类看起来都正常的故障时间戳非常关键。记录每次断开某路分支的准确时间和用户报障时间对齐比凭印象判断可靠得多。5. 避坑与排查五个在现场最容易翻车的细节5.1 万兆上联板插千兆光模块端口起不来现象上联板端口配置都写好了show interface显示物理层 down换模块、换跳线都没用。原因万兆上联板的端口标识为XGE物理上兼容千兆光模块但速率不会自动降到GE必须显式设置。解决进入端口配置速率模式为GE保存后复看物理状态如果对端是自协商两端速率模式要保持一致一端强制一端自协商同样起不来。5.2 一上来就重启重启完现场没了现象故障处理到一半重启了主控或板卡业务恢复了但没人说得清是什么原因过几天同样的问题再来一次。原因重启会清掉CPU历史、告警缓存、注册失败记录这些一次性证据而这些恰恰是定位根因的关键。解决把取证排在恢复前面先执行show processor、show card、show pon onu uncfg并把输出留存再做恢复动作。业务压力大时可以并行一边取证一边恢复但不能跳过取证。5.3 双层VLAN只配了一层光猫在线但业务不通现象光猫注册正常状态正常用户拨号失败或者IPTV黑屏。原因该场景是双层VLANservice-port 里必须同时有 vlan 和 svlan 两个参数只写其中一个时上行报文能通、下行报文打不上正确的标签表现为单向不通或者完全不通。解决核对show running-config interface gpon-onu_x/x/x:x的 service-port 行与规划表逐条比对 vlan 和 svlan注意同一个PON口下不同业务的 svlan 通常不同。5.4 未注册表里一堆历史记录误判成新装用户现象用户报装后不通查未注册表看到有记录以为光猫已上线实际那是一条几个月前的历史数据。原因未注册表保留的是曾经上报过但未配置的ONU信息专线光猫、拆机未清理的、测试留下的都会长期挂在里面。解决用 SN 或 LOID 做精确定点反查而不是在未注册表里靠肉眼比对同时注意 EPON 行的 SN 列本来就是 N/A不代表数据异常。5.5 只看温度当前值忽略5分钟和1小时均值现象现场看单板温度 40 度出头判断散热正常但用户持续报随机掉线。原因故障可能是间歇性的空调停机或者单组风扇卡死只发生在某些时段当前值恰好落在两次高温之间。解决把当前值、5分钟均值、1小时均值三个数字一起看均值明显高于当前值就说明刚经历过高负荷同时配合show fan看风扇档位与实际转速是否匹配环境温度不高但风扇长期满转基本可以锁定风道或风扇本体问题。6. 验收与答辩用三个故障场景证明这套手册能落地手册写完不等于能用验收的标准应该是换一个人拿着它能不能把问题处理掉。我一般用三个场景做闭环验收每个场景都从现象描述开始只允许使用手册里列出的命令看最终能不能收敛到具体动作。第一个场景是单PON口下全部光猫掉线。合格的处理路径应该是show card确认板卡状态为 INSERVICEshow processor确认CPU无异常show pon onu uncfg确认该PON口下光猫集体回到未注册状态然后判定为PON口或光路问题而不是逐台去查光猫。如果处理人在这个场景里花时间去问用户你家光猫什么灯说明手册的收敛路径没写清楚。第二个场景是单用户IPTV黑屏但宽带正常。合格路径是确认光猫在线查该用户的show running-config interface gpon-onu_x/x/x:x核对 IPTV 对应的 service-port 的 VLAN 与组播 VLAN 是否齐全再查光猫侧 flow 与 gemport 的对应关系。这条路径能覆盖八成以上的IPTV单用户故障。第三个场景是网管告警显示某台设备离线。合格路径是先区分是设备掉电还是上联断链再查上联端口物理状态与光功率最后才查管理通道。验收项检查方法合格标准命令覆盖度从手册抽取10条命令现场执行至少8条能正确解读输出状态语义准确性给出4种板卡状态要求说明处理方向4种全部答对且区分软件侧与硬件侧故障收敛速度三个场景分别计时单场景定位到层不超过10分钟案例可复现性按案例步骤在实验环境走一遍步骤无缺漏命令可直接复制执行文档完整性检查是否含信息收集清单六项收集项齐全且可落地答辩环节有个技巧不要念目录直接讲一个故障从报障到闭环的全过程中间自然带出用到的命令和判断依据。评审最想听的是你为什么在那一刻决定查这一条而不是这条命令是干什么的。如果能在十分钟里把四层模型讲透再演示一次show pon onu uncfg到show running-config interface gpon-onu_x/x/x:x的连贯动作基本就稳了。这套手册我自己改过三版前两版都栽在同一个地方命令写得很全但没有告诉读者先敲哪一条。后来我每次交付这类文档都强制走一遍陌生人测试——找一个没参与编写的人只给现象不给提示看他能不能在手册里找到下一步动作。找不到的地方就是文档的漏洞比任何评审意见都准。希望帮到你。本文还有配套的精品资源点击获取