中兴OLT故障诊断手册：从命令到根因的闭环排障指南

简介：本资源是一份面向通信与网络运维工程师的中兴OLT设备实战运维手册，聚焦ZXA10 C300/C320系列OLT的日常管理、故障定位与快速处置。内容覆盖设备硬件面板详解（含主控板、上联卡、PON业务板等组件功能与槽位规范）、核心CLI命令实操（如show card状态判读、show version、show interface等），以及涵盖板卡异常、ONU注册失败、光猫侧注册/地址分配错误、流氓光猫干扰、测速不达标等十余类典型故障的SOP级处理流程与真实案例解析。资源为单个7.17MB的PPTX文件，结构清晰、图文并茂，每页标注ZTE官方配色与字体规范，含完整目录导航与命令输出示例截图，便于现场查阅与培训复用。已有2811人学习下载，是新手入门快速掌握OLT运维要点、资深工程师沉淀排错经验的高实用性参考材料。

1. 这不是命令速查表，而是一份能让你在凌晨三点接到告警电话后，三分钟内定位到是哪块板卡在“装死”的OLT故障响应手册

你有没有遇到过这样的场景：深夜值班，监控平台突然弹出“C300主控板CPU飙升至99%”，你抓起键盘想查show processor，却发现命令输错成show process，系统返回% Invalid input detected at '^' marker——光标停在那行报错上，心跳比风扇转速还快；又或者现场反馈“整栋楼宽带断了”，你连上设备敲show card，一眼扫过去全是INSERVICE，但偏偏那个gpon-olt_1/14/8槽位下挂的23台光猫全掉线，而日志里连个ERROR都没写。这不是操作不熟，是缺一套带上下文、有判断逻辑、能闭环验证的故障响应路径。这份《中兴OLT常用命令及故障解析处理手册》就是为这种真实压力场景写的：它不教你怎么背命令，而是告诉你什么状态下该看哪条命令、结果里哪个字段是关键信号、这个信号异常背后对应哪类物理或配置问题、下一步该验证什么才能排除干扰项。适用于刚接手OLT设备的新人工程师、需要快速交付排障SOP的集成商技术负责人，以及正在做通信类毕设/课设、需要体现“故障建模—诊断路径—验证闭环”完整工程思维的学生。它覆盖ZXA10 C300/C320主流型号，聚焦GPON/EPON双模场景，所有命令和案例均来自真实现网配置片段，不是实验室模拟器里的理想输出。

2. 总体架构设计：三层物理结构与四类核心状态监控域的职责划分

中兴OLT（以C300/C320为代表）不是一台“黑匣子”，而是一个分层明确、状态可逐级收敛的硬件系统。理解其物理架构，是避免“一上来就reload”式玄学排障的前提。我们按信号流向和管理粒度，将其划分为物理层、控制层、业务层三层，并围绕这三层定义四个必须常态化监控的核心状态域：单板在线性、环境稳定性、资源承载力、业务可达性。这四个域不是并列关系，而是存在强依赖链路——比如风扇故障（环境域）→ 板卡温度超限（物理域）→ CPU异常飙高（控制域）→ 光猫批量掉线（业务域）。下面从面板实物切入，落到每个监控域的具体命令与判据。

2.1 物理层：从机框面板到单板级健康状态的逐级穿透

ZXA10 C300/C320采用模块化机框设计，各功能板卡物理位置固定，状态可直接映射到show card输出的Rack/Shelf/Slot坐标。这不是简单的“插没插进去”，而是包含供电、识别、版本加载、服务注册四个阶段的状态机。例如，show card输出中Status字段的NOPOWER（在位不通电）和HWONLINE（在位不在线）看似接近，但根因完全不同：前者是电源板或背板供电异常，后者可能是单板Flash损坏、BootROM校验失败，或更隐蔽的——主控板未向该槽位下发启动指令（常见于主控切换后同步延迟）。再如TYPEMISMATCH，表面是“添加板卡类型与实际不符”，实则是配置库中记录的CfgType（如GTGO）与物理插入的RealType（如GTGOG）不匹配，这往往发生在更换备件后忘记执行config add-card命令，或升级软件后新旧板卡兼容性未更新。

