Traag Ziggo netwerk

[MatthijsZ]

Hoi allen,

We hebben al een poosje last van een traag netwerk van Ziggo. Sommige pagina's duren uren om te laden, of laden helemaal niet. Een speedtest laat zien dat het in de basis wel oké is: 15ms ping, 37,31 Mbps down, 4.90 Mbps up.

Het probleem lijkt te zitten in één of andere Vodafone Libertel proxy (

code:

213.51.196.205

).
In een traceroute zit daar namelijk altijd de hoge latency, tussen de 25ms en 30ms.

code:

traceroute to google.com (216.58.208.110), 64 hops max, 72 byte packets
 1  lede (192.168.1.1)  3.083 ms  0.949 ms  1.482 ms
 2  * * *
 3  213.51.196.205 (213.51.196.205)  25.782 ms  14.375 ms  25.171 ms
 4  asd-tr0021-cr101-be156-10.core.as9143.net (213.51.158.2)  15.737 ms  17.202 ms  22.109 ms
 5  nl-ams14a-ri1-ae51-0.aorta.net (213.51.64.186)  21.994 ms  15.330 ms  12.601 ms
 6  10ge-1-4.cr1.ams2.baseip.com (213.46.182.22)  14.115 ms  16.053 ms  17.686 ms
 7  216.239.51.139 (216.239.51.139)  15.729 ms  23.077 ms  38.305 ms
 8  172.253.66.185 (172.253.66.185)  22.148 ms  14.291 ms  21.936 ms
 9  ams17s08-in-f14.1e100.net (216.58.208.110)  12.893 ms  31.214 ms  11.887 ms

[lier]

Los van het feit dat het handig is om een vraag te stellen in een topic...definieer "sommige pagina's". En wat is "een traag netwerk"? Wat is het gedrag? En waarom denk je dat de traceroute jou iets vertelt over sommige pagina's?

[Groentjuh]

Die traceroute zie er toch niet gek uit. Uiteindelijk kom je uit op 11 tot 12 ms naar Google.
Ik zie bovenaan lede als router. Heb je al eens redirect bekabeld aan de modem getest (speedtest etc) om bottlenecks binnen eigen netwerk uit te sluiten?

[ Voor 45% gewijzigd door Groentjuh op 13-10-2020 10:24 ]

[Vorkie]

Je lijkt een eigen router te hebben, wat voor 1 is dat?

En zonder die router? Hoe werkt het dan?

[TommieW]

Welke DNS servers heb je ingesteld? Trage DNS kan voor heel wat vage problemen zorgen.

[eric.1]

Deze traceroute verklaart je problemen i.i.g. niet. Een ms van 15 tot 24 merk je in dat opzicht gewoon niet.

Zijn het altijd dezelfde websites of is dit willekeurig?

[MatthijsZ]

Wow, jullie zijn snel

@lier traag betekent dat pagina's lang "wit" blijven, voordat ze verschijnen. Daarnaast verschilt dat enorm van moment op moment. Traceroute had ik toegevoegd omdat schijnbaar iedereen dat doet op internet en ik hoopte dat jullie daar iets meer mee konden dan alleen mijn vage opmerking "het doet vaak langzaam"

@Groentjuh hmmm, ik weet blijkbaar niet goed hoe ik raceroutes moet lezen. Ik dacht dat die waardes allemaal optelden: mijn interpretatie is dat de laatste hop 11ms is, maar dat je alles ertussen in ook hebt 'ervaren'

@Vorkie ik heb een D-Link DIR860L, waar LEDE op draait (variant van openwrt)

@TommieW via de router gebruik ik de DNS-servers van Google (ingesteld voor WAN en WAN6)

@eric.1 het zijn willekeurige sites. Heb je een idee hoe ik dit beter kan kwantificeren?

Off-topic:
@lier "Los van het feit dat het handig is om een vraag te stellen in een topic" dat dacht ik gedaan te hebben?

