Bridge mode makes the ONU a Layer 2 pipe and lets a downstream router terminate PPPoE and run NAT; router mode makes the ONU terminate PPPoE itself, hand out DHCP and translate addresses, so subscribers plug in and work with no configuration.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
The bridge mode vs router mode choice looks like a preference. In practice it decides three things you cannot change later without a truck roll: where the NAT session table lives, how many devices sit between the subscriber and the OLT, and how much of the subscriber's network your management platform can actually see.
In bridge mode the data plane never touches the ONU CPU, so GPON downstream of 2.488 Gbit/s can run at full rate. The cost is one more device on site and a much shorter troubleshooting reach.
In router mode the bottleneck is the NAT session table, commonly 2K, 4K, 8K or 16K entries. A full table looks like "the internet is slow" but behaves like a specific fault: ping works, DNS resolves, pages do not open.
An 8K table in a ten-device home survives steady browsing at roughly 11% occupancy, survives two heavy downloaders, and starts dropping new sessions at three.
Service separation is done with VLANs in both modes. Bridge passes the tags through; router mode has to bind each VLAN to a WAN connection and be re-tuned whenever the head end changes its plan.
Bridge mode uses the ONU for optical-to-electrical conversion and Layer 2 forwarding only. What the subscriber's equipment sees is a stretch of Ethernet. PPPoE dialling happens on the router or PC behind it, NAT runs there too, and the ONU processor is essentially idle on the data path. An ONU bridge mode deployment is transparent by design: the terminal needs no understanding of addresses, sessions or dialling.
Router mode moves all of that inside the ONU. It originates PPPoE itself — RFC 2516 defines the discovery and session stages — obtains an address, performs NAT under the address translation model in RFC 2663, and runs a DHCP server for the LAN.
| Item | Bridge mode | Router mode |
|---|---|---|
| Data plane role | Layer 2 pass-through | Layer 3 forwarding plus NAT |
| Dial termination | Downstream router | The ONU itself |
| Forwarding ceiling | Limited by the PON port rate (GPON downstream 2.488 Gbit/s) | Limited by the ONU CPU and the NAT implementation |
| Multicast handling | Passed through to the set-top box untouched | IGMP proxy or forwarding inside the ONU |
| Multi-service VLAN | Each service VLAN passed straight through, most flexible | Each service must be bound to a WAN connection |
| Remote visibility | ONU status only | Session count, uptime, DHCP leases |
| Number of failure points | One more subscriber device | One fewer device, but the failure surface concentrates |
The first advantage is resource use. The data plane barely touches the CPU because forwarding happens in silicon, so GPON downstream at 2.488 Gbit/s runs at line rate without hitting the processor ceiling of a low-cost terminal.
The second advantage shows up with multiple services. An IPTV multicast stream is passed through to the set-top box unmodified, and the box sends its own IGMP join under RFC 3376 v3 messages. The ONU does not participate. When an operator moves multicast source addresses around — which happens more often than anyone plans for — nothing on the ONU side needs editing. Our note on how PON runs multicast with IGMP snooping covers the head-end side of that arrangement.
The costs land in two places.
The first is troubleshooting depth. Once the subscriber attaches their own router, the operator's management system sees an ONU that is online with normal optical power, and nothing beyond it. DHCP problems, DNS problems, Wi-Fi problems inside that router are invisible. Fault handling turns into a phone conversation with someone who is not technical.
The second is device count. Bridge mode always means at least two boxes: the ONU plus a subscriber router. Every extra box is another failure point, and a reboot of either one interrupts service.
There is a third point that has nothing to do with user experience but matters for compliance: in bridge mode the ONU does not perform NAT, so the public address the subscriber uses comes straight from the operator. Address assignment and audit records stay clean on the operator side.
The attraction is delivery simplicity. Dial parameters are pre-provisioned at the factory, the subscriber plugs in and works, and the operator can remotely read uptime, session count, DHCP leases and the Wi-Fi association list. Fewer site visits.
The real bottleneck is the NAT session table. Home ONUs typically ship with 2K, 4K, 8K or 16K entries. It is a memory-bound table, and each entry has to hold source address, source port, destination address, destination port, protocol and a timeout. The timeouts are not short either: TCP idle timeout commonly sits around 300 seconds, UDP is shorter but still measured in tens of seconds to a few minutes.
Once the table is full, new connections are dropped outright. The field symptom is distinctive: ping succeeds, DNS queries resolve, web pages do not open. The subscriber describes it as "the connection got slow". It is not slow. It is out of session entries.
Field conditions: one ONU in router mode with an 8192-entry NAT table; ten devices online in the household — four phones, two computers, two televisions, one set-top box and one NAS.
Step one, steady state. In ordinary browsing and video use, a single device holds roughly 60 to 120 concurrent sessions. Take 90 as the midpoint: 10 x 90 = 900 entries, which is 11% of 8192. Plenty of room.
Step two, burst. Put two of those devices on multi-threaded downloads or peer-to-peer applications and a single device passes 1500 sessions easily, because each connection is one session and a download manager opens dozens or hundreds at once. 2 x 1500 = 3000, plus 720 for the other eight devices, gives 3720. Still headroom.
Step three is where it breaks. Three devices running high-concurrency applications: 3 x 1800 = 5400, plus 630 for the remaining seven, gives 6030. Add the set-top box multicast sessions and transient connections and the table crosses 90% of 8192 without much effort. New sessions then fail to establish, which shows up as some pages refusing to load and some apps reporting network errors while ping and DNS stay healthy.
On that model, an 8K table in a ten-device home has a safe concurrency of two to three devices running high-connection applications at the same time. Three ways to raise the ceiling: shorten the session timeout (dropping from 300 to 120 seconds improves table turnover noticeably, at the risk of cutting long-lived connections early), upgrade to 16K or larger, or switch to bridge mode and hand NAT to a dedicated router downstream. The last option is what high-bandwidth subscribers tend to end up with anyway.
Service separation runs on VLANs regardless of mode. The four-byte tag defined in IEEE 802.1Q is what tells a frame which service it belongs to.
| Service | Typical VLAN plan | Bridge mode | Router mode |
|---|---|---|---|
| Internet | VLAN 41 | Passed through to the downstream router, which dials | ONU originates PPPoE directly on VLAN 41 |
| IPTV | VLAN 45 | Multicast passed through untouched, set-top box sends IGMP join | ONU runs IGMP proxy and forwards multicast on demand |
| VoIP | VLAN 46 | Passed through to the voice gateway | Voice handled inside the ONU or forwarded to a designated port |
The bridge column in that table has an advantage that is easy to miss: none of the three rows needs editing. An ONU bridge mode plan therefore carries a benefit that only shows up at scale — service VLANs run from the OLT side all the way to the subscriber equipment with no conversion in between. Router mode requires each WAN connection to be bound to a VLAN and a service type inside the ONU, so when the head end changes its service plan the ONU side must change with it. That is why bridge deployments are easier to standardise in bulk and router deployments depend more heavily on template management.
If the subscriber side also needs IPv6, the same tagging logic applies — see IPv6 over PON for how addresses get assigned on each mode.
Put bridge mode vs router mode against real deployments and the argument dissolves quickly, because the answer follows the operating model rather than the hardware.
| Scenario | Recommended mode | Reason |
|---|---|---|
| Home broadband where the operator wants remote troubleshooting | Router | Session count and online state are readable, fewer visits |
| High-bandwidth home with an owner-supplied router or multi-AP mesh | Bridge | Keeps ONU forwarding capacity out of the critical path |
| IPTV-heavy household where the set-top box handles multicast | Bridge | Multicast passes through untouched, head-end source changes do not touch the terminal |
| Hotel, dormitory, small office | Router, with template-based bulk provisioning | Standardised delivery, no configuration by the user |
| Industrial site with a PLC or cameras behind the ONU | Bridge | Layer 2 reachability, clean VLAN isolation and static addressing |
| Need to read what is behind the terminal remotely | Router | DHCP leases show which device is misbehaving |
The bottom two rows are worth expanding. On an industrial site the ONU usually sits in a cabinet with a switch behind it, and the engineering team wants deterministic Layer 2 behaviour rather than a second NAT boundary. That is a bridge job, and the industrial Ethernet switch range is where the access layer behind it gets designed.
In a hotel or dormitory the opposite applies. Hundreds of rooms, no on-site IT, and a support desk that needs to see whether a room is actually online: router mode with a provisioning template wins, because the alternative is a call to reception every time a guest unplugs something.
Limit one: router mode does not scale with hardware alone. An ONU is a cost-sensitive terminal. NAT throughput is bounded by CPU and memory, and a port labelled gigabit does not mean gigabit NAT forwarding. When comparing models, look at the routing forwarding performance figure, not just the electrical port rate.
Limit two: switching modes is not a software toggle. Going from bridge to router means the head-end service configuration, authentication parameters and QoS policy all have to be adjusted, and switching an installed base in bulk is almost never a single-pass operation. Going the other way means re-configuring the subscriber's dial parameters. Decide the mode at design time, not on installation day.
Rayin's XPON ONU terminals support both WAN modes and are designed to pair with the mini GPON OLT (1-port and 2-port) or the 4-port and 8-port box OLTs. Interface and service details are on the PON access page. Industrial sites that put a switch behind the ONU for field device access should start from the access-layer recommendations in the switch section.
A practical habit for operators standardising on one mode: publish the session table size and the routing throughput as part of the procurement specification, and treat "supports router mode" as an incomplete statement until both numbers are attached.
Why is PPPoE MTU limited to 1492 in bridge mode?
The PPPoE header occupies 8 bytes under RFC 2516 and the standard Ethernet frame payload ceiling is 1500 bytes. Subtract the 8 and 1492 bytes are left for PPP and IP. That is protocol overhead, not a configuration limit. The practical consequences are large-packet fragmentation and the need to lower MTU on some VPN tunnels. If the downstream router does not negotiate MTU properly, the usual symptom is ping working while pages fail to open — which looks very much like a full NAT table, so separate the two when troubleshooting.
Will IPTV stutter on a set-top box when the ONU is in router mode?
It depends on how multicast is handled. With IGMP proxy the ONU forwards only the groups the set-top box requested, so unrequested multicast costs no bandwidth and the resource load stays low. If the implementation simply floods all multicast to the LAN port, bandwidth gets consumed by traffic nobody asked for. The check is whether the ONU management page reports active multicast groups, or simply compare picture quality against the same line in bridge mode. A drop in quality after a mode change usually points here.
Can TR-069 manage the ONU in both modes?
Yes, at different depths. In bridge mode TR-069 reaches the ONU itself — optical power, registration state, port state — and cannot see devices on the subscriber LAN. In router mode it can also read DHCP leases, uptime and session count, and can reboot the ONU remotely. That difference is a large part of why operators prefer router mode for standard residential service: a higher share of faults can be closed remotely.
Can one ONU run some services bridged and others routed?
Some platforms support it, splitting by WAN connection: internet routed and dialled by the ONU, IPTV bridged straight through to the set-top box. Mixed configurations are common enough in live networks. The cost is configuration complexity and the need to inspect two paths during troubleshooting. Without a hard service-isolation requirement, standardising on one mode removes a variable.
How do I confirm the NAT session table is actually full?
Read the session count and CPU utilisation on the ONU management page. If the count sits close to capacity for extended periods — say consistently above 7500 out of 8192 — and CPU is high at the same time, the table is tight. The tell is some new connections failing while ping and DNS behave normally. The order of remedies: shorten the session timeout and see whether it eases, then evaluate moving to bridge mode and giving NAT to a downstream device, and only then replace the unit with a larger model.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
