企业官网建设流程全解析

简介：面向网络运维人员与中兴OLT设备维护工程师的故障处理速查手册，内容覆盖ZXA10 C300/C320硬件面板、单板状态解读、常用命令行查询以及常见故障分类与案例。手册按设备介绍、常用命令、故障分类、案例介绍四部分组织，从设备板卡、ONU、上联状态到光猫侧、机顶盒、流氓光猫、测速不达标等场景均有对应排查思路与处理步骤，并给出光网络整体连接架构，便于理解故障影响范围。资源包为单个pptx格式文件，大小约7.17MB，版式清晰适合随身查阅。目前已有2789人学习下载。读者可通过show card、show interface等命令快速定位板卡不在位、配置不匹配等状态，也可参照ONU注册异常、网元断链、光猫注册异常等案例，建立从故障现象、触发条件到信息反馈收集的完整定位方法，快速解决实际网络问题。

1. OLT故障排查：为什么一行状态输出比满屏日志更管用

一个反直觉的场景：某局点凌晨PON口下十几个用户同时掉线，设备日志刷了几十屏，但真正有用的线索只有show card输出里那一列Status——某块GPON板卡的状态从INSERVICE变成HWONLINE。OLT的板卡状态、光猫注册状态、业务数据链路，本质上是一台设备把「硬件健康、注册凭据、业务映射」三层事实压缩成了几个字段。搞懂这些字段怎么产生、怎么流转，比背一百条命令更能应对断链、注册异常、流氓光猫这类故障。这就是为什么OLT故障解析手册的价值不在于命令本身，而在于它教你从状态反推根因。

2. 硬件架构与板卡状态机：槽位布局如何决定故障的边界

2.1 槽位规划：主控、上联、业务板的分层隔离

ZXA10 C300和C320的机框布局，本质上是一张故障隔离图。主控交换板占9U高度、双槽位冗余保护；业务板卡占最多14个槽位，EPON/GPON板按8口或16口划分；上联卡独立成4.5U的槽位区域，支持千兆光口、光电混合口、万兆口不同规格；电源板双路-48V冗余；风扇插箱1U高度装3组风扇。这套布局的潜台词是：哪一层出问题都不该跨层扩散——风扇挂了不该影响业务板转发，主控切换不该导致PON口下光猫全部重注册。

维护中真正要用到的是「槽位号→板卡类型」的映射关系。比如业务板槽位习惯上按 2～8、12～19 分布，主控固定在 10、11，上联在 12、13 附近；如果某个槽位的CfgType与实际插入的板卡不符，OLT会直接把状态打成TYPEMISMATCH，而不是假装正常工作。这个字段是配置管理员和现场工程师之间最容易扯皮的地方——配置管理侧以为插的是EPON板，现场实际插了GPON板，业务一开就异常。先核对CfgType与RealType是否一致，能避免一大半「板卡故障」误报。

2.2 板卡状态字段：六个状态对应的物理事实

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 13 ETGO 8 V1.0.0 V2.1.0 TYPEMISMATCH 1 1 14 GTGH GTGHG 16 V1.0.0 V2.1.0 CONFIGING 1 1 11 SCXM SCXM 0 V1.0.0 V2.1.0 STANDBY

这段输出最关键的是区分CfgType和RealType。CfgType是配置文件里「你以为这个槽位有什么」，RealType是系统实际识别到的硬件。两者不一致时状态直接给TYPEMISMATCH；RealType为空说明槽位没识别到板卡。HWONLINE的含义是板卡在位但不在线，常见成因有三类：版本文件丢失、配置里没有添加这块单板、单板硬件损坏导致主控无法完成软件握手。NOPOWER则是在位但未通电，供电链路或板卡电源模块的问题，和HWONLINE完全是两个故障层。

HWONLINE背后还有一层时序逻辑：主控会周期性轮询业务板的在位状态，但「轮询有响应」和「软件握手完成」是两件事。V2.1.0软件版本下，板卡要经过上电自检、版本加载、配置同步三个阶段才能进入INSERVICE。HWONLINE往往意味着前两个阶段已经通过，但第三个阶段没走完——所以这类板卡在日志里通常伴随加载失败的记录，而不是完全静默。

2.3 环境监控：风扇、温度与CPU如何提前暴露故障

show fan的输出里藏着一个容易被忽略的设计：风扇转速是分级的，级数与温度阈值一一对应。TemperatureThreshold: 10 30 38 46对应转速20% 35% 50% 75%，还有高温60℃、低温-20℃的告警线。这套温度-转速联动逻辑的意义在于OLT风扇是自适应调速，不是全速狂转。反过来说，如果环境温度正常但风扇长期停在高档位，说明风扇老化或机柜积热，只靠「风扇online」判断不了健康度。

C300# show card-temperature 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.

