Haperende internetverbinding, routing issues en IPTV VLAN zonder TV abo

  • 24 February 2022
  • 24 reacties
  • 925 Bekeken

Ik ben eind vorig jaar overgestapt van KPN en nu een T-mobile VDSL verbinding, zonder extra diensten zoals TV of telefonie. Standaard Zyxel modem, bekabeld, en nu aanhoudende problemen bij thuiswerken.

Tijdens vergaderingen hapert beeld en geluid regelmatig, chat kan af en toe even geen verbinding maken, O365 & Google editors synchroniseren niet meer. Kortom, (een deel van) het internet is niet meer beschikbaar, terwijl ik gewoon DSL sync heb, mijn modem en de eerste gateway zijn dan ook bereikbaar.

Een externe DNS (Cloudfare of Google) gebruiken verergert de problemen, of ik die nu in het modem of mijn (Windows 10) PC instel: dan gaat ook mijn interne netwerk haperen en zijn de stotteringen bij videobellen aanzienlijk intensiever.

Ondanks 4x telefonisch contact, een chatconversatie, 4 mails, 2x ‘afwachten’, en modem-resets ben ik tot nu toe alleen maar afgescheept met ‘er was een storing, maar die is opgelost’. Dit terwijl ik logs met tracerts/latency/packetloss heb aangeleverd en in ten minste 4 topics mijn problemen herken:

Consequente ping spikes | T-Mobile Community

VPN, gaming server en website-issues buiten Dordrecht | T-Mobile Community

Trage upload en packetloss in het T-Mobile corenetwerk | T-Mobile Community

Router constant bezig met discoveren TV die ik niet afneem | T-Mobile Community

Die laatste is mogelijk meer vervelend dan echt een probleem, maar mijn modem wordt er wel langzamer van en de logs worden onleesbaar.

 

Vanmiddag had ik gedurende 2 uur weer incidentele haperingen, 34% packetloss over 10.10.12.53 en 350~400ms latency zodra ik langs T-mobile's 10.*.*.* reeks ga.

Adressen die op gvt2.com eindigen (Google clouddiensten) hebben standaard een latency van 300+ lijkt het, maar blijven soort van bereikbaar. Voor zover 3000MS en 30% packetloss bereikbaar te noemen is.

MS Teams probeert me regelmatig via de VS, Japan of Australië routen, met hapering, 140p video en walktie-talkie geluid tot gevolg. Zo te zien omdat de Europese Azure servers opeens niet meer bereikbaar zijn.

Externe DNS instellen lijkt te veroorzaken dat adressen van MS clouddiensten geheel niet bereikbaar zijn, wat het probleem erger maakt, want dan heb ik geen haperende/langzame verbinding, maar gewoon geen verbinding. Daaruit maak ik op dat T-mobile bekend is met het probleem en hun DNS servers dit probleem laat compenseren: DNS resolves op IP adressen die niet bereikbaar zijn worden gewoon niet teruggegeven en dan probeert Teams het opnieuw met als resultaat een server in timboektoe ofzo, want de weg daarheen heeft geen file?

Raarste probleem is wel dat In-home streaming uitvalt als ik een externe DNS gebruik en het modem een DHCP renew op de IPTV interface probeert te doen. Ik heb geen TV abo.

Dit verhaal is natuurlijk veel te lang, maar ik ben gefrustreerd en wanhopig aanknopingspunten aan het geven zodat iemand bij T-mobile iets herkent wat opgelost kan worden. Dat ik voor kwaliteit ergens anders moet zijn is me duidelijk, maar ik vraag niet om <5ms naar een willekeurige game-server in lutjebroek, maximale uploadsnelheid om 17.00, een modem dat koffie zet of een helpdeskmedewerker die me vraagt hoe het eigenlijk met me gaat vandaag!

Grote clouddiensten moeten (in de regel) gewoon bereikbaar zijn, modem/lijn config moet kloppen met de diensten die ik afneem en als ik bewijs lever dat iets niet werkt moet mijn ticket terug naar de TD i.p.v. afgesloten.

Voor de duidelijkheid, dit was hoe mijn laatste chat werd afgebroken, na ruim 25 minuten uitleggen dat ik last heb van routing issues.

Kirty (17-2-2022 11:43:35): Misschien kan je een topic openen op onze community. Daar zitten heel veel techneuten op, die iets meer verstand er van hebben Ik (17-2-2022 11:44:13): Doe ff normaal Kirty (17-2-2022 11:44:22): Hoezo? Ik (17-2-2022 11:44:37): Ik heb laten zien dat mijn verbinding een probleem heeft Ik (17-2-2022 11:44:57): Hoezo willen jullie niks meer doen Kirty (17-2-2022 11:44:59): en de technische dienst geeft aan dat er bij ons een storing was, die is opgelost Kirty (17-2-2022 11:45:25): En als jij issues hebt een eigen iptv Ik (17-2-2022 11:45:27): Ok, maar dat betekent toch niet dat ik geen storing mag melden Kirty (17-2-2022 11:45:31): Dat valt niet binnen ons domein Ik (17-2-2022 11:45:34): Ik heb geen iptv Kirty (17-2-2022 11:45:57): Maar ook als de DHCP op iptv Ik (17-2-2022 11:46:01): Mijn modem denk van wel, als dat een probleem is... wie lost dat op? Kirty (17-2-2022 11:46:08): Net zei je van wel Ik (17-2-2022 11:46:29): Nee, ik zei dat mijn modem iptv dhco request doetIk (17-2-2022 11:46:37): Lees het ticket dan! Ik (17-2-2022 11:46:42): Laat maar Kirty (17-2-2022 11:46:47): Oke! Kirty (17-2-2022 11:46:49): Fijne dag<Chat direct gesloten door medewerker>