提示：show card命令必须配合show version交叉验证。例如某C300显示SCXM主控板SoftVer V2.1.0，但show version却显示系统主版本为V2.0.5，说明该主控板固件未完成同步，此时即使状态为INSERVICE，其转发能力也可能受限。

2.2 控制层：主控与资源的协同负载模型

控制层的核心是主控交换板（SCXM）及其管理的全局资源池，包括CPU、内存、TCAM（用于ACL/QoS查表）、以及最关键的——PON口资源池（TCONT/GEMPORT分配）。show processor输出的CPU(5s)/CPU(1m)/CPU(5m)三组值，不能只看瞬时峰值。我一般会这样判断：若CPU(5m)持续>60%，且PhyMem(MB)中Memory列显示主控内存占用>70%，则优先排查是否启用了未优化的SNMP轮询策略（如每10秒轮询全部PON口光猫状态），而非直接怀疑病毒攻击。更隐蔽的是CPU(5s)尖峰达99%但CPU(1m)仅20%，这大概率是某个协议报文风暴（如非法LLDP报文循环广播）触发的瞬时中断，需用show logging抓取%GPONSRV-3-CPU_OVERLOAD类日志佐证。

2.3 业务层：PON口与ONU的双向绑定关系建模

业务层的最小闭环单元是“PON口 → ONU → 业务端口”。show pon onu uncfg列出的未注册ONU，其SN和LOID字段缺失模式直接指向根因：若SN为空而LOID有值（如gpon-olt_1/14/8行），说明ONU已上电但光功率不足（<-28dBm）或中心波长偏移，导致OLT无法完成测距；若LOID为空而SN有值（如epon-olt_1/2/6行），则是ONU配置了静态SN绑定但未在OLT侧执行onu x type xxx loid yyy命令。这里有个关键细节：show gpon onu by loid返回%Code 62310-GPONSRV : No related information to show.并不等于“该LOID不存在”，而是该LOID未被分配到任何PON口——可能是在其他机框，也可能是配置被误删。必须用show running-config | include "loid.*9980260532C"全局搜索配置文本确认。

2.4 环境域：温控与供电的隐性故障放大器

环境域常被忽略，却是压垮骆驼的最后一根稻草。show fan输出中Environment Temperature: 23(deg c)看似正常，但要结合TemperatureThreshold: 10 30 38 46看：当环境温度逼近38℃时，风扇进入第三档（50%转速），若此时某块业务板卡散热片积灰，其show card-temperature读数可能已达52℃（临界值55℃），虽未告警，但该板卡的FPGA时钟抖动已增大，导致PON口误码率上升，最终表现为部分光猫间歇性掉线。show power命令虽未在原文列出，但它是验证电源域的基石——show power中State为OK仅表示电源模块自检通过，必须进一步看Output Voltage是否稳定在-48.0 ± 0.5V，波动超±1V即可能引发主控板复位。某次现场故障，show card一切正常，show processor负载平稳，但show power显示A路电源输出电压为-46.2V，B路为-47.8V，更换A路电源模块后故障消失。

3. 核心命令实战：从输入到决策的完整链路还原

命令不是孤立的字符串，而是诊断链路上的一个“探针”。每个命令的输入参数、输出字段、异常值含义、以及它与其他命令的逻辑关联，共同构成一个可推理的诊断图谱。下面选取五个高频、高信息密度的命令，还原其在真实排障中的完整使用链路。

3.1show card：单板状态的“X光片”，重点看Status与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 13 ETGO 8 V1.0.0 V2.1.0 TYPEMISMATCH

这段输出里，Slot 1的NOPOWER是典型供电问题，应立即检查该槽位对应的电源分支开关及线缆；Slot 2的HWONLINE需立刻执行show version slot 2确认其SoftVer是否为空（空则Flash损坏），若非空，则执行config remove-card 1 1 2再config add-card 1 1 2 GTGOG强制重载驱动；Slot 13的TYPEMISMATCH则要核对CfgType（ETGO）与RealType（GTGOG）是否属于同一硬件家族——ZTE文档规定ETGO是早期EPON板，GTGOG是增强型，二者物理接口兼容但驱动不通用，必须统一为GTGOG并更新配置。

