Haperende internetverbinding, routing issues en IPTV VLAN zonder TV abo
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:
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>
Bladzijde 1 / 1
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.
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
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+:
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.
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.
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?)
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
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. s47-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.)
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.
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.
Modemfirewall staat op Medium, default settings vanuit T-mobile
UPnP (incl. Nat-t) staat gewoon aan, default settings vanuit T-mobile
Issue is niet alleen aanwezig bij Teams, maar ook bij Meet, Parsec en Citrix VDI
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
Dit probleemloos werkte bij de concurrent.
Afgelopen week opeens veel erger is, terwijl het 2 weken geleden opeens opgelost leek.
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)
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.
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:
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?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Bestand scannen voor virussen
Sorry, we zijn de inhoud van dit bestand nog aan het controleren om er zeker van te zijn dat het veilig is om te downloaden. Probeer het nog een keer over een paar minuten.