This topic has been closed for comments

24 reacties

Reputatie 7

Hi @Kevin789 ,

Dank voor het delen van je gevoel en ervaring! Dit is natuurlijk niet de ervaring die wij voor ogen hebben. Ik denk daarbij graag met je mee. Nu zie ik dat je het bovenstaande probleem al hebt aangekaart in het volgende topic: 

Daarbij heeft mijn collega Jason de situatie zoals jij die hierboven al beschrijft doorgespeeld aan de technische dienst, waarbij we hard werken aan een directe oplossing. Ik wil graag dat onderzoek afwachten. Mocht het onverhoopt daarna nog niet gefixt zijn, lijkt het mij verstandig om te kijken naar de route die de verbinding aflegt met een MTR of traceroute. Hoe je deze precies uitvoert, vind je in dit filmpje: 

 

... Nu zie ik dat je het bovenstaande probleem al hebt aangekaart... Mocht het onverhoopt daarna nog niet gefixt zijn..

 

Edit: ik zie dat het antwoord als ‘beste antwoord’ is aangemerkt door de moderator zelf en het topic als ‘beantwoord’ is gemarkeerd. Maar zelfs de IPTV DHCP requests gaan door in mijn modem, dus er is werkelijk niks veranderd en geen nieuwe informatie gegeven. Deze ‘community’ is gewoon een marketingtool om online klachten af te vangen, puur perceptiemanagement.

De kern van problemen die ik ervaar blijken na wat beter zoeken 
al jaren onveranderd, en worden nog altijd actief ontkend door moderators die het zelf ook niet snappen. T-mobile's interne netwerk is gewoon gammel en connecties naar buiten onbetrouwbaar. Voor 10% minder kosten dan bij de concurrent krijg je 20~30% minder van je pakketjes en 200% meer kopzorgen.

Beetje ironisch dat je net als je collega op de chat de indruk wekt dat er iets is opgelost, zonder iets te hebben gedaan. Ik gaf duidelijk aan geen behoefte te hebben aan overdreven vriendelijkheid, maar actie.

Al bij mijn eerste ticket in januari heb ik MTR logs (en latency logs van netwerkmonitor + logs van mijn modem) aangeleverd. Dit staat expliciet in mijn post, inclusief het IP van de zwakke schakel. Toen is mijn ticket gesloten onder het mom van een algemene storing.

 

Je reactie bevestigt het gevoel wat ik nu al weken heb, dat niemand bij T-mobile daadwerkelijk luistert of leest als ik uitleg wat het probleem is, maar gewoon op zoek gaat naar een standaardantwoord, als een soort veredelde bot.

En als het gevonden antwoord niet op mij van toepassing is, gaan we natuurlijk weer terug naar ‘Iemand anders heeft wel iets gedaan, straks zou het beter moeten zijn, wacht nog maar even’.

 

Voor de duidelijkheid, zo ziet het er op dit moment uit, jullie koppeling op amsix had initieel 2000ms nodig en heeft 3% packetloss? Om over 10.10.12.53 nog maar niet te spreken.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |  423 |  423 |    0 |    0 |  200 |    0 |
|        1-104-21-31.ftth.glasoperator.nl -    1 |  415 |  413 |   12 |   13 |  370 |   12 |
|                            10.10.10.253 -    1 |  415 |  413 |   11 |   12 |  370 |   12 |
|                             10.10.12.53 -   24 |  217 |  165 |    0 |   13 |  254 |   12 |
|         amsix-200gbps.core1.ams1.he.net -    3 |  388 |  379 |    0 |   36 | 2009 |   13 |
|         port-channel8.core3.lon2.he.net -    1 |  408 |  404 |   17 |   22 | 1297 |   17 |
|              100ge8-1.core1.lon2.he.net -    1 |  415 |  413 |   17 |   18 |  370 |   17 |
|              100ge4-1.core1.nyc4.he.net -    1 |  415 |  413 |   82 |   84 |  370 |   83 |
|              100ge8-1.core1.sjc2.he.net -    1 |  415 |  413 |  145 |  146 |  371 |  146 |
|               10ge4-4.core1.sjc1.he.net -    1 |  415 |  413 |  145 |  146 |  371 |  146 |
|vocus.gigabitethernet2-13.core1.sjc1.he.net -    2 |  400 |  394 |  145 |  145 |  371 |  146 |
|     be202.cor02.syd04.nsw.vocus.network -    1 |  415 |  413 |    0 |  296 |  297 |  297 |
|     be100.bdr01.syd01.nsw.vocus.network -    1 |  415 |  413 |    0 |  295 |  312 |  296 |
|                            49.255.92.74 -    1 |  415 |  413 |    0 |  285 |  290 |  286 |
|                           72.14.237.251 -    1 |  415 |  413 |    0 |  286 |  288 |  287 |
|                          216.239.42.172 -    1 |  415 |  413 |    0 |  286 |  287 |  286 |
|                   No response from host -  100 |   85 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   85 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   85 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   85 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   85 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   85 |    0 |    0 |    0 |    0 |    0 |
|  93.232.213.35.bc.googleusercontent.com -    1 |  411 |  408 |    0 |  286 |  287 |  286 |
|________________________________________________|______|______|______|______|______|______|

 

 

 

93.232.213.35.bc.googleusercontent.com a.k.a. 35.213.232.93 is niet echt een goed voorbeeld, dit IP-Adres behoort dan wel toe aan de Google Cloud diensten maar het behoort niet toe tot de CDN / Unicast die wereldwijd voor een lagere latency zorgt.

