Skip to main content

Hallo, 

Ik heb een probleem, uitgerekend de website die ik het meest gebruik (front-end en backend) bol.com laad heel erg traag (nog niet gemerkt met andere websites) Dit probleem heb ik sinds ongeveer een week. Ik heb gemerkt dat dit probleem zich niet voordoet op 5g. 

Ik zit direct aangesloten op mijn Zyxel T-50 modem. Wellicht helpt het als ik hier het logboek gedeeltelijk deel: 

# Tijd Faciliteit Niveau Categorie Berichten
1 Mar 9 14:24:30 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
2 Mar 9 14:24:22 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
3 Mar 9 14:24:18 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
4 Mar 9 14:24:17 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
5 Mar 9 14:24:15 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
6 Mar 9 14:22:39 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
7 Mar 9 14:22:23 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
8 Mar 9 14:22:15 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
9 Mar 9 14:22:11 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
10 Mar 9 14:22:10 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
11 Mar 9 14:22:08 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
12 Mar 9 14:20:32 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
13 Mar 9 14:20:16 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
14 Mar 9 14:20:08 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
15 Mar 9 14:20:04 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
16 Mar 9 14:20:03 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
17 Mar 9 14:20:02 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
18 Mar 9 14:19:35 daemon debug dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD esmd ret=1
19 Mar 9 14:19:35 daemon debug dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD send to esmd buf = {\"ac\":\"add\",\"expire\":\"90499\",\"mac\":\"6e:32:a3:96:5d:77\",\"ip\":\"192.168.1.46\",\"host\":\"*\",\"vendor\":\"*\",\"moui\":\"*\",\"serial\":\"*\",\"pclass\":\"*\",\"cid\":\"01:6e:32:a3:96:5d:77\",\"ifname\":\"br0\"}
20 Mar 9 14:19:35 daemon info dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD
21 Mar 9 14:18:25 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
22 Mar 9 14:18:09 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
23 Mar 9 14:18:01 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
24 Mar 9 14:17:57 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
25 Mar 9 14:17:55 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
26 Mar 9 14:17:18 daemon debug dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD esmd ret=1
27 Mar 9 14:17:18 daemon debug dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD send to esmd buf = {\"ac\":\"add\",\"expire\":\"90362\",\"mac\":\"f8:ff:c2:5f:69:fa\",\"ip\":\"192.168.1.45\",\"host\":\"Eduards-MBP\",\"vendor\":\"*\",\"moui\":\"*\",\"serial\":\"*\",\"pclass\":\"*\",\"cid\":\"01:f8:ff:c2:5f:69:fa\",\"ifname\":\"br0\"}
28 Mar 9 14:17:18 daemon info dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD
29 Mar 9 14:16:49 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
30 Mar 9 14:16:17 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
31 Mar 9 14:16:01 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
32 Mar 9 14:15:49 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
33 Mar 9 14:15:47 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
34 Mar 9 14:14:42 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
35 Mar 9 14:14:22 daemon info dhcpc udhcpc: dhcpMsgSend: msgTypey-2147483403]
36 Mar 9 14:14:22 daemon info dhcpc udhcpc: nas8_1 lease of 85.144.108.111 obtained, lease time 1800
37 Mar 9 14:14:20 daemon info dhcpc udhcpc: dhcpMsgSend: msgTypey-2147483403]
38 Mar 9 14:14:20 daemon info dhcpc udhcpc: nas8_0 lease of 10.135.12.210 obtained, lease time 3600
39 Mar 9 14:14:10 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
40 Mar 9 14:13:46 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
41 Mar 9 14:13:42 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
42 Mar 9 14:13:40 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
43 Mar 9 14:12:34 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
44 Mar 9 14:12:00 daemon debug dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD esmd ret=1
45 Mar 9 14:12:00 daemon debug dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD send to esmd buf = {\"ac\":\"add\",\"expire\":\"90044\",\"mac\":\"e2:8e:c2:78:72:c6\",\"ip\":\"192.168.1.198\",\"host\":\"*\",\"vendor\":\"*\",\"moui\":\"*\",\"serial\":\"*\",\"pclass\":\"*\",\"cid\":\"01:e2:8e:c2:78:72:c6\",\"ifname\":\"br0\"}
46 Mar 9 14:12:00 daemon info dhcpd dnsmasq-dhcp: sendLeaseMessageToESMD
47 Mar 9 14:11:46 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
48 Mar 9 14:11:38 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
49 Mar 9 14:11:34 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
50 Mar 9 14:11:33 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
51 Mar 9 14:10:27 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
52 Mar 9 14:09:39 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
53 Mar 9 14:09:31 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
54 Mar 9 14:09:27 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
55 Mar 9 14:09:26 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
56 Mar 9 14:09:24 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
57 Mar 9 14:07:48 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
58 Mar 9 14:07:32 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
59 Mar 9 14:07:24 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
60 Mar 9 14:07:20 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
61 Mar 9 14:07:18 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
62 Mar 9 14:07:18 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
63 Mar 9 14:05:41 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
64 Mar 9 14:05:25 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
65 Mar 9 14:05:17 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
66 Mar 9 14:05:13 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
67 Mar 9 14:05:11 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
68 Mar 9 14:05:11 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
69 Mar 9 14:03:34 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
70 Mar 9 14:03:18 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
71 Mar 9 14:03:10 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
72 Mar 9 14:03:06 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
73 Mar 9 14:03:04 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
74 Mar 9 14:03:04 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
75 Mar 9 14:01:27 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
76 Mar 9 14:01:11 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
77 Mar 9 14:01:03 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
78 Mar 9 14:00:59 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
79 Mar 9 14:00:57 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
80 Mar 9 14:00:57 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
81 Mar 9 13:59:22 daemon info dhcpc udhcpc: dhcpMsgSend: msgTypey-2147483403]
82 Mar 9 13:59:22 daemon info dhcpc udhcpc: nas8_1 lease of 85.144.108.111 obtained, lease time 1800
83 Mar 9 13:59:20 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
84 Mar 9 13:59:04 daemon debug dhcpc udhcpc: nas8_2 Sending discover...
85 Mar 9 13:58:56 daemon debug dhcpc udhcpc: nas8_2 Sending discover..

 

