OLT 上联从 1G 升到 10G：割接当天怎么做到业务不断
核心要点：把 OLT 上联从 1G 换成 10G，卡住项目的通常不是买不到模块，而是割接当晚那九十分钟怎么安排。这篇文章不讨论要不要换 PON 制式，只讨论上联口本身怎么换：先确认瓶颈出在上联还是出在 PON 口，再决定是"同口换模块"还是"新增链路并行"，然后把光层预算、链路聚合的哈希、网关侧联动、回退判据和割接后 72 小时的观察指标，全部排进一张按分钟执行的时间表。按这套流程走，割接可以做到业务不断，最差也能把中断控制在 30 秒以内。
一、先确认瓶颈在上联口，不在 PON 口
上联升级最常见的浪费，是花了两周时间准备，割接完发现用户还是慢，因为真正的瓶颈在分光比或者某几个 PON 口上。动手前先看三个信号，同时成立才说明该升上联。
- 连续七天的忙时上联利用率都在 70% 以上。只看日平均没有意义，晚高峰 20:00 到 23:00 的 15 分钟粒度峰值才是决策依据。
- OLT 上联口有持续的出向队列丢弃。看接口计数里的 output drops，而不是只看有没有告警灯。
- 投诉集中在晚间，白天正常。如果白天也慢，问题多半在光层或者分光比，换 10G 上联反而把钱花在错的地方。
顺手算一笔账：1G 上联实际可用大约 950 Mbps，按人均忙时 8 Mbps 计算只能支撑约 120 户，按 4 Mbps 计算约 240 户。超过这个量级还挂在单条 1G 上，无论 PON 口怎么加，晚高峰都会堵在同一个地方。
二、割接前必须拿到的五个数字
这五个数字不齐，就不要定割接日期。它们决定了你选哪种割接形态、需要多长的窗口、以及回退有没有意义。
- 上联 15 分钟粒度峰值，连续七天，含周末。用这个数字算真实收敛比，不要用套餐名义带宽。
- 户数与分光结构：OLT 上联 ÷ PON 口数 ÷ 分光比，得出单户可用带宽，判断升级后能撑几年。
- 现网模块的型号、波长、距离与实际收光。收光余量低于 3 dB 的链路，先处理连接器和跳线，不要带着隐患割接。
- 上游交换机或路由器的空闲 10G 端口与剩余转发能力。上联换了、上游没口，等于白换。
- 网关侧协议状态：VRRP 主备关系、OSPF 或 BGP 邻居数、路由条目、ARP 表规模。这些数字是割接后判断"是否恢复正常"的对照基线。
三、两种割接形态：同口换模块，还是新增链路并行
形态选错，窗口长度会差三倍。判断依据只有两条：机型有没有 10G 口，以及业务能不能接受一次端口 down。
| 维度 | 同口换模块 | 新增链路并行 |
|---|---|---|
| 适用条件 | 机型已有 10G 口，只是插了 1G 模块 | 需要带宽叠加或链路冗余 |
| 业务中断 | 端口 down/up，通常 30 秒到 3 分钟 | 理论上可为零，但配置期有抖动 |
| 带宽上限 | 单口 10G | 2×10G 聚合可达 20G，但受哈希限制 |
| 主要风险 | 模块兼容性与光预算余量 | 哈希不均、二层环路、聚合模式不匹配 |
| 回退方式 | 换回原模块，两分钟内恢复 | 关闭新成员口，保留原链路 |
四、光层核对：10G 比 1G 更挑距离和工艺
1G 时代大家习惯"纤通了就行"，10G 不行。同样是 10 公里级单模方案，10G 的链路预算通常比 1G 紧 2 到 4 dB，对连接器和熔接点的容忍度明显下降。原来勉强能通的链路，换了模块就可能变成时通时断，表现为 CRC 错包缓慢增长，而不是彻底不通，最难排查。
- 先测后换。割接前用光功率计实测现网收光，记录仪表型号和波长。余量不足 3 dB 的，先清洗端面、换跳线、重做熔接，再谈升级。
- 多模场景要算距离。10G 在多模上跑不了多远，OM3 约 300 米、OM4 约 400 米就到极限。楼间距离超过这个数，直接走单模，别抱侥幸。
- SFP+ 口向下兼容 1G，但模块要匹配。把 1G 模块插进 10G 口能用，反向不行。混插时速率要手工固定，不要让两端自动协商。
- 清洁是成本最低的一步。现场统计里，割接后错包问题有相当比例来自端面污染，而不是模块本身坏了。
五、链路聚合能加带宽，但不保证分得均匀
做了 2×10G 聚合，结果一条跑到 90%、另一条只有 10%，这是哈希问题，不是带宽不够。四种原因最常见。
- 单条大流只走一条成员链路。一条 TCP 连接的五元组固定，哈希结果固定，再多成员口也用不上。
- 哈希字段太少。只按源 MAC 和目的 MAC 做哈希时，跨网段流量会全落到同一条链路。
- 转发侧是单队列。部分紧凑型 OLT 的转发面队列较少，聚合了链路但发送侧还是一个队列在排队。
- 两端聚合模式不一致。一端动态 LACP、一端静态捆绑，或者 active/passive 配错，链路能起来但不出流量。
判断方法很直接：聚合后分别看每个成员口的五分钟流量曲线，偏差超过 20% 就按哈希问题处理，而不是继续加链路。
六、割接窗口的九十分钟脚本
把窗口切成几段，每段有明确的出口条件，现场就不会出现"大家都到了但不知道下一步干什么"。
| 时间点 | 动作 | 出口条件 |
|---|---|---|
| T-7 天 | 备件到位、配置备份、脚本与回退清单定稿 | 备份可回滚验证通过 |
| T-30 分钟 | 确认无 P1 故障，通知值班，记录割接前基线 | 基线数据留存截图 |
| T+0 至 10 分钟 | 换模块或插新链路，确认物理层 up | 两端收光正常，端口 up |
| T+10 至 25 分钟 | 起聚合、放行 VLAN、确认网关邻居与路由 | 邻居全部建立，路由表条目与基线一致 |
| T+25 至 40 分钟 | 抽样十户宽带、三路直播频道、一路语音 | 接通率与测速达标 |
| T+40 至 70 分钟 | 全量放行，盯错包与利用率 | 错包零增长，利用率平稳 |
| T+70 至 90 分钟 | 出结论：确认或回退 | 报告签字，值班接手观察 |
七、路由与网关侧的三个联动点
上联口换了，OLT 之外还有三处会跟着变，忘了任何一处都会出现"能上但很怪"的现象。
- 网关与 VRRP。端口 MAC 变了，上游 ARP 表会短暂指向旧口，表现为个别用户几十秒不通。割接前把 ARP 老化时间调短，或者切换后手工清理一次。
- 路由度量。OSPF cost 或 BGP MED 要与新带宽匹配。10G 口还挂着 1G 时代的 cost，流量会绕远路，割接看起来成功，实际走了次优路径。
- 二层冗余。新增并行链路若走二层，先确认不会和原有冗余口形成环路；跨设备场景优先用动态 LACP，不要手工捆两个口了事。
八、回退：先定判据，再定动作
回退不是失败，没有准备回退才是。判据要在割接前写进脚本，现场不许临时讨论。
| 观察到的现象 | 动作 | 时限 |
|---|---|---|
| 抽样用户超过 5% 不通 | 立即回退，回退后再分析 | 10 分钟内 |
| 丢包率超过 1% 且持续五分钟 | 回退，检查光层与聚合配置 | 15 分钟内 |
| 路由未收敛超过十五分钟 | 回退，核对度量与邻居配置 | 15 分钟内 |
| 仅个别链路 CRC 增长 | 现场换模块或跳线，不必整体回退 | 30 分钟内 |
判据之外还有一条纪律：回退窗口一过就不要再"边跑边修"。带病运行的上联，往往在第二天晚高峰才暴露出真正的问题，那时候处理的成本是割接当天的三倍。
九、割接后 72 小时看五个指标
割接完成不等于项目结束。接下来三天看的不是能不能通，而是稳不稳。
- 上联 5 分钟峰值利用率，理想状态应低于 60%，留出突发余量。
- 成员口流量均衡度，偏差超过 20% 就回头查哈希字段。
- CRC 与丢弃计数，应为零增长；缓慢增长通常是端面或跳线问题。
- 网关会话数、ARP 表规模、路由抖动，与割接前基线逐项对照。
- 晚高峰用户侧测速与投诉量，这是唯一有业务意义的结论。
三个常见残留问题值得单独提：一是 MTU 没跟着改，PPPoE 场景 1492 的大包不通；二是时间同步没恢复，日志时间错位影响后续排查；三是新换下来的模块没登记，下次故障时找不到备件。
结语
上联从 1G 到 10G，技术门槛并不高，真正决定成败的是流程颗粒度：有没有算清五个数字、有没有选对割接形态、有没有把回退判据写在纸上。把这四件事做扎实，割接就是一次普通的变更窗口；做不扎实，它就是一次持续三天的救火。PON 制式怎么演进是另一个话题，上联口这一层，先把当下这条链路换干净。
联系我们
如需讨论 OLT 上联升级、链路聚合配置或割接方案评审，欢迎联系 AINOPOL：
- 邮箱：zhenghui.xu@sczhgx.com
- WhatsApp：+86 17612849559
- 官方商城：shop.sczhgx.com
