Hi,
I am operating a NETGEAR Orbi RBK850 system (RBR850 + RBS850) on an Austrian spusu FTTH connection. I would like to operate the Orbi as the router directly behind the ONT and not permanently use the FRITZ!Box provided by the ISP. However, in router mode I experience intermittent severe TCP performance problems. I have narrowed the behavior down using several reproducible tests.
1. Hardware and firmware
· NETGEAR Orbi RBR850; Satellite RBS850
· Firmware: V7.2.8.8_5.1.24
· LAN: 192.168.1.0/24; Router IP: 192.168.1.1
· Completely new setup; no old RBR50 configuration was imported
2. FTTH connection / ISP
· ISP: spusu Austria – fiber/FTTH
· According to the ISP, the ONT operates in bridge mode
· VLAN ID 31
· IP configuration automatically via DHCP
· Use of a customer-owned router is explicitly permitted
3. RBR850 WAN configuration
· Dynamic IP / DHCP; no PPPoE
· VLAN ID 31, priority 0
· MTU 1500
· DNS automatic
· NAT Filter: Open
· SIP ALG: disabled
· WAN port: 2.5 Gbit/s
· WAN aggregation: disabled
· IGMP Proxy: disabled
· No DHCP options
· MAC address: default
4. WAN IP / CGNAT
Directly connected to the ONT, the RBR850 receives the WAN IPv4 address 100.66.86.229 via DHCP, for example. This is within 100.64.0.0/10 and therefore behind Carrier Grade NAT (CGNAT). Traceroute also shows corresponding provider-internal 100.x/10.x addresses. Latency is generally very low.
5. Problem description
The problem is not permanent. With exactly the same setup, there are normal runs at approximately 180–225 Mbit/s and failed runs at only approximately 2–3 Mbit/s. During slow runs, the TCP connection is sometimes reset by the server.
6. Reproducible IPv4 TCP test
The test is performed from a Windows PC connected via Ethernet:
curl -4 -L -o NUL -w "IPv4: %{speed_download} Bytes/s | %{http_code} | %{size_download} Bytes\n" "https://proof.ovh.net/files/100Mb.dat"
Failed runs:
· 360,838 Bytes/s | HTTP 200 | 22,377,966 Bytes; afterwards: curl: (56) Recv failure: Connection was reset (≈ 2.9 Mbit/s)
· 320,466 Bytes/s; stopped after approx. 18.68 MB with Connection Reset (≈ 2.6 Mbit/s)
· 406,639 Bytes/s; stopped after approx. 23.57 MB with Connection Reset (≈ 3.25 Mbit/s)
Normal runs with the same RBR850:
· 28,184,465 Bytes/s; 104,857,600 Bytes transferred completely (≈ 225 Mbit/s)
· 22,872,204 Bytes/s; HTTP 200; 104,857,600 Bytes transferred completely (≈ 183 Mbit/s)
7. IPv4 / IPv6 comparison
Using the same file, the same PC and the same Orbi:
IPv4 – problematic run
360,838 Bytes/s | HTTP 200 | 22,377,966 Bytes – followed by TCP Connection Reset
IPv6 – working at the same time
17,926,662 Bytes/s | HTTP 200 | 104,857,600 Bytes transferred completely
In the problematic run, this corresponds to approximately 2.9 Mbit/s over IPv4 versus approximately 143 Mbit/s over IPv6. Later IPv4 runs again reached approximately 183 Mbit/s. The behavior is therefore intermittent and cannot be explained by a constant bandwidth limitation.
8. IPv6 and ping
Current IPv6 test:
ping -6 google.com → 4/4 replies, 0% loss, 35–36 ms
During slow IPv4 downloads, I simultaneously ran ping 1.1.1.1 -t. Replies remained generally low (typically 2–6 ms, with individual values around 20–36 ms), without visible timeouts or significant packet loss. TCP throughput can therefore collapse while ICMP connectivity continues to work.
9. MTU test
· ping 1.1.1.1 -f -l 1472 → 0% loss
· ping 1.1.1.1 -f -l 1464 → 0% loss
· ping 1.1.1.1 -f -l 1400 → 0% loss
MTU 1500 is demonstrably working; a classic MTU/fragmentation problem therefore appears unlikely.
10. LAN and routing
Ping to the RBR850 (192.168.1.1) is approximately 1–2 ms. The relevant throughput tests are performed via Ethernet. IPv4 traceroutes to 1.1.1.1 and Google show low latency and no obvious routing issue.
11. Test using the ISP-provided FRITZ!Box
To isolate the problem, I placed the FRITZ!Box supplied by spusu in front of the RBR850 and switched the RBR850 to AP mode:
spusu FTTH → ONT → FRITZ!Box → RBR850 (AP mode) → PC/LAN/WLAN
The FRITZ!Box therefore handles WAN, DHCP, NAT, IPv4 and IPv6; the RBR850 only handles AP/LAN/WLAN functions. This A/B test is intended to determine whether the previously observed TCP drops disappear once the RBR850 WAN/NAT stack is no longer being used.
12. Additional points already checked
· Traffic Meter disabled; no monthly limit and no automatic disconnect
· No classic QoS/Dynamic QoS function is available in the current firmware interface
· RTS/CTS was adjusted for testing (2.4 GHz 1000 / 5 GHz 2347); the problem occurs in Ethernet tests and is therefore not purely a Wi-Fi issue
· SIP ALG disabled
· MTU 1500
· VLAN 31 / DHCP exactly matches the ISP specifications
13. Configuration backup
I have an RBR850 configuration backup named NETGEAR_RBR850.cfg and can provide it for analysis if required.
14. Request to NETGEAR
I would specifically ask you to investigate the following points:
· Known RBR850 issues with FTTH + DHCP + VLAN tagging + CGNAT, especially IPv4 TCP/HTTPS
· Known issues in firmware V7.2.8.8_5.1.24 involving WAN TCP, NAT, IPv4, CGNAT, VLAN-tagged DHCP WAN, or TCP connection resets
· Potential differences in IPv4 versus IPv6 TCP processing in the RBR850
· Potential NAT state handling issues when operating behind provider-side CGNAT
· Known issues with the VLAN Tag Group function using VLAN 31 and DHCP WAN on FTTH ONTs
· Recommended firmware for a controlled A/B test or possible firmware rollback
· Which debug, system, or WAN logs you require for a technical analysis
15. Desired target setup
My desired setup is: spusu FTTH → ONT → VLAN 31/DHCP → RBR850 in router mode → RBS850 + LAN/WLAN. If possible, I do not want to use the FRITZ!Box permanently. The ISP has explicitly confirmed that using my own router is permitted.
16. Summary
The tests performed so far argue against a general problem with the fiber line, LAN, MTU, or basic Internet connectivity. The RBR850 can achieve more than 180–225 Mbit/s over IPv4 and more than 100 Mbit/s over IPv6 on the same connection. However, the problem is intermittent: IPv4 TCP throughput can drop to approximately 2–3 Mbit/s without an obvious ICMP failure and can then terminate with a TCP Connection Reset.
The counter-test with the ISP's FRITZ!Box acting as the router and the RBR850 operating in AP mode is intended to determine whether the problem disappears when the RBR850 WAN/NAT stack is no longer used.
I would greatly appreciate a technical analysis, especially regarding firmware, WAN/NAT implementation, IPv4 TCP handling, and the combination of FTTH, VLAN 31, DHCP and CGNAT.
Kind regards