简介：中兴OLT常用命令与故障解析处理手册，面向接入网运维、装维及负责OLT/光猫排障的工程师。内容以ZXA10 C300/C320面板构成为起点，详细说明电源板、风扇插箱、主控交换板、上联卡和业务板卡的功能，并结合show card等常用命令的状态输出，解释INSERVICE、NOPOWER、HWONLINE、OFFLINE、TYPEMISMATCH等含义，可快速判断板卡是否在位、通电、在线或配置异常。资源为单个PPTX演示文稿，约7.17MB，图文并茂地呈现设备结构与排障流程。故障分类覆盖设备板卡、ONU注册、上联状态、光猫注册异常、机顶盒获取错误地址、流氓光猫、测速不达标和专线卡顿等典型场景，同时给出光网络整体架构说明，并按现象、原因、处理步骤介绍完整案例，如OLT网元断链、光猫注册异常、机顶盒地址错误、流氓光猫干扰等，形成可复用的SOP排障思路。已有2789人浏览学习，对日常维护、应急抢修和新人培训都有直接参考价值。
1. 一条告警背后的三张表：为什么 OLT 排障要先懂状态机
凌晨两点，值班群弹出一条告警：某小区 C300 的一个 PON 口下，几十户宽带同时掉线。赶到机房登录设备，show card一看，主控正常，业务板卡的状态却是NOPOWER——板卡在位但没通电。换板、恢复、写报告，操作半小时就结束了，但真正值得追问的问题才刚浮出来：从板卡插入到提供服务，设备内部到底经历了什么？光猫上线、业务放通，背后又是哪几张表在联动？这份中兴 OLT 常用命令及故障解析处理手册，价值恰恰不在命令本身，而在把这些状态词、注册机制和 VLAN 映射链串成一条可推导的因果链。搞懂它，排障就不再是逐个敲命令试运气。
2. 设备健康感知：show card、show fan、show processor 背后那套状态机
2.1 机框槽位：主控、上联、业务板分离的故障域设计
C300 的面板信息很容易被当成背景介绍略过，实际上它是一张故障域地图。通用公共接口板负责 BITS 时钟输入输出、1PPS+TOD 接口和环境监控接口，这块板不能插 PON 板，因为它的职责是给全框提供时钟基准和环境采样，而不是承载用户流量。电源板高度 4.5U，双路冗余 -48V 供电；风扇插箱 1U 高度、三组风扇；主控交换板 9U、冗余保护；上联卡 4.5U、两个槽位，可选四口千兆以太网光口板、四口千兆光电混合接口板、两口 10GE 加两口 GE 混合接口板。业务板区域最多 14 个槽位，按 8/16 口 EPON、8/16 口 GPON、8 口 10G-EPON、8 口 10G-GPON 划分。
C320 的差异在于把上联能力集成到了主控板上：有千兆上联主控板和万兆上联主控板两种形态，万兆上联板上的接口英文标识为 XGE，这意味着它可以插千兆光模块，速率在配置里设为 GE 就能降级使用。这个设计动机很直白：上联是整台 OLT 的带宽汇聚瓶颈，独立槽位或独立板型让运维人员可以在不碰业务板的前提下升级上联速率；而 XGE 口兼容千兆光模块，是为了在光模块库存不足时保留灰度过渡的余地。常见的实现思路是，主控和上联板都参与转发控制，一旦主控倒换，业务板上的 PON 口并不会中断，只有管理面会短暂闪断——这就是为什么排查断链时要先分清是业务面断了还是管理面断了。
2.2 单板状态机：从 OFFINE 到 INSERVICE 要闯过几道关
show card是登录 OLT 后第一个值得敲的命令，它输出的每个状态词都对应单板生命周期中的一个明确阶段：
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 5 ETGH GTGHK 16 V1.0.0 V2.1.0 INSERVICE 1 1 7 GTGHK 16 V1.0.0 V2.1.0 HWONLINE 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 8 V1.0.0 V2.1.0 TYPEMISMATCH 1 1 14 GTGH GTGHG 16 V1.0.0 V2.1.0 CONFIGING这段输出里藏着一条完整的单板状态迁移链：OFFLINE表示槽位根本没有板卡；NOPOWER是板卡在位但背板没有供电，常见于电源槽位异常或板卡插入未到位；HWONLINE是硬件在位但软件不在线，原因通常是版本文件缺失、配置中没有添加这块单板，或者板卡本身已损坏；TYPEMISMATCH是配置库里的板卡型号和物理插入的板卡不一致；CONFIGING是配置同步中，主备倒换或热插拔后经常出现；STANDBY是备用主控板；只有INSERVICE才是真正处于服务状态。
我一般会这么理解：这一串状态词不是随便起的字符串，而是单板管理器内部的有限状态机。板卡插入后要依次通过硬件在位检测、背板供电、BootROM 引导、版本文件加载、配置回灌这几道关，才能进入INSERVICE。排障时最容易犯的错误是把HWONLINE当成"板卡在线"，实际上它只是"硬件在位"，软件还没起来；此时查单板是查不出流量的，得从版本目录和配置表入手。
2.3 环境与负荷：风扇档位、温度阈值、CPU 冲击怎么联动
show fan把风扇控制策略暴露得很清楚：温控模式（temperature-control）下，温度阈值10 30 38 46分别对应20% 35% 50% 75%四档转速，环境温度 23℃ 时风扇停在第二档。关键参数是那三个保护阈值：低温 -20℃、高温 60℃、临界 160℃，以及EnvTemperatureProtect: disable、OpticalCriticalTempProtection: enable这两个开关。
C300# show fan FanControlType : temperature-control TemperatureThreshold : 10 30 38 46 (deg c) FanSpeedLevelPercent : 20% 35% 50% 75% CriticalTemperatureThreshold : 160(deg c) HighTemperatureThreshold : 60(deg c) LowTemperatureThreshold : -20(deg c) Environment Temperature : 23(deg c) EnvTemperatureProtect : disable OpticalCriticalTempProtection: enable FanUnitId SpeedLevel ActualSpeed(RPM) 1 2 2100 2 2 2100 3 2 2100注意EnvTemperatureProtect是关闭的，而光模块临界温度保护是开启的。机房环境温度通常靠空调兜底，因此环境温度保护关闭不会出大事；但光模块是光电转换器件，过热会直接导致发射功率劣化甚至永久损伤，所以光模块临界温度保护必须常开。show card-temperature里每一块业务板都会显示当前温度、5 分钟平均和 1 小时平均，运维经验值是单板温度不要超过 55℃，超过就要查风扇和机房空调。
再看 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 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%主控板内存占用 66%、业务板只有 26%，这不是故障信号，而是职责差异：主控承载网管、协议报文和转发控制，业务板大部分报文走硬件转发，CPU 只处理控制面。真正要警惕的是 CPU 长时间超过 60%，特别是接近 99% 的场景。常见的实现思路是，OLT 控制面有独立的收包队列和限速机制，但广播风暴、环路引起的重复报文、以及某种未知单播洪泛仍可能打满收包 CPU——这种故障用show processor看 5s 均值就能快速识别，而不必等到用户报障。
3. ONU 上线机制：SN、LOID、MAC 三套身份证如何决定你能不能上网
3.1 show pon onu uncfg：未注册光猫为什么会被设备"看见"
很多运维新手第一次敲show pon onu uncfg时会愣住：设备还没给光猫做任何配置，为什么就能列出它的 SN 和 LOID？理解这一点要从 PON 的物理层说起。OLT 的每个 PON 口是一个点对多点光域，光模块持续接收下行方向所有 ONU 发来的光信号。GPON 在注册流程里通过 PLOAM 信道承载 ONU 的序列号上报，EPON 走的是 MPCP 的发现注册流程；无论 ONU 有没有被认证授权，只要它上电发光并响应了发现窗口，OLT 就能在物理层"看见"它，然后把它挂到一张未配置表中。
C300# show pon onu uncfg OltIndex SN LOID ------------------------------------------------------------------------- gpon-olt_1/1/6 FHTT56ABCD10 9980991234C gpon-olt_1/2/10 HWTC33C856A3 N/A epon-olt_1/2/6 N/A N/A --- 专线光猫 epon-olt_1/3/2 N/A 9980260532C gpon-olt_1/14/2 SCTY40F25A38 N/A ---- LOID 为空 gpon-olt_1/14/8 YHTCE88A12C3 useradmin gpon-olt_1/15/2 ZTEGC04A5073 ZTEGC04A5073 --- 专线光猫这张表的信息量很大。GPON 光猫通常 SN 和 LOID 都有值；EPON 光猫的 SN 列是N/A，因为 EPON 的身份标识是 MAC 地址或 ONU ID，SN 不是它的首选身份。LOID 为空或为N/A，代表认证还没走完。EPON 有一种典型状态叫authentication deny，show onu unauthentication可以看到具体是哪台设备被拒：
C300# show onu unauthentication Onu interface : epon-onu_1/2/6:1 MAC address : 0026.ed88.5683 Online State : authentication deny Software Version : V1.1.0c_ZL2 RegTime : 2020/07/21 18:04:01authentication deny不是物理故障，而是认证被主动拒绝——常见原因是 MAC 白名单里没有这条记录，或者 ONU 型号不在允许列表里。和 GPON 的"未注册"相比，EPON 多了一道认证闸门，这道闸门过滤的不只是序列号，还包括厂商 OUI 和型号信息。
3.2 反查注册表：SN 和 LOID 各自解决什么问题
有未注册表，就一定有反查手段。show gpon onu by loid和show gpon onu by sn是两条方向相反的查询：前者用业务逻辑号找光猫，后者用硬件序列号找光猫。
C300# show gpon onu by loid 9980599382C Search result gpon-onu_1/1/1:1 C300# show gpon onu by sn FHTT57D2AEF0 Search result gpon-onu_1/1/1:2 C300# show gpon onu by loid 9980260532C %Code 62310-GPONSRV : No related information to show.最后一条%Code 62310-GPONSRV表示查无此 LOID，最常见的场景是注册表里根本没有这条数据。这里要理解 SN 和 LOID 的分工：SN 是硬件序列号，绑定的是"这台光猫"；LOID 是业务逻辑号，绑定的是"这条业务"。所以 LOID 的设计动机就是业务迁移——用户换一台光猫，只要把 LOID 配置到新猫上，认证就能通过，业务不用改。对应的，SN 绑定用于防私接：如果你在配置里写了sn-bind enable，光猫序列号一变就会掉线，这能防止用户把家里光猫拆到别处乱用。两张表配合，既保业务灵活性，又保接入可控性。
3.3 注册配置与专线差异：从 onu type 到 LOID 命名规则
注册的最终落点是一段接口配置。show running-config interface gpon-olt_1/1/2会把 PON 口下已注册光猫的信息列出来：
C320# show running-config interface gpon-olt_1/1/2 interface gpon-olt_1/1/2 no shutdown onu 1 type ZTEG-F660 loid 9980661234C onu 17 type ZTEG-F660 loid 9980661232C onu 18 type ZTEG-F660 loid 9980661233Conu 1 type ZTEG-F660 loid 9980661234C这一行说明三件事：ONU 编号是 1，型号是 ZTEG-F660，认证方式是 LOID。type字段决定 ONU 加载哪套软件版本和业务模板；loid以 C 结尾是这类设备的校验格式。如果这里写的是sn-bind disable，表示允许用户自行更换同型号光猫，只要 LOID 相同就能上线。
专线光猫在注册表里长得很特别：SN 和 LOID 的值完全相同，比如ZTEGC04A5073。原因在于专线业务不需要运营商分配的逻辑号码，设备序列号本身就是身份；FTTH 用户则必须用 LOID，因为业务号码要和计费、认证系统对接。EPON 侧还会多一条ip-cfg static，专线光猫需要固定管理 IP，不能靠 DHCP 动态获取。理解这个差异，看到/14/2口的 GPON 光猫 LOID 为空时，就知道它不是注册异常，而是专线场景下本身就只认 SN。
4. 业务链路：Tcont、GEM port、service-port 的四层映射是怎么串起来的
4.1 从光猫电口到 BAS：一条宽带业务的完整数据路径
注册成功只是第一步，真正让用户能上网的是业务配置。看一份典型的 FTTH GPON 光猫配置：
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这段配置实际上定义了一条完整的数据路径。用户电脑发出的报文进入光猫 LAN 口后，光猫内部把它映射到某个 GEM port，GEM port 再挂到 Tcont 这个带宽容器上，通过 PON 口上行到 OLT；OLT 收到后，service-port做 VLAN 翻译，从 PON 口转到上联口，最后到达交换机或 BAS。整条链路里三个角色各管一件事：Tcont 管带宽调度，allocid是 GPON 标准里上行带宽的调度实体标识，profile ITMS/HSI/ITV/VOIP分别是四类业务的带宽模板；GEM port 管业务通道，portid是通道编号；service-port 管 VLAN 映射，user-vlan是光猫侧带着的 VLAN 标签，vlan是进入网络侧后实际的业务 VLAN。
我一般会这么记忆：Tcont 解决"给多少带宽"，GEM port 解决"走哪条道"，service-port 解决"打什么标签"。三者独立配置再绑定，才能让一条物理链路承载 ITMS 管理、宽带、IPTV、语音四种逻辑业务，互不抢占也不串扰。
4.2 单层 VLAN 与双层 VLAN：svlan 是给谁看的
同一类业务在不同组网下可能差一个svlan参数。上联交换机的手册配置里，ITMS 是user-vlan 46 vlan 46，单层 VLAN 直接翻译；而上行直连 BAS 的配置里，宽带业务变成了user-vlan 41 vlan 312 svlan 270，双层 VLAN。
为什么有这个差别？上联对象决定了封装格式。上联是二层交换机时，交换机只需要一个 VLAN 就能完成转发和隔离，OLT 把用户侧 VLAN 翻译成网络侧 VLAN 即可；上联是 BAS 时，BAS 可能同时接入几十台 OLT、几十万用户的流量，它需要一个外层 VLAN 来标识"流量来自哪台 OLT 的哪个区域"，再用内层 VLAN 标识具体的业务种类。外层svlan相当于区域标签，内层vlan是业务标签，两层合起来才能让 BAS 精准识别用户。
有一个反直觉的细节：组播 VLAN 50 通常不带 svlan，即使上行直连 BAS 也一样。因为 IPTV 组播流不上 BAS，它在 OLT 本地通过 IGMP snooping 完成复制和转发，igmp fast-leave enable vport 3让用户切台时的离开报文立即生效。组播流量根本不经过 BAS，自然不需要外层标签。
4.3 简化命令与 flow 模式：pon-onu-mng 里的等价变换
同样是配置光猫业务，这台设备提供两套写法。手册里称前者为"远程下发模式"：
C320# show onu running config gpon-onu_1/1/2:1 pon-onu-mng gpon-onu_1/1/2:1 service ITMS gemport 1 vlan 46 service HSI gemport 2 vlan 41 service ITV gemport 3 vlan 45 service VOIP gemport 4 vlan 43后者是完整的 flow 模式：
C300# show onu running config gpon-onu_1/7/9:12 pon-onu-mng gpon-onu_1/7/9:12 flow mode 1 tag-filter vlan-filter untag-filter transparent flow mode 2 tag-filter vlan-filter untag-filter transparent flow 1 pri 7 vlan 46 flow 2 pri 0 vlan 41 flow 3 pri 5 vlan 45 flow 3 pri 5 vlan 50 flow 4 pri 7 vlan 43 gemport 1 flow 1 gemport 2 flow 2 gemport 3 flow 3 gemport 4 flow 4两套写法描述的是同一件事。service ITMS gemport 1 vlan 46是flow 1 pri 7 vlan 46加gemport 1 flow 1的压缩表达；flow mode后面的tag-filter vlan-filter untag-filter transparent定义了 ONU 内部交换芯片对报文的匹配行为——带标签的报文看 VLAN，不带标签的报文透传。pri是 802.1p 优先级，ITMS 和 VOIP 给 7、ITV 给 5、宽带给 0，这是为了让语音和网管流量在 ONU 内部队列里优先于普通上网流量。
两套写法本质上是一张表的两个视图。简化命令隐藏了 flow 匹配细节，适合区域大批量标准化下发；完整 flow 模式暴露了 ONU 交换芯片的真实行为，适合排障时定位报文为什么没进对的 GEM port。明白了这层等价关系，看到配置不一致时就不会慌——先分清楚设备当前用的是哪种视图，再谈下一步。
5. 现场避坑：五个典型故障从现象到根因的完整推导
5.1 板卡状态异常：HWONLINE 和 TYPEMISMATCH 为什么重启也救不回来
现象：新插一块 GTGH 单板，show card里状态是HWONLINE，PON 口下一个 ONU 都起不来；另一个槽位直接显示TYPEMISMATCH。
原因：HWONLINE说明硬件在位但软件没加载，常见于版本文件缺失、配置里没添加这块单板，或板卡已经损坏；TYPEMISMATCH是配置库里的型号和物理板卡不一致，设备拒绝加载。这两种都不是重启能解决的，因为问题出在配置或文件层面。
解决：HWONLINE先确认版本目录里有没有匹配的软件文件，再查配置表里有没有 add card；TYPEMISMATCH只能先把错误槽位的配置删掉，重新按物理板卡的真实型号添加，再触发一次配置同步。血泪经验是别急着换硬件，大部分状态异常是配置和文件的问题。
5.2 流氓光猫：一个不守时隙的发光源如何拖垮整个 PON 口
现象：某个 PON 口下十几户用户间歇性掉线，单户测光功率都正常，但 PON 口上行方向误码率飙升，OLT 侧收光功率异常偏高。
原因：这是典型的流氓光猫（rogue ONU）。PON 是 TDMA 时分多址，OLT 给每台 ONU 分配上行时隙，正常光猫只在属于自己的时隙里发光；流氓光猫的发光电路故障，持续发射光信号，把其他光猫的上行时隙全部冲掉。它的光信号甚至能让 OLT 光模块饱和，连注册报文都解不出来。
解决：逐一断开 PON 口下的光猫，每断一台观察一次 OLT 收光功率和误码，掉电后收光功率骤降的那台就是元凶。批量整治的思路是开启设备自身的流氓 ONU 检测机制，周期性统计每个 ONU 的发送窗口是否符合分配结果。这里最容易踩的坑是误判为光模块故障——换了光模块问题依旧，才想起来查 ONU 发光行为。
5.3 机顶盒获取错误地址：DHCP 走到了错误的 VLAN
现象：IPTV 机顶盒反复认证失败，抓包发现机顶盒拿到的 IP 网段是宽带业务网段，甚至拿到 192.168.x.x 的私网地址。
原因：机顶盒的 DHCP 请求没有走 ITV 对应的 service-port，而是被转发到了宽带的 VLAN 通道。回想第 4 章的映射链：service-port 是vport + user-vlan + vlan三者的联合匹配，如果user-vlan 45（ITV）和user-vlan 41（宽带）在光猫 LAN 口上的配置错位，或者pon-onu-mng里 ITV 服务绑错了 gemport，DHCP 请求就会从错误的 GEM port 上行。
解决：先核对 OLT 侧三段配置——interface gpon-onu里的 service-port 映射、pon-onu-mng里 ITV 绑的 gemport、以及 ONU 感知侧的 VLAN 划分，确认机顶盒报文实际进了哪个 vport。再检查igmp fast-leave的 vport 是否和组播业务一致。这条链路错一层，表现就是"能注册但拿不到正确地址"。
5.4 测速不达标与专线卡顿：限速、光衰、拥塞的三方博弈
现象：FTTH 套餐是 200M，测速稳定在 90M；专线客户反馈高峰时段丢包、时延抖动。
原因：测速不达标先看三类因素。第一是 Tcont 带宽模板限速，profile HSI档位给的是 100M 还是 200M 决定上限；第二是光链路劣化，ONU 收光功率低于 -25dBm 或者光模块温度过高，物理层协商速率会降级；第三是上联口拥塞，OLT 上联带宽满了，PON 口局部再快也是白搭。专线卡顿还要多查一层——上联口是不是和其他大流量业务共享。
解决：按顺序查，不要上来就改带宽模板。先show card-temperature看光模块温度，再测 ONU 收光功率，然后看上联口统计里的丢弃计数，最后才是核对allocid的 profile 档位。最常见的翻车是把"上联拥塞"误判成"用户侧光衰"，调了半天 ONU 位置，问题还在上行口。
5.5 OLT 网元断链：先用运行时间判断设备是否重启过
现象：网管上 OLT 网元离线，但用户业务并没有全部中断，部分 PON 口还能正常转发。
原因：管理面断了、业务面还活着，通常是主控倒换或管理通道中断；如果整个框所有业务全断，才优先怀疑整机掉电或电源模块故障。
解决：登录设备后第一件事是show system-group，看Started before字段。如果显示只有几小时或几天，说明设备近期重启过，断链大概率是掉电或主控重启引起；如果运行时间是几个月，说明管理通道本身出了问题，检查上联管理 VLAN 的连通性。再配合show card看主控板是不是处于STANDBY、INSERVICE之外的状态，很快就能把断链归因到管理面还是硬件面。这里的关键是别急着拔插板卡，先用运行时间字段排除掉电历史，很多"玄学断链"其实是半夜机房空调跳闸导致的整机重启。
6. 设计取舍：为什么"远程下发模式"值得成为默认习惯
回到第 4 章那组对比：service ITMS gemport 1 vlan 46和flow 1 pri 7 vlan 46加gemport 1 flow 1，描述的是同一条业务路径，但视角完全不同。简化命令把 ONU 内部交换芯片的匹配细节隐藏了，只暴露"哪个 gemport、哪个 vlan"这种业务语义；完整 flow 模式则把优先级、匹配模式、VLAN 过滤全部摊开。
这个设计背后是一个经典的取舍：配置的可读性与诊断的精确性不可兼得。远程批量下发场景里，成百上千条 ONU 配置如果全是 flow 模式，一条业务要写四五行，字段一多必然出错；而且标准化模板根本不需要每次都写pri 7、transparent这些固定值，简化命令把它们收敛成默认行为，反而降低了人为漂移的风险。但故障排查时，恰恰是这些被隐藏的字段决定了一个报文会不会进错通道——所以设备必须保留完整视图作为兜底。两套命令不是历史遗留，而是同一张配置表的两种投影。
理解这个取舍后，我的运维习惯就固定下来了：日常变更一律走简化命令，但任何一次业务不通的排查，第一步必然是show running-config interface把完整配置拉出来，先确认设备当前是哪种下发模式，再决定用service还是flow去对映射。从那以后，我每次接手一个故障现场，第一件事不是敲命令，而是先把show card、show pon onu uncfg、show running-config interface三个视图拉齐，确认设备停在状态机的哪个位置、光猫卡在注册表的哪一步、业务走的是哪条映射链，再动手操作。这套状态机与映射链在脑子里立起来之后，OLT 就不再是黑匣子了。希望帮到你。
本文还有配套的精品资源，点击获取
