企业官网建设流程全解析

简介：中兴OLT常用命令及故障解析处理手册面向光接入网运维人员，是一份系统梳理中兴OLT设备运维与排障的SOP资料。内容先介绍ZXA10 C300/C320的面板结构、电源板、主控交换板及上联卡等硬件组成，随后给出show card、show version、show running-config等常用命令及状态字段释义，帮助读者快速掌握设备健康度检查，并理解光网络整体连接架构与ONU常见操作。故障章节按设备板卡、ONU、上联状态、光猫侧、机顶盒、流氓光猫等场景分类，详细解析OLT网元断链、光猫注册异常、获取错误地址、测速不达标、专线卡顿等高频故障的处理流程，并结合现场案例演示从告警收集、业务范围判断到根因定位的完整排障思路。资源包为1个PPTX文件，约7.17MB，目录清晰，适合日常查阅与团队培训。目前已有2789人学习下载，是一份实用的光接入网络运维参考。

1. 接入网运维的第一现场：这套手册解决什么问题

一个雷雨夜，某小区上千户宽带同时掉线，光猫全部离线，后台重启无效。登进 OLT 看到show card里一块 8 口 GPON 板显着HWONLINE，光功率全部消失——这种大面积业务异常，最怕的不是故障本身，而是现场人员不知道该先看哪条命令、先排除哪层原因。

这套《中兴 OLT 常用命令及故障解析处理手册》的核心价值，就是把这类场景拆成可控的排查步骤：先判断设备层有没有硬件故障，再查 ONU 注册状态，最后核对 VLAN 与上联配置。适合接入网运维、装维支撑人员使用，也适合网络方向做毕设或课设时，作为“设备状态管理 + 故障定位流程”这类题目的完整方案参考。下文从设备面板、常用命令、故障分类到具体案例，完整演示怎么用它定位问题、怎么在答辩时把过程讲清楚。

2. 设备认知先行：C300/C320 的面板、槽位与板卡状态机

2.1 两代平台的槽位布局差异

拿到一台 OLT，第一件事不是敲命令，而是先看清机框里插了什么板。C300 和 C320 的面板布局不同，槽位含义也不同，认错板卡类型会直接导致后续判断失误。

C300 的典型结构分五层：最上方是通用公共接口板，提供 BITS 时钟输入/输出、1PPS+TOD 接口和环境监控接口，这块板不能插 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 的结构更紧凑，主控和上联合一，分为千兆上联主控板和万兆上联主控板。这里有个容易看走眼的点：万兆上联板的 4/2 接口英文标识是 XGE，但物理上可插千兆光模块，速率要手动设为 GE。现场见过有人拿 XGE 口当千兆口用，速率不匹配导致上联起不来，这属于典型的“看型号不看配置”。

2.2 show card 状态机：每个字段对应什么物理含义

判断板卡故障，show card是最先要敲的命令。输出里每个状态字段都有明确的物理含义，不能只看“是不是 INSERVICE”。

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 8 V1.0.0 V2.1.0 TYPEMISMATCH

状态字段的对应关系如下：INSERVICE表示板卡进入服务状态，正常工作；NOPOWER表示板卡在位但没通电，优先查槽位供电和背板；HWONLINE是板卡在位但不在线，常见原因是没有版本文件、没有添加单板或单板硬件损坏；OFFLINE表示槽位为空、板卡不在位；STANDBY是备用主控板，处于热备状态；TYPEMISMATCH表示配置中添加的板卡与实际插入的板卡型号不匹配；CONFIGING表示正在做配置同步。

排障时我一般会先看 Status 列，把所有非 INSERVICE 的槽位全部标记出来，再逐条对应 CfgType 和 RealType。比如1/1/13显示 TYPEMISMATCH，CfgType 是 ETGO 而实际槽位信息缺失，这就是开局时板卡插错槽位或数据配置错误，不是板子坏了，重插或改配置即可，不用换板。