注意：show card不显示板卡序列号（SN），若需追踪硬件资产，必须用show hardware命令，其输出包含Serial Number字段，这对备件更换后的审计至关重要。

3.2show card-temperature：温度数据的“时间切片”，警惕滞后性告警

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 3 43 43 43 N/A. 1 1 10 32 32 32 N/A. ...

温度值本身不是绝对指标，Temperature(5m)和Temperature(1h)的时间维度才是关键。若Slot 2当前温度44℃，但Temperature(1h)为35℃，说明温度在1小时内上升了9℃，远超正常散热曲线（通常≤2℃/h），此时即使未达55℃阈值，也必须立即检查该板卡散热鳍片是否被异物堵塞，或机框进风口滤网是否严重积尘。曾有一个案例，show card-temperature显示所有板卡温度正常，但show fan中Upper Fanboard Status为offline，导致上层业务板卡热量无法导出，最终Temperature(1h)曲线呈现阶梯式跃升。

3.3show processor：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 11 22% 24% 23% 510 66% ...

CPU(5s)=12%、CPU(1m)=16%、CPU(5m)=13%的组合，表明负载存在短时脉冲，需用show logging | last 50查找%SYS-3-CPUHOG日志；而Slot 10和Slot 11内存占用同为66%，但PhyMem(MB)均为510MB，说明两块主控板内存总量一致，这是冗余保护正常工作的前提。若发现Slot 10内存占用66%而Slot 11仅26%，则Slot 11可能处于Standby状态未同步内存数据，需执行show redundancy确认主备状态。

3.4show pon onu uncfg：未注册ONU的“身份档案”，SN与LOID的缺失模式即根因

C300# show pon onu uncfg OltIndex SN LOID ------------------------------------------------------------------------- gpon-olt_1/1/6 FHTT56075A10 9980991636C gpon-olt_1/2/10 HWTC33C854A3 N/A epon-olt_1/2/6 N/A N/A ...

SN有值、LOID为空（gpon-olt_1/2/10）：ONU已上电并完成物理层握手（有SN），但未向OLT发送注册请求（LOID为空），原因通常是ONU配置了LOID authentication disable或光功率过低导致注册信令丢包；SN为空、LOID有值（epon-olt_1/2/6）：ONU未上电或光链路完全中断（无SN），但OLT配置库中存在该LOID记录，属“幽灵配置”，需清理；SN与LOID均为空：PON口光模块故障或光纤完全中断，此时show interface gpon-olt_1/2/10应显示line protocol is down。

3.5show running-config interface gpon-onu_1/1/2:1：业务端口的“DNA图谱”，VLAN/SVLAN/Service-Port的精确映射

interface gpon-onu_1/1/2:1 description $onuname$$$ sn-bind disable tcont 1 name ITMS allocid 256 profile ITMS tcont 2 name HSI allocid 257 profile HSI gemport 1 name ITMS portid 129 tcont 1 gemport 2 name HSI portid 130 tcont 2 service-port 1 vport 1 user-vlan 46 vlan 46 //ITMS单层VLAN service-port 2 vport 2 user-vlan 41 vlan 877 //宽带单层VLAN

这段配置揭示了业务流的完整路径：ONU上行流量打上user-vlan 41标签 → 经gemport 2→ 绑定TCONT 2→ 最终映射到service-port 2的vlan 877。若用户投诉“能上网但IPTV卡顿”，先查service-port 3（IPTV）的vlan 45是否在BAS侧正确透传；若show mac-address中该ONU的MAC地址出现在错误的VLAN（如vlan 877下出现了IPTV机顶盒MAC），说明service-port的user-vlan与vlan映射关系配置错误，需修正service-port 3的user-vlan值。

4. 故障排查避坑指南：那些让老手也翻车的5个隐蔽陷阱