Een simpele check via Hirricane Electric’ Looking Glass maar ook die van OpenTransit laten zien dat een ping (latency) van meer dan 200ms niet meer dan normaal is.

Afhankelijk van het type cloud-service dat de betreffende partij heeft gekozen - met de daaraan verbonden kosten - kan het wel eens zijn dat dit de reden is van de hoge latency.

Ik had een spike van 2000ms naar AMS-IX

Packetloss op T-mobile's interne netwerk omdat ik niet Google's CDN gebruik maar een specifieke server lijkt me ook erg apart.

Eentje naar NOS.nl dan, met ping spikes van 373ms bij de eerste hop en 36% packetloss op 10.10.12.53

 

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |  115 |  115 |    0 |    0 |   61 |    0 |
|        1-104-21-31.ftth.glasoperator.nl -    1 |  111 |  110 |   12 |   15 |  373 |   12 |
|                            10.10.10.253 -    1 |  111 |  110 |   12 |   15 |  373 |   12 |
|                             10.10.12.53 -   36 |   48 |   31 |   12 |   25 |  373 |   12 |
|                 amsix01-ams1.amazon.com -    1 |  111 |  110 |   12 |   17 |  373 |   13 |
|                           52.93.113.175 -    1 |  111 |  110 |   13 |   17 |  374 |   13 |
|                           150.222.107.3 -    1 |  111 |  110 |   12 |   17 |  374 |   13 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|server-52-222-137-18.ams50.r.cloudfront.net -    2 |  107 |  105 |    0 |   13 |   14 |   13 |
|________________________________________________|______|______|______|______|______|______|
 

Reputatie 7

Hi @Kevin789 ,

Dank je wel voor je snelle terugkoppeling. Ik verbaas me over je bericht, hier op de Community doen we er alles aan om ieder van een fijne ervaring en tijd bij ons te voorzien. Daarbij zijn de voorbeelden die je in je eerste post aanhaalt grondig door ons netwerk-team gecheckt, waarbij metingen zijn gedaan en kenbaar is geworden dat dit niet bij ons domein lag. Dat neemt natuurlijk niet weg dat we jouw situatie individueel behandelen. Dat is samen met de bovenstaande gegevens toegevoegd in een onderzoek, gestart door mijn collega en wat samenspeelt met de problemen aangekaart in bovengenoemde topic. 

Wat betreft het ‘Beste Antwoord’ probeer ik geen suggestie te schetsen dat we een probleem hebben opgelost, bij lange na niet. Met het markeren van mijn antwoord heb ik alleen de tip en vraag onder aandacht bij de poster, in dit geval jou, willen brengen. Ik heb daarom nu het topic omgezet naar een conversatie, zodat deze suggestie terug wordt gedraaid.

Ik begrijp echt dat je zo snel mogelijk een oplossing probeert te vinden en help je daar graag bij. Ik heb de gegevens toegevoegd aan het onderzoek wat onlangs is geopend door mijn collega. 

