Onstabiele verbinding Cisco EPC3928AD; eeuwig ladende sites.

[Svenzeau]

Hallo tweakers,

Ik heb sinds ongeveer twee weken erg last van een onstabiele verbinding;

• Websites blijven soms oneindig laden, of laden half en blijven dan heel lang of oneindig lang laden. Browser opnieuw starten en direct naar het adres gaan dat ik probeerde te laden lost het probleem op.
• Bij het kijken van bijvoorbeeld tv via Ziggo GO op de laptop heb ik ongeveer 5 minuten beeld voordat het laadicoon verschijnt en dan vaak oneindig blijft laden. De app herstarten is dan de enige oplossing maar dat is uiteraard niet een oplossing.
• Zelfde probleem bij andere streaming diensten, bijvoorbeeld de Netflix app in Windows.
• Probleem speelt met zowel ethernet kabel als via de wifi.
• Alleen ziggo modem + router Cisco EPC3928AD in gebruik.
• Probleem speelt op Android + IOS telefoons, Windows laptops en Windows desktops.

Ik heb het volgende al geprobeerd:

• Wifi kanaal 1 / 6 / 11 geprobeerd, zelfde probleem maar zou niet uit moeten maken bij een ethernet kabel.
• Coax kabel losgeschroefd, omgedraaid en weer vast geschroefd.
• Modem uitgeschakeld, uitgelaten (15+ minuten) weer aangezet. Probleem lijkt kort opgelost en is dan weer terug.
• Modem volledig gereset, standaard settings weer geprobeerd met wifi / ethernet en zelfde probleem.
• DNS server gewisseld naar Google (8.8.8.8 etc) en OpenDNS, probleem blijft.
• Alle lampjes branden constant groen.
• Log bekeken van modem, geen foutmeldingen.
• Event log van Windows computers bekeken, foutmeldingen ongeveer 10 minuten nadat het beeld vastloopt: Het pakket LibertyGlobal.ZiggoGO_1.2.1.0_x64__gmwgfebrpy77e+App is beëindigd omdat het onderbreken te lang duurde (event id 2484).
• Zoeken op tweakers en ziggo community, maar ik word er niet echt wijs uit, veel suggesties wijzen naar DNS server aanpassen en dergelijke.
• Ping gedaan van een paar websites: normale response tijden en geen 0% packet loss.

Hebben jullie nog meer suggesties om te analyseren? Ticket overigens ook al bij Ziggo ingeschoten, en dank voor het lezen in ieder geval

[Anoniem: 203842]

Heb je de laptop ook bekabeld aangesloten (en WiFi UIT zetten met schakelaar op de laptop)?

[Svenzeau]

Hi haik01,

Dank voor je antwoord. Niet met de laptop nog, wel met een desktop (die geen wifi heeft) en daarbij heb ik hetzelfde probleem.

[dion_b]

Klinkt als iets tussen router en het bredere internet...

Het gaat hier over kabelinternet, log eens in op de modemrouter en geef de signaalwaardes eens. Meest interessante kun je niet op de kabelmodem uitlezen (US Rx SNR), maar de US Tx en DS Rx waardes zouden al wat kunnen aangeven.

Verder: je symptoom klinkt als packetloss. Probeer eens te achterhalen waar dat gebeurt. Doe een pathping naar een server waar je problemen op ervaart (liefst een zo simpel mogelijke website). Dan zie je bij welke hop het fout gaat.

[Brahiewahiewa]

't Klinkt allemaal een beetje of path-MTU discovery in de soep loopt.
Staat ICMP misschien uit op je modem?

[Anoniem: 203842]

Misschien even een belletje naar Ziggo? Of die kabel bedrijf bij wie je dit afneemt.

[ThinkPad]

Dat modem is al een wat ouder model volgens mij, ik zou Ziggo vragen of ze een vervanger kunnen sturen.
Tegenwoordig krijg je een Ubee dacht ik.

[hcQd]

ThinkPadd schreef op woensdag 2 augustus 2017 @ 11:00:
Tegenwoordig krijg je een Ubee dacht ik.

Tegenwoordig krijg je een ConnectBox met alle bijbehorende PUMA6 problemen.

[dion_b]

ThinkPadd schreef op woensdag 2 augustus 2017 @ 11:00:
Dat modem is al een wat ouder model volgens mij, ik zou Ziggo vragen of ze een vervanger kunnen sturen.
Tegenwoordig krijg je een Ubee dacht ik.