排障中最耗时的往往不是解决故障，而是绕开那些设计精巧的“坑”。这些坑不违反语法，不触发告警，却能让诊断方向彻底跑偏。以下是我在多个现网项目中踩过的、最易被忽视的5个致命陷阱，每一条都附带真实复现步骤和绕过方案。

4.1 陷阱一：show card显示INSERVICE，但show interface gpon-olt_x/x/x显示down——板卡“假在线”

• 现象：show card中某GPON板状态为INSERVICE，但show interface gpon-olt_1/14/8返回line protocol is down，且show optical-info gpon-olt_1/14/8显示Rx Power: -35.2dBm（严重偏低）。
• 原因：该GPON板的光模块接收灵敏度已劣化，但仍能通过硬件自检（故show card为INSERVICE），但无法维持有效光链路（故接口down）。ZTE设备对光模块的“在线”判定仅基于I2C通信是否正常，不校验光功率是否在有效动态范围内。
• 解决：不能依赖show card判断光口可用性。必须将show interface与show optical-info联动：只要Rx Power< -28dBm 或 > -8dBm，无论show card状态如何，均视为光模块失效，需更换。补充命令：show transceiver diagnostics gpon-olt_1/14/8可查看光模块内部温度、偏置电流等深层参数。

4.2 陷阱二：show gpon onu by loid返回“No related information”，但show running-config里明明有该LOID

• 现象：show gpon onu by loid 9980260532C返回%Code 62310-GPONSRV : No related information to show.，但show running-config | include "9980260532C"确实在interface gpon-olt_1/7/9下找到onu 12 type ZTEG-F660 loid 9980260532C。
• 原因：该LOID被配置在gpon-olt_1/7/9，但该PON口当前处于shutdown状态（show interface gpon-olt_1/7/9显示administratively down），或该PON口光模块未安装，导致OLT未激活该LOID的注册监听。
• 解决：先执行show interface gpon-olt_1/7/9确认PON口物理状态，再用show gpon onu uncfg | include "9980260532C"确认该LOID是否出现在未注册列表中。若在未注册列表中，则说明PON口已启用，问题在ONU侧；若不在，则PON口未启用，需no shutdown。

4.3 陷阱三：show processorCPU正常，但光猫批量掉线——罪魁祸首是TCAM资源耗尽

• 现象：show processor所有槽位CPU<30%，内存<50%，但show pon onu发现某PON口下30台ONU全部offline，show logging无相关错误。
• 原因：TCAM（Ternary Content-Addressable Memory）是OLT进行QoS策略、ACL规则、VLAN映射匹配的专用硬件资源。当配置了大量细颗粒度的service-port（如为每台ONU单独配service-port）或复杂ACL时，TCAM可能耗尽。此时OLT仍能转发基础流量，但无法处理新ONU注册、VLAN转换等控制面操作，表现为ONU无法上线。
• 解决：执行show tcam usage（或show resource tcam，具体命令依软件版本而定）查看TCAM利用率。若Used列>95%，需精简service-port配置（如合并相同VLAN的ONU到同一service-port）或删除冗余ACL。这是个典型的“资源瓶颈不体现在CPU/内存”的案例。

4.4 陷阱四：show card-temperature一切正常，但show fan显示FanControlType: temperature-control且EnvTemperatureProtect: disable

• 现象：所有板卡温度<45℃，风扇转速正常，但某业务板卡在高温天气下频繁重启。
• 原因：EnvTemperatureProtect: disable意味着环境温度保护功能被关闭，风扇不会因机框整体升温而提速。当机房空调局部失效，机框顶部温度升至40℃时，底部业务板卡虽自身温度仅42℃，但其散热风道已被热空气阻塞，实际结温已超限。
• 解决：必须启用环境温度保护：config fan control enable。同时，show fan中的CriticalTemperatureThreshold: 160(deg c)是风扇自身保护阈值，与业务板卡无关，切勿混淆。业务板卡的温度阈值由show card-temperature的硬件规格决定。

4.5 陷阱五：“流氓光猫”导致全PON口误码，但show pon onu无异常ONU