[mash_man02]

Mogelijk dat je 2 routers in lijn hebt, maar dat zou niet dergelijke resultaten tot gevolg moeten hebben.

Ik denk dat je problemen op je coax segment hebt vanwege je relatief hoge 3e hop latency.

Kun je eens in je ziggo modem kijken en zien of er veel post / pre RS errors in staan ?

Als je veel errors hebt zullen je applicaties zelf error's moeten gaan corrigeren op TCP niveau wat je traagheid en soms niet doorlopen van websites kan vertragen.

[Groentjuh]

MatthijsZ schreef op dinsdag 13 oktober 2020 @ 10:30:
@Groentjuh hmmm, ik weet blijkbaar niet goed hoe ik raceroutes moet lezen. Ik dacht dat die waardes allemaal optelden: mijn interpretatie is dat de laatste hop 11ms is, maar dat je alles ertussen in ook hebt 'ervaren'

Nee, ping resultaten zijn alle 3 de ping naar die hup/stap. Het telt niet op.

MatthijsZ schreef op dinsdag 13 oktober 2020 @ 10:30:
@Vorkie ik heb een D-Link DIR860L, waar LEDE op draait (variant van openwrt)

Waarom heb je nog LEDE? Inmiddels is LEDE weer samen met OpenWRT, oftewel tijd om te updaten?!

mash_man02 schreef op dinsdag 13 oktober 2020 @ 10:32:
Mogelijk dat je 2 routers in lijn hebt, maar dat zou niet dergelijke resultaten tot gevolg moeten hebben.

Ik denk dat je problemen op je coax segment hebt vanwege je relatief hoge 3e hop latency.

Hij heeft maar 1 router. Anders had je onder de LEDE router nog een tweede router (van Ziggo met IP in de privé-ip-ranges) gezien.

De signaalwaarden van de modem zouden inderdaad kunnen helpen.

[ Voor 26% gewijzigd door Groentjuh op 13-10-2020 10:38 ]

[mash_man02]

Groentjuh schreef op dinsdag 13 oktober 2020 @ 10:34:
[...]

Hij heeft maar 1 router. Anders had je onder de LEDE router nog een tweede router (van Ziggo met IP in de privé-ip-ranges) gezien.

De signaalwaarden van de modem zouden inderdaad kunnen helpen.

Dat is juist mijn verdenking, die zien we daar niet en waarom zien we die niet ?

[Groentjuh]

mash_man02 schreef op dinsdag 13 oktober 2020 @ 10:45:
[...]


Dat is juist mijn verdenking, die zien we daar niet en waarom zien we die niet ?

Omdat die modem/router/connectbox in bridge-modus staat of zo oud is dat ie nog geen ingebouwde router had. In die beide gevallen zou dat geen probleem moeten zijn!

[ Voor 8% gewijzigd door Groentjuh op 13-10-2020 10:48 ]

[mash_man02]

Groentjuh schreef op dinsdag 13 oktober 2020 @ 10:47:
[...]

Omdat die modem/router/connectbox in bridge-modus staat of zo oud is dat ie nog geen ingebouwde router had.

Zou die ook niet als next hop in de trace staan. hop 2 die geen response geeft kent geen route terug naar de source van de traceroute en dat is al raar op zich aangezien de router meestal Pat doet en het source adres daarmee in het lokale directly connected netwerk zou moeten zitten.

[ Voor 29% gewijzigd door mash_man02 op 13-10-2020 10:53 ]

[mash_man02]

de TS kan het denk ik het beste even testen door een client direct op zij kabelmodem aan te sluiten, als dat geen verbetering bied moet je contact opnemen met ziggo, zij kunnen de Pre / Post RS fouten aan zowel up als donwstream beoordelen en acties uitzetten.

[Groentjuh]

mash_man02 schreef op dinsdag 13 oktober 2020 @ 10:48:
[...]


Zou die ook niet als next hop in de trace staan.