2.3 温度、风扇与 CPU：硬件健康的三组联动指标

单板状态正常不代表设备健康，温度、风扇转速和 CPU 占用率必须组合起来看。这三组数据单独看都有迷惑性，但放在一起能还原设备真实运行状态。

C300# show fan FanControlType : temperature-control TemperatureThreshold : 10 30 38 46 (deg c) FanSpeedLevelPercent : 20% 35% 50% 75% CriticalTemperatureThreshold : 160(deg c) Environment Temperature : 23(deg c) FanUnitId SpeedLevel ActualSpeed(RPM) ---------------------------------------------- 1 2 2100 2 2 2100 3 2 2100

风扇是温度控制模式，四个温度阈值 10/30/38/46 对应四档转速 20%/35%/50%/75%。当前环境温度 23℃，风扇处于第二档 2100 RPM，这是正常联动。需要警惕的是两个极端：环境温度长时间高于 46℃ 风扇仍不升档，说明风扇控制链路有问题；温度正常但转速异常偏高，可能是风扇轴承老化或温控策略被改过。

C300# show card-temperature Rack Shelf Slot Temperature Temperature(5m) Temperature(1h) Optical-Temp ------------------------------------------------------------------------------- 1 1 5 42 42 42 N/A. 1 1 10 32 32 32 N/A.

单板温度超过 55℃ 就要重视了，高温会直接影响光模块发光功率和转发芯片稳定性，业务时延变大、丢包增多往往就是温度问题引起。show processor输出里 CPU 利用率分 5s、1m、5m 三个窗口，长时段大于 60% 需要核查原因；如果 CPU 长时间压在 99%，大概率不是业务量大，而是协议报文冲击，后面故障章节会展开说。

3. 常用命令组合：状态查询、注册核对与配置解读

3.1 三板斧：先看硬件、再看时间、最后看链路

OLT 排障的第一组命令，永远是硬件状态、系统运行时间和上联链路。顺序不能乱，先确认设备本身没病，再谈业务。

show system-group用于查看系统运行时间和设备位置信息，最核心的字段是Started before，直接反映设备最近有没有掉过电。如果用户报障“凌晨断网”，而系统时间显示设备 5 天前启动，说明 OLT 没掉电，问题在别处；如果显示刚启动 20 分钟，那先查电源和机房供电，别急着查光猫。

C300# show system-group System Description: C300 Version V2.1.0 Software Started before: 5 days, 16 hours, 15 minutes System name: KS-TS-26HaoXiaoQu-C300

show processor要重点看主控板槽位的 CPU 和内存。主控板内存占用率如果从 26% 涨到 66%，且 CPU 5m 窗口持续上涨，通常是有异常协议报文或某块业务板在反复请求配置。查链路用show interface看上联口收发光和错包计数，物理层没问题再往上联交换机 ping 网关。

3.2 注册查询：未注册列表、按 LOID 查、按 SN 查

光猫上不了网，先分清是“没注册”还是“注册了但业务不通”。这两种情况的排查路径完全不同。

查看未注册光猫用show pon onu uncfg，GPON 和 EPON 都适用：

C300# show pon onu uncfg OltIndex SN LOID ------------------------------------------------------------------------- gpon-olt_1/1/6 FHTT56075A10 9980991636C gpon-olt_1/14/2 SCTY40F25A38 N/A gpon-olt_1/15/2 ZTEGC04A5073 ZTEGC04A5073

这个命令的价值在于快速发现“在线但未注册”的光猫。LOID 为空的设备要特别留意，专线光猫经常用 SN 做认证，LOID 为空属于正常。EPON 侧用show onu unauthentication，输出包含 MAC、SN、LOID、Online State 和 RegTime，其中authentication deny表示认证被拒绝，优先检查 OLT 侧是否配置了该 ONU 的 MAC 或 SN 白名单。

已注册光猫的查询用show gpon onu by loid和show gpon onu by sn：