单板温度超过55℃时，光模块的发光功率会漂移，PON口下光猫的收光裕量被压缩，外表看起来就是「测速不稳定」。手册给的这条线其实很保守，工程上一般在50℃左右就开始介入。注意输出同时给了5分钟均值和1小时均值：如果两者差距大，说明温度在快速爬升，优先查风扇和机房空调，而不是业务配置。show processor同理，各槽位CPU和内存都列出来，主控槽CPU长时间超过60%要警惕协议报文冲击——单板CPU高是局部故障，主控CPU高是全局风险，处置优先级完全不同。

3. 注册机制与数据模型：光猫从上线到通业务要过几道门

3.1 SN与LOID：硬件身份与业务身份的分离设计

GPON和EPON在光猫认证上走的是两套逻辑，但共同点是都把「硬件身份」和「业务身份」分开了。GPON光猫有8字节的SN，EPON光猫有MAC地址，这是出厂固定的硬件身份；LOID是运营商下发的业务身份，与具体用户账号绑定。硬件身份用于发现光猫，业务身份用于认领光猫——所以说换光猫不换业务时，只需要在新光猫上配同样的LOID，OLT侧不用改任何绑定关系。

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

show pon onu uncfg查的是GPON下未注册光猫的对照表。注意看第三行：SN有值，LOID是N/A——说明光猫在OLT的发现窗口里上报了硬件身份，但OLT没有任何一条onu X type ... loid ...配置认领它。新装宽带时看到这一行，补一条onu配置就完了；专线光猫则相反，SN为空而LOID有值，因为专线业务要求LOID认证，SN绑定被刻意关闭。EPON侧对应的是show onu unauthentication，它查的已经是「在线但认证被拒」的光猫，关键字段是Online State: authentication deny。physically online 但 logically denied，这是EPON认证失败最典型的现场：光功率正常，认证流程没过。

3.2 T-CONT、GEM port与service-port：三级映射链路

一台光猫从注册成功到真正能上网，配置上要过三关。T-CONT是带宽容器，allocid是OLT给容器的分配标识，profile引用带宽模板，决定这条业务能占多少带宽。GEM port在T-CONT之上建立承载通道，portid标识通道号，一个T-CONT下可以挂多个GEM port来区分业务。service-port把业务映射到具体VLAN，真正决定数据怎么转发。

interface gpon-onu_1/1/2:1 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 service-port 2 vport 2 user-vlan 41 vlan 877

这条配置要倒着读：service-port 2 说「用户侧VLAN 41的流量从vport 2进入，映射到业务VLAN 877」，vport 2对应gemport 2，gemport 2挂在tcont 2上。于是完整链路串起来：光猫LAN口出来的VLAN 41数据，经GEM port 130通道进入T-CONT 257带宽容器，再由OLT改写VLAN标签后送往上联。三个环节各司其职：T-CONT管带宽，GEM port管通道，service-port管VLAN映射。排查时也按这个分层走——带宽不足看profile，通道异常看gemport，VLAN不通看service-port。show onu running config里的pon-onu-mng段是远程下发模式下OLT与光猫之间的桥梁配置，它告诉光猫「哪个GEM port承载哪个VLAN」，业务不通时除了看OLT侧，还要确认光猫侧这段配置有没有被RMS平台覆盖掉。

3.3 单层与双层VLAN：上联交换机与直连BAS的分支点

对比手册里两组running-config，会发现VLAN设计上的一个分支点。上联交换机场景下，service-port写的是user-vlan 46 vlan 46，单层VLAN，用户VLAN直接透传到交换机；直连BAS场景下变成user-vlan 41 vlan 312 svlan 270，双层VLAN。为什么有这种差异？上联交换机时OLT和BAS之间隔着汇聚交换机，汇聚设备只做二层透传，用户VLAN原样穿过；直连BAS时OLT直接把内外层标签给BAS，BAS按外层SVLAN快速分流到不同业务板卡，减少内层VLAN解析压力。

组播这里有个容易忽略的开关：igmp fast-leave enable vport 3。IPTV场景下用户切台时，如果IGMP leave报文后还要等通用查询超时，换台会有明显卡顿；fast-leave让OLT收到leave立即删掉组播复制关系。但这个开关只能开在组播VLAN的vport上，不能对普通上网业务开，否则用户短暂断网时IGMP状态被快速清理，组播流量会闪断。手册案例里「IPTV卡顿但上网正常」的高频根因，一半出在这个开关的配置位置，而不是组播源本身。

4. 故障分类与排查路径：从现象到根因的分层决策

4.1 三层故障模型：设备层、接入层与业务层的症状映射