Beetje voorbarig. We weten nog niet of het probleem in de modem zelf zit, laat staan dat het iets is wat enkel met nieuwe modem vervangen kan worden. Eerst root cause achterhalen, dan pas oplossingsrichting definieren.

Als het probleem niet in het apparaat zelf zit, lost het vervangen ervan niets op en voegt mogelijk andere problemen toe...

[Svenzeau]

Ietsje later antwoord, maar ik moest even thuis komen van werk om de gevraagde zaken op te zoeken

dion_b schreef op woensdag 2 augustus 2017 @ 01:25:
Klinkt als iets tussen router en het bredere internet...

Het gaat hier over kabelinternet, log eens in op de modemrouter en geef de signaalwaardes eens. Meest interessante kun je niet op de kabelmodem uitlezen (US Rx SNR), maar de US Tx en DS Rx waardes zouden al wat kunnen aangeven.

Ik denk dat dit is wat we zoeken, right?

Downstream channels:

• Channel 1:
• Channel ID: 9
• Downstream Frequency: 242000000 Hz
• Modulation: 256 QAM
• Power Level: 1.6 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 0.0 dB
• Correctable FEC: 21 codewords
• Uncorrectable FEC: 14 codewords
• Channel 2:
• Channel ID: 10
• Downstream Frequency: 250000000 Hz
• Modulation: 256 QAM
• Power Level: 1.1 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 0.0 dB
• Correctable FEC: 22 codewords
• Uncorrectable FEC: 13 codewords
• Channel 3:
• Channel ID: 11
• Downstream Frequency: 258000000 Hz
• Modulation: 256 QAM
• Power Level: 0.9 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 0.0 dB
• Correctable FEC: 14 codewords
• Uncorrectable FEC: 12 codewords
• Channel 4:
• Channel ID: 12
• Downstream Frequency: 266000000 Hz
• Modulation: 256 QAM
• Power Level: 1.6 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 42.5 dB
• Correctable FEC: 5 codewords
• Uncorrectable FEC: 0 codewords
• Channel 5:
• Channel ID: 13
• Downstream Frequency: 274000000 Hz
• Modulation: 256 QAM
• Power Level: 1.7 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 42.5 dB
• Correctable FEC: 6 codewords
• Uncorrectable FEC: 0 codewords
• Channel 6:
• Channel ID: 14
• Downstream Frequency: 282000000 Hz
• Modulation: 256 QAM
• Power Level: 1.4 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 42.5 dB
• Correctable FEC: 7 codewords
• Uncorrectable FEC: 0 codewords
• Channel 7:
• Channel ID: 15
• Downstream Frequency: 290000000 Hz
• Modulation: 256 QAM
• Power Level: 1.4 dBmV
• Signal to Noise Ratio: 42.5 dB
• MER: 42.5 dB
• Correctable FEC: 11 codewords
• Uncorrectable FEC: 5 codewords
• Channel 8:
• Channel ID: 16
• Downstream Frequency: 298000000 Hz
• Modulation: 256 QAM
• Power Level: 1.1 dBmV
• Signal to Noise Ratio: 42.1 dB
• MER: 42.5 dB
• Correctable FEC: 14 codewords
• Uncorrectable FEC: 2 codewords

Upstream Channels

• Channel1:
• Channel ID: 78
• Upstream Frequency: 44500000 Hz
• Modulation: 64 QAM
• Bit Rate: 30720 kBits/sec
• Power Level: 42.5 dBmV
• Channel2:
• Channel ID: 77
• Upstream Frequency: 52000000 Hz
• Modulation: 64 QAM
• Bit Rate: 30720 kBits/sec
• Power Level: 43.3 dBmV
• Channel3:
• Channel ID: 79
• Upstream Frequency: 36000000 Hz
• Modulation: 64 QAM
• Bit Rate: 30720 kBits/sec
• Power Level: 42.5 dBmV
• Channel4:
• Channel ID: 80
• Upstream Frequency: 58800000 Hz
• Modulation: 64 QAM
• Bit Rate: 30720 kBits/sec
• Power Level: 43.3 dBmV

Brahiewahiewa schreef op woensdag 2 augustus 2017 @ 08:41:
't Klinkt allemaal een beetje of path-MTU discovery in de soep loopt.
Staat ICMP misschien uit op je modem?

