RBR850 – massive IPv4-TCP-einbrüche bei FTTH/VLAN 31 – Verdacht auf WAN/NAT/Firmware-Problem

Sehr geehrtes NETGEAR Support-Team,

ich betreibe ein NETGEAR Orbi RBK850 System (RBR850 + RBS850) an einem österreichischen spusu-FTTH-Anschluss. Ich möchte den Orbi als Router direkt hinter dem ONT betreiben und nicht dauerhaft die vom Provider gelieferte FRITZ!Box verwenden. Im Router-Modus treten jedoch sporadisch massive TCP-Performanceprobleme auf. Ich habe das Verhalten mit mehreren reproduzierbaren Tests eingegrenzt.

1. Hardware und 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

Komplett neue Einrichtung; keine alte RBR50-Konfiguration importiert

1. FTTH-Anschluss / Provider

Provider: spusu Österreich – Glasfaser/FTTH. Das ONT arbeitet laut Provider im Bridge-Modus.

VLAN ID 31

IP automatisch über DHCP

ONT im Normalbetrieb als Bridge

Verwendung eines eigenen Routers ausdrücklich erlaubt

1. WAN-Konfiguration des RBR850

Dynamic IP / DHCP; kein PPPoE

VLAN ID 31, Priorität 0

MTU 1500

DNS automatisch

NAT Filter: Offen

SIP ALG: deaktiviert

WAN-Port: 2.5 Gbit/s

WAN Aggregation: deaktiviert

IGMP Proxy: deaktiviert

Keine DHCP Options

MAC-Adresse: Standard

1. WAN-IP / CGNAT

Direkt am ONT erhält der RBR850 per DHCP beispielsweise die WAN-IPv4-Adresse 100.66.86.229. Diese liegt im Bereich 100.64.0.0/10 und damit hinter Carrier Grade NAT (CGNAT). Traceroute zeigt entsprechende Provider-interne 100.x-/10.x-Adressen. Die Latenz ist grundsätzlich sehr niedrig.

1. Fehlerbild

Das Problem ist nicht dauerhaft. Bei identischem Setup gibt es normale Läufe mit ca. 180–225 Mbit/s und Fehlerläufe mit nur ca. 2–3 Mbit/s. Bei den langsamen Läufen wird die TCP-Verbindung teilweise vom Server zurückgesetzt.

1. Reproduzierbarer IPv4-TCP-Test

Der Test erfolgt von einem per Ethernet angeschlossenen Windows-PC:

curl -4 -L -o NUL -w "IPv4: %{speed_download} Bytes/s | %{http_code} | %{size_download} Bytes\n" "https://proof.ovh.net/files/100Mb.dat"

Fehlerläufe:

360.838 Bytes/s | HTTP 200 | 22.377.966 Bytes; danach: curl: (56) Recv failure: Connection was reset (≈ 2,9 Mbit/s)

320.466 Bytes/s; Abbruch nach ca. 18,68 MB mit Connection Reset (≈ 2,6 Mbit/s)

406.639 Bytes/s; Abbruch nach ca. 23,57 MB mit Connection Reset (≈ 3,25 Mbit/s)

Normale Läufe mit demselben RBR850:

28.184.465 Bytes/s; 104.857.600 Bytes vollständig übertragen (≈ 225 Mbit/s)

22.872.204 Bytes/s; HTTP 200; 104.857.600 Bytes vollständig übertragen (≈ 183 Mbit/s)

1. IPv4-/IPv6-Vergleich

Mit derselben Datei, demselben PC und demselben Orbi:

IPv4 – problematischer Lauf

360.838 Bytes/s | HTTP 200 | 22.377.966 Bytes – anschließend TCP Connection Reset

IPv6 – gleichzeitig funktionierend

17.926.662 Bytes/s | HTTP 200 | 104.857.600 Bytes vollständig übertragen

Das entspricht im problematischen Lauf ungefähr 2,9 Mbit/s über IPv4 gegenüber ca. 143 Mbit/s über IPv6. Später waren auch IPv4-Läufe wieder mit ca. 183 Mbit/s möglich. Das Verhalten ist daher intermittierend und nicht durch eine konstante Bandbreitenbegrenzung erklärbar.

1. IPv6 und Ping

Aktueller IPv6-Test:

ping -6 google.com → 4/4 Antworten, 0 % Verlust, 35–36 ms

Während langsamer IPv4-Downloads wurde parallel ping 1.1.1.1 -t ausgeführt. Die Antworten blieben grundsätzlich niedrig (typisch 2–6 ms, einzelne Werte etwa 20–36 ms), ohne sichtbare Timeouts oder massiven Paketverlust. Der TCP-Durchsatz kann somit stark einbrechen, obwohl ICMP weiterhin funktioniert.