• 现象：某PON口下所有ONURx Power正常，show pon onu状态均为online，但show pon statistics gpon-olt_1/14/8显示Total FEC Corrected Errors每小时增长数千次，用户普遍反映上网卡顿。
• 原因：存在一台ONU（“流氓光猫”）发射光功率严重超标（>+5dBm），其强光信号淹没同PON口下其他ONU的微弱上行信号，导致OLT接收端信噪比（SNR）急剧下降，触发FEC纠错。但该ONU自身状态正常，因其发射功率过高不影响其接收OLT下行信号。
• 解决：show pon onu无法发现此问题。必须用show pon optical-power gpon-olt_1/14/8查看各ONU的Tx Power（发射功率），正常范围应为+0.5 ~ +5.0 dBm。若发现某ONUTx Power为+7.2 dBm，立即shutdown该ONU端口并更换光猫。这是唯一能定位“发射端异常”的命令。

5. 故障分类与案例闭环：从现象到根因的四步归因法

面对一个故障现象，工程师的本能反应常是“试”，但高效排障必须建立结构化归因框架。我采用“现象→域定位→命令链→根因闭环”四步法，将零散命令组织成可复用的诊断流水线。下面以三个典型故障为例，展示该方法如何落地。

5.1 案例一：整PON口光猫批量掉线，show pon onu全为offline

• Step 1 现象锚定：gpon-olt_1/14/8下23台ONU在5分钟内陆续变为offline，非单点故障。
• Step 2 域定位：优先锁定物理层（整PON口失效）和环境域（是否高温/断电）。执行show card确认该PON板Status为INSERVICE；执行show power确认双路电源State为OK；执行show fan确认风扇Status为online。
• Step 3 命令链执行：
  1. show interface gpon-olt_1/14/8→line protocol is down（物理链路中断）
  2. show optical-info gpon-olt_1/14/8→Rx Power: -42.1dBm（光功率严重不足）
  3. show transceiver diagnostics gpon-olt_1/14/8→Laser Bias Current: 0mA（光模块激光器未启动）
• Step 4 根因闭环：光模块硬件故障。更换光模块后，show optical-info中Rx Power恢复至-18.5dBm，show interface状态变为up，ONU在2分钟内全部自动上线。验证闭环：show pon onu | include "gpon-olt_1/14/8"输出23行online状态。

5.2 案例二：部分光猫能上网但IPTV卡顿，show mac-address发现IPTV MAC在错误VLAN

• Step 1 现象锚定：gpon-onu_1/1/2:1下IPTV机顶盒能获取IP但画面卡顿，其他业务正常。
• Step 2 域定位：锁定业务层（VLAN映射错误）和控制层（QoS策略未生效）。show processor确认CPU正常，排除资源瓶颈。
• Step 3 命令链执行：
  1. show mac-address | include "0011.2233.4455"（机顶盒MAC）→ 发现其出现在vlan 877（宽带VLAN），而非vlan 45（IPTV VLAN）
  2. show running-config interface gpon-onu_1/1/2:1→service-port 3 vport 3 user-vlan 45 vlan 45（配置正确）
  3. show service-port gpon-onu_1/1/2:1→vport 3的User-Vlan显示为41（与配置不符！）
• Step 4 根因闭环：service-port配置未生效。执行no service-port 3后重新输入service-port 3 vport 3 user-vlan 45 vlan 45，show service-port输出立即更新。验证闭环：show mac-address中该MAC迁移至vlan 45，IPTV播放恢复正常。

5.3 案例三：新装光猫始终无法注册，show pon onu uncfg有SN无LOID

• Step 1 现象锚定：gpon-olt_1/1/1下新插ONU，show pon onu uncfg显示SN: ZTEGC04A5073, LOID: N/A。
• Step 2 域定位：锁定物理层（光功率）和业务层（LOID认证模式）。show card确认PON板正常。
• Step 3 命令链执行：
  1. show optical-info gpon-olt_1/1/1→Rx Power: -26.3dBm（合格）
  2. show gpon onu profile→Authentication Mode: LOID（需LOID认证）
  3. show running-config interface gpon-olt_1/1/1→ 无onu x type xxx loid yyy配置