C320# show gpon onu by loid 9980599382C Search result ------------------ gpon-onu_1/1/1:1

返回gpon-onu_1/1/1:1表示该 LOID 注册在 1 框 1 槽 1 口下。如果返回%Code 62310-GPONSRV: No related information to show.，说明 LOID 在 OLT 侧没有数据，光猫根本没完成注册流程，往 PON 口下挂情况、光路质量和注册模板方向查。

3.3 配置核对：running-config 里的业务链路还原

注册成功但业务不通，就要核对业务配置。从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 linktrap disable resource-id-assign-mode mode2 onu 1 type ZTEG-F660 loid 9980662366C onu 17 type ZTEG-F660 loid 9980662324C

再查单个光猫的数据配置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 service-port 1 vport 1 user-vlan 46 vlan 46 service-port 2 vport 2 user-vlan 41 vlan 877 service-port 5 vport 3 user-vlan 50 vlan 50 igmp fast-leave enable vport 3

配置文件里依次定义了 TCONT（上行带宽管道）、GEMPORT（业务流封装）、SERVICE-PORT（VLAN 映射）。user-vlan 46 vlan 877表示用户侧 VLAN 46 进入 OLT 后映射到网络侧 VLAN 877，这是常见的单层 VLAN 透传。有些局点采用双层 VLAN，配置里会出现svlan 270这样的字段，表示外层 VLAN 封装。这套“用户 VLAN → 网络 VLAN → SVLAN”的映射关系，是判断数据配置是否正确的关键，也是答辩时最能体现功底的细节。

远程下发模式下还需要看show onu running config gpon-onu_1/1/2:1，确认光猫侧电口与 GEMPORT 的对应关系。简化命令模式直接用service ITMS gemport 1 vlan 46建立桥接；非简化模式则用flow 3 pri 5 vlan 45指定每个 flow 的优先级和 VLAN。这两种模式配置写法不同，但作用相同，现场最常翻车的点是改了一侧忘了改另一侧，造成 OLT 侧 VLAN 映射和光猫侧桥接对应不上。

4. 故障分类与避坑：五类高发问题的定位流程

4.1 先把故障分类：设备板卡、ONU、上联、光猫与业务

故障处理最忌讳上来就猜。手册的故障分类逻辑是按“业务范围 + 故障现象 + 触发条件”三维划分，先定位故障发生在哪一层，再决定用哪组命令。

设备板卡故障表现为整框或某槽位业务全断，优先用show card和show card-temperature确认硬件状态；ONU 故障表现为单户或单 PON 口下部分光猫掉线，查show pon onu uncfg和注册信息；上联状态问题表现为整台 OLT 下所有用户同时卡顿或丢包，查上联口收发光和错包计数，配合show processor看主控 CPU 是否异常；光猫侧故障表现为光猫在线但业务不通，重点核对 LOID、VLAN 配置和 ITMS 下发状态；业务类故障比如机顶盒获取错误地址、测速不达标，则需要结合组网拓扑逐跳排查。分类对了，命令组合自然就出来了，这也是这套手册最有价值的部分。

4.2 典型故障处理流程：网元断链、注册异常与流氓光猫

OLT 网元断链是网管侧最常见的告警，现象是网管平台上这台 OLT 离线，但用户可能一切正常。处理流程按四步走：第一步，show system-group确认设备是否掉电重启过；第二步，ping 网管服务器地址，不通再查管理通道，确认是带外管理还是带内管理，带内管理要检查上联链路；第三步，show card看主控板是否有倒换，STANDBY 板变为 ACTIVE 时网管会短暂断链；第四步，show log查断链时间点附近是否有链路抖动记录。按照这个顺序走一遍，基本能在 10 分钟内定位到具体原因，而不是在网管上反复重启采集通道。