1. MTU-Test

ping 1.1.1.1 -f -l 1472 → 0 % Verlust

ping 1.1.1.1 -f -l 1464 → 0 % Verlust

ping 1.1.1.1 -f -l 1400 → 0 % Verlust

MTU 1500 funktioniert nachweislich; ein klassisches MTU-/Fragmentierungsproblem erscheint unwahrscheinlich.

1. LAN und Routing

Ping zum RBR850 (192.168.1.1) liegt bei ca. 1–2 ms. Die entscheidenden Durchsatztests erfolgen per Ethernet. IPv4-Traceroutes zu 1.1.1.1 und Google sind niedrig-latenz und unauffällig.

1. Gegenprobe mit der Provider-FRITZ!Box

Zur Eingrenzung habe ich die von spusu gelieferte FRITZ!Box vor den RBR850 gesetzt und den RBR850 in den AP-Modus versetzt:

spusu FTTH → ONT → FRITZ!Box → RBR850 (AP-Modus) → PC/LAN/WLAN

Damit übernimmt die FRITZ!Box WAN, DHCP, NAT, IPv4 und IPv6; der RBR850 übernimmt nur AP-/LAN-/WLAN-Funktionen. Dieser A/B-Test soll zeigen, ob die zuvor beobachteten TCP-Einbrüche verschwinden, sobald der WAN-/NAT-Stack des RBR850 nicht mehr verwendet wird.

1. Weitere bereits geprüfte Punkte

Traffic Meter deaktiviert; kein Monatslimit und keine automatische Trennung

Keine klassische QoS-/Dynamic-QoS-Funktion in der aktuellen Firmware-Oberfläche vorhanden

RTS/CTS testweise angepasst (2,4 GHz 1000 / 5 GHz 2347); Problem tritt bei Ethernet-Tests auf und ist daher kein reines WLAN-Problem

SIP ALG deaktiviert

MTU 1500

VLAN 31 / DHCP entspricht exakt den Angaben von spusu

1. Konfigurationsbackup

Ich habe eine RBR850-Konfigurationssicherung namens NETGEAR_RBR850.cfg und kann diese bei Bedarf zur Analyse bereitstellen. 

1. Bitte an NETGEAR

Ich bitte Sie insbesondere um Prüfung folgender Punkte:

Bekannte Probleme des RBR850 mit FTTH + DHCP + VLAN Tagging + CGNAT, speziell IPv4-TCP/HTTPS

Bekannte Probleme der Firmware V7.2.8.8_5.1.24 mit WAN-TCP, NAT, IPv4, CGNAT, VLAN-tagged DHCP WAN oder TCP Connection Resets

Mögliche Unterschiede in der IPv4-/IPv6-TCP-Verarbeitung des RBR850

Mögliche Probleme beim NAT-State-Handling hinter Provider-CGNAT

Bekannte Probleme der VLAN-Tag-Group-Funktion bei VLAN 31 und DHCP-WAN an FTTH-ONTs

Empfohlene Firmware für einen kontrollierten A/B-Test bzw. möglichen Firmware-Rollback

Welche Debug-, System- oder WAN-Logs Sie für eine technische Analyse benötigen

1. Gewünschtes Zielsetup

Mein gewünschtes Setup ist: spusu FTTH → ONT → VLAN 31/DHCP → RBR850 im Router-Modus → RBS850 + LAN/WLAN. Die FRITZ!Box möchte ich nach Möglichkeit nicht dauerhaft verwenden. Der Provider hat die Nutzung eines eigenen Routers ausdrücklich bestätigt.

1. Zusammenfassung

Die bisherigen Tests sprechen gegen ein allgemeines Problem der Glasfaserleitung, des LANs, der MTU oder der grundsätzlichen Internet-Erreichbarkeit. Der RBR850 kann über denselben Anschluss zeitweise mehr als 180–225 Mbit/s über IPv4 übertragen und über 100 Mbit/s über IPv6. Das Problem ist jedoch intermittierend: IPv4-TCP kann ohne erkennbaren ICMP-Ausfall auf ca. 2–3 Mbit/s einbrechen und anschließend mit einem TCP Connection Reset abbrechen.

Der Gegenversuch mit der Provider-FRITZ!Box als Router und dem RBR850 im AP-Modus soll nun klären, ob das Problem verschwindet, sobald der WAN-/NAT-Stack des RBR850 nicht mehr verwendet wird.

Ich wäre für eine technische Analyse durch NETGEAR sehr dankbar, insbesondere im Hinblick auf Firmware, WAN-/NAT-Implementierung, IPv4-TCP und die Kombination aus FTTH, VLAN 31, DHCP und CGNAT.

Mit freundlichen Grüßen