简介：面向光网络运维、接入网维护及通信工程人员，这份中兴OLT常用命令及故障解析处理手册以单个PPTX演示文稿承载，共7.17MB，聚焦ZXA10 C300/C320设备的面板结构、电源与主控板位、上联卡及PON业务板卡等硬件认知，并系统汇总日常运维中的高频命令，如通过show card检查单板运行状态，识别INSERVICE、NOPOWER、HWONLINE、TYPEMISMATCH、CONFIGING等状态含义，快速判断板卡是否在位、通电、在线或配置异常。内容按设备介绍、常用命令、故障分类、案例介绍四部分组织，覆盖设备板卡故障、ONU注册失败、光猫侧故障、机顶盒获取错误地址、流氓光猫干扰、上联状态异常、测速不达标及专线卡顿等典型场景，并给出网元断链处理、光猫注册异常排查、流氓光猫整治等详细处置流程。资源包内共1个文件，类型为PPTX，适合有一定基础并希望建立标准化故障处理SOP的运维人员系统学习，目前已有2789人学习下载。
1. 先看懂这台OLT再敲命令：从面板到故障定位的完整链路
手里这台OLT，在网络里是“最后一公里”的总闸：底下挂着几十上百个光猫，上面接着BAS或交换机。业务一断，用户第一个骂的就是装维，可真正出问题的往往不是光猫，而是OLT上某块板卡状态异常，或者某个PON口下的流氓光猫在发光。这份OLT常用命令及故障解析处理手册的价值，不在于让你背命令，而是给你一套从“设备面板认知”到“故障分类定位”的完整SOP。设备长什么样、单板什么状态算正常、CPU负荷多高算危险、光猫怎么查注册、业务怎么对VLAN——每一步都能落到一条命令上。适合谁？刚接手OLT运维的新手，以及被“测速不达标”“专线卡顿”反复折腾的装维和接入网工程师，照着命令往下走，大部分故障能在十分钟内圈定范围。
2. 设备面板与单板状态：C300/C320 的槽位结构和四个状态字段
2.1 面板结构决定排查顺序：从板卡类型反推故障面
OLT设备的面板不是给你看的，是给故障定位用的。先认识槽位，才知道show card输出里每一行对应的是哪块硬件。以常见的ZXA10 C300为例，从上到下分别是：通用公共接口板（BITS时钟、1PPS+TOD环境监控，不能插PON板）、双路冗余电源板（-48V）、1U风扇插箱、9U主控交换板、上联卡槽和最多14个业务板槽位。业务板可以是8/16口EPON、8/16口GPON、10G-EPON或10G-GPON板；上联卡则有4口千兆光口板、光电混合板和2口10GE+2口GE板三种。
C320的布局略有不同，但关键差异在上联主控板：万兆上联板的接口名是XGE，它兼容千兆光模块，插上千兆模块后要把速率设置为GE，否则端口起不来。很多“上联接口灯亮但业务不通”的案例，根因就是这里速率协商没配好。
| 板卡区域 | 常见板型 | 故障影响面 |
|---|---|---|
| 主控交换板 | SCXM等 | 整机管理、协议处理，冗余保护 |
| 上联板 | ETGH/ETGO/ETGOD | 上行业务汇聚，断链影响面最大 |
| 业务板 | GTGH/GTGO（GPON）、EPON板 | 单板下所有PON口用户 |
| 公共接口板 | HUTQ/HUVQ | 环境监控、时钟同步，不承载业务 |
| 电源/风扇 | PRWG/风扇插箱 | 供电与散热，异常会引发批量掉线 |
实际操作里，出现批量用户掉线时我一般先看业务板状态，再看上联口收发光，最后才查光猫侧。面板结构先入脑，后续命令才有参照物。
2.2 show card 输出逐个字段解读：每个状态背后都是一种故障
登录OLT后第一步不是ping，而是看单板在不在位、通没通电、认没认到型号。show card的输出里藏着大量信息，我拆开讲：
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 7 GTGHK 16 V1.0.0 V2.1.0 HWONLINE 1 1 11 SCXM SCXM 0 V1.0.0 V2.1.0 STANDBY 1 1 13 ETGO 8 V1.0.0 V2.1.0 TYPEMISMATCH 1 1 14 GTGH GTGHG 16 V1.0.0 V2.1.0 CONFIGINGStatus列是核心，整列状态含义如下：
- INSERVICE：板卡正常进入服务状态，可以承载业务。
- NOPOWER：板卡在位但不通电。优先查槽位供电、电源模块输出、背板连接，而不是直接换板。
- HWONLINE：板卡在位不在线。通常是版本文件缺失、单板没添加成功或板卡硬件损坏。看HardVer和SoftVer列是否为空就能区分：SoftVer为空大概率是没加载到版本。
- OFFLINE：板卡不在位。查物理插拔，或槽位本身损坏。
- TYPEMISMATCH：配置的板卡型号和实际插入不一致。比如槽位配置是ETGO，实际插了别的板。把板卡拔出重新识别，或修改配置。
- CONFIGING：配置同步状态，表示正在下发配置，一般几十秒后转为INSERVICE。如果长时间停留在此状态，多半是主控与业务板通信异常。
- STANDBY：备用主控板，正常工作。
看输出时我习惯先扫Status列找非INSERVICE项，再用“Rack/Shelf/Slot”定位物理位置去现场处理。板卡温度、光模块发光这类问题不会在这条命令里体现，留给后面的温度与风扇检查。
3. 环境与负荷检查：show fan、温度与CPU占用率的异常阈值
3.1 风扇状态：温度控制逻辑与转速异常判断
机房空调坏了，OLT风扇会先替用户扛下来。show fan命令能看到风扇控制模式、温度阈值和每台风扇实际转速：
C300# show fan Shelf : 1 epm : FanControlType : temperature-control TemperatureThreshold : 10 30 38 46 (deg c) FanSpeedLevelPercent : 20% 35% 50% 75% Environment Temperature : 23(deg c) Upper Fanboard Status : online FanUnitId SpeedLevel ActualSpeed(RPM) 1 2 2100 2 2 2100 3 2 2100风扇默认是温度控制模式，阈值10/30/38/46对应四档转速（20%/35%/50%/75%）。我判断异常主要看两点：一是环境温度23度时风扇已经跑到第二档50%左右，说明机柜风道有问题；二是ActualSpeed与SpeedLevel不匹配——比如SpeedLevel显示2但转速只有几百转，基本是风扇寿命到头或供电异常。风扇全部在线的情况下，先清尘、查风道，再考虑换风扇；如果Upper Fanboard Status显示offline，则直接联系备件更换。
3.2 板卡温度：55度是警戒线，光模块温度同等重要
单板过热是“慢性病”，初期只是偶发丢包，后期直接随机死机。show card-temperature输出的是每块板卡当前温度、5分钟均温和1小时均温：
C300# show card-temperature 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 10 32 32 32 N/A. 1 1 12 38 38 38 N/A.单板温度最好不要超过55度，超过就需要到机房摸一下机柜温度，确认风扇转速有没有跟上。Optical-Temp列显示光模块温度，这一项容易被忽略：光模块温度过高时，发光功率会漂移，表现为用户端光功率正常但光猫频繁掉线。另外，5分钟均温和1小时均温差距大，说明机柜温度在波动，要盯着空调是不是间歇性停机。
3.3 CPU负荷与内存占用：60%是预警线，持续99%要查协议冲击
业务板CPU过高最直接的影响是PON口管理报文处理不过来，光猫注册、保活都会出问题。show processor命令按板卡给出CPU和内存占用：
C300# show processor Rack Shelf Slot CPU(5s) CPU(1m) CPU(5m) PhyMem(MB) Memory ------------------------------------------------------------------------------- 1 1 2 14% 14% 14% 512 26% 1 1 3 14% 14% 14% 512 26% 1 1 10 12% 16% 13% 510 66% 1 1 11 22% 24% 23% 510 66% 1 1 14 15% 17% 17% 1024 19% 1 1 19 23% 23% 22% 32 24%两个阈值要记住：CPU利用率长时间大于60%需要核查原因；占用率长时间处于99%，大概率是协议报文冲击——比如某个PON口下面挂了流氓ONU，不停发上行报文把单板CPU打满。这时不是重启板卡，而是逐个PON口排查，找到异常ONU并隔离。另外注意槽位19/20是公共接口板，内存很小，不是它性能差，是它本来只跑环境监控。看CPU时还要结合峰值时段，晚高峰CPU略高是正常的，凌晨三四点还高才异常。
3.4 系统运行时间：判断设备是否异常掉电重启
设备是不是悄悄重启过？pppoe拨号用户会告诉你“断过一次”，但具体什么时候断的得看show system-group：
C300# show system-group System Description: C300 Version V2.1.0 Software System ObjectId: .1.3.6.1.4.1.3902.1082.1001.300.2.1 Started before: 5 days, 16 hours, 15 minutes System name: KS-TS-26HaoXiaoQu-C300重点看Started before字段。如果显示只有几小时，说明这台OLT近期掉电过或主动重启过，配合告警记录判断是电源问题还是主控板故障。现场排查开关电源、UPS输出和配电空开，不要急着怀疑用户侧。
4. 光猫注册与业务配置查询：从“找不到设备”到“对不上VLAN”
4.1 未注册光猫查询：新装和换机场景的第一条命令
新装宽带最典型的故障是光猫注册不上去，OLT侧看不到任何设备信息。这时用show pon onu uncfg，它会列出该OLT下所有未注册的PON口设备：
C300# show pon onu uncfg OltIndex SN LOID -------------------------------------------------------------------------- gpon-olt_1/1/6 FHTT56075A10 - gpon-olt_1/2/10 HWTC33C854A3 N/A epon-olt_1/2/6 N/A 9980991636C epon-olt_1/6/2 N/A 9980256809C gpon-olt_1/14/2 SCTY40F25A38 N/A这段输出里，GPON口下看到的基本是SN序列号，EPON口下可能是LOID。需要注意的是，光猫如果已经正确注册，就不会出现在这个列表里；如果出现在这里，说明数据没做或光猫认证模式不匹配。EPON还有一种查看方式：show onu unauthentication，显示更详细，包括设备型号、MAC地址、在线状态。SN和LOID都为空的那一行，通常对应专线光猫或者还没做认证数据的接入型光猫，需要先确认现场用的是哪种认证方式。
4.2 通过SN或LOID反查注册位置：换光猫时的“后悔药”
用户报障说“光猫换了但上不了网”，多半是新的光猫SN或LOID没绑定。此时先反查新光猫的SN和LOID在OLT上的位置，再决定是做数据还是改绑定：
C320# show gpon onu by sn FHTT57D2AEF0 Search result ------------------ gpon-onu_1/1/1:2 C320# show gpon onu by loid 9980599382C Search result ------------------ gpon-onu_1/1/1:1 C300# show gpon onu by loid 9980260532C %Code 62310-GPONSRV : No related information to show.最后一条报错很常见：No related information to show表示这个LOID在GPON口下没有对应数据。这时先确认设备是GPON还是EPON，EPON要用show epon onu by loid查询，命令不通用。查到了注册位置，再去对应PON口下核对光猫配置。这套组合拳在用户换猫、移机、10G GPON升级场景里非常实用，不用再翻台账。
4.3 GPON光猫业务配置解读：单层VLAN、双层VLAN与组播VLAN
光猫注册上了但业务不通，问题多半出在service-port的VLAN映射。用show running-config interface gpon-onu_1/1/2:1查看单台光猫的完整配置：
KS-JS-YuDaiLiKe-C320# show running-config interface gpon-onu_1/1/2:1 interface gpon-onu_1/1/2:1 sn-bind disable 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 service-port 2 vport 2 user-vlan 41 vlan 877 service-port 3 vport 3 user-vlan 45 vlan 45 service-port 4 vport 4 user-vlan 43 vlan 43 service-port 5 vport 3 user-vlan 50 vlan 50 igmp fast-leave enable vport 3上行接交换机时通常做单层VLAN转发，user-vlan是光猫侧VLAN，vlan是OLT上联给交换机的VLAN，两者一致时就是“透传”。上行直连BAS时则要打外层VLAN，出现svlan字段，比如user-vlan 41 vlan 312 svlan 270，表示用户内层41、设备VLAN 312、外层270。组播VLAN的处理是另一个高频坑：service-port 5专门给ITV组播用，igmp fast-leave要开，否则换台卡顿。对照配置检查时，先看tcont和gemport的对应关系是否完整，再看service-port的VLAN是否和上联方向匹配。
EPON侧的配置语法不同，用sla-profile和service-port，且没有tcont/gemport概念。EPON光猫数据通常配在epon-onu_1/2/1:33这样的接口下，包含admin enable、property description和service-port。查看EPON光猫用show running-config interface epon-onu_1/2/1:33，不要拿GPON的模板去套。
5. 故障排查与避坑：网元断链、流氓光猫、测速不达标
5.1 故障分类与定位顺序：物理、单板、注册、业务四层递进
这份手册把故障分成设备板卡类、ONU类、上联状态类、光猫侧类、业务体验类五类。实际处理时我按“物理→单板→注册→业务”的顺序走，每层都有对应命令。物理层查风扇温度电源，用的是第3章的命令；单板层用show card；注册层用show pon onu uncfg和show gpon onu by sn/loid；业务层用show running-config interface。乱序排查是新手最容易翻车的地方：用户说上不了网，直接查光猫数据配置，折腾半天发现是上联光模块收光低。
网元断链的排查要特别注意：第一步ping网元管理地址，第二步show card主控板状态，第三步查上联口物理状态和光功率。一个容易忽略的点是——断链可能不是OLT侧，而是BAS或交换机侧的上联口down了，我在现场遇到过OLT上联光模块收了灰尘导致收光功率降到临界值，时通时断，ping的丢包率只有5%，不仔细看根本发现不了。
5.2 三个高频案例的完整处理过程
光猫注册异常是出现频率最高的故障类型，处理路径是：先show pon onu uncfg看设备有没有被OLT发现，没发现就查光路和光猫状态——用光功率计测收光，必须在-8dBm到-28dBm之间；发现设备但认证失败，则核对SN和LOID，用show gpon onu by sn确认光猫SN是否已经在其他PON口下注册。同一个SN同时出现在两个PON口，直接把新PON口下的注册数据删掉，否则光猫会被“踢来踢去”，表现为每隔几分钟掉线一次。机顶盒获取错误地址的处理路径是：查机顶盒PPPoE或DHCP报文，确认olt侧组播VLAN配了没（service-port 5那行），再看igmp fast-leave是否开启。错误地址通常是获取到了管理VLAN的地址，说明组播VLAN和业务VLAN没有隔离。
流氓光猫故障最值得单独说。它会持续发光，把整个PON口下的光功率抬高，导致同PON口其他用户光猫“收光过载”无法正常工作，表现是同一栋楼内多户同时掉线。处理不能靠猜，要逐个PON口检查：show int pon口光功率，找到发光功率异常高且持续不断的ONU，然后用命令将该光猫去激活或直接拔纤隔离。手册中明确提到，OLT单板CPU长时间99%时也要回头查流氓光猫，因为持续的异常上行报文同样能打满CPU。
测速不达标和专线卡顿不能一概而论。先要区分是“OLT到光猫”还是“光猫到终端”的问题。OLT侧查上联口有没有拥塞，用show interface统计丢弃计数；光功率在合理范围但测速依旧上不去，则要光猫侧pon口的光模块发光功率是否衰减。专线客户卡顿时，我见过一个典型案例：客户侧光猫的PON口发光功率正常，但光模块温度已经55度，导致误码率飙升，把光猫换掉后业务恢复。硬件隐性故障最难查，但温度命令早就给出了提示。
5.3 命令使用中的典型踩坑记录
现象：show gpon onu by loid查询EPON光猫报“No related information to show”，注册数据明明存在但查不到。原因：EPON和GPON的命令不通用，EPON要用show epon onu by loid。解决：先确认光猫是EPON还是GPON，再选对应命令。我当时在这个坑上浪费了十几分钟，后来养成一看产品型号就先分EPON/GPON的习惯。
现象：单板上电后长时间处于CONFIGING状态，业务板始终无法进入INSERVICE。原因：主控板和业务板之间配置同步中断，常见于主控板倒换后单板版本不一致。解决：先看主控是否STANDBY状态正常，再尝试重新同步此单板配置，最后再考虑重启单板。切忌直接拔板，拔板前先看有没有业务在承载。
现象：某PON口下的光猫频繁掉线，单个光猫拿出来测一切正常。原因：存在流氓光猫持续发光，导致同PON口其他用户收光过载。解决：show pon光功率找到异常发光者，隔离后再逐一恢复其他用户。这个故障隐蔽性极强，单查用户侧永远查不出来。
现象：新增光猫无论如何都无法注册，show pon onu uncfg里看不到设备。原因：光纤实际接到了另一个PON口，现场装维和后台数据对不上。解决：用SN反查整机所有PON口，找到实际注册位置再调整数据。不要只盯着配置单上的PON口名。
6. 把故障定位收敛成一页清单：六个必查项与两种验证手段
命令学得再多，到了现场最怕的是“从哪查起”。我手里有一份固定检查顺序，故障现场照着走一遍，大部分问题能收敛到具体环节。第一项show system-group看是否掉电重启，三秒钟排除整机重启引起的批量异常；第二项show card扫单板状态，锁定非INSERVICE的槽位；第三项show fan和show card-temperature看环境，避免在散热问题上反复折腾业务配置；第四项show processor看CPU，重点排查持续高位的板卡；第五项show pon onu uncfg看未注册设备，针对新装或换机场景非常高效；第六项show running-config interface对业务配置，核对VLAN和组播配置。
验证手段只用两种。一种是ping网关，判断OLT上联链路是否通：ping不通先查上联口物理状态和光功率，而不是去光猫侧折腾；另一种是光功率计实测，OLT侧PON口发光正常不代表用户侧收光正常，分光器衰减和跳线损耗都要计入。专线卡顿类问题加一个中间节点测试，逐步收缩是OLT上联口还是光猫到客户设备的链路。从那以后，我每次上站处理OLT相关故障都强制自己先走完这套清单再动配置，血泪经验告诉我：不按顺序来，往往会在错误的方向上折腾半天。希望这份基于常用命令的故障处理习惯，能帮你在现场少走几步弯路，把问题定位得更快更准。
本文还有配套的精品资源，点击获取