Dit durf ik niet te zeggen. Hij staat op de standaardwaarden van de router dus als ICMP standaard aan staat, dan zal het nu ook aanstaan. Ik kon de setting in ieder geval niet vinden in het menu. Kan het een andere naam hebben?

Anoniem: 203842 schreef op woensdag 2 augustus 2017 @ 10:41:
Misschien even een belletje naar Ziggo? Of die kabel bedrijf bij wie je dit afneemt.

Ja ben ook in gesprek met de Webcare van Ziggo zelf

dion_b schreef op woensdag 2 augustus 2017 @ 01:25:
Verder: je symptoom klinkt als packetloss. Probeer eens te achterhalen waar dat gebeurt. Doe een pathping naar een server waar je problemen op ervaart (liefst een zo simpel mogelijke website). Dan zie je bij welke hop het fout gaat.

Dit is wat ik eruit kreeg met drie voorbeelden maar er komt niet zo gek veel uit. Mis ik iets?

C:\Users\Svenzeau>pathping gathering.tweakers.net

Tracing route to gathering.tweakers.net [213.239.154.30]
over a maximum of 30 hops:
0 Laptop [192.168.178.11]
1 192.168.178.1
2 * * *
Computing statistics for 25 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Laptop [192.168.178.11]
0/ 100 = 0% |
1 2ms 0/ 100 = 0% 0/ 100 = 0% 192.168.178.1

Trace complete.

C:\Users\Svenzeau>pathping nl.ign.com

Tracing route to e5042.e2.akamaiedge.net [95.100.135.42]
over a maximum of 30 hops:
0 Laptop [192.168.178.11]
1 192.168.178.1
2 * * *
Computing statistics for 25 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Laptop [192.168.178.11]
0/ 100 = 0% |
1 2ms 0/ 100 = 0% 0/ 100 = 0% 192.168.178.1

Trace complete.

C:\Users\Svenzeau>pathping www.google.nl

Tracing route to www.google.nl [216.58.212.195]
over a maximum of 30 hops:
0 Laptop [192.168.178.11]
1 192.168.178.1
2 * * *
Computing statistics for 25 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Laptop [192.168.178.11]
0/ 100 = 0% |
1 3ms 0/ 100 = 0% 0/ 100 = 0% 192.168.178.1

Trace complete.

[Brahiewahiewa]

Svenzeau schreef op woensdag 2 augustus 2017 @ 19:18:
...Dit durf ik niet te zeggen. Hij staat op de standaardwaarden van de router dus als ICMP standaard aan staat, dan zal het nu ook aanstaan. Ik kon de setting in ieder geval niet vinden in het menu. Kan het een andere naam hebben?...

Sorry, dit valt alleen breedsprakig te beantwoorden: de fout die de meeste routers maken is dat er één button is waarmee je ICMP aan- of uitzet. En de fabrikant de misvatting heeft dat 't maar beter uit kan staan, ivm security enzo. Terwijl zowel windows- als linuxclients zo ongeveer verslaafd zijn aan het ICMP-packet_too_big signaal. Dat komt door de path-MTU-discovery, wat er op neer komt dat je met de maximale MTU packets in het rond slingert en pretendeert te kunnen ontvangen. pMTU verwacht dat een tussenliggende router wel slim genoeg is om de juiste MTU voor het vervolgtraject te hanteren en - in geval het aangeboden packet groter is - het packet te droppen en een ICMP-frame terug te sturen (met de boodschap "packet too big"; dûh)

Nou is niet iedere router slim genoeg om dat te doen (sommigen gaan het packet fragmenteren). Maar als dat jouw problemen veroorzaakte, was je niet de enige. Daarom ligt het voor de hand om de oorzaak in jouw netwerk te zoeken. Dat kan op je router zijn. Daar kan het gewoon ICMP heten of IP-protocol 1. Maar ook "ping from the internet" of soortgelijk twengels. Verder kan het ook op je clients misgaan; je firewall kan het tegenhouden of je virusscanner of je netwerkkaart. En dan zijn er ook nog tussenliggende zaken als een VPN waar je alleen TCP en UDP forwardt en voor 't gemak ICMP vergeet. Kortom: ruimte genoeg voor één of meerdere configuratiefouten

Anyway: 't zou het gedrag van jouw browsers goed verklaren: alleen kleine frames komen binnen, zodat korte teksten en paginalayout wel doorkomen, maar grotere (m.n. plaatjes) niet

[Brahiewahiewa]

