做过接入网维护的人十有八九都遇到过这种局面用户报修“网速慢”你赶到现场一查光猫PON指示灯正常、注册状态在线、光功率也在合理范围内ONU怎么看怎么“健康”可一测速就是上不去。这种故障最磨人因为表面上看一切正常问题往往藏在OLT侧、BRAS侧或者是PON口下挂着的那一堆用户共同造成的拥塞里。这篇文章就围绕“ONU正常但网速不达标”这个具体场景从PON网络的基本关系讲起把带宽限速和链路拥塞这两大类原因彻底拆开再给出一套可以直接照着做的排查流程。不管你是装维工程师、ISP网维人员还是自己折腾家庭网络的资深玩家只要能看懂OLT和ONU的概念这篇文章里的大部分操作你都能落地。1. 先搞清楚PON网络的“家庭关系”OLT、ONU、分光器到底谁管谁排查故障之前必须先搞清楚PON网络里几个核心角色之间的关系。很多时候网速问题的根源不在于某一个设备坏了而在于整条链路的协作出了问题。1.1 PON网络的三层结构用一张“小区快递”的图就能讲明白PONPassive Optical Network无源光网络本质上是一个点对多点的光纤接入架构。局端放一台OLTOptical Line Terminal光线路终端用户家里放一台ONUOptical Network Unit光网络单元也就是我们常说的光猫中间由ODNOptical Distribution Network光分配网络连接核心器件就是无源分光器。用小区快递来类比就很好懂OLT是小区门口的快递总站ONU是你家门口的快递柜分光器就是那栋楼的单元门禁——快递员光信号从总站出发经过单元门禁最后送到你家快递柜。注意一个关键点分光器是无源的它不处理信号、不识别地址它做的事情就是把一路光信号“复制”成多路同时把多路光信号“合并”成一路。整个过程不需要供电也不需要软件配置。一个PON口下通常可以挂32、64甚至128个ONU取决于PON类型和分光比。这些ONU共享同一个PON口的带宽这是理解后面所有拥塞问题的基石。1.2 OLT和ONU的分工谁在“发号施令”谁在“听令行事”OLT是整个PON网络的“大脑”负责管理所有下挂的ONU。具体管三件事一是发现新ONU并完成注册二是通过DBADynamic Bandwidth Allocation动态带宽分配算法给每个ONU分配上行时隙三是下发各种配置包括限速模板、VLANVirtual Local Area Network虚拟局域网划分、组播配置等。ONU则是“执行者”它听从OLT的指令在分配好的时隙内发送数据。下行方向OLT到ONU是广播式的OLT发出的数据帧带有ONU的标识每个ONU只接收发给自己的帧上行方向ONU到OLT是时分多址的多个ONU必须轮流发数据不能同时发否则就冲突了。这个“轮流发数据”的机制特别重要。GPONGigabit-capable PON的下行速率是2.5Gbps上行是1.25GbpsEPONEthernet PON上下行都是1Gbps。如果一个PON口下挂了32个ONU每个ONU理论上只能分到下行约78Mbps、上行约39Mbps的平均带宽GPON。当然实际情况中OLT的DBA会根据每个ONU的实时需求动态调整瞬时可以让某个ONU用满整个PON口的带宽但如果多个ONU同时要大带宽就必然出现竞争和拥塞。1.3 ONU显示“在线”不等于“健康”这两个状态要分清装维人员在光猫上看到的“PON灯常亮”“注册成功”只代表这个ONU已经在OLT上完成了注册且OLT和ONU之间能够正常通信。但这完全不等于ONU的链路质量好、带宽充足。OLT上会显示ONU的状态常见的有online在线、offline离线、unknown未知。很多人一看到online就放心了却忽略了OLT告警里可能还有CRCCyclic Redundancy Check循环冗余校验误码告警、光功率低告警、PON口拥塞告警等。ONU在线只是“能通”而“能通”和“通得好”之间差了十万八千里。所以排查故障的第一原则就是不要被ONU的“在线”状态迷惑一定要结合流量统计、误码统计、光功率、限速配置等多个维度综合判断。2. 带宽限速和链路拥塞两个最容易被忽略的“隐形杀手”ONU正常但网速不达标原因基本可以归为两大类一是被限速了配置层面的问题二是链路拥塞了资源层面的问题。这两类问题的判断思路和处理方式完全不同。2.1 带宽限速明明办的是500M套餐为什么测出来只有100M带宽限速是指在网络设备的配置里人为地对某个用户、某个VLAN或某个端口设置速率上限。限速可以在多个层面实施但用户的直观感受是一样的不管怎么测速率总是被“卡”在一个固定值上。一是OLT侧限速。这是最常见也最容易被忽略的。OLT上通常有流量模板Traffic Profile或带宽模板可以针对单个ONU或单个业务流设置上下行速率。比如某个ONU的线路模板里配置了下行限速100M那不管用户套餐是500M还是1000M实际速率最多就是100M。二是BRAS/AAA侧限速。BRASBroadband Remote Access Server宽带远程接入服务器是运营商宽带网络的核心网关用户拨号认证、带宽策略都在这里执行。用户办的宽带套餐速率最终是在BRAS上通过用户账号下发的。PPPoEPoint-to-Point Protocol over Ethernet以太网点对点协议拨号成功后BRAS会根据用户账号对应的速率模板给这个连接限速。三是ONT/ONU侧限速。光猫本身也可能有限速配置。一些光猫的LAN口有速率限制功能或者无线SSID有独立的限速策略。这种情况在家庭用户里相对少见但在政企客户或者出租屋场景里会碰到。排查限速问题的关键方法是“分段测速”在光猫LAN口用电脑直连测速如果达标说明OLT和BRAS侧都没问题问题可能在路由器或WiFi如果LAN口测速不达标再看看是不是OLT侧模板或BRAS账号速率不对。通过这个方法可以先把故障范围缩小一大半。2.2 链路拥塞PON口就像早高峰的匝道车多就必然慢链路拥塞是指PON口下的所有ONU实际需要传输的数据量总和超过了PON口的物理带宽上限导致每个用户都“吃不饱”。注意一个常见的认知误区很多人觉得PON口带宽是“按分光比平均分配”的1:64分光就把2.5G除以64每个用户大约39M。但实际上PON系统的带宽是“共享动态分配”的OLT的DBA算法会根据每个ONU的实时业务需求动态分配带宽。闲时一个ONU可以独占大部分带宽忙时大家都要带宽每个ONU分到的就少。所以拥塞有一个显著特征时段性。白天上班时间测速正常晚上7点到11点高峰时段速度明显下降或者下雨天、节假日速度变慢。这种“时快时慢”的现象基本就能锁定是拥塞而不是限速因为限速是恒定不变的不会分时段。判断拥塞还有一个重要指标PON口的上行/下行利用率。如果PON口的下行利用率长期超过70%80%或者出现周期性峰值打满的情况就可以判定这个PON口存在拥塞。上行方向同理GPON上行只有1.25Gbps对于追求上行带宽的场景直播、监控回传、云盘上传上行拥塞比下行更常见。2.3 拥塞的连锁反应不仅是慢还会产生大量丢包和延迟这里需要提醒一句拥塞不只是“网速慢”这么简单。当PON口流量接近饱和时OLT和ONU的缓存队列会堆积导致三个后果一是时延增加游戏卡顿、视频会议画面模糊二是丢包率上升TCPTransmission Control Protocol传输控制协议流量会因重传而进一步加剧拥塞三是某些对实时性要求高的业务语音、视频会明显劣化。我在实际处理过一个案例某个城中村的PON口下挂了60多个ONU每天晚上8点过后PON口下行利用率持续在95%以上。用户普遍反映“网速不到10M”但ONU状态全部正常、光功率正常、没有任何限速。后来把其中30个ONU割接到新增的PON口后所有问题迎刃而解。这种情况下ONU和光路都没有任何故障纯粹是“路太窄、车太多”。3. 实操篇从ONU到OLT一套完整的排查流程接下来进入正题分享一套我实际工作中验证过的排查流程。这套流程的特点是“由近及远、先易后难、先配置后资源”避免一上来就动光路或板卡做无用功。3.1 第一步确认“ONU正常”到底正不正常光功率和误码一个都不能少虽然题目说“ONU正常”但我们要先把“正常”的定义搞清楚不能光看指示灯。在ONU上需要确认的项目收光功率RX PowerGPON ONU的收光范围通常在-8dBm到-28dBm之间最佳区间是-18dBm到-25dBm。如果收光在-27dBm到-28dBm虽然还“能亮”但已经处在临界状态光模块的误码率会明显上升。发光功率TX PowerONU的发光一般在0.5dBm到5dBm左右如果明显偏低可能是光模块老化或光纤弯折过大。连接状态PON口注册状态、OLT授权的业务VLAN是否正常下发。如果光功率在正常范围内也别急着排除光路问题。还需要检查OLT上报的ONU误码率。GPON ONU的在线误码如果持续增长哪怕光功率看起来正常也说明光路中有某个接头、法兰盘或分光器存在微弯或污染。这种问题用光功率计不一定能测出来但误码统计会如实反映。3.2 第二步分段测速把故障范围缩小到“最后一公里”内的某个环节这是最关键的一步直接决定后面该往哪个方向排查。先说标准的测速方法电脑通过网线直连光猫的LAN1口不要连路由器不要用WiFi。关闭光猫WiFi功能或者把光猫设为桥接模式用电脑PPPoE拨号测试。使用运营商的测速平台或国内主流测速应用测速3次取平均值。根据测速结果分情况处理情况一LAN口直连测速达标WiFi测速不达标。问题在WiFi覆盖、路由器转发性能或无线干扰跟PON网络无关。情况二LAN口直连测速不达标但更换不同时段比如凌晨测速达标。这种现象指向链路拥塞需要去OLT侧看PON口流量。情况三任何时段、任何方式测速都恒定在一个值比如100M换光猫也一样。这种指向限速配置需要查OLT流量模板和BRAS账号速率。情况四测速结果忽高忽低间隔几秒就有明显波动。大概率是PON口流量波动大或者UPON线路存在光模块劣化导致的偶发误码。3.3 第三步登录OLT查看PON口流量和DBA配置找出“元凶”如果判断是拥塞或者限速问题就需要登录OLT做进一步确认。不同厂商的OLT命令不同但核心逻辑一致。检查PON口流量利用率的思路华为MA5680T/MA5800系列display traffic table display ont-port 0/x y display pon power attenuation 0/x y中兴C320/600系列show gpon onu state gpon-onu_1/1/x:y show pon power attenuation gpon_olt-1/1/x show pon statistics gpon-olt_1/1/x查看PON口利用率一般看两个维度的数据PON口总流量包括上行和下行流量关注是否接近端口物理带宽上限GPON下行2.5G、上行1.25GEPON上下行1G。每个ONU的实时流量找到占用率最高的几个ONU看是否存在某个ONU长期占用大量带宽。检查限速配置的思路在OLT上查看该ONU绑定的流量模板或DBA模板。如果模板中配置了固定速率Fixed和保证速率Assured要注意它们的值是否小于用户套餐速率。重点看DBA模板。DBA模板定义了上行带宽的分配方式包括Fixed固定带宽不管用户用不用都保留一般用于语音等需要稳定带宽的业务。Assured保证带宽只要有需求就会尽量保证。Maximum最大带宽也是用户能到达的上行速率上限。如果ONU的DBA模板里Maximum值设成了100M那这个用户上行速率最多就是100M哪怕BRAS上给了200M也没用。这里给一个实际案例。某用户办的是1000M下行/200M上行套餐但上行测速始终只有100M。检查BRAS账号速率是200MOLT上ONU的DBA模板Maximum却是100M。将DBA模板Maximum改为200M后上行测速恢复正常。3.4 第四步判断是否需要扩容以及如何“花小钱办大事”如果确认PON口拥塞严重解决办法不是调参数而是扩容。扩容的方式根据资源情况选择。方式一同PON口下新增OLT端口。如果OLT上还有空闲的PON口把部分ONU割接到新PON口这是成本最低的方案。操作时要注意先在新PON口上完成ONU注册和业务配置再通过修改ONU的注册信息和VLAN实现业务无损切换避免用户业务中断。方式二新增OLT板卡或设备。当现有OLT板卡的所有PON口都用满了就只能加板卡或加设备。加板卡时要注意PON口光功率预算分光比不宜过大长距离场景需用Class C或Class D光模块。方式三调整分光比。比如把一个1:64分光器的某些ONU挪到另一个空闲PON口通过重新占光路的方式降低单PON口负载。这属于比较彻底的整治手段适合长期高负载的场景。关于扩容的判断标准有一个经验值可以分享。PON口下行利用率连续一周内出现3次以上超过70%的情况且高峰时段用户投诉网速不达标的占比超过单PON口下用户总数的30%就应该启动扩容。3.5 实操心得查拥塞时建议注意的3个小细节先看“平均流量”和“峰值流量”的差异。如果PON口平均利用率只有30%但每天晚上8点到11点峰值能冲到95%这属于典型的“潮汐拥塞”扩容重点要覆盖高峰时段。不要只看PON口总流量要区分上行和下行。很多PON口下行不拥塞但上行利用率长期超过90%直播、监控类用户多这种情况扩容时要注意GPON的上行瓶颈远大于下行。扩容时先看分光器的端口占用情况优先把占空比高、用户数多的PON口拆开而不是简单地把新用户加到旧PON口上。4. 常见问题与排查技巧实录那些年我们踩过的坑做PON故障排查光是懂原理还不够实际操作中有很多“看起来合理但实际会误导你”的坑。这一部分把这些年积累的典型坑整理成速查表格和避坑说明希望你在实际工作中用得上。4.1 问题速查表现象、定位方向、处理建议现象可能原因排查方向处理建议ONU正常但任何时候测速都恒定限速值OLT流量模板、BRAS账号速率、ONU端口限速检查OLT模板、BRAS用户表、ONU端口配置逐层解除限速优先查OLT和BRASONU正常但高峰时段慢、闲时正常PON口拥塞看PON口利用率、用户数量、分光比扩容PON口、调整用户分布、调整DBAONU收光功率正常但误码高光模块劣化、法兰盘污染、光纤微弯查看ONU在线误码、光路可见光检查重新插拔法兰盘、用酒精清洁端面、排查光纤弯折ONU偶发离线重注册每次几分钟后恢复光路瞬断、ONU供电不稳、OLT上ONU配置冲突查ONU掉电记录、光路告警、OLT日志检查电源适配器、更换光模块、检查分光器端口PON口流量不高但单用户速率低用户侧路由器/NAT瓶颈、光猫LAN口协商速率低光猫LAN口协商状态是否千兆、路由器有线转发能力换千兆光猫、检查网线是否为超五类/六类、关闭路由器QoSONU状态显示unknownONU注册信息丢失、OLT软件版本不兼容ONUOLT上查看ONU历史注册信息、确认ONU固件版本重新注册ONU、升级ONU固件、在OLT上重新绑定SN/Password重启OLT PON口后部分ONU无法注册PON口光模块故障、分光器端口损坏检查PON口光模块收发光功率、分光器端口插入损耗更换PON口光模块、调整分光器端口4.2 第一个坑ONU状态“unknown”不代表ONU坏了我们在实际工作中多次遇到ONU状态显示“unknown”但ONU本身是完好的换一个环境就能正常注册。这时要先判断问题是出在OLT侧还是ONU侧。判断的方法是在OLT上执行命令查看该ONU的注册IDSN或Password是否存在且正确如果注册ID在OLT上不存在或与ONU实际不一致ONU自然无法注册上OLT状态就会变unknown。此时只需在OLT上重新绑定正确的注册ID或恢复出厂设置重新注册即可。还有一种情况是OLT升级后某些旧型号的ONU与新版本OLT软件不兼容导致状态unknown。这种问题需要关注厂商兼容性列表必要时对ONU做固件升级。4.3 第二个坑光功率“正常”但速度还是慢一定要看“误码”在PON网络里光功率是一个宏观指标它告诉你“信号强度够不够”但不能告诉你“信号质量好不好”。最典型的情况是光功率计显示收光为-20dBm完全在正常范围内但OLT上对应的ONU的误码率已经高得离谱。误码高的原因通常有三个一是光路上的某个连接器端面脏污这种情况只要重新插拔法兰盘或用专用工具清洁端面即可二是光纤弯曲半径过小特别是在用户家里或楼道中光纤被用力折成很小的角度肉眼不容易看出来三是分光器的某个端口本身性能劣化这种情况需要通过更换分光器端口来验证。我在处理过一个政企客户的故障用户报修“专线不稳定丢包严重”现场测光功率-19dBm看起来没问题但发现OLT上报该ONU的误码秒级递增。最后查出是楼道分光器进了一个灰尘颗粒导致上行光路发生严重散射。清洁分光器端口后误码归零。4.4 第三个坑DBA配置“看起来正常”但实际限制了上行很多人在排查上行速率不达标时只关注BRAS账号速率和OLT流量模板忽略了DBA模板。实际上DBA模板中的Maximum参数就是ONU上行带宽的“天花板”如果这个值设小了其他任何地方的配置都无法突破这个上限。在华为OLT上查看DBA模板的命令大致是display ont-line-profile gpon profile-id X在输出中重点看“T-CONT”字段下的DBA Type和Maximum Bandwidth。如果Maximum显示为100M或更低而上行策略要求更高就需要修改DBA模板并应用到ONU上。修改DBA模板时有一个需要注意的地方修改后需要重新下发配置才能生效在业务高峰期操作时要谨慎评估对用户的影响尽量安排深夜窗口执行。4.5 第四个坑PON口拥塞不是只靠“看流量”就能看出来的有时PON口流量统计显示利用率并不高但用户测速就是不稳定。这种“假性不拥塞”的情况可能有两个原因一是统计周期太粗。OLT上的流量统计可能是一个15分钟或5分钟的平均值如果拥塞只发生在几秒钟的峰值时段平均值并不高但用户体验已经受损。这种情况需要查看更细粒度的流量数据或者通过PON口CRC错误帧的数量间接判断。二是ONU侧的突发流量。某些ONU特别是连接了NAS、监控等设备的会在特定时刻产生突发流量瞬间占满PON口的所有带宽导致其他用户瞬时卡顿。这种情况通过查看PON口下各ONU的实时实际速率通常能找到“罪魁祸首”。4.6 第五个坑测速工具和测速方法本身就有问题最后说一个很多人忽略的问题测速的方法和工具本身就会导致“误报故障”。比如测速时连接的是光猫的WiFi而不是有线网口——WiFi速率受无线环境干扰、信号衰减影响即使是千兆WiFi实际速率也可能只有100M。又比如测速的服务器距离过远或负载过高也会导致测速结果偏低。推荐的测速方法是电脑通过六类网线直连光猫千兆LAN口PPPoE拨号后使用本地运营商的测速服务器或国内主流测速平台多节点测试连续测3次取最大值。如果可能最好再换一台电脑或笔记本交叉验证排除电脑网卡性能因素。5. 最后分享一个实测有效的“黄金排查顺序”文章最后分享一个我用了很久的故障排查口诀“先测光、再看流、三查模板、四看拥塞”。先测光确认ONU收发光的功率和误码是否正常。再看流登录OLT查看PON口的上行/下行流量统计判断是否存在拥塞。三查模板核对OLT上的DBA模板和流量模板、BRAS上的账号速率是否满足用户套餐。四看拥塞如果前三个都没问题但高峰时段速度下降基本就是PON口用户数过多或分光比过大需要扩容或割接。这套顺序的核心逻辑是先排除“物理层”问题再排除“配置层”问题最后处理“资源层”问题。按照这个顺序走基本能在一个小时内定位到90%以上的“ONU正常但网速不达标”故障。在实际操作中我还发现一个很有用的小技巧登录OLT后先看一眼PON口下所有ONU的收光功率分布如果某个PON口下的ONU收光功率普遍在-25dBm以下那这个PON口大概率存在光路老化问题即使光功率仍然在阈值内线路的长期稳定性也无法保证。遇到这种情况建议优先处理分光器至OLT之间的主干光路而不是在单个ONU上反复折腾。PON故障排查这门手艺说到底考验的不是你会不会抄命令而是你能不能把物理层、配置层、资源层的问题分开看再串起来想。多踩几次坑、多复盘几轮自然就快了。