光猫注册异常分为两类，一类是注册不上，另一类是注册了又被踢下线。注册不上先查show pon onu uncfg确认光猫是否被 OLT 发现；如果列表里根本没有这台光猫，说明光路有问题，查分光器到 OLT 的收光功率；如果列表里有但认证不通过，检查 LOID 是否输入错误、注册模板是否绑定 SN。常见的隐蔽场景是“新光猫替换旧光猫”，OLT 侧仍绑定旧 SN，新光猫无法通过认证，此时用sn-bind disable关闭绑定或重新绑定新 SN 即可。

流氓光猫故障隐蔽性很强，现象是某个 PON 口下所有光猫时断时续，单独看每台光猫光功率都正常。原因是一台光猫异常发光或产生环路，把整个 PON 口的上行时隙占满。排查时用show pon power attenuation或逐台关闭 ONU 口的方式定位异常设备，处理完成后要把该光猫的发光功率和状态作为基线记录，下次再出同类问题可以直接对比。这类故障在手册里专门强调了“隔离问题光猫、调整光功率”的处置思路，属于典型的“一只老鼠坏一锅汤”。

4.3 最容易翻车的三个坑：现象、原因与解决

第一个坑是HWONLINE直接判板卡损坏。现象是show card里某业务板显示 HWONLINE，现场人员直接申请换板，但问题依旧。原因是 HWONLINE 只表示“板卡在位但不在线”，可能是槽位没有添加单板数据、版本文件缺失，或者板卡与背板接触不良，不一定是硬件损坏。解决方法是先show card核对 CfgType 和 RealType 是否一致，再通过拔插板卡或重启单板观察状态是否恢复，确认硬件故障后才走换板流程。

第二个坑是 LOID 和 SN 混用导致认证失败。现象是光猫注册时提示认证拒绝，但 LOID 明明没错。原因是部分专线光猫使用 SN 认证，GPON 和 EPON 的认证字段不同，GPON 看 SN，EPON 看 MAC 或 SN，现场只查 LOID 忽略 SN 绑定，自然查不到问题。解决方法是先确认该局点的认证模式，再分别用show gpon onu by sn和show gpon onu by loid查询，双字段比对后才能确认注册链路是否完整。

第三个坑是把 CPU 高占用简单地归因于话务量大。现象是show processor显示主控板 CPU 长时间 99%，业务侧表现是光猫频繁掉线。原因是协议报文冲击，比如下挂环路导致的广播风暴或某个 ONU 疯狂发送报文，而不是用户量真的那么大。解决方法是先看 CPU 5s、1m、5m 三个窗口的变化趋势，再通过 Wireshark 或设备抓包确认报文类型，定位到具体端口后隔离处理。CPU 冲高不解决就重启主控板，往往重启完几分钟又打满，治标不治本。

5. 验收与答辩：让这套方案能证明你的故障定位能力

如果你的任务是拿这套手册交课设或毕设，验收的关键不是“能背出多少命令”，而是能不能现场走通一条完整的故障定位链路。我建议按下面的验收清单自测，每一项都对应一个可演示的动作：

答辩时最大的加分技巧是“按层次讲故障”。比如评委问你怎么排查光猫不能上网，不要一上来就背命令，而是先说排查思路：先看show card排除单板问题，再看show pon onu uncfg确认光猫注册状态，最后查show running-config interface gpon-onu核对 VLAN 映射，三层逐级收窄，逻辑清晰且有工程感。讲解时配合命令输出截图，把每个状态字段的含义说清楚，比罗列二十条命令有效得多。

还有一个小技巧，可以把整套手册整理成“现象 → 定位命令 → 处理动作”的速查表，放在方案最后当附录。这个速查表既是你实际落地的工具，也是答辩时快速回答问题的底稿，评委问任何一个故障场景，你都能在三秒内翻到对应处理步骤。从那以后我每次做网络类项目，都强制走一遍“先分类、再查状态、后验证配置”的标准流程，不再凭感觉跳步排查，少走了很多弯路。这份手册的完整命令和案例细节，直接跟着原文过一遍就能复现。希望帮到你。

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