Svenzeau schreef op woensdag 2 augustus 2017 @ 19:18:
...
Dit is wat ik eruit kreeg met drie voorbeelden maar er komt niet zo gek veel uit. Mis ik iets?

[...]

Nee, da's een misser van pathping: die stopt bij de eerste router die niets terugstuurt terwijl routers verderop in het traject best nog wel iets terug zouden willen sturen

[Svenzeau]

Hi Brahiewahiewa,

Ik heb nog een keer door de settings gebladerd naar aanleiding van je eerste post, maar ik kan echt niets soortgelijks vinden. Het klinkt ook als best een geavanceerde setting (meer iets voor DD-WRT bijvoorbeeld?).

Brahiewahiewa schreef op woensdag 2 augustus 2017 @ 23:50:
[...]

Nee, da's een misser van pathping: die stopt bij de eerste router die niets terugstuurt terwijl routers verderop in het traject best nog wel iets terug zouden willen sturen

Is hier nog iets anders op te proberen in dat geval? Kan ik er omheen?

[Brahiewahiewa]

Svenzeau schreef op donderdag 3 augustus 2017 @ 21:47:
...
Is hier nog iets anders op te proberen in dat geval? Kan ik er omheen?

Je kunt gewoon ping gebruiken met een oplopende payload en het not fragment bit gezet

ping -l 576 -f tweakers.net

om te beginnen, de 576 verhogen tot max 1500; mooi gevalletje voor de regula falsi.
De maximale payload die je vindt moet je met 28 verhogen; da's je MTU

[kwakzalver]

Volgens mij ligt het probleem dieper dan dit en ligt in het Ziggo netwerk.

Het probleem van packet loss zie ik de laatste maand steeds vaker optreden bij Ziggo.
Over verschillende lokaties in NL; zowel op zakelijke als prive aansluitingen.

Soms duidelijk herkenbaar, soms heel sneaky (packet loss bij VoIP verbindingen) dat het moeilijk te identificeren is.

Het is een structureel probleem.

Dit treed nadrukkelijk op bij locaties waar Ziggo haar hele infrastructuur (kabels, switches) heeft vervangen.
(D'r was hier na een blikseminslag alles gefrituurd en ook letterlijk alles vervangen....)

Ga je er te diep op in; met technisch bewijs...was het subtiele antwoord 'mag er van mijn teamleider niet meer op ingaan'.

Het probleem ligt ook bij het feit dat Ziggo elke case als een 'aparte nieuwe case' behandeld. En dus identieke cases continu apart behandeld en geen inzicht heeft (of wilt hebben) in het groter geheel.

Losse mogelijke oplossingen:

1. Heb je toevallig een gelijkwaardige voeding liggen? Vervang die eens. De Cisco's EPC zijn berucht dat ze met te zwakke/instabiele voedingen worden uitgeleverd.

2. Blijf voorlopig proberen de modem een paar minuten uit te zetten en weer aan te zetten. Wellicht krijg je een routering die 'iets stabieler' werkt dan de voorgaande. Werkt die verbinding...afblijven van de modem.

3. Een nieuwe model modem is eigenlijk ook niet de oplossing (zie opmerking hcQd) gezien deze ook niet stabiel is.

[Svenzeau]

Hallo allen,

Nog even terugkoppelen dat dankzij de snelle hulp van @VodafoneZiggo we een nieuwe modem hebben (de ConnectBox) en die werkt tot nu toe prima! Als test tijdje tv gekeken op de laptop met Ziggo GO, gaat prima en gewoon verder gewerkt in Coursera course en dat gaat ook prima (sessie viel altijd weg naar dat gele lampje rechtsbovenin).

Brahiewahiewa schreef op vrijdag 4 augustus 2017 @ 08:28:
[...]

Je kunt gewoon ping gebruiken met een oplopende payload en het not fragment bit gezet

ping -l 576 -f tweakers.net

om te beginnen, de 576 verhogen tot max 1500; mooi gevalletje voor de regula falsi.
De maximale payload die je vindt moet je met 28 verhogen; da's je MTU

Dit heb ik nog gedaan, steeds +28 vanaf 576 als ik je goed heb begrepen. Er zat niet veel variatie in de responses, dit leek allemaal goed te gaan.

Misschien dat de modem inderdaad wat oud was zoals eerder opgemerkt, of is het uiteindelijk de voeding geweest zoals @kwakzalver noemt - maar het probleem is opgelost dus.

Dank voor het meedenken allemaal!