Nee, als er geen router tussen zit, zie je ze niet terug in een traceroute. Net als switches, access points etc doet een modem/router in bridge niet mee op layer 3 van het osi-model.

[lier]

@MatthijsZ Zou je alle vragen willen beantwoorden?
Zou je daarnaast in de browser (welke gebruik je?) de Dev tools (F12) willen gebruiken om te bekijken wat vertraagt?

Leuk trouwens dat er een hop wat trager reageert...die heeft wel belangrijkere dingen te doen dan op dit soort verzoeken te reageren.

En verder met @mash_man02 ^-^

[eric.1]

mash_man02 schreef op dinsdag 13 oktober 2020 @ 10:48:
[...]

hop 2 die geen response geeft kent geen route terug naar de source van de traceroute en dat is al raar op zich aangezien de router meestal Pat doet en het source adres daarmee in het lokale directly connected netwerk zou moeten zitten.

Hop 2 reageert simpelweg niet op het pakketje wat de traceroute verstuurt (vaak ICMP). Dit heeft niets met een route terug te maken.

mash_man02 schreef op dinsdag 13 oktober 2020 @ 10:50:
de TS kan het denk ik het beste even testen door een client direct op zij kabelmodem aan te sluiten, als dat geen verbetering bied moet je contact opnemen met ziggo, zij kunnen de Pre / Post RS fouten aan zowel up als donwstream beoordelen en acties uitzetten.

Indien zijn modem in Bridge Mode staat is dit best wel een slecht advies...

---

Mij lijkt het vooralsnog verstandiger om te achterhalen wat er nu precies langzaam is.

- nslookup via verschillende dns servers
- meer gedetailleerde traceroute dmv MTR oid.
- het is me ook nog niet duidelijk geworden of de traagheid op meerdere devices optreedt, anders zou het ook gewoon een driver kunnen zijn
- logs bekijken? Wellicht zijn er gewoon errors terug te vinden
- ...

[mash_man02]

eric.1 schreef op dinsdag 13 oktober 2020 @ 11:24:
[...]

Hop 2 reageert simpelweg niet op het pakketje wat de traceroute verstuurt (vaak ICMP). Dit heeft niets met een route terug te maken.


[...]

Indien zijn modem in Bridge Mode staat is dit best wel een slecht advies...

---

Mij lijkt het vooralsnog verstandiger om te achterhalen wat er nu precies langzaam is.

- nslookup via verschillende dns servers
- meer gedetailleerde traceroute dmv MTR oid.
- het is me ook nog niet duidelijk geworden of de traagheid op meerdere devices optreedt, anders zou het ook gewoon een driver kunnen zijn
- logs bekijken? Wellicht zijn er gewoon errors terug te vinden
- ...

toon volledige bericht

1, Ook dat is net zoals mijn stelling mogelijk geen feit, geen route terug is geen antwoord dat is dan wel weer een feit

2. Een test om aan te tonen bij welke partij de verantwoordelijkheid voor hetgeen wat ervaren word ligt een slecht advies ? Tja, dat gaat Ziggo je op een bepaald moment ook vragen, dat kun je ook in de Ziggo community in ruime mate terugvinden, dus dat ben ik per definitie niet met je eens.

Maar laten we vooral de TS zijn antwoorden even afwachten om te zien waar dat toe leid voordat we nog veel verder off topic gaan.

[MatthijsZ]

- De modem staat inderdaad in Bridge modus, dus ik denk niet dat ik daar nog signaalwaardes uit kan toveren
- De traagheid gebeurt op meerdere devices (MacBook van mij en vrouw, mijn iPhone en mijn vrouw haar Android)
- LEDE draait nu lekker, ik was wat angstig om te updaten. Problemen zijn ook pas afgelopen jaar, daarvoor heeft het lang "goed gewerkt" in dezelfde setup
- ik gebruik ook verschillende browsers, maar voornamelijk Safari