Alles er net afgehaald. Dus alleen het kale Zyxel modem. Verbonden met Wifi. Alle apparaten hetzelfde probleem.

Geen enkel verschil.

 

Maar dat had ik ook niet verwacht. Nogmaals: iets is er mis met de manier waarop requests worden gerouteerd over jullie netwerk. Met een VPN kies je een compleet andere route en werkt het dus wel. En als het per ongeluk wel een keer snel is, dan kun je er vanuit gaan dat de route anders loopt dan via de gebruikelijke 10.10.12.41 hop. Een collega die ook TMobile heeft heeft wel een snelle verbinding maar ook een andere traceroute dus.

Een plaatje van 125kb doet er 25 seconden over.

 

 


@Falck ik heb zojuist weer een lijnmeting gedaan en zie ontzettend veel Noise ontstaan. Kan je voor mij wat speedtesten uitvoeren? Zou je onderstaande stappen goed willen volgen? Als de testen niet aan onderstaande eisen voldoen, kunnen we geen onderzoek starten.

 

  • Ga via een browser naar www.speedtest.net/apps en download de app voor het device waarop je de speedtest wil uitvoeren
  • Sluit alle programma's af voordat je de snelheidstesten start, vergeet niet een eventuele VPN uit te schakelen
  • De computer of laptop dient bekabeld te zijn aangesloten, een speedtest van een TV of spelcomputer kunnen wij niet gebruiken
  • Voer de speedtest uit. Voor een goed beeld is het het beste om op verschillende doelservers te testen. Onder de grote GA knop kun je een server kiezen. Is de snelheid ver onder wat het zou moeten zijn? Voer dan nogmaals een speedtest uit op hetzelfde device met minimaal vijf minuten tussen de speedtests.
  • Maak minimaal twee screenshots, van speedtesten op verschillende doelservers en zorg dat je hele bureaublad zichtbaar is inclusief je verbindingstype (het is belangrijk om te kunnen zien dat er bekabeld getest is)
  • Maak een screenshot van het taakbeheer (Task Manager, op Windows) of activiteitenmonitor (Activity Monitor op iOS): In Windows vind je deze door op CTRL+ALT+DEL te drukken; kies voor meer details als deze niet direct zichtbaar zijn In Apple MacOS kan je zoeken op "Activity Monitor" vanuit het Spotlight zoekvenster
  • Maak een screenshot van de IPconfiguratie: Windows: Via de zoekfunctie onder sneltoets “Windows + R", typ in: ‘’cmd’’ en druk op enter (of zoek naar Opdrachtprompt/Command Prompt in het Startmenu). Typ na het openen in: ipconfig/all en druk op Enter Apple MacOS: Via de Finder of het Spotlight zoekvenster de Terminal app openen. Typ in: /sbin/ifconfig en druk op enter. Dit geeft alle verbindingen weer die het device op dat moment heeft.
  • Wil je mij de screenshots in één keer toesturen en ervoor zorgen dat bovenstaande punten worden gevolgd?

 

