Wenn der 600er-Glasfaser-Anschluss sich wie 300 anfühlt: eine Detektivgeschichte mit dem UniFi UCG Ultra

Vier Stunden, ein PPPoE-Stack auf dem Linux-Laptop, ein abgesteckter Switch, ein deaktivierter Honeypot, ein gelöschter Content Filter — und am Ende war es eine einzige QoS-Regel. Das ist die Geschichte einer Performance-Debugging-Session, die mir gezeigt hat, wie tückisch harmlos aussehende Features auf einem Consumer-Gateway sein können. Und nebenbei eine Anleitung, wie man unter Linux einen Glasfaser-Anschluss direkt testet, ohne den eigenen Router dazwischen.

Das Setup

• Anschluss: O2 Home XL 600 Flex (600/300 Mbit) über Telekom-FTTH-Infrastruktur
• ONT: Huawei EcoLife (Bridge-Modus, 1 GbE)
• Router: UniFi Cloud Gateway Ultra (UCG Ultra)
• Symptom: Speedtest zeigt konsistent ~300 Mbit Download statt der erwarteten 600

Die Hälfte. Exakt die Hälfte. Das ist ein Muster, das jeden Netzwerker stutzig macht: Bei einem Duplex-Mismatch sieht man genau das. Aber wir hatten keinen.

Was wir probiert und ausgeschlossen haben

Bevor ich zur Auflösung komme, hier die Liste der Verdächtigen, die wir nacheinander entlastet haben.

Layer 1 (Kabel und Ports): Jedes Ethernet-Kabel war Cat6, alle Links handelten 1 GbE Full Duplex aus, der 2,5G-Switch zwischen Workstation und UCG wurde komplett entfernt: keine Veränderung. Die NIC der Workstation (Intel I225) zeigte 2,5 Gbps Full Duplex stabil.

ISP-Profil: Erst Speedtest gegen einen tschechischen Server (435 Mbit), dann gegen einen Server praktisch um die Ecke: plötzlich 598 Mbit. Wichtige Erkenntnis: Immer mit mehreren Speedtest-Servern testen, bevor man Hardware tauscht. Ein einzelner schlecht angebundener Server verfälscht das Bild komplett.

ONT: Der Verdacht, dass der Huawei EcoLife limitiert, ließ sich entkräften, indem ich den Laptop direkt am ONT angeschlossen und per PPPoE eingewählt habe (Anleitung unten). Volle 600 Mbit. Der ONT war es nicht.

UniFi-Security-Features: Honeypot deaktiviert (brachte einen kleinen Sprung), IDS/IPS war ohnehin aus, ein Content Filter existierte gar nicht als Policy, Threat Management aus.

Hardware-Offloading: Auf dem UCG Ultra standardmäßig aktiv und nicht abschaltbar.

VPN-Konfiguration: Eine Policy-Based-Routing-Regel für Proton VPN war konfiguriert, aber deaktiviert, der Tunnel „Not Established“. Probeweise komplett entfernt: keine Veränderung.

Firewall-Regeln: 151 Firewall-Regeln, 87 Default-Policies, 4 VLANs, 2 WireGuard-Server. Komplex, aber nicht das Problem.

Der Linux-Direkttest: PPPoE auf dem Laptop ohne Router

Das war der entscheidende Diagnose-Schritt: den eigenen Router komplett rauszunehmen und zu beweisen, dass der Anschluss in Ordnung ist. Das geht unter Linux mit Bordmitteln, hat aber ein paar Stolperfallen.

Voraussetzungen

# Auf Arch / CachyOS
sudo pacman -S rp-pppoe ppp

VLAN-Interface anlegen

O2 auf Telekom-FTTH läuft über VLAN 7. Das muss auf dem Ethernet-Interface getaggt werden:

# VLAN 7 auf dem physischen Interface anlegen
sudo ip link add link enp0s31f6 name enp0s31f6.7 type vlan id 7
sudo ip link set enp0s31f6 up
sudo ip link set enp0s31f6.7 up

Interface-Name an die eigene Hardware anpassen (ip link show zeigt alle).

PPPoE-Konfiguration

Datei /etc/ppp/peers/o2:

plugin /usr/lib/rp-pppoe/rp-pppoe.so
nic-enp0s31f6.7
user "[email protected]"
defaultroute
usepeerdns
persist
noauth
mtu 1492
mru 1492

Wichtig: nic-<interface> als eigene Zeile direkt nach dem plugin. Sonst weiß pppd nicht, auf welchem Interface es das PPPoE-Discovery starten soll.

Datei /etc/ppp/chap-secrets:

[email protected]  *  DEIN_PASSWORT  *

Die Zugangsdaten gibt es im O2-Kundenportal unter „Mein Vertrag → Zugangsdaten“.

NetworkManager ruhigstellen

Ein häufiger Fallstrick: NetworkManager versucht parallel DHCP auf dem Interface, während pppd die PPPoE-Session aufbaut. Das stört.

sudo nmcli device set enp0s31f6 managed no
sudo nmcli device set enp0s31f6.7 managed no

Wichtig: Die alte PPPoE-Session muss erst sterben

Das war der Moment, an dem ich kurz vor dem Aufgeben war. Symptom: Timeout waiting for PADO packets. Übersetzung: Der Laptop sendet PPPoE-Discovery-Pakete (PADI) raus, aber niemand antwortet (PADO).

Der Grund: Auf O2-Seite läuft noch die PPPoE-Session des Routers. Auf dem BNG (Broadband Network Gateway) ist nur eine Session pro Anschluss erlaubt. Solange die alte aktiv ist, werden neue PADIs ignoriert.

