上周刚从北方一个制造园区的全光网络改造现场回来。这个项目从设计到交付用了两个月核心就是PON架构也就是很多人常说的全光网络。趁着手上还有热乎气我把整个项目的思路、踩过的坑和一些实战经验都写下来。如果你正要规划园区网络、运营商接入网或者只是好奇家里光猫背后的网络到底长什么样这篇应该能帮你少走不少弯路。PON全称是Passive Optical Network无源光网络。圈内人聊起来一般不看那些高大上的宣传词只看一件事从局端到用户之间到底有没有有源设备。没有就是纯正的PON架构有那就是挂着羊头卖狗肉。这个无源二字是整个架构的灵魂也是全光网络近几年在园区、家宽、政企市场全面铺开的核心原因。1. PON到底是什么——无源这两个字是设计的灵魂1.1 四个关键角色一张无源网络PON架构里就四个角色OLT、ODN、ONU还有藏在ODN里的分光器。OLT是光线路终端放在局端或机房相当于整个网络的大脑ONU是光网络单元放在用户侧最常见的就是家里那个光猫ODN是光分配网络由光纤、分光器、法兰、尾纤这些无源器件组成负责把光信号分配到每一个ONU。下行方向OLT发出的光信号到达分光器后被一分为N广播出去每个ONU都能收到全部信号靠GEM Port ID或者LLID挑出属于自己的数据。上行方向不一样多个ONU共用一根光纤、同一个波长所以必须轮流发言。OLT通过DBA动态带宽分配算法给每个ONU分配时间片避免数据撞车。这套机制学习成本不高但理解它后面的排障才不会一脸懵。我实际做项目时最喜欢干的一件事就是拿光功率计和OTDR在ODN上打数据。因为ODN不动脑只要光纤、分光器、法兰干净、匹配、衰耗达标整条链路就稳了。反过来ODN里任何一段出问题用户侧就是各种光衰大、丢包、掉线。为什么无源这么重要举个最直白的例子传统以太网方案每个楼层弱电井里得放交换机、配电源、堆设备、夏天还得考虑散热。PON架构下弱电井里可能只有分光器和配线架没有一块需要供电的板卡。整个项目少了几十台交换机少了几十路UPS供电故障点自然也少了一大截。1.2 GPON、EPON、XGS-PON怎么选现在主流PON标准有三个家族GPON、EPON以及后面的XGS-PON。我直接给一个对比表方便大家选型。项目GPONEPONXGS-PON标准ITU-T G.984IEEE 802.3ahITU-T G.9807.1下行速率2.488 Gbps1.25 Gbps9.953 Gbps上行速率1.244 Gbps1.25 Gbps9.953 Gbps常用分光比1:64 / 1:1281:32 / 1:641:64 / 1:128典型场景家宽、园区早期宽带、政企专线万兆到户、全光园区注意EPON和GPON都属于千兆接入代际单用户实际体验差别没有想象中那么大但GPON的T-CONT带宽控制和QoS体系更细适合多业务融合承载。EPON协议简单在纯以太网环境的时代接受度很高。这两年新项目我基本只考虑GPON和XGS-PON。GPON成熟、成本低光模块和ONU一堆厂商可选覆盖绝大多数场景XGS-PON适合业务模型比较明确的场景比如4K/8K视频监控、园区里频繁传递大文件的办公环境、云桌面这类重上行应用。对称10G的好处是上行也能跑满给视频回传、云桌面留足了带宽。这里有一个实操经验很多厂商OLT支持Combo PON口一个PON口同时兼容GPON和XGS-PON通过在光模块里集成WDM合波器实现。新园区如果预算允许优先选Combo口后面升级不用换OLT板卡只需要把ONU从GPON换成XGS-PON光纤链路完全复用。我之前好几个只做了GPON的项目就是靠这个方案赚到了升级空间。1.3 开工前先算清楚的光功率预算PON能不能跑得动最终都要回到光功率预算这条物理铁律上。光从OLT发光口出来经过尾纤、法兰、分光器、主干光缆、熔接点、用户光缆最后进ONU的接收口每一段都有损耗。只要ONU实际收到的光功率低于接收灵敏度业务就是起不来。工程上常用的估算损耗如下OLT PON口发光一般2到7dBmGPON B模块预算阶段通常取中间值3dBm。分光器损耗含附加损耗大约是1:8约10.5dB、1:16约13.8dB、1:32约17.1dB、1:64约20.4dB。光纤传输损耗1310nm波长约0.35dB/km1490nm波长约0.25dB/km预算阶段统一按0.3dB/km做余量。活动连接器也就是法兰每个约0.3dB预算阶段建议按0.5dB算。熔接点质量好的在0.05到0.1dB工程上按0.15dB算。我拿一个最常见的一级1:64分光、10km光缆项目为例。OLT发光3dBm减去分光器20.4dB减去10km乘以0.3dB等于3dB再减去各种法兰、熔接、尾纤和链路弯曲损耗约2dB到ONU大约是-22.4dBm。GPON的ONU接收灵敏度一般在-27dBm左右也就是说还有4到5dB的余量。这个余量够用吗说实话只能算及格。一旦链路里有老化、脏污或者施工时不规范弯曲再掉几个dB就可能出问题。所以我的经验是工程交付时至少给自己留3dB以上余量低于3dB的项目不管当时测试多好我都会让施工队返工。这里还有一类容易踩的坑很多人只测ONU接收光功率不看OLT侧接收到ONU的上行光功率。上行和下行走不同波长损耗不完全一样。1310nm比1490nm每公里大约多0.1dB损耗长距离链路必须两个方向都测。否则下行业务看着正常上行一高负载就丢包最后才发现是OLT侧收光过低。这两个方向的光功率我一律要求施工队留双份测试记录。2. 方案设计里最容易翻车的三个细节2.1 一级分光、二级分光分光比到底怎么定ODN怎么布对整个施工体验影响特别大。一级分光是分光器集中放在一个位置比如机房或者园区中心然后每根纤直接拉到用户。二级分光则是先一个1:N分光器把光分到几个片区片区里再用一个1:M分光器二次分配总的分光比近似N×M。选哪种我一般按用户密度和管线路由定。用户密集、点位集中一级分光最省心管理简单链路点少故障率低。用户很分散、管线到了片区还要拐很多路一级分光会导致主干光缆用量暴涨这时候二级分光更划算所谓以光分路。分光比也不能乱定。GPON的PON口速率2.488Gbps下行是广播共享假设一个PON口带64个ONU平均每个用户只有约38Mbps可用。听起来不多但这是物理共享带宽不是同时并发。普通家宽、办公上网这种突发型业务1:64没问题如果做实时的视频在线剪辑、多路4K监控回传我建议1:32甚至1:16宁可OLT PON口多占用也别让带宽成为瓶颈。注意一个很容易踩的坑部分厂商OLT单PON口带64个ONU需要license授权或者需要选用更高功率预算的光模块比如Class C预算阶段就要把光模块等级和license费用问清楚。分光比不是光看分光器上标个1:128就完事工程上要确认局端和终端光模块的功率等级匹配否则光功率预算根本打不平。2.2 保护方式选不选、怎么选很多园区项目铺PON上来就问要不要做保护。我的观点很直接先看业务等级。普通办公、宿舍宽带一般不需要PON口的冷备、热备靠OLT主控板卡、电源模块冗余就够了银行网点、医院核心、数据中心这类不允许中断的场景才考虑Type B甚至Type C保护。Type B保护是OLT的PON口11冗余主干光缆被保护通过光开关切换成本适中切换时间一般在50ms以内能满足大多数政企业务。Type C保护则保护OLT PON口到ONU的全程用两条独立物理路由成本高除非是金融级客户否则很少用。还有一种省钱的思路叫手拉手两个OLT互为备份ONU的光纤分别连到两个OLT的分光器由上层设备做业务切换。我做过几个医院项目用这个方案效果不错缺点是要多拉一半光缆。这里有个很现实的问题保护方案写进设计容易真正到维护阶段很难落实。因为冗余链路平常没有业务往往被施工队挪作他用或者光路里被乱接了法兰。所以只要签了要做保护的项目我每次巡检都会把备纤、备口的损耗数据测一遍并存档确保关键时刻备路真的能用。2.3 OLT上联和出口带宽怎么算PON侧带宽算完别忘了上联。这是我见过最容易被忽略的环节一个PON口带64个ONU如果只算平均带宽很容易低估实际上OLT上联带宽要按照业务并发和峰值来设计。经验公式大致是上联带宽 同时在线用户数 × 单用户保证带宽 × 并发收敛比。家宽场景并发收敛比可以取0.3甚至更低因为不是所有人都同时在跑大流量办公园区就得高一些0.5左右如果是学校机房、视频监控这类持续高负载收敛比直接按0.8甚至1.0算。举个实际数字一个园区OLT下面挂400个ONU给每个ONU规划100Mbps的下行保障带宽平均并发按0.4考虑上联带宽至少要400×100M×0.416Gbps那上联最少得跑2个10GE聚合或者直接上25GE。要是只拉了1个10GE高峰期必然拥塞。另外OLT上联口和业务vlan规划要提前想好。一个原则用户vlan最好按OLT的PON卡或区域来规划上联用单独的vlan做透传这样排障时能快速定位是PON侧还是上联侧问题。我见过太多项目把用户vlan和上联vlan混着用一出问题两边都说不清。3. 一次标准交付OLT开局到ONU注册全流程3.1 开局前的信息收集和拓扑规划PON项目交付最怕边干边想。我一般开局前至少完成三件事。一是拓扑落地把ODN的所有分光器位置、分光比、主干光缆段、每个PON口带多少ONU画成一张表这张表在后期的运维里就是保命图。二是IP和vlan规划管理vlan、业务vlan、组播vlanOLT上联口地址、ONU管理地址段都要提前写好。三是ONU信息台账每个ONU的SN、安装位置、所属PON口、业务类型提前录入Excel再导入OLT。这里特别强调SN信息台账的重要性。ONU注册最常见的方式是SN认证和Password认证OLT上需要先录入SN或者密码才能注册成功。如果前期没有台账现场一台一台抄SN特别浪费时间而且容易漏。我习惯在做跳纤记录的同时就顺便把SN抄好两件事一次做完返工概率会低很多。3.2 OLT和ODN的核心配置步骤不同厂商CLI有差异我不贴某个厂商的完整命令把通用步骤列出来大家拿到任何一款OLT都能对应操作。创建业务vlan和管理vlan配置上联接口为trunk模式允许相应vlan通过。给OLT配置管理IP和路由确保能远程管理。在PON口下创建ONT的线路模板和业务模板模板里定义流量带宽T-CONT、DBA策略、管理vlan等。执行ONU注册命令填写SN或密码绑定到对应PON口。注册成功后在ONU上设置业务流把用户vlan映射到指定的T-CONT中一般还要开启组播vlan或者上网、语音业务模板。保存配置并备份。配置里的动心DBA模板别设置太死。GPON的DBA有几种类型常用的是SR模式也就是ONU会上报自己的缓存占用OLT按需分配上行带宽。这个机制就是PON能超卖带宽的根本。给普通业务建议把DBA类型设成动态给固定带宽业务单独设固定带宽T-CONT不要让所有业务挤在同一个DBA里。ONU注册后还有一个容易被忽视的步骤在OLT侧确认ONU的接收光功率和发送光功率是否正常。现在主流OLT都能直接查到ONU光模块的收发光功率开局时把每个PON口下光功率异常的ONU先排查掉能省掉后面一半的故障工单。3.3 业务下发的验证清单ONU全部注册完不是直接交付。我会按下面清单逐项验证。光功率每个ONU接收光功率在合理范围GPON一般在-8到-25dBm之间低于-25先排查链路。连通性从OLT ping通ONU的管理IP从ONU侧ping通网关和上联核心交换机。丢包率持续ping 1000个1000字节包丢包率必须为0。带宽用iperf测上下行速率GPON单个ONU至少能跑到套餐设定值XGS-PON能跑满带宽。业务网页、视频、语音按实际业务类型逐一验证组播业务要看直播是否起流。备份把OLT配置、ODN链路光功率台账、ONU台账导出归档。这些动作看着繁琐但能帮交付团队提前暴露80%以上的问题。尤其从ONU侧ping通网关这一步很多人只在OLT上ping通了ONU的管理IP就觉得通了实际上用户数据面通不通只有从ONU业务口发ping才能验证。4. 常见光路故障与排查技巧实录4.1 光衰大、时好时坏按这个顺序查ODN物理链路下挂ONU频繁掉线、链路通了但丢包率高十有八九是光衰问题。排查按下面顺序来。第一用光功率计在ONU侧测接收光功率对照台账里的历史值。如果衰减了3dB以上基本可以判定链路有新增损耗点。第二看法兰盘。PON系统里法兰是最容易出问题的位置没拧紧、接头脏污、用了适配型号不对的尾纤都会带来明显损耗。用酒精和无尘纸清洁接头端面拧紧法兰再看功率有没有恢复。这一步成本最低但很多人习惯直接怀疑光模块。第三查尾纤和跳线的弯曲半径。单模光纤弯曲半径小于30mm时损耗会急剧上升而且目测根本看不出来。我处理过好几个诡异故障最后发现都是施工队把尾纤扎带勒得太紧光纤在拐角处弯成了直角。这种情况用余光功率计测试摊开布线就能看到变化。第四上OTDR打曲线。OTDR能定位到具体是哪个位置断、哪个位置有反射峰异常。这里有一个经验OTDR测试时要把测试尾纤的长度和事件盲区考虑进去先用短脉冲、窄量程测近端再用长量程测全链路否则很容易把起始接头误判成断点。4.2 长发光ONU一个坏终端拖垮整个PON口这是一个很经典的PON故障。正常情况下ONU只在OLT分配给自己的时间片内发光。某个ONU出了问题变成持续发光其他ONU的上行数据全被干扰表现为整个PON口下的所有用户同时掉线或严重丢包。定位方法其实不难。先从OLT看这个PON口下所有ONU是否全部离线或在线但大量误码。把可疑PON口下的ONU逐个断电或者逐根拔掉用户侧尾纤拔到某一根时分光器输入端的光功率从持续有光变成正常间歇光就找到了问题设备。有些OLT自带长发光检测功能能直接上报具体是哪个ONU在违规长发光优先用这个功能效率最高。我处理这类故障的心得长发光往往是ONU光模块老化或者固件bug导致的。抢救回来之后一定要让厂家换光模块而不是简单重启。我见过同一台ONU重启好用到能跑过两个星期又长发光最后换模块才彻底解决。4.3 光功率正常却上行丢包小心流氓ONU的隐形问题还有一种更隐蔽的故障每个ONU光功率都正常、看统计也不掉线就是整网上行丢包严重。这种情况我第一排查项是流氓ONU。它不一定是长发光而是在错误的时间窗口里发了数据或者它的发光功率太高盖住了隔壁ONU的信号属于一种时序层面的干扰。定位起来比常发光麻烦因为设备时好时坏。常用手段是在OLT侧配置上行时隙过流检测查看是否有ONU上报异常或者把PON口下的ONU数量临时减半看丢包率是否下降再逐个把ONU挪到其他PON口测试隔离出问题设备。另外一个实用技巧新入网的ONU批次如果接连出这个问题先怀疑这批设备的光模块质量让供应商把模块批次数据发过来对比。我踩过这个坑一整批劣质光模块让一个项目多花了一周排障时间。4.4 故障排查速查表故障现象可能原因首选排查手段单个ONU掉线光衰过大、ONU死机、SN不匹配测光功率、重启ONU、核对OLT注册状态整个PON口所有ONU掉线长发光ONU、分光器损坏、主干光纤断检查长发光告警、OTDR打主干链路丢包时好时坏流氓ONU、光模块劣化、法兰脏污上行时隙检测、逐个隔离、清洁法兰业务带宽远低于套餐DBA模板配置过小、上联拥塞、ONU模板错误检查DBA策略、上联带宽使用率注册不上SN录入错误、PON口容量达上限、vlan不通核对台账、查看PON口授权、检查管理vlan最后聊点个人体会。做PON项目这么多年我越来越觉得这技术真正厉害的地方不是光进铜退这种口号而是无源带来的架构红利。ODN不耗电、不发热、不需要人看管可靠性天然就高。但无源也意味着一旦光路出问题没有中间设备帮你兜底诊断你必须老老实实回到物理层用仪表说话。所以每次交付我都会把每一段光缆的OTDR曲线存档把每个分光器、每个法兰的衰耗记在台账里。这些东西现在看着麻烦等哪天深夜用户报障你就知道有基线数据是多么救命的一件事。如果你是刚接触PON建议先从一个1:16分光、几十个ONU的小项目练手把DBA、注册、光功率预算这些基础吃透再去碰复杂组网。相信我这条路比任何高深的技巧都走得远。