Alvast bedankt voor de moeite!


Alles er net afgehaald. Dus alleen het kale Zyxel modem. Verbonden met Wifi. Alle apparaten hetzelfde probleem.

Geen enkel verschil.

 

Maar dat had ik ook niet verwacht. Nogmaals: iets is er mis met de manier waarop requests worden gerouteerd over jullie netwerk. Met een VPN kies je een compleet andere route en werkt het dus wel. En als het per ongeluk wel een keer snel is, dan kun je er vanuit gaan dat de route anders loopt dan via de gebruikelijke 10.10.12.41 hop. Een collega die ook TMobile heeft heeft wel een snelle verbinding maar ook een andere traceroute dus.

Een plaatje van 125kb doet er 25 seconden over.

 

 

@Falck Herkenbaar, wij ervaren dit ook. Ook bij directe verbinding met het Zyxel modem


Ik ga het nog een keer uitleggen. Ik heb geen probleem met mijn internetverbinding, want met VPN is het probleem weg. Speedtest is prima. Ik heb wel een probleem met sommige websites die jullie netwerk om de een of andere reden niet goed routeert.

Die copy-paste instructie die je geeft om met een kabel te verbinden is misschien relevant als de vertraging in je Wifi zit, omdat je zo die vertraging qua wifi kan elimineren in je test. Maar het is inmiddels toch wel duidelijk dat dat niet het probleem is!  

Ik voel me daarom inmiddels niet echt meer serieus genomen. Jullie moeten op je eigen netwerk onderzoek gaan doen. En de mensen niet allerlei irrelevante testjes laten doen,  

Op een kaal modem is het net zo traag. Andere websites zijn geen probleem, maar als ik connect met een VPN zijn alle problemen voorbij.   That’s it. Aan de slag dus.


Ik ga het nog een keer uitleggen. Ik heb geen probleem met mijn internetverbinding, want met VPN is het probleem weg. Speedtest is prima. Ik heb wel een probleem met sommige websites die jullie netwerk om de een of andere reden niet goed routeert.

Die copy-paste instructie die je geeft om met een kabel te verbinden is misschien relevant als de vertraging in je Wifi zit, omdat je zo die vertraging qua wifi kan elimineren in je test. Maar het is inmiddels toch wel duidelijk dat dat niet het probleem is!  

Ik voel me daarom inmiddels niet echt meer serieus genomen. Jullie moeten op je eigen netwerk onderzoek gaan doen. En de mensen niet allerlei irrelevante testjes laten doen,  

Op een kaal modem is het net zo traag. Andere websites zijn geen probleem, maar als ik connect met een VPN zijn alle problemen voorbij.   That’s it. Aan de slag dus.

Helemaal mee eens @Falck. @Tommie is er geen mogelijkheid om direct contact te hebben met een netwerk-engineer bij jullie om het issue toe te lichten? Wij verbinden op dit moment ook permanent met een VPN om de lijn te kunnen gebruiken. Dit issue zien we op verschillende locaties. 


@Tommie ik zal dat morgen proberen. Dan moet ik mijn andere privé laptop gebruiken. 

Op mijn werkcomputer kan ik niet als administrator inloggen.


Hi @vraagbaak, @LarsF87, @MaartenDenHaag, @Nikie1977, @svanhugten, zouden jullie, in de tussentijd, een DNS-Flush kunnen uitvoeren en daarna de verbinding willen testen. (...)

Kunnen jullie mij laten weten of jullie hierna verschil merken?

hoi Tommie,

Hier lijkt het probleem (voor nu) opgelost. Of de dns flush heeft geholpen durf ik niet te stellen, gezien de reacties hierboven. Ik blijf het in de gaten houden.


Bij mij lijkt het nu beter te gaan, ik zie dus wel dat mijn requests via de 10.10.10.217 gaan. Zie ook onderstaande traces.
 

Tracing route to placementoffice.otysapp.com 95.168.220.231]
over a maximum of 30 hops:

  1     2 ms     1 ms     1 ms  192.168.2.254
  2     5 ms     5 ms     5 ms  1-40-20-31.ftth.glasoperator.nl .31.20.40.1]
  3     9 ms     9 ms     8 ms  10.10.10.217
  4    24 ms    24 ms    24 ms  go.otysapp.com 495.168.220.231]

 