Vorige week doodleuk via de mail weer hetzelfde verhaal, mailtje met als onderwerp [Ticket#2022022411011986] Goed nieuws! en enige inhoud '’ Goed nieuws: je vraag of verzoek waar we over gesproken hebben, is opgelost! Heb je toch nog vragen? Dan weet je ons te vinden”

Geen uitleg, geen mogelijkheid om direct te reageren op het probleem naar degene die het heeft ‘opgelost’.

Ik heb geen zin om wéér de riedel langs helpdeskmedewerkers zonder technische kennis te halen, extreem frustrerende ervaring op deze manier. Er is duidelijk wat veranderd/verbeterd namelijk, maar haperingen zijn niet opgelost. Ja, soms werkt mijn verbinding even perfect, maar ik heb nog geen werkdag zonder issues gehad sinds mijn overstap vanaf KPN, dus ‘Goed nieuws!’ is wel het laatste wat ik denk..

 

Ik heb nog steeds issues met het bereiken van o.a. Microsoft servers, bijvoorbeeld vrijdag naar 52.112.243.146. Nog steeds 350~400ms latency op de gateway van mijn modem en achtergelegen interne hops. T-mobile/Glasoperator DNS server reageert af en toe ook niet of heel slecht met latency van 4 cijfers.

Zodra ik uit de 10.*.*.* kom krijg zie ik packetloss, bijvoorbeeld op ams-ix.as13335.net als ik 1.1.1.1 probeer te bereiken, maar als ik naar 8.8.8.8 ga zie ik packetloss op de laatste interne hop (10.10.12.53). t-mobilethuis.ier01.amb.ntwk.msn.net wil ook niet meewerken als ik naar een 52.*.*.* adres moet.

En soms is het gewoon totaal onvoorspelbaar, zoals deze trace naar nos.nl met her en der packetloss + latency spikes van de gebruikelijke 12~16ms naar 400+:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |  364 |  364 |    0 |    4 |  412 |    0 |
|        1-104-21-31.ftth.glasoperator.nl -    5 |  305 |  290 |   11 |   13 |  372 |   12 |
|                            10.10.10.253 -    5 |  313 |  300 |   12 |   16 |  442 |   12 |
|                             10.10.12.53 -    5 |  305 |  290 |   12 |   13 |  372 |   12 |
|                             10.226.4.29 -    2 |  340 |  334 |   11 |   13 |  372 |   12 |
|                   No response from host -  100 |   74 |    0 |    0 |    0 |    0 |    0 |
|                            52.93.113.28 -    5 |  309 |  295 |   12 |   16 |  481 |   13 |
|                          150.222.107.11 -    2 |  348 |  344 |   12 |   16 |  468 |   13 |
|                   No response from host -  100 |   74 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   74 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   74 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   74 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   74 |    0 |    0 |    0 |    0 |    0 |
|server-52-222-137-99.ams50.r.cloudfront.net -    5 |  305 |  290 |    0 |   13 |  370 |   13 |
|________________________________________________|______|______|______|______|______|

 

 

Reputatie 7

Hi @Kevin789,

Dank je wel voor je terugkoppeling en heldere signaal. Graag leg ik nogmaals het probleem neer bij onze technische dienst, waarbij het probleem al eerder is doorgelopen. Bovenstaande bevindingen zijn na monitoring en een verwijdering van een discover namelijk niet terug te lezen door onze technische specialisten. Dat neemt niet weg dat jij problemen blijft ervaren en dat we daar graag bij helpen. Momenteel wacht ik daarbij nog op de terugkoppeling, maar houd ik je graag op de hoogte via dit topic wat de beste vervolgstap is. We houden contact.

De structurele problemen tijdens online-vergaderen waren afgelopen week geheel afwezig.

Latency is nog steed absurd bij het opzetten van een nieuwe verbinding (370~410 ms) dus de ‘snelheidservaring‘ blijft me irriteren. En ik zie mijn chat zo nu en dan nog offline gaan, heb packet loss op 10.10.12.53 (incidenteel juist niet op *53, maar op de hop direct erna c.q. exit node).

Ik vermoed zelf dat (de firewall van?) mijn Zyxel de situatie met routing via 10.*.*.* maar beetje eng vind, of externe systemen soms niet goed kunnen inschatten waar ik (fysiek) zit waardoor er vertraging ontstaat.

 

 

Reputatie 7

Duidelijk punt @Kevin789, thanks voor de opheldering. Om het beste beeld van de situatie te creëren, ben ik erg benieuwd of er nog externe factoren zijn waar wij rekening mee moeten houden. Denk daarbij aan een eigen firewall, een VPN die aanstaat of een anti-virus systeem die de verbinding kan ‘knijpen’. We zien vaker dat bovengenoemde factoren roet in het eten kunnen gooien. Ik hoor het nog graag van je! 

Nee, geen VPN, geen eigen firewall, m'n losse AP (OpenWRT, statisch IP en geen mesh o.i.d.) afkoppelen veranderd ook niks aan de situatie. 3 verschillende systemen laten allemaal hetzelfde gedrag zien.

Mijn HTPC is ‘barebones’ W10 home, enige wat daar op staat is een Ghostery-addon en snelkoppelingen naar Amazon Prime & Netflix. Onderstaande test is weliswaar over WiFi maar gedrag is gelijk aan andere systemen: packetloss op *53, initiële verbinding ~360ms latency:

Vanmiddag was het ook weer raak qua haperingen, paar minuten lang amper verbinding naar buiten op mijn werklaptop (bedraad):


Ik snap best dat alles uitgesloten moet worden, maar ik wordt er echt een beetje moe van steeds maar weer iets anders te moeten uitsluiten, om te bewijzen dat ik dezelfde soort problemen heb die andere klanten ook al jaren melden. Dit kost me veel te veel tijd terwijl ik helemaal geen bijzondere dingen doe of wil doen. Het mag toch wel duidelijk zijn dat de oorzaak ergens aan jullie kant zit?

Of het nu ligt aan de cheapo modems, bij elkaar geraapte netwerkinfra, support die nog geen USB stick zou kunnen aansluiten zonder belscript of gewoon slecht beheer, wat het precies is zal me een worst wezen, ik wil gewoon een stabiele verbinding, of anders ontbinding van m'n contract zodat ik naar een concurrent kan die z'n shit wel op orde heeft. Dit is niet werkbaar.

Edit: kijk eens, hier nog iemand, echt toevallig zeg, packetloss, hapering, modem wat overstuur lijkt te raken: 
Internet verbinding valt steeds weg | T-Mobile Community

Reputatie 7

Hi @Kevin789 ,

Dank voor je bericht. Ik begrijp je sentiment goed, ook ik wil dat je gewoon een werkende en stabiele verbinding ervaart. Omdat onze metingen het euvel niet kenbaar maken, is uitvraag in dit geval nodig. Zo kunnen we, samen met de fijne metingen die jij al hebt gedaan, bepalen waar het euvel zich wél bevindt. Ook begrijp ik dat je eerder meldingen ziet, waarbij we dezelfde uitvragen hebben gedaan om tot een oplossing te komen. Ik leg jouw situatie dan ook weer graag voor bij onze technische dienst en IT specialisten, waarbij we ook andere signalen die wellicht overeenkomen met jouw situatie, meenemen. Ik houd je daarvan graag via deze weg op de hoogte. Mocht je in de tussentijd vragen hebben, laat het vooral weten. 

Uitvragen is niet het probleem, maar dat er dik 2 maanden, tig contactmomenten en een vrijwillige registratie op dit forum nodig is om überhaupt gehoord te worden stoort me!

Ik ervaar het hele communicatieproces als zeer onprofessioneel; support lijkt ontworpen om zo snel mogelijk het vinkje ‘opgelost’ te kunnen zetten in plaats van problemen echt op te lossen. Dit topic moest bijvoorbeeld als discussie gemarkeerd worden, anders kon je niet reageren op mijn vraag zonder te doen voorkomen er een oplossing was!

Bij nagenoeg elk groot bedrijf kan je (eventueel na het melden van de storing via de telefoon) via email contact onderhouden over een ticket. Meestal krijg je dan ook bij elke stap gestructureerde vragen die gedegen analyse mogelijk maken. Maar bij T-mobile moet ik alles zelf opzoeken, steeds weer klagen, tig keer dezelfde vragen op een andere manier beantwoorden.

Klanten die minder assertief en/of minder digitaal vaardig zijn, kunnen op zo'n manier gewoon geen degelijke support krijgen als ze met een (technisch) complex probleem zitten. De drempel is absurd hoog.

Als ik niet kan vertrouwen op het process, moet ik kunnen vertrouwen op de persoon. Maar door steeds de overduidelijke kromme gang van zaken te rechtvaardigen en excuseren, lukt dat ook niet meer.

Dus, fuck het ‘sentiment’, beperk je bij antwoorden tot de relevante feiten & pak het probleem aan. Slaapt iedereen beter van.

18 dagen verder, niks gehoord.

Terug van vakantie, eerste meeting vanmiddag...  En de verbinding naar zowel Google als MS clouddiensten hapert als de pest, nog altijd geen verlies van lokaal netwerk of dsl sync, lijkt weer dezelfde shit ergens in die vage 10.* range waar het als sinds januari fout gaat.

Totaal onmogelijk om een videovergadering te houden, haperingen van meerdere seconden om de paar minuten, hierbij een stukje latency log ter onderbouwing:

Source Address	Destination Address	Source Host Name	Destination Host Name	Average	First Latency Time	Last Latency Time	Failed Count	1	2	3	4	5	6	7	8	9 10	
192.168.1.144 142.250.179.142 DESKTOP-EB3A107.home plus.l.google.com 12 ms 05/04/2022 14:38:56 05/04/2022 14:51:19 12 ms 12 ms
192.168.1.144 142.251.39.106 DESKTOP-EB3A107.home addons-pa.clients6.google.com 15 ms 05/04/2022 14:22:31 05/04/2022 14:51:19 20 ms 12 ms 12 ms
192.168.1.144 142.250.179.165 DESKTOP-EB3A107.home googlemail.l.google.com 12 ms 05/04/2022 14:42:19 05/04/2022 14:51:19 12 ms 12 ms 12 ms 12 ms 12 ms
192.168.1.144 142.250.179.206 DESKTOP-EB3A107.home clients.l.google.com 12 ms 05/04/2022 14:22:29 05/04/2022 14:51:19 12 ms 12 ms
192.168.1.144 142.250.179.202 DESKTOP-EB3A107.home chat-pa.clients6.google.com 13 ms 05/04/2022 14:22:05 05/04/2022 14:51:19 13 ms 13 ms 12 ms
192.168.1.144 172.217.168.202 DESKTOP-EB3A107.home people-pa.clients6.google.com 1017 ms 05/04/2022 14:34:19 05/04/2022 14:51:19 19 ms 12 ms 3023 ms * * 3025 ms 12 ms 12 ms
192.168.1.144 142.251.39.110 DESKTOP-EB3A107.home www3.l.google.com 3019 ms 05/04/2022 14:22:06 05/04/2022 14:51:18 15046 ms * * * * * 12 ms 12 ms 15 ms 12 ms
192.168.1.144 142.250.179.163 DESKTOP-EB3A107.home ssl.gstatic.com 13 ms 05/04/2022 14:34:27 05/04/2022 14:51:16 14 ms 12 ms
192.168.1.144 172.217.168.197 DESKTOP-EB3A107.home gmail.com 12 ms 05/04/2022 14:51:16 05/04/2022 14:51:16 12 ms
192.168.1.144 204.79.197.219 DESKTOP-EB3A107.home a-0016.a-msedge.net 116 ms 05/04/2022 14:51:09 05/04/2022 14:51:13 16 ms 21 ms 414 ms 13 ms
192.168.1.144 199.232.150.132 DESKTOP-EB3A107.home outbrain.map.fastly.net 12 ms 05/04/2022 14:51:11 05/04/2022 14:51:11 12 ms
192.168.1.144 13.107.21.200 DESKTOP-EB3A107.home dual-a-0001.a-msedge.net 213 ms 05/04/2022 14:44:25 05/04/2022 14:51:11 13 ms 13 ms 413 ms 412 ms

                        
Van 12ms naar 4x geen reactie en dan 15046 ms bij Google. Van 12ms naar 412 ms bij Microsoft in dit geval. Is er al een oplossing?

Ik voorspel: dat ticket is nooit geopend sorry, er is niks gebeurd bij techniek volgens hen was het al opgelost, oeps sorry we proberen het weer, was echt niet de bedoeling, hoop dat je lekker hebt geslapen, we zijn hier om je te helpen!

Weer de hele dag hetzelfde probleem. Uit wanhoop maar Wireshark aangezet, tijdens een hapering gebeurde er dit (packets komen out-of-order?)

2178915    14318.217781    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178916    14318.217897    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=204042 Win=262656 Len=0
2178917    14318.218011    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178918    14318.218011    216.58.214.5    192.168.1.144    TLSv1.3    798    Application Data
2178919    14318.218066    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=206216 Win=262656 Len=0
2178920    14318.224020    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178921    14318.224020    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178922    14318.224020    216.58.214.5    192.168.1.144    TLSv1.3    1211    Application Data
2178923    14318.224174    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=210233 Win=262656 Len=0
2178924    14318.226754    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178925    14318.226924    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=211663 Win=262656 Len=0
2178926    14318.227059    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178927    14318.227059    216.58.214.5    192.168.1.144    TLSv1.3    1232    Application Data
2178928    14318.227143    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=214271 Win=262656 Len=0
2178929    14318.229728    216.58.214.5    192.168.1.144    TLSv1.3    906    [TCP Previous segment not captured] , Application Data
2178930    14318.229866    192.168.1.144    216.58.214.5    TCP    66    [TCP Dup ACK 2178928#1] 61712 → 443 [ACK] Seq=520024 Ack=214271 Win=262656 Len=0 SLE=217131 SRE=217983
2178931    14318.230033    216.58.214.5    192.168.1.144    TCP    1484    [TCP Out-Of-Order] 443 → 61712 [PSH, ACK] Seq=214271 Ack=520024 Win=1145088 Len=1430
2178932    14318.230033    216.58.214.5    192.168.1.144    TCP    1484    [TCP Out-Of-Order] 443 → 61712 [ACK] Seq=215701 Ack=520024 Win=1145088 Len=1430
2178933    14318.230160    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=217983 Win=262656 Len=0
2178934    14318.235279    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178935    14318.235279    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178936    14318.235414    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=220843 Win=262656 Len=0
2178937    14318.235533    216.58.214.5    192.168.1.144    TLSv1.3    1261    Application Data
2178938    14318.238295    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178939    14318.238435    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=223480 Win=262656 Len=0
2178940    14318.238507    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178941    14318.238507    216.58.214.5    192.168.1.144    TLSv1.3    264    Application Data
2178942    14318.238566    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=225120 Win=262656 Len=0
2178943    14318.241028    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178944    14318.241381    216.58.214.5    192.168.1.144    TLSv1.3    1484    Application Data
2178945    14318.241381    216.58.214.5    192.168.1.144    TLSv1.3    517    Application Data
2178946    14318.241381    216.58.214.5    192.168.1.144    TLSv1.3    321    Application Data
2178947    14318.241381    216.58.214.5    192.168.1.144    TLSv1.3    272    Application Data, Application Data
2178948    14318.241503    192.168.1.144    216.58.214.5    TCP    54    61712 → 443 [ACK] Seq=520024 Ack=228928 Win=262656 Len=0
2178949    14318.242988    192.168.1.144    216.58.214.5    TLSv1.3    93    Application Data
2178950    14318.260104    216.58.214.5    192.168.1.144    TCP    60    443 → 61712 [ACK] Seq=228928 Ack=520063 Win=1145088 Len=0

En hier ging het fout tijdens een Teams meeting, want NAT is natuurlijk geen oplossing om je klanten bereikbaar te houden:

416605    2022-04-06 13:40:38,746325    52.112.221.46    192.168.1.144    STUN    114    Binding Success Response XOR-MAPPED-ADDRESS: 31.21.111.47:55673

 

416638    2022-04-06 13:40:38,774737    52.112.221.46    192.168.1.144    RTCP    142    Sender Report   ([Malformed Packet]

416743    2022-04-06 13:40:39,011330    192.168.1.144    52.112.221.46    RTCP    94    Receiver Report   Generic RTP Feedback   [Malformed Packet]

416833    2022-04-06 13:40:39,170430    52.112.221.46    192.168.1.144    RTCP    218    Sender Report   (PSE:Unknown  [Malformed Packet]

616305    2022-04-06 13:48:09,998293    52.112.221.46    192.168.1.144    RTCP    122    Receiver Report   (PSE:Unknown  PSE:Unknown  PSE:Unknown  PSE:Unknown  [Malformed Packet]

 

en deze:

616160    2022-04-06 13:48:09,656921    23.208.77.7    192.168.1.144    TCP    1514    443 → 60890 [ACK] Seq=342285 Ack=131049 Win=195968 Len=1460 [TCP segment of a reassembled PDU]
616161    2022-04-06 13:48:09,656921    23.208.77.7    192.168.1.144    TLSv1.3    503    Application Data
616162    2022-04-06 13:48:09,656976    192.168.1.144    23.208.77.7    TCP    54    60890 → 443 [ACK] Seq=131049 Ack=344194 Win=262656 Len=0
616170    2022-04-06 13:48:09,665621    23.208.77.7    192.168.1.144    TCP    503    [TCP Spurious Retransmission] 443 → 60890 [PSH, ACK] Seq=343745 Ack=131049 Win=195968 Len=449
616171    2022-04-06 13:48:09,665650    192.168.1.144    23.208.77.7    TCP    66    [TCP Dup ACK 616162#1] 60890 → 443 [ACK] Seq=131049 Ack=344194 Win=262656 Len=0 SLE=343745 SRE=344194

Reputatie 7

Hi @Kevin789 ,

Dank voor je update; ik zal meteen ook direct een update geven vanaf onze kant. We hebben een onderzoek laten openen bij ons netwerk team om de route en daarbij ook de wegvallende verbinding te reproduceren. Momenteel staat het onderzoek nog steeds open, omdat dit nog niet reproduceerbaar lijkt te zijn. Mijn welgemeende excuses. Ik heb hierop direct opnieuw gevraagd om zo snel mogelijk tot een oplossing te komen. Ik houd je op de hoogte.

Edit: Wireshark geeft me een lijst met meerdere STUN requests per seconden die niet worden beantwoord. Zie ws dump - Google Spreadsheets

Net weer 2x uitval en een hapering tijdens een Teams meeting. Meerdere servers zijn opeens niet meer bereikbaar of met extreme vertraging:

Destination Address    Average    Last Latency Time    Failed Count    1    2    3    4    5    6    
52.113.203.142    7542 ms    08/04/2022 11:15:54        21ms    21ms    15067ms    15060ms
216.239.32.116    4694 ms    08/04/2022 11:26:16        7037ms    7034ms    12ms                
142.250.179.131  1768 ms    08/04/2022 11:27:20        7028ms    7032ms  12ms  12ms 12ms

142.251.36.46    347 ms    08/04/2022 11:27:24        12ms    12ms  12ms  *  1018ms 1018ms

40.79.189.59    240 ms    08/04/2022 11:18:02        240ms    240ms                    
13.78.111.198    238 ms    08/04/2022 11:22:44        239 ms    237 ms                    
40.74.98.195    235 ms    08/04/2022 11:15:56        234 ms    234 ms    236 ms                
35.206.80.10    123 ms    08/04/2022 11:20:29        123 ms                        
13.89.178.26    123 ms    08/04/2022 11:14:18        119ms    124ms    125ms    125ms    *        

Modemlog geeft me rond het moment van verstoring de volgende security meldingen, waardoor ik vermoed dat gedwongen NATten over eindpunt 31.21.111.47 c.q. [47-111-21-31.ftth.glasoperator.nl] in jullie core netwerk het probleem is! (wireshark logging laat retransmission, malformed & out-of-order paketten zien nadat er een er een “Binding Success Response XOR-MAPPED-ADDRESS: 31.21.111.47:55673” voorkomt.)

 

1 Apr 8 11:25:18 kern alert attack kernel: IN=nas8_1 OUT= MAC=5c:64:8e:6d:01:74:00:02:00:00:00:03:08:00 SRC=52.114.248.56 DST=31.21.111.47 LEN=36 TOS=0x00 PREC=0x00 TTL=114 ID=41074 PROTO=UDP SPT=3478 DPT=3478 LEN=16
2 Apr 8 11:15:15 kern alert attack kernel: IN=nas8_1 OUT= MAC=5c:64:8e:6d:01:74:00:02:00:00:00:03:08:00 SRC=165.225.240.107 DST=31.21.111.47 LEN=140 TOS=0x18 PREC=0xA0 TTL=123 ID=20405 PROTO=UDP SPT=42229 DPT=59288 LEN=120
3 Apr 8 11:01:16 kern alert attack kernel: IN=nas8_1 OUT= MAC=5c:64:8e:6d:01:74:00:02:00:00:00:03:08:00 SRC=52.114.89.94 DST=31.21.111.47 LEN=36 TOS=0x00 PREC=0x00 TTL=116 ID=64224 PROTO=UDP SPT=3478 DPT=3478 LEN=16

 

Modemlog geeft me rond het moment van verstoring de volgende security meldingen, waardoor ik vermoed dat gedwongen NATten over eindpunt 31.21.111.47 c.q. [47-111-21-31.ftth.glasoperator.nl] in jullie core netwerk het probleem is!

Komt dit IP-Adres niet toevallig overeen met wat je ziet op Wat is mijn IP? Voor zover weet is het genoemde IP-Adres gewoon een customer IP wat betekent dat het IP-Adres mogelijk aan jou uitgedeeld via DHCP.

Ook de seucirty logs tonen genoemd IP-Adres wat inhoud dat dit het door jou gebruikte IP-Adres is. De meldingen lijken in te houden dat de firewall het verkeer tussen jou en de ander wordt geblokkeerd.

Die 1e en 3e regel in je log;

3 Apr 8 11:01:16 kern alert

attack

kernel: IN=nas8_1 OUT= MAC=5c:64:8e:6d:01:74:00:02:00:00:00:03:08:00 SRC=52.114.89.94 DST=31.21.111.47 LEN=36 TOS=0x00 PREC=0x00 TTL=116 ID=64224 PROTO=UDP SPT=3478 DPT=3478 LEN=16


Hier wordt Microsoft Teams, die gebruik maakt van poort 3478 geblokkeerd.

31.21.111.47 is inderdaad mijn eigen WAN ip!

Niet dat die info helpt natuurlijk. Heb ik nog steeds geen controle over :/

31.21.111.47 is inderdaad mijn eigen WAN ip!

Niet dat die info helpt natuurlijk. Heb ik nog steeds geen controle over :/

Over die meldingen heb je in dit geval wel controle, de meldingen zeggen dat Microsoft Teams geen verbinding kan maken en dat deze wordt tegengehouden door de Firewall in het modem. Als je dus de Firewall of minder strikt zet of een port-forwarding instelt naar de computer/laptop waarop Teams draait, dan zou die melding moeten verdwijnen.

Source (52.114.89.94 (port 3478)) naar Destination (31.21.111.47 (port 3478)) wordt tegengehouden.

Kijkende in de handleiding van de Zyxel T50 klopt dit ook wel;

Iedere andere service die wel functioneert buiten de genoemde services, is mooi meegenomen maar kan dus worden geblokkeerd.

 

31.21.111.47 is inderdaad mijn eigen WAN ip!

Niet dat die info helpt natuurlijk. Heb ik nog steeds geen controle over :/

Over die meldingen heb je in dit geval wel controle, de meldingen zeggen dat Microsoft Teams geen verbinding kan maken en dat deze wordt tegengehouden door de Firewall in het modem. Als je dus de Firewall of minder strikt zet of een port-forwarding instelt naar de computer/laptop waarop Teams draait, dan zou die melding moeten verdwijnen.

Source (52.114.89.94 (port 3478)) naar Destination (31.21.111.47 (port 3478)) wordt tegengehouden.

Kijkende in de handleiding van de Zyxel T50 klopt dit ook wel;

Iedere andere service die wel functioneert buiten de genoemde services, is mooi meegenomen maar kan dus worden geblokkeerd.

 

Ik snap dat je probeert te helpen, maar je doet aannames die niet kloppen. 

  1. Modemfirewall staat op Medium, default settings vanuit T-mobile
  2. UPnP (incl. Nat-t) staat gewoon aan, default settings vanuit T-mobile
  3. Issue is niet alleen aanwezig bij Teams, maar ook bij Meet, Parsec en Citrix VDI
  4. 2 gebruikers in huis moeten Teams gelijktijdig kunnen gebruiken EN incidenteel werk ik via wireless i.p.v. kabel; Teams moet werken op 3 interne IP's.

Daar komt nog bij dat

  1. Dit probleemloos werkte bij de concurrent.
  2. Afgelopen week opeens veel erger is, terwijl het 2 weken geleden opeens opgelost leek.
  3. Er zijn ook verstoringen waarbij er geen meldingen in het security log verschijnen (dus niet oorzakelijk, maar correlatie of symptoom: hapering triggert de firewall i.p.v. andersom,maar totaal verlies verbinding komt door firewall)
  4. Mijn probleem ook kan ontstaan als T-mobile teveel mensen achter hetzelfde externe IP zet op een ander punt in de routing, of een van de nodes te vaak van route wisselt en/of overbelast is; 10.10.12.53 geeft mij nog altijd packtloss bij ping en hoge responstijden.

Als het iemand helpt; ik heb hier exact dezelfde problemen zoals hierboven beschreven. In dit geval probeer ik www.ubuntu.com te bereiken. Deze website is via t-mobile glasvezel niet bereikbaar. De domeinnaam resolved naar verschillende IP adressen, bijvoorbeeld: 185.125.190.21, of 185.125.190.29.
Een beetje afhankelijk welk IP adres er wordt gebruikt is het probleem groter of kleiner, maar het resultaat is eigenlijk altijd wel dat de website onbereikbaar is.

Zie bijvoorbeeld: mtr 185.125.190.29
 

Host                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev

1. 192.168.1.252                                           0.0%    27    0.5   0.5   0.4   0.6   0.0

2. 1-224-178-143.ftth.glasoperator.nl                      0.0%    26    2.6   2.3   2.0   2.6   0.0

3. 10.10.10.170                                            0.0%    26    3.8   3.9   3.4   4.6   0.0

    10.10.10.174

4. amsix-200gbps.core1.ams1.he.net                         0.0%    26   27.4  69.2   3.8 291.5  82.4

5. amsix-200gbps.core1.ams1.he.net                         7.7%    26    3.5  45.8   3.5 266.7  69.4

6. port-channel8.core3.lon2.he.net                        36.0%    26   13.5  10.4   9.4  14.2   1.3

7. ve958.core2.lon2.he.net                                 0.0%    26   10.2  11.4  10.1  39.3   5.6

8. port-channel1.core1.lon6.he.net                         0.0%    26   11.0  11.2  10.7  11.4   0.0

9. swp9.il3-core1.canonical.com                            0.0%    26    9.3   9.4   9.3  10.0   0.0

10. website-content-cache-3.canonical.com                   0.0%    26   14.1  14.2  14.1  14.6   0.0

Verder klagen mijn huisgenoten inderdaad ook dat verbindingen naar grote sites, bijvoorbeeld de thuiswerk servers van de gemeente Amsterdam, niet bereikbaar zijn. Er is een ticket aangemaakt met nummer: Ticket#2022041211001256 en ik heb met iemand van de helpdesk gesproken. Daar kreeg ik niet de indruk dat ze mijn probleem herkenden… :-/

Je bent niet de enige met dit probleem!

27 dagen geleden de laatste update, niks gebeurd...

Hi @Kevin789 ,

Dank voor je update; ik zal meteen ook direct een update geven vanaf onze kant. We hebben een onderzoek laten openen bij ons netwerk team om de route en daarbij ook de wegvallende verbinding te reproduceren. Momenteel staat het onderzoek nog steeds open, omdat dit nog niet reproduceerbaar lijkt te zijn. Mijn welgemeende excuses. Ik heb hierop direct opnieuw gevraagd om zo snel mogelijk tot een oplossing te komen. Ik houd je op de hoogte.

 

Ter referentie nog maar wat topics met nagenoeg hetzelfde probleem als ik heb:

Traag DSL internet en hoge latency | T-Mobile Community

Poste.it | T-Mobile Community

Relatief hoge ping glasvezel | T-Mobile Community (heerlijk bullshit antwoord weer, alsof het niet duidelijk is waar de oorzaak zit!)

Packetloss / nextdns? | T-Mobile Community

 

Inmiddels bevestigd via Azure Latency Test - Azure Speed Test dat het issue reproduceerbaar is. Om de zoveel dagen verandert er even wat, maar in de praktijk blijft het issues geven. Thuiswerken met een vaste T-mobile verbinding is de beste reclame die Ka-Pee-eN zich kan wensen.

Ohja, bijna vergeten te vragen, wanneer komt er een oplossing? 🙄

Weer een maand verder, weer geen update. Kon vanochtend niet bij de Azure.com portal komen. 35% packetloss op 10.10.12.53 en nog meer shit daarna.

Nos.nl deed het op dat moment perfect en een paar minuten later werkte de portal weer, dus issue zit niet bij mij lokaal. Geen storingsmelding van azure portal.

 

Moet ik bellen? Ophouden met betalen? Wat kan ik nog doen om aandacht te krijgen voor mijn internetissues?