• Step 4 根因闭环：OLT侧未配置LOID白名单。执行config terminal→interface gpon-olt_1/1/1→onu 1 type ZTEG-F660 loid 9980662366C。验证闭环：30秒后show pon onu显示gpon-onu_1/1/1:1状态为online，show gpon onu by sn ZTEGC04A5073返回正确PON口索引。

6. 验收与答辩：用“故障注入-响应-验证”三阶法证明你的方案真实有效

交一份毕设或课设，最怕答辩老师问：“你这个方案，真能在现网用起来吗？” 或者“如果现场突然断网，你靠这套手册能搞定吗？” 这时候，堆砌再多的命令截图都没用，必须拿出可量化、可重现、可验证的证据链。我的做法是构建一个“故障注入-响应-验证”三阶验收流程，它不追求覆盖所有故障，而是精选3个最具代表性的故障场景，用严格的操作步骤和明确的验收标准，证明手册的每一个环节都经得起推敲。这个流程，也是我每次交付前必做的“后悔药”。

6.1 阶段一：故障注入——在可控环境中精准复现问题

绝不依赖“运气”等故障发生。我使用ZTE官方提供的C300模拟器（或真实备机），按手册中“案例一”描述，主动制造一个PON口光模块失效故障：

• 步骤1：登录模拟器，执行show interface gpon-olt_1/1/1记录初始状态（up）。
• 步骤2：执行config interface gpon-olt_1/1/1→shutdown，模拟光模块拔出。
• 步骤3：等待30秒，执行show pon onu，确认该PON口下所有ONU状态变为offline。
• 验收标准：注入后，show interface必须返回line protocol is down，且show pon onu输出中该PON口索引下的ONU数量与注入前一致，状态全为offline。不满足则重做注入。

6.2 阶段二：响应执行——严格按手册步骤操作，记录每一步耗时与输出

打开手册第5.1节，像执行手术一样，逐字执行每一条命令，不跳步、不猜测、不“应该”：

• 步骤1：执行show card，找到Slot对应值（如1），记录耗时（<5秒）。
• 步骤2：执行show optical-info gpon-olt_1/1/1，复制Rx Power值（如-42.1dBm），记录耗时（<3秒）。
• 步骤3：执行show transceiver diagnostics gpon-olt_1/1/1，确认Laser Bias Current为0mA，记录耗时（<8秒）。
• 验收标准：所有命令必须在15秒内完成，且输出结果与手册中“Step 3 命令链”完全一致。任何一条命令返回% Invalid input或结果字段缺失，即视为响应流程失败，需回溯手册步骤描述是否准确。

6.3 阶段三：验证闭环——用客观指标确认故障彻底解决

修复不是目的，闭环才是。修复后，必须用三个独立指标交叉验证：

• 指标1（业务层）：show pon onu | include "gpon-olt_1/1/1"输出行数 = 注入前ONU总数，且每行含online字样。
• 指标2（控制层）：show processor slot 1中CPU(5m)值与注入前偏差 < 5%，证明无额外负载。
• 指标3（物理层）：show optical-info gpon-olt_1/1/1中Rx Power恢复至-8 ~ -28dBm区间，且Tx Power在+0.5 ~ +5.0dBm区间。
• 验收标准：三个指标必须在修复操作（更换光模块）完成后5分钟内全部达成。任一指标不满足，即判定手册的“根因闭环”步骤存在缺陷。

从那以后我每次交付一份新的OLT排障手册，都强制走一遍这个三阶流程：先花20分钟注入一个故障，再用3分钟执行响应，最后用5分钟验证闭环。它逼着我把手册里每一句“执行XXX命令”都变成可触摸的动作，把每一个“应显示YYY”都变成屏幕上真实跳动的字符。这不仅是给老师看的，更是给我自己的一份承诺——当深夜电话响起，我知道手册里写的每一个字，都经过了真实故障的淬炼。希望帮到你。

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