桥接模式下，ONU 只做光电转换与二层透传。终端侧看到的是一段以太网，PPPoE 拨号由后级路由器或 PC 完成，NAT 也由后级设备承担。ONU 的 CPU 几乎不参与数据面转发。
路由模式下，ONU 自己发起 PPPoE（RFC 2516 定义的发现与会话两个阶段），完成地址获取、NAT（RFC 2663 的地址转换模型）、DHCP 分配，下游设备插上就能用，不需要任何配置。
| 对比项 | 桥接模式 | 路由模式 |
|---|---|---|
| 数据面角色 | 二层透传 | 三层转发 + NAT |
| 拨号终结 | 后级路由器 | ONU 自身 |
| 转发能力上限 | 受 PON 口速率限制（GPON 下行 2.488 Gbit/s） | 受 ONU CPU 与 NAT 实现限制 |
| 组播处理 | 可原样透传到机顶盒 | ONU 内做 IGMP Proxy 或转发 |
| 多业务 VLAN | 各业务 VLAN 直接透传，最灵活 | 需在 ONU 内绑定到 WAN 连接 |
| 远程可管理性 | 只能看到 ONU 自身状态 | 可看会话数、在线时长、DHCP 租约 |
| 故障点数量 | 多一层用户设备 | 少一层，但故障面集中 |
桥接的优点是资源占用低、链路透明。数据面几乎不经 CPU，转发由芯片完成，GPON 下行的 2.488 Gbit/s 速率可以跑满而不受 ONU 的处理器限制。
第二个优点在多业务上尤其明显。IPTV 的组播流可以原样透传到机顶盒，由机顶盒自己发 IGMP 加入（RFC 3376 的 v3 报文），不需要 ONU 参与。这在运营商频繁调整组播源地址时格外省事——ONU 侧不需要跟着改配置。
代价在两个地方。其一是排障分层：用户自己接了一台路由器，运营商的网管只能看到 ONU 在线、光功率正常，再往里的 DHCP、DNS、Wi-Fi 问题一律看不见，排障变成电话沟通。其二是设备数量：桥接必然意味着至少两台设备（ONU + 用户路由器），多一台设备就多一个故障点，也意味着用户侧任何一台设备重启都会影响业务。
还有一条与体验无关但与合规有关：桥接模式下 ONU 不做 NAT，用户看到的公网地址直接来自运营商，运营商侧的地址分配与审计口径更清楚。
路由模式的吸引力在于交付简单。ONU 出厂预置拨号参数，用户插上就用；运营商远程能读到在线时长、会话数、DHCP 租约、Wi-Fi 关联设备列表，排障不用上门。
真正的瓶颈在 NAT 会话表。家用 ONU 的会话表容量常见在 2K、4K、8K、16K 几档，这是一张内存受限的表，每条会话都要保存源地址、源端口、目的地址、目的端口、协议、超时计时等字段。会话超时也不短：TCP 会话的常见默认空闲超时在 300 秒量级，UDP 更短但也常见几十秒到几分钟。
一旦表被占满，新的连接直接被丢弃。现场表现很有辨识度：ping 通、DNS 查询正常，但网页打不开。用户会描述成「网速变慢」，实际是会话资源耗尽。
现场条件：一只配置为路由模式的 ONU，NAT 会话表容量 8192 条；家庭中有 10 台设备在线（手机 4 台、电脑 2 台、电视 2 台、机顶盒 1 台、NAS 1 台）。
第一步算稳态占用。普通浏览与视频场景下，单台设备并发会话数大致在 60~120 条之间，取中值 90 条：10 × 90 = 900 条，占 8192 的 11%，非常宽松。
第二步算突发场景。当其中有 2 台设备在跑多线程下载或 P2P 类应用时，单台会话数可以轻松到 1500 条以上（每个连接一个会话，多线程下载器同时开几十上百个连接）；2 × 1500 = 3000 条，加上其余 8 台设备的 720 条，合计 3720 条，仍有余量。
临界点在第三步。如果三台设备同时跑高并发应用：3 × 1800 = 5400 条，加上其余 7 台设备的 630 条，合计 6030 条；再叠加机顶盒的组播会话与临时连接，很容易越过 8192 的 90% 水位。此时新会话建立失败，表现就是部分网页打不开、部分 App 提示网络异常，而 ping 与 DNS 都正常。
按这个模型，8K 会话表在 10 台设备的家庭里，安全并发数是「同时 2~3 台设备进行高并发连接应用」。要提升这个上限，路径有三条：把会话超时调短（从 300 秒降到 120 秒可以显著提升表的周转率，代价是会话被过早回收可能造成长时间的连接被中断）；升级到 16K 或更高容量；或者干脆改成桥接模式，把 NAT 交给后级专门的路由器——这也是高带宽用户场景更常见的处置方式。
无论哪种模式，业务分隔都靠 VLAN。IEEE 802.1Q 定义的四字节标签决定了报文属于哪个业务。
| 业务 | 常见 VLAN 规划 | 桥接模式处理 | 路由模式处理 |
|---|---|---|---|
| 上网 | VLAN 41 | 透传到后级路由器，由路由器拨号 | ONU 直接在 VLAN 41 上发起 PPPoE |
| IPTV | VLAN 45 | 组播原样透传，机顶盒发 IGMP 加入 | ONU 做 IGMP Proxy，按需转发组播 |
| VoIP | VLAN 46 | 透传到电话网关 | ONU 内做语音处理或转发到指定口 |
桥接模式在这张表里的优势是三行都不用改：业务 VLAN 从 OLT 侧一路透传到用户设备，中间不做任何转换。路由模式则需要在 ONU 里为每条 WAN 连接绑定 VLAN 与业务类型，一旦局端调整业务规划，ONU 侧必须同步改。这也是批量交付时桥接方案更容易标准化、路由方案更依赖模板管理的原因。
| 场景 | 推荐模式 | 理由 |
|---|---|---|
| 家庭宽带，运营商希望远程排障 | 路由 | 可读会话数与在线状态，减少上门 |
| 家庭高带宽 + 自备高性能路由器 / 多 AP 组网 | 桥接 | 避免 ONU 转发能力成为瓶颈 |
| IPTV 为主，机顶盒需自行处理组播 | 桥接 | 组播原样透传，局端改源不影响终端 |
| 酒店、宿舍、小微办公 | 路由（配合模板批量下发） | 交付标准化，无需用户配置 |
| 工业现场：ONU 下挂 PLC / 摄像头 | 桥接 | 二层直达，便于 VLAN 隔离与静态地址规划 |
| 需要远程读取终端下挂设备信息 | 路由 | 可读 DHCP 租约，定位是哪台设备异常 |
边界一：路由模式不能靠硬件无限扩展。 ONU 是低成本终端，NAT 转发的实际吞吐受 CPU 与内存限制，标称千兆口不等于能跑满千兆的 NAT 转发。选型时应该看「路由转发性能」这一项，而不是只看电口速率。
边界二：模式切换不是纯软件动作。 从桥接改路由，意味着局端侧的业务配置、认证参数、QoS 策略都要跟着调整，存量用户批量切换几乎不可能一次性完成。反过来从路由改桥接，用户侧的拨号参数也要重新配置。因此模式应在方案设计阶段定下来，而不是装机时随手选。
锐应科技的 XPON ONU 终端支持路由与桥接两种 WAN 模式，可与 mini GPON OLT（1 口 / 2 口）或 4 口 / 8 口盒式 OLT 配合组网，具体接口与业务能力见 PON 接入方案页；ONU 下挂工业交换机做现场设备接入的部分，参考 工业交换机方案 的接入层建议。
PPPoE 报头占 8 字节（RFC 2516），以太网标准帧的净荷上限是 1500 字节，扣掉这 8 字节，留给 PPP 与 IP 层的空间就是 1492 字节。这不是配置限制而是协议开销。实际影响是大包分片与部分 VPN 隧道需要相应下调 MTU。如果后级路由器不支持 MTU 自动协商，常见现象是能 ping 通但网页打不开——和 NAT 会话表打满的表现很像，排查时要区分开。
取决于组播处理方式。ONU 做 IGMP Proxy 时只需要把机顶盒请求的组播流转发下来，其余组播不占带宽，资源占用小；如果实现方式是简单地把所有组播都透传到 LAN 口，带宽会被无效流量占掉。判断方法是看 ONU 的管理界面里有无线速与组播组数量的统计，或者直接对比桥接模式下的画质表现。改了模式之后画质变差，问题多半在这。
都能，管理的层次不同。桥接模式下 TR-069 只能管到 ONU 自身（光功率、注册状态、端口状态），用户内网设备的信息看不到。路由模式下还可以读 DHCP 租约、在线时长、会话数，甚至可以远程重启 ONU。这也是运营商在标准家庭宽带方案里倾向路由模式的原因——远程可处理的故障比例更高。
部分平台支持，做法是按 WAN 连接区分：上网走路由模式由 ONU 拨号，IPTV 走桥接模式直接透传到机顶盒。这种混合配置在现网里不少见，代价是配置复杂度上升、排障时需要同时看两条链路。如果没有明确的业务隔离要求，建议统一成一种模式，减少变量。
看 ONU 管理界面里的会话数统计与 CPU 占用：会话数长时间贴近容量上限（比如 8192 里稳定在 7500 以上），同时 CPU 占用偏高，就说明表已经紧张。此时的现象是部分新连接失败而 ping 与 DNS 正常。处置顺序是先调短会话超时观察是否缓解，其次评估切换到桥接模式把 NAT 交给下游设备，最后才是更换容量更大的机型。
路由与桥接之争没有通用答案，只有交付方式与运维能力的匹配。要减少上门、要远程看到内网状态，就选路由，代价是把 NAT 的性能天花板挪进了 ONU；要跑满带宽、要组播干净透传、要二层隔离，就选桥接，代价是排障接口变少、用户侧多一台设备。把模式在方案阶段定死、把会话表容量与转发性能写进选型条件，比装机现场临时决定要省事得多。完整参数与接口定义见 关于锐应。