Momenteel draait het netwerk weer stabiel, dus de ontwikkelaars-tools in de browser gaan niets laten zien. Ik heb haast het gevoel dat ik een betere verbinding heb sinds ik een speedtest heb gedraaid 🤔 (alsof Ziggo je dan even prioriteit gunt)

Ik zie wel wat interessante dingen in de LEDE-logs, deze meldingen komen vaak voorbij:
- br-lan: port 3(wlan0) entered disabled state
- br-lan: port 3(wlan0) entered blocking state
- mt76x2e 0000:01:00.0: MCU message 31 (seq 3) timed out

[eric.1]

mash_man02 schreef op dinsdag 13 oktober 2020 @ 11:59:
[...]


1, Ook dat is net zoals mijn stelling geen feit, geen route terug is geen antwoord dat is dan wel weer een feit

indien hop2 geen weg terug kent dan houdt de traceroute daar op...want er komt vanaf dat punt nooit meer wat retour.

2. Een test om aan te tonen bij welke partij de verantwoordelijkheid voor hetgeen wat ervaren word ligt een slecht advies ? Tja, dat gaat Ziggo je op een bepaald moment ook vragen, dat kun je ook in de Ziggo community in ruime mate terugvinden, dus dat ben ik per definitie niet met je eens.

Punt is, we weten nog niets. Vooralsnog wijst niets op een structureel netwerkprobleem. Om dan je device rechtstreeks publiekelijk bereikbaar te maken als test is ... Uhm ... Ja ... Het overslaan van 5 stappen en het nemen van een flink risico.

Maar laten we vooral de TS zijn antwoorden even afwachten om te zien waar dat toe leid voordat we nog veel verder off topic gaan.

Eens.

[mash_man02]

eric.1 schreef op dinsdag 13 oktober 2020 @ 12:03:
[...]
indien hop2 geen weg terug kent dan houdt de traceroute daar op...want er komt vanaf dat punt nooit meer wat retour.


[...]

Punt is, we weten nog niets. Vooralsnog wijst niets op een structureel netwerkprobleem. Om dan je device rechtstreeks publiekelijk bereikbaar te maken als test is ... Uhm ... Ja ... Het overslaan van 5 stappen en het nemen van een flink risico.


[...]

Eens.

Punt 1, Dat is juist wat ik zeg, punt 2, als we dan niets weten is iedere methode om aan te tonen waar we moeten zoeken een goede toch ?! En over die 5 stappen, deze zullen het meest efficient blijken als je met ieder stap je fout domein in 2 delen splitst en beoordeeld, de TS 5 stappen laten uitvoeren om achteraf tot de conclusie te komen dat er 4 overbodig waren, tja, 1 per keer is misschien wel verstandiger.

Anders kunnen we een TS in zijn geheel niet helpen en dat is wat ik in ieder geval wel graag wil doen.

Vergeet niet, het is niet om ons gelijk, maar de mogelijke oplossing voor de TS, en dat is gelijk het laatste wat ik er over ga zeggen.

[ Voor 20% gewijzigd door mash_man02 op 13-10-2020 12:16 ]

[vanaalten]

MatthijsZ schreef op dinsdag 13 oktober 2020 @ 12:01:
- De modem staat inderdaad in Bridge modus, dus ik denk niet dat ik daar nog signaalwaardes uit kan toveren

Ik weet niet wat voor modem je precies gebruikt, maar probeer eens te browsen naar 192.168.178.1 of 192.168.100.1 ?
(die eerste gaf mij de modem inlogpagina bij het vorige modem, die tweede werkt bij mijn huidige modem)

Ondanks dat ik het modem in bridge-mode heb kan ik via die pagina bij de signaalwaardes komen.

[dion_b]

MatthijsZ schreef op dinsdag 13 oktober 2020 @ 12:01:
- De modem staat inderdaad in Bridge modus, dus ik denk niet dat ik daar nog signaalwaardes uit kan toveren