Vorgehen:

1. UCG Ultra vom Strom trennen, nicht nur das Netzwerkkabel ziehen
2. Huawei ONT auch vom Strom trennen, 30 Sekunden warten
3. ONT wieder anschalten, warten bis die PON-LED dauerhaft grün leuchtet
4. 5–10 Minuten warten, damit die alte Session am OLT austimed
5. Erst dann pppd starten

Verbinden

sudo pppd call o2 nodetach debug

nodetach debug zeigt direkt im Terminal, was passiert. Kein Hin und Her zwischen Terminals und journalctl.

Wenn alles klappt, taucht ein ppp0-Interface auf, eine öffentliche IP wird zugewiesen, und der Laptop hat direkten Internet-Zugang am ONT, vorbei am eigenen Router.

# Speedtest mit dem offiziellen Ookla-Client (nicht das Python speedtest-cli, das underperformt)
speedtest -s 23712

In meinem Fall: 598 Mbit Download, 293 Mbit Upload. Anschluss-Diagnose abgeschlossen, der Provider liefert, was er soll.

Zurück zum normalen Betrieb

sudo killall pppd
sudo ip link delete enp0s31f6.7
sudo nmcli device set enp0s31f6 managed yes
sudo nmcli device disconnect enp0s31f6
sudo nmcli device connect enp0s31f6

Die Auflösung: Es waren die Critical Apps

Nachdem alle naheliegenden Verdächtigen entlastet waren, lag der Übeltäter unscheinbar ganz oben in der UniFi Policy Engine: eine QoS-Regel namens „Critical Apps Prioritization“ mit der Action „Prioritize“ und einer Liste von Anwendungen — Microsoft Teams, Zoom, plus drei weitere.

Die Regel war zu einem unverdächtigen Zeitpunkt mal angelegt worden, „weil schaden kann es nicht“. Sie sah harmlos aus: priorisiert nur ein paar Apps, blockt nichts.

Was sie aber wirklich tut: Application-basierte QoS auf dem UCG Ultra macht Deep Packet Inspection. Auf jedem einzelnen Paket. Damit der Router weiß, ob ein Paket zu Teams gehört oder nicht, muss er es analysieren: Header, Payload-Patterns, bei verschlüsselten Verbindungen mitunter SNI-Inspection.

Der UCG Ultra hat laut Datenblatt einen Quad-Core ARM Cortex-A53 mit 1,2 GHz. Das ist nicht viel CPU für DPI bei 600+ Mbit. Bei normaler Last reicht es, aber sobald ein einzelner Stream den ganzen Anschluss füllen will, geht das CPU-Budget aus. Das Ergebnis: praktisch genau die Hälfte des Profils kommt durch.

Regel deaktiviert. Speedtest:

Download: 647.75 Mbps
Upload:   304.01 Mbps
Packet Loss: 0.0%

Sogar leicht über dem Profil. Das Rätsel war gelöst.

Lessons Learned

1. Application-basierte QoS ist auf Consumer-Hardware ein Performance-Killer. Wenn man Teams oder Zoom wirklich priorisieren will, geht das auch ohne DPI: DSCP-Markierung auf dem Client (Windows Group Policy oder Registry). Dann erkennt der Router die Priorität an einem einzigen Byte im IP-Header, ganz ohne Payload-Scan.

2. UCG-interner Speedtest ≠ Forwarding-Performance. Der eingebaute Speedtest läuft auf dem Gerät selbst und geht nicht durch die Firewall- und QoS-Pipeline. 580 Mbit intern bedeuten nicht, dass Clients dieselbe Geschwindigkeit erreichen.

3. Bei „exakt halbem“ Durchsatz muss es kein Duplex-Mismatch sein. Es kann auch CPU-Sättigung durch DPI sein. Das Symptom ist dasselbe.

4. Der Speedtest-Server zählt mit. Der erste Test gegen einen schlecht angebundenen Server hätte mich fast in die völlig falsche Richtung gelenkt. Immer zwei, drei verschiedene Server probieren, idealerweise einen direkt im ISP-Netz.

5. Single-Stream vs. Multi-Stream. Browser-Speedtests öffnen mehrere parallele Verbindungen. curl mit einem einzelnen Download zeigt oft dramatisch andere Werte. Beide sind valide, messen aber unterschiedliche Dinge. Bei meinem fertig konfigurierten UCG: Speedtest 380 Mbit, Single-Stream-curl nur 160 Mbit. Nach dem Fix: beides bei ~600.

6. Der Linux-PPPoE-Direkttest ist Gold wert. Sobald der Verdacht auf einen Router-Konfigurationsfehler aufkommt, ist die wichtigste Frage: Liegt es am Anschluss oder an meiner Hardware? Mit dem Laptop direkt am ONT klärt man das in zehn Minuten.

Was ich beim nächsten Mal anders machen würde

Bei UniFi-Performance-Problemen ist die Reihenfolge der Verdächtigen-Befragung ungefähr so:

1. Application-basierte QoS (oben in der Policy Engine prüfen)
2. Honeypot, Threat Management, Content Filter — alles, was Pakete inspiziert
3. Smart Queues auf dem WAN-Interface
4. Region Blocking, Encrypted DNS Filtering
5. Firewall-Regel-Komplexität mit GeoIP oder Application-Match
6. Erst dann die Hardware verdächtigen

Den Linux-Direkttest immer als ersten Schritt zur Anschluss-Validierung nutzen, bevor man stundenlang an der Router-Konfiguration herumprobiert.