手册按故障类型、业务范围、故障现象、触发条件四个维度切分故障，本质上是在表达一个三层模型。设备层包括OLT硬件、板卡状态、环境温控和主控倒换；接入层包括PON口光功率、光猫注册、ONU认证；业务层包括VLAN映射、DHCP地址分配、组播复制和专线通道。三层之间有清晰的症状映射：设备层故障通常表现为多业务同时闪断或整机失管；接入层故障表现为某个PON口下光猫集体掉线或注册失败；业务层故障表现为光猫在线、注册正常，但特定业务不通或质量差。

这个模型的价值在于排除法。业务范围是第一把尺子：整台OLT所有用户都断，优先查上联和主控；一个PON口所有用户都断，优先查PON口光模块、分光器和长发光；单户业务不通而其它业务正常，优先查光猫配置和service-port。故障现象决定命令选择：掉线看注册状态，卡顿看光功率和CRC，不通看VLAN映射。

手册强调的「故障信息反馈与收集」也基于这层模型。一个合格的故障上报至少包含五要素：故障类型（断链/注册失败/测速慢/专线卡顿）、业务范围（整机/单PON口/单用户）、故障现象（掉线/闪断/不通/丢包）、触发条件（升级后/雷雨后/换猫后）、以及现场收集到的状态输出。这五要素本身就是一张决策树：范围决定查上联还是查PON口，现象决定查光功率还是查VLAN，触发条件决定查变更还是查环境。

4.2 排查顺序：先看板卡、再看注册、最后查配置

我一般会把OLT故障排查的起步动作固化成一条命令链，顺序不能乱：

C300# show card // 1. 硬件是否健康 C300# show pon onu uncfg // 2. 哪些光猫没有完成注册 C300# show running-config interface gpon-olt_1/1/2 // 3. 注册与数据配置是否有变 C300# show gpon onu by loid 9980662366C // 4. 反向确认某台光猫落在哪个PON口

先看板卡状态，是因为硬件异常会同时影响注册和数据面，此时查配置属于白费力气。再看未注册光猫，是因为它能区分「光猫没上线」和「光猫上线了没认领」。最后才碰配置，避免把配置往错误方向带偏排查。这条链的每一步都在收窄故障层，而不是在增加变量。手册里show gpon onu by sn和show gpon onu by loid这类反向查询命令，用途就是拿到注册结果后再回来定位物理位置，属于同一闭环的收尾动作。

4.3 OLT网元断链：管理面与业务面的分离排查

网元断链是最容易误判成「设备宕机」的故障。第一步不是重启，而是确认设备是否活着。show system-group里Started before: 5 days, 16 hours, 15 minutes这一行，直接告诉你设备自上次启动以来运行了多久——如果这个时间远小于预期，说明掉过电或主控重启过；如果设备的运行时间正常但网管仍然不通，问题大概率在管理通道而不是设备本身。

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

判断完存活后看主控是否倒换。双主控配置下正常状态是槽位10 INSERVICE、槽位11 STANDBY；如果槽位10变成OFFLINE而槽位11转成INSERVICE，说明发生过主备切换。主控倒换会让管理面断链，但业务面不一定断——PON口下的光猫注册关系需要备主控重新同步，如果同步没完成，会出现光猫在线但业务不通的中间态，此时业务板状态多半是CONFIGING。

断链排查顺序应该固化为：物理连通（上联口光模块收发光）→ 协议状态（主控与上联口协议UP）→ 设备状态（CPU、内存是否被报文打满）。很多断链的根因是管理VLAN的CPU队列被广播报文占满，设备活着但网管报文挤不进去。这种场景重启设备属于帮倒忙——重启后所有光猫重新注册，业务中断时间被拉长。正确的临时手段是拔掉异常上联或封堵广播源，恢复管理通道后再定位根因。

5. OLT常见问题避坑指南：注册异常、流氓光猫与测速不达标

5.1 光猫注册不上：LOID为空与认证拒绝是两回事

现象：光猫指示灯正常、PON口物理链路也通，但RMS/ITMS平台上看不到光猫上线，用户业务不通。

原因：把「光猫在线」和「光猫注册成功」混为一谈。GPON下用show pon onu uncfg查未注册光猫，SN有值而LOID是N/A，说明光猫在OLT的发现窗口里报到了，但OLT没有任何一条onu配置认领它；EPON下用show onu unauthentication看到Online State: authentication deny，则是OLT明确拒绝了认证。前者是「没人认领」，后者是「认领了但凭据不对」，处理方向完全相反。

解决：LOID为N/A的场景，在PON口下补onu X type ZTEG-F660 loid 9980XXXX即可。authentication deny的场景，先核对光猫里配的LOID和OLT侧配置是否一字不差，再查LOID_PSW注册密码是否被平台改过。我的血泪经验是：LOID错误多半是手输时把数字0和字母O看混；密码错误多半是RMS重新下发过注册密码，光猫侧没同步。处理前先show gpon onu by loid反向确认OLT侧到底存了什么，再动光猫。