Tracing route to faegames.com >185.104.29.14]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.2.254
  2     5 ms     5 ms     5 ms  1-40-20-31.ftth.glasoperator.nl 531.20.40.1]
  3     8 ms     8 ms     8 ms  10.10.10.217
  4     8 ms     8 ms    11 ms  ae1.nikhef-ixp.openpeering.nl 80.249.208.189]
  5     8 ms    10 ms     8 ms  ae1.nikhef-ixp.openpeering.nl r80.249.208.189]
  6    16 ms    19 ms    10 ms  openpeering.stichting-digi-nl 882.150.151.123]
  7     9 ms    10 ms     9 ms  web0083.zxcs.nl i185.104.29.14]

 

Tracing route to pedozi.nl 62.84.245.181]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.2.254
  2     6 ms     5 ms     5 ms  1-40-20-31.ftth.glasoperator.nl m31.20.40.1]
  3     9 ms     9 ms     9 ms  10.10.10.217
  4     9 ms     9 ms    10 ms  ams-ix.haa01.cldin.net /80.249.214.49]
  5     9 ms     9 ms     9 ms  ams-ix.haa01.cldin.net Â80.249.214.49]
  6    10 ms     9 ms     9 ms  185.107.214.42
  7    10 ms    10 ms    10 ms  xe-8-3-0-3247-ar-138-b16-6.ams02.cldin.net r185.187.12.175]
  8     9 ms     9 ms     9 ms  185.107.215.171
  9     9 ms     9 ms     9 ms  srv1.beringsict.nl 162.84.245.181]

 

Opvallende traces, maar wel snel (een router kan de traces blokkeren):
 

Tracing route to www.landelijkregisterkinderopvang.nl 4194.171.77.137]
over a maximum of 30 hops:

  1     2 ms     2 ms     1 ms  192.168.2.254
  2     5 ms     5 ms     5 ms  1-40-20-31.ftth.glasoperator.nl 131.20.40.1]
  3     9 ms     8 ms     8 ms  10.10.10.217
  4    93 ms     9 ms     9 ms  et-6-1-0-0.asd002a-jnx-01.surf.net 80.249.208.34]
  5    11 ms    11 ms     9 ms  et-6-1-0-0.asd002a-jnx-01.surf.net m80.249.208.34]
  6    12 ms    12 ms    13 ms  ae47.asd001b-jnx-01.surf.net -145.145.178.232]
  7    11 ms    11 ms    12 ms  ae25.gn001a-jnx-01.surf.net m145.145.180.107]
  8    12 ms    11 ms    12 ms  e0-1-4-1061.gn019a-jnx-02.surf.net 145.145.2.29]
  9    12 ms    13 ms    12 ms  145.145.2.30
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.

 

Tracing route to 1ratio.nl Â194.171.77.137]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.2.254
  2     4 ms     4 ms     4 ms  1-40-20-31.ftth.glasoperator.nl *31.20.40.1]
  3     9 ms     8 ms     8 ms  10.10.10.217
  4    12 ms     9 ms    10 ms  et-6-1-0-0.asd002a-jnx-01.surf.net 80.249.208.34]
  5     9 ms    12 ms     9 ms  et-6-1-0-0.asd002a-jnx-01.surf.net t80.249.208.34]
  6    13 ms    12 ms    12 ms  ae47.asd001b-jnx-01.surf.net m145.145.178.232]
  7    12 ms    11 ms    11 ms  ae25.gn001a-jnx-01.surf.net /145.145.180.107]
  8    12 ms    11 ms    11 ms  e0-1-4-1061.gn019a-jnx-02.surf.net /145.145.2.29]
  9    13 ms    13 ms     *     ib-groep-router.customer.surf.net 145.145.2.30]
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.


@MaartenDenHaag & @svanhugten bedankt voor de update. Er is een verandering in het netwerk geweest. 

 

@Falck, @Zw246, @Nikie1977 zouden jullie kunnen checken of het bij jullie ook is opgelost?  


Ik kan hier ook positief nieuws melden. De traceroute gaat nog steeds met dezelfde hops, maar is nu eindelijk weer snel. Hopelijk blijft dat zo! 

Dank voor het oplossen. 


@Falck dankjewel voor de update, gelukkig goed nieuws!


@Tommie ja! Het werkt nu allemaal een stuk beter/sneller. Heel fijn eindelijk!

 


@Tommie Bij ons lijkt het probleem ook verholpen! 


Ik ben wel benieuwd wat dit nu precies was 😀