Surf eens naar 192.168.100.1

Krijg je daar geen login? Geef dan aan exact welke modem je van Ziggo hebt (merk+modelnr), want door de jaren heen zijn dat er tientallen geweest, elk met eigen nukken en manieren.

- De traagheid gebeurt op meerdere devices (MacBook van mij en vrouw, mijn iPhone en mijn vrouw haar Android)
- LEDE draait nu lekker, ik was wat angstig om te updaten. Problemen zijn ook pas afgelopen jaar, daarvoor heeft het lang "goed gewerkt" in dezelfde setup
- ik gebruik ook verschillende browsers, maar voornamelijk Safari

Momenteel draait het netwerk weer stabiel, dus de ontwikkelaars-tools in de browser gaan niets laten zien. Ik heb haast het gevoel dat ik een betere verbinding heb sinds ik een speedtest heb gedraaid 🤔 (alsof Ziggo je dan even prioriteit gunt)

Ik zie wel wat interessante dingen in de LEDE-logs, deze meldingen komen vaak voorbij:
- br-lan: port 3(wlan0) entered disabled state
- br-lan: port 3(wlan0) entered blocking state
- mt76x2e 0000:01:00.0: MCU message 31 (seq 3) timed out

Dat zit op de WLAN. Ervaar je deze problemen ook bedraad op de router? Zo nee heb je gewoon een WiFi-probleem binnenhuis... sowieso raar dat je dat niet eerst uitsluit

Test dat sowieso eerst voordat je met de modem gaat rommelen - je wilt stap voor stap schakels van de keten uitsluiten.

Mocht je trouwens wel rechtstreeks op de modem willen testen, dan moet je vrij secuur een volgorde aanhouden:
- modem uit, router los van modem.
- modem aan, wachten tot het online is.
- client bedraad op modem.
- als het goed is krijg je publiek IPv4-adres en kun je testen.
- uitgetest? modem uit, client los van modem.
- modem aan, wachten tot het online is.
- router aansluiten op modem en aanzetten.

Bovenstaande is nodig omdat er per boot van de modem maar één device een DHCPv4 lease kan krijgen in bridge mode, dus moet je steeds rebooten voordat je een tweede aansluit.

[MatthijsZ]

Wonderbaarlijk! Ik kan inderdaad naar de modem toe

Ik heb de waardes bijgesloten, als leek lijken die ok.

[dion_b]

MatthijsZ schreef op dinsdag 13 oktober 2020 @ 17:04:
Wonderbaarlijk! Ik kan inderdaad naar de modem toe

Ik heb de waardes bijgesloten, als leek lijken die ok.

[Afbeelding]

[Afbeelding]

[Afbeelding]

Dat tweede tabel dat half op je eerste screenshot te zien is, met MER-waardes, is interessant. Ik zie in de 8 kanalen daar al een paar kantje-boord zijn. Ben vooral geinteresseerd in de hogere kanalen waar LTE-interferentie mogelijk is, rond de 800MHz.

Maar dat gezegd: heb je het al bedraad op je router getest?

[mash_man02]

Pre en Post RS errors zijn echt veel te hoog, met name pre mag wel wat hebben, maar post zou zo goed als tegen 0 aan moeten zitten omdat deze niet corrigeerbaar zijn.

Of er zitten serieuze bugs in de firmware of je hebt een oorzaak gevonden voor twijfelachtige prestaties.

Ter vergelijking, mijn modem is 12 dagen wakker en de hoogste waarde pre is 326 en post 0.



Ziggo bellen of een topic starten op het Ziggo community forum, daar komen ook vaak moderators voorbij die voor Ziggo werken en tickets ook vanuit het forum oppakken.

[ Voor 73% gewijzigd door mash_man02 op 13-10-2020 20:10 ]

[dion_b]