5.2 流氓光猫：长发光如何拖垮整个PON口

现象：某个PON口下多台光猫同时段集体掉线或频繁闪断，OLT的PON口收光功率异常偏高，但单台光猫逐个测试都正常。

原因：PON是点到多点的时分复用架构，同一PON口下所有光猫共享上行时隙，由OLT通过测距和时隙授权避免冲突。流氓光猫（长发光ONU）的发光器件损坏或软件异常，导致它在未获得授权的时隙里持续发光，把整个PON口的上行通道占死，其它光猫的上行数据全部碰撞丢失。表现就是集体掉线，而且越靠近故障PON口越严重。

解决：逐台拔纤隔离。把该PON口分光器前端的尾纤依次拔掉，每拔一台观察PON口收光功率和在线光猫数量是否恢复，拔到哪台时功率恢复正常，哪台就是长发光源。定位后先用shutdown隔离该光猫的注册端口，再联系用户更换光猫。

提示：长发光光猫在OLT侧往往显示在线且注册正常，因为它只是多发数据，不是不响应管理。靠注册状态查不出它，必须对比PON口收光功率的变化来定位。

5.3 测速不达标与机顶盒获取错误地址：先分内网外网再动配置

现象：用户报宽带测速不达标，或者IPTV机顶盒获取到的IP网段不对、不能看直播。

原因：测速不达标背后至少有四层可能性——PON口收发光功率劣化导致误码重传、光猫与OLT协商速率低于签约带宽、上联口CRC错误计数增长导致丢包、service-port引用的带宽profile限速值偏小。机顶盒获取错误IP则多半是组播VLAN和上网VLAN混在了同一个vport上，或者DHCP报文的VLAN标签没被正确改写，机顶盒拿到了上网业务地址段的地址。

解决：测速问题按物理→协商→配置顺序查。先看光猫收光是否在合理区间（GPON一般要求收光不低于-27dBm），再看PON口和上联口的协商速率与CRC计数，最后核对service-port和带宽profile。机顶盒问题先确认机顶盒接的光猫LAN口是否绑定在ITV业务VLAN上，再查OLT侧组播service-port是否独立vport——组播和上网必须走不同vport和不同service-port，这是杜绝地址串扰的前提。专线卡顿走同样的排查链，只多查一层：专线光猫的SN绑定是否被误改成了LOID认证。

5.4 板卡更换与配置同步：CONFIGING不能当故障处理

现象：更换主控板或业务板后，板卡状态长时间停在CONFIGING，业务板看着在线但业务时通时断，部分用户持续掉线重注册。

原因：CONFIGING是配置同步的过渡态，不是故障态。主控倒换或板卡重启后，新主控要把全局配置下发到业务板，业务板内存里的转发表、光猫注册表都要重建。如果新板卡软件版本与主控不完全一致，或配置量过大，同步时间会明显拉长；此时如果人为重启或拔插板卡，会打断同步过程，让板卡陷入反复CONFIGING的循环。

解决：看到CONFIGING先等，同步完成后状态会自行转成INSERVICE。同时用show card-temperature和show processor观察板卡运行指标，确认它是在同步而不是死循环。超过预期时间仍不恢复，优先查板卡软件版本是否与主控匹配，再查CfgType与实际板卡型号是否一致（TYPEMISMATCH），而不是直接重启。换板前先核对新板卡型号与CfgType一致，能省掉一整轮此类故障。

6. 设计取舍：SOP为什么比一条调试命令更值钱

整本手册最值得琢磨的不是某个命令的语法，而是它的组织方式——设备面板→常用命令→故障分类→案例介绍，把「状态字段」和「处置动作」绑成了固定的排查链路。show card看硬件，show pon onu uncfg看注册，show running-config interface看数据，三组命令正好覆盖了设备管理的三个平面。这个设计取舍很明确：与其背两百条命令，不如掌握十条能反推根因的核心命令，并且把它们的执行顺序固化成习惯。

另一个值得注意的取舍是它对「故障信息反馈与收集」的强调。一个合格的故障描述应该包含故障类型、业务范围、故障现象、触发条件四项，这实际上是在逼运维先完成分层定位再上报，而不是把日志一股脑扔给后端。手册的几个案例——光猫注册异常、机顶盒拿错地址、流氓光猫、测速不达标——全部落在三平面的某一条链路上，没有一个是靠单条调试命令能解决的，靠的是按层拆解。

我自己的习惯是：接到任何OLT相关报障，先命令走完硬件→注册→数据三条链路，把状态字段抄下来再动手改配置。这个习惯来自一次教训——某次光猫注册异常，我直接在PON口下追加了onu配置，结果发现根因在service-port的vport映射上，多出来的配置反而让光猫注册到了错误的业务通道。从那以后，每次排查我都强制先走完状态收集这一步再碰配置，希望帮到你。

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