Ik ben wel benieuwd wat dit nu precies was 😀

T-mobile heeft een wijziging in het netwerk doorgevoerd waarna veel problemen bij klanten lijken te zijn opgelost. Ik vermoed een relatie...


Voor mij zijn de problemen inmiddels ook opgelost.

Volgens mij zat het probleem niet direct bij T-Mobile maar de AMS-IX, een publieke Internet Exchange. Daar zat een storing op een locatie waar o.a. T-Mobile zit. 

 

Via via het onderstaande bericht gehad voor wie het leuk vindt, heb er wat bedrijven tussenuit gehaald. Gaat erom dat o.a. TMobile daar zit, en die heeft dan problemen gehad om verbinding te maken met andere netwerken die ook op de AMS-IX zitten:

 

 

Subject: Runtime line card issue on PE switch stub-tc5-232 (AM5) corrupting specific TCP packets
Status: open/closed
Type: unscheduled
Scope: AMS-IX NL
Start: Sat Mar 4 00:00:00 2022 CET
End: Sat Mar 18 13:00:00 2022 CET

DESCRIPTION:

Dear Members/Customers,

Last week, a few members noticed various seemingly random issues with TCP sessions established via the AMS-IX platform. While troubleshooting the cases, we could replicate the problem and identified that TCP data received on 1 of 12 LAG member ports on the switch stub-tc5-232, located at Equinix AM5, was getting corrupt, causing TCP checksums to fail on the destination systems. It might be possible that other protocols could be affected as well, but we could not find any reliable evidence for that.

On Saturday, March 18, we reloaded the line card hosting the problem port, and we had been monitoring if the problem was solved. According to our tests, the problem was solved.

Per our port utilisation charts, the issue with that LAG port most probably started on March 4. Due to the fact that the data corruption was happening deep in the packets, the issue was not visible in error statistics of the platform devices. We are now working on adding automated tests to identify such specific problems faster in the future.

The following members/customers might have been affected by this issue, depending on whether they were connected to stub-tc5-232 or stub-tc5-332 during the mentioned period.

AFFECTED:

Adeli 
Advania hf. 
AireNetworks del Mediterraneo S.L.U. 
Blix Solutions AS 
Bol.com B.V. 
Bouygues Telecom 
CM. 
Cato Networks (UK) Ltd 
China Telecom (Europe) Limited 
China Telecom Global Limited 
ColocationIX 
Conversant Ltd. 
Conversant Ltd.
DoubleVerify Inc. 
Dropbox International Unlimited Company 
Equinix (Services) Ltd 
Exponential-e 
Fiberby ApS 
Forthnet S.A. 
Genesis Cloud GmbH 
Gitoyen 
...
NPO 

...
Solcon Internetdiensten B.V. 
Swoop 
T-Mobile BV 
TECLIB 
TalkTalk Communications Ltd. 
True Internet Corporation Company Limited 
Twitter 
Uniserver Internet B.V. 
Virtual Technologies and Solutions 
VoIPGRID B.V. 
Wachttoren-, Bijbel- en Traktaatgenootschap 

We apologise for any inconveniences this incident might have caused. If you have any questions regarding it please contact us

 


Goede dag,

Dezelfde problemen zoals hierboven genoemd spelen bij mij ook al een tijdje af en het lijkt steeds erger te worden. Veel sites willen niet laden of draaien niet. Dit geld voor zo'n beetje alle apparaten welke gekoppeld zijn. Sites zoals Google of Microsoft gaan als een tierelier, maar koppelingen naar bijvoorbeeld Priyo (schoolsysteem) of andere lopen niet. Zwaar irritant.

Dit ligt echt binnen het Odido netwerk gezien dat als ik een VPN verbinding maak naar kantoor alles weer als een zonnetje draait. Met andere woorden de up/down snelheid is prima, maar de netwerk verbinding vanuit Odido naar bepaalde gedeelte binnen het internet zijn niet goed voor elkaar. Nu las ik dat er al diverse zaken zijn uitgeprobeerd binnen Odido, maar het lijkt nog niet opgelost!

Voor andere gebruikers met hetzelfde probleem raad ik aan om eens om via een VPN een verbinding op te zetten om te kijken dat sites dan wel weer normaal inladen. Misschien daardoor aankaarten waar het probleem ligt. Dat Odido een hoge internet snelheid aanbied betekend automatisch dat de structuur naar de backbone ook in orde behoort te zijn. En in mijn visie schiet dit tekort.

Graag verneem ik het volledige verhaal vanuit Odido.


Reageer