mash_man02 schreef op dinsdag 13 oktober 2020 @ 20:03:
Pre en Post RS errors zijn echt veel te hoog, met name pre mag wel wat hebben, maar post zou zo goed als tegen 0 aan moeten zitten omdat deze niet corrigeerbaar zijn.

Of er zitten serieuze bugs in de firmware of je hebt een oorzaak gevonden voor twijfelachtige prestaties.

Ter vergelijking, mijn modem is 12 dagen wakker en de hoogste waarde pre is 326 en post 0.

[Afbeelding]

Ziggo bellen of een topic starten op het Ziggo community forum, daar komen ook vaak moderators voorbij die voor Ziggo werken en tickets ook vanuit het forum oppakken.

Je slaat stapje over: hoe is de modem binnenhuis aangesloten op coax? Dichtbij AOP met enkele splitter en twee korte, door Ziggo geleverde kabels? Of elders in huis, met andere kabels of met ander apparatuur ertussen.

Als je het zelf verprutst hebt en Ziggo stuurt een monteur komt daar ook een rekening bij kijken, dus beter om zelf eerst alles na te lopen

[mash_man02]

dion_b schreef op dinsdag 13 oktober 2020 @ 20:16:
[...]

Je slaat stapje over: hoe is de modem binnenhuis aangesloten op coax? Dichtbij AOP met enkele splitter en twee korte, door Ziggo geleverde kabels? Of elders in huis, met andere kabels of met ander apparatuur ertussen.

Als je het zelf verprutst hebt en Ziggo stuurt een monteur komt daar ook een rekening bij kijken, dus beter om zelf eerst alles na te lopen

Daar heb je gelijk in, maar daar geeft Ziggo ook advies over voordat ze een monteur sturen. Met name in het community forum wil men met je meekijken als je foto's van de aansluiting post, daar vraagt men ook vaak om.

Dan stuurt men bij vermoeden zelfs al kosteloos materiaal op om te kijken of het zonder monteur opgelost kan worden.

[ Voor 9% gewijzigd door mash_man02 op 13-10-2020 20:21 ]

[dion_b]

Klopt, maar we kunnen hier ook kijken, en het voorstellen om discussies van het forum naar een andere plek te verplaatsen is eigenlijk not-done.

[mash_man02]

dion_b schreef op dinsdag 13 oktober 2020 @ 20:44:
Klopt, maar we kunnen hier ook kijken, en het voorstellen om discussies van het forum naar een andere plek te verplaatsen is eigenlijk not-done.

fair enough

[MatthijsZ]

Top comments weer iedereen! Het modem is aangesloten op een bestaande coax situatie hier in huis, bij nader inzien had ik al kunnen vermoeden dat dat problemen kon geven want de vorige eigenaar had door het hele huis kabels en splitters.

Ik ga dat dit weekend eens onder handen nemen (moet waarschijnlijk onder de vloer zijn)

Dus vervolg reacties en evt fotos komen pas in het weekend!

[Ben(V)]

Een modem mag niet meer dan 2m van het Aop aangesloten worden en met een degelijke coax kabel dus geen huisvlijt met plastic connectors.
Tussen de Aop mag je hooguit een enkele splitter zetten met f-connectors.

[dion_b]

MatthijsZ schreef op woensdag 14 oktober 2020 @ 09:01:
Top comments weer iedereen! Het modem is aangesloten op een bestaande coax situatie hier in huis, bij nader inzien had ik al kunnen vermoeden dat dat problemen kon geven want de vorige eigenaar had door het hele huis kabels en splitters.

Ik ga dat dit weekend eens onder handen nemen (moet waarschijnlijk onder de vloer zijn)

Dus vervolg reacties en evt fotos komen pas in het weekend!

Toch even kanttekening: het ziet ernaar uit dat daar een en ander niet goed is, maar of dat daadwerkelijk oorzaak is van de problemen die je ervaart is een tweede. Ik zou voor de derde keer aanraden om eens bedraad via Ethernet op router te testen.