Degradatie snelheidsprofiel na onderhoud en migratie naar ander IP-segment

Question

Sinds de afronding van het aangekondigde netwerkonderhoud van 8 juli 2026 levert mijn 1 Gbit/s-glasvezelabonnement (klantnummer: [klantnummer]) structureel nog circa 400 Mbit/s. Op basis van doorlopende monitoring en systematische uitsluiting heb ik de indruk dat er iets mis is gegaan met mijn snelheidsproefie.

1. Baseline. Mijn doorlopende monitoring (Ookla-metingen, uurlijks middels Home Assistant) toont van 1 t/m 7 juli een consistente doorvoer van 800–900 Mbit/s.

2. Breukmoment. Op 8 juli mat het systeem om 06:11 uur nog 808 Mbit/s; om 07:11 uur 391 Mbit/s. De breuk valt daarmee samen met de afronding van het onderhoudsvenster (tot 07:00 uur). Bij dit onderhoud is mijn aansluiting tevens gemigreerd naar een ander IP-segment (05:40 uur: van 188.90.182.x/23 naar 188.89.x.x/20). Sindsdien is de doorvoer onafgebroken vlak begrensd op circa 400 Mbit/s.

3. De lijn levert wél. Tijdens de test met het Zyxel-modem op 8 juli werd op dezelfde aansluiting 713 Mbit/s gemeten (gemeten op tablet via wifi over het modem). Lijn, vezel en ONT functioneren dus volledig; de begrenzing treft uitsluitend sessies van mijn eigen router Asus RT-BE92U.

4. Klantzijde uitgesloten. Ik heb aan mijn kant systematisch geëlimineerd: vier speedtests naar vier verschillende servers (Odido Arnhem, KPN Amstelveen, Citymesh Antwerpen, PhoenixNAP Amsterdam) tonen hetzelfde plafond van ~415–428 Mbit/s; QoS en AiProtection zijn uitgeschakeld (aantoonbaar in de systeemlog); de router is volledig herstart; er is getest met nieuwe DHCP-sessies op drie verschillende WAN-IP-adressen en twee verschillende MAC-adressen; een controle van de routerconfiguratie bevestigt dat er geen enkele bandbreedtebeperking actief is. De 10 Gbit/s-link tussen router en ONT functioneerde bovendien na de ONT-vervanging van 6 juli anderhalve dag foutloos op volle snelheid.

5. Conclusie. Alle waarnemingen wijzen op een onjuist snelheidsprofiel in de provisioning sinds het onderhoud — vermoedelijk een 400 Mbit/s-profiel voor sessies van eigen randapparatuur.

Helaas kwam ik er met de helpdeskmedewerker niet uit. Hij gaf aan er zelf eigenlijk helemaal geen verstand van te hebben en dat de Technische Dienst hem uitgelegd had wat hij mij moest vragen.

Ik werd moedeloos. Ruim een uur met de man aan de telefoon gezeten, maar mijn uitleg zei hem helemaal niets. Opschalen daar iemand die er wel verstand van had was niet mogelijk.
Volgens hem werkte de lijn correct omdat de Zyxel meting wel goed was. Maar, die Zyxel geeft een TR-069 melding mee, waardoor automatisch de juiste snelheid wordt ingesteld. Ik kreeg de indruk dat de goede man een beetje klem zat tussen een klant met een technisch verhaal en een Technische Dienst die geen tijd had.

Is er hier iemand die mij de juiste richting kan wijzen?

Weergave vanuit vaste test internetverbinding in Home Assistant

Rene-Hawk · Accepted Answer

OPGELOST — oorzaak lag aan eigen zijde: ASUS Bandwidth Limiter schakelt hardware-acceleratie uit (fc_disable/runner_disable)Allereerst: excuses aan Odido zijn hier op zijn plaats — het onderhoud van 8 juli bleek onschuldig.En dank @Waqqas: je tip over NAT acceleration zette me op het juiste spoor.Hieronder de volledige oplossing, ook voor die andere Asus-gebruiker met hetzelfde probleem.Het probleemNa 8 juli leverde mijn 1 Gbit/s-aansluiting nog maar ~420 Mbit/s, kaarsrecht begrensd, op elke server. Het Zyxel-testmodem haalde wél volle snelheid, dus alles wees ogenschijnlijk naar een verkeerd snelheidsprofiel bij Odido. Ten onrechte.De werkelijke oorzaakTijdens troubleshooting was het QoS-raamwerk van mijn RT-BE92U in een tussenstand beland: qos_enable=1 met qos_type=2 (Bandbreedtebeperking / Bandwidth Limiter) — terwijl de GUI gewoon "Adaptieve QoS: OFF" toonde. En hier zit de valkuil: de Bandwidth Limiter schakelt bij elke boot de hardware-acceleratie (Flow Cache/Runner) uit, óók als er geen enkele limietregel is ingesteld. Al het WAN-verkeer gaat dan door de CPU, en die topt op deze router af rond 420–450 Mbit/s. Op de nieuwere 3006-firmware staat er bovendien geen NAT Acceleration-optie meer in de GUI, dus je ziet het nergens.Zo controleer je het (SSH)fc status | grep -i "Ucast Learning"→ staat daar "Disabled" met Active<0>, dan is de acceleratie uitnvram get fc_disablenvram get runner_disable→ horen beide 0 te zijn; bij mij stonden ze op 1nvram get qos_enable / nvram get qos_type→ bij mij: 1 en 2, ondanks "OFF" in de GUIDe fix1. GUI: Adaptieve QoS → hoofdschakelaar echt op OFF → Toepassen (controleer daarna: nvram get qos_enable moet 0 zijn)2. SSH: nvram set fc_disable=0 ; nvram set runner_disable=0 ; nvram commit ; reboot3. Na herstart controleren dat de waardes op 0 blíjven en "Flow Ucast Learning Enabled" toontResultaat: van 420 naar 949/925 Mbit/s, ping 7 ms.Leerpunt voor wie hetzelfde zoekt: als je Asus (RT-BE92U of vergelijkbaar) op glasvezel exact rond de 420–450 Mbit/s blijft hangen terwijl het providermodem wel vol levert — check eérst fc status via SSH voordat je je provider belt. De timing kan je zomaar op het verkeerde been zetten; bij mij viel het exact samen met gepland onderhoud en een IP-migratie, en dat maakte het provider-spoor verleidelijk maar onjuist.Nogmaals dank voor het meedenken — topic mag wat mij betreft als opgelost gemarkeerd worden.

Waqqas · Answer

Hallo ​@Rene-HawkJe bent niet de enige, er is nog iemand met een Asus die exact hetzelfde ervaart. Helpt NAT acceleration op auto zetten.Of voer eens een fabrieksreset uit en stel de Asus opnieuw in.

Niet gevonden wat je zocht?

Meld je aan

Welkom