Problemen met dns resolving interne (tmobile) ipadressen
Hoi T-Mobile en gebruikers,
wij zijn sinds een aantal weken klant bij t-mobile thuis, maar ik kan momenteel echt niet zeggen dat we tevreden zijn over het internet. verre van zelfs. we staan eigenlijk op het punt ziggo zakelijk internet weer (tijdelijk) terug te nemen en tmobile voor thuis maar even te parkeren..:
Met regelmaat is de verbinding slecht, en met slecht bedoel ik dan, “even” geen verbinding. Het gaat hier om een aantal seconden per x minuten, en is dus niet continue. Ik ben op onderzoek uit gegaan, en daaruit is gebleken dat het probleem zit 1 van de interne (10.x) ipadressen van T-Mobile?!
Ik heb op deze ‘brakke’ momenten een aantal keer tracert gedaan, en daaruit komt steeds weer naar voren dat ik regelmatig timeouts heb in de aanvragen.
url word aangevraagd door mijn gateway (usg) > stuurt het vervolgens netjes door naar glasoperator > glasoperator stuurt het naar de 10.x ipadressen > en dan begint de ellende en gaat het dan ook regelmatig fout.
Trace tijdens een wegvallende verbinding:
tracert google.nl
Tracing route to google.nl g142.251.39.3] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Gateway t192.168.1.1] 2 2 ms 2 ms 2 ms x.ftth.glasoperator.nl 87.210.136.1] 3 7 ms 7 ms 7 ms 10.10.12.45 4 * * * Request timed out. 5 7 ms 7 ms 7 ms 10.226.4.58 6 37 ms 21 ms 16 ms 108.170.241.236 7 6 ms 6 ms 6 ms 72.14.209.208 8 7 ms 7 ms 7 ms 108.170.241.225 9 6 ms 6 ms 7 ms 108.170.241.236 10 8 ms 8 ms 8 ms 142.251.237.172 11 13 ms 13 ms 13 ms 142.251.237.185 12 26 ms 26 ms 26 ms 216.239.43.208 13 27 ms 27 ms 26 ms 74.125.242.225 14 25 ms 25 ms 25 ms 142.251.228.23 15 26 ms 26 ms 26 ms bud02s37-in-f3.1e100.net 2142.251.39.3]
Trace tijdens een “normale” verbinding:
1 <1 ms <1 ms <1 ms Gateway e192.168.1.1] 2 2 ms 2 ms 2 ms x.ftth.glasoperator.nl r87.210.136.1] 3 7 ms 7 ms 7 ms 10.10.12.45 4 8 ms 7 ms 7 ms 10.226.4.54 5 7 ms 7 ms 7 ms 10.226.4.58 6 6 ms 6 ms 6 ms 172.253.71.201 7 6 ms 7 ms 7 ms 72.14.209.42 8 7 ms 7 ms 7 ms 142.251.70.129 9 6 ms 6 ms 6 ms 172.253.71.201 10 6 ms 6 ms 6 ms ams15s44-in-f3.1e100.net 142.251.36.3]
(PS, heb mijn hostname even vervangen voor een x)
Uiteraard is het probleem niet alleen op deze (geteste) windows pc, maar gaat het hier om het gehele internet in huis. Voorheen dus 12 jaar lang ziggo zakelijk gehad met een vast ipadres, en daar ervaarde ik nooit deze problemen. Het moet dus ergens zitten in dat interne 10.x netwerk van t-mobile.
Tevens heb ik hier een lokale “uptime” server lopen dat continue, 24/7 een ping uitvoert op diverse dns servers/url's, en ook daarin zie ik met grote regelmaat korte time-outs. Een leek zal dit wellicht niet opvallen, maar in mijn geval is de verbinding hinderlijk en heb ik (en ons huis) daar last van.
Oja, ik gebruik een unifi gateway (dus niet het modem van tmobile) direct achter de converter, maar zoals je wellicht kunt lezen heb ik intern geen problemen, en met het internet zelf ook niet, maar gaat het pas fout NA de aanvraag vanaf glasoperator.nl richting de 10.x adressen, oftewel in het interne netwerk van t-mobile..
Wellicht hebben meer mensen dit soort problemen, en/of kan dit hiermee opgelost worden?
De servers(s) waarom het gaat zijn: 10.10.12.45, 10.226.4.54 en 10.226.4.58, misschien goed om deze eens onder de loep te nemen?
Deze hebben tevens ook een enorm lange werking om de aanvragen te realiseren? glasoperator doet het perfect binnen 1/2ms, maar daarna is het wachten op die 10.x. adressen wat (volgens mij dan weer) zorgt voor een brakke verbinding.
Ik hoop dat dit serieus word genomen en dat er wat aan gedaan kan worden want dit is niet fijn!
Bladzijde 1 / 1
Met regelmaat is de verbinding slecht, en met slecht bedoel ik dan, “even” geen verbinding. Het gaat hier om een aantal seconden per x minuten, en is dus niet continue. Ik ben op onderzoek uit gegaan, en daaruit is gebleken dat het probleem zit 1 van de interne (10.x) ipadressen van T-Mobile?!
Waar maak je uit op dat er “even” geen verbinding is?
De 10.x reeks is een lokale reeks waarbij rate-limit wordt toegepast. Hierdoor kunnen pakketjes worden gefilterd, vaak wordt dit filteren door de router gedaan aan de hand van hoe druk het is. Als ik een tracert doe, zie ik in principe alles voorbij komen maar in de echt drukke uurtjes zie ik vaak zat z.g.n. timeouts optreden. Dat betekent overigens nog niet dat de router instabiel of onbereikbaar is maar gewoon de pakketjes voor traceroute en ping verzoeken weigert. Er zijn tenslotte wel belangrijkere dingen dan ping of traceroute data te verwerken.
Tevens heb ik hier een lokale “uptime” server lopen dat continue, 24/7 een ping uitvoert op diverse dns servers/url's, en ook daarin zie ik met grote regelmaat korte time-outs.
Tracert is eigenlijk onbetrouwbaar, waarom? Het toont niet of iets wat zich bevind in de tussenliggende route daadwerkelijk offline is of niet. Wanneer je een tracert wilt doen kan je beter inloggen op je USG (admin@192.168.1.1) en je admin wachtwoord gebruiken (moet overigens wel ingeschakeld zijn in je controller), doe vanaf hier een mtr naar bijvoorbeeld 142.251.36.3, dus;
mtr 142.251.36.3
Je zult zien dat de hier getoonde resultaten een heel stuk betrouwbaarder zijn, maar ook dan geld nog steeds… zolang alle verzonden en ontvangen pakketjes bij de 1e en laatste hop overeenkomen, is er in principe helemaal niets aan de hand.
Een leek zal dit wellicht niet opvallen, maar in mijn geval is de verbinding hinderlijk en heb ik (en ons huis) daar last van.
Wat mooi leesvoer over ping en tracert? Je vind het o.a. op; Netbrain en Sonic.
Hoi Gerrit,
bedankt voor je reactie! Wat ik ervaar is een onnozele onstabiele verbinding, en dat haal ik uit alles:
ping tijden varierend van 1ms tot 580ms, en zelfs time-outs. zodra er iemand in huis naar een website surft, word de aanvraag www.website.nl gedaan (in bijvoorbeeld de chrome browser, maar het maakt uit waar of hoe want de dns aanvragen blijven hetzelfde).
men krijgt dan een tijdje een wit scherm te zien en staat er ook letterlijk: wachten op www.website.nl en duurt het soms wel 20/30 seconden voordat een site op je scherm staat. tijdens deze aanvragen kan je makkelijk even een tracert uitvoeren, en zie je dus de timeouts op 1 van de servers. let wel, het is niet continue zo, vaak staat de site er keurig op tijd, maar ook regelmatig dus niet, en hangt het internet een tijdje (zo lijkt het). Ik heb hier overigens ook nog een wifi-lijntje van de buurman welke ik gebruik om dns aanvragen te volgen middels traceroutes omdat ik een aantal servers beheer en kijk welke dns de aanvragen het snelst update na een wijziging. wat mij als eerste hierin opvalt is dat de aanvragen via tmobile vaak met een verschrikkelijke omweg geleid worden terwijl deze zelfde aanvraag via mijn buurman (ziggo) er meestal al met 2 tot 4 hops zijn. dit in tegenstelling tot tmobile waar er alleen al 3x 10.x adressen zijn met lange latency (7/8+ms) voordat de route uberhaubt verder gaat... er zit bij tmobile ergens gewoon iets niet lekker, en of ik dat nou met tracert doe of met de traceroute,of wat dan ook maakt in dit geval weinig uit, de route blijft op x aanvraag hetzelfde..
Ps, ik weet dat tracert niet heel betrouwbaar is om dit soort problemen te tackelen, maar ergens moet dat probleem zitten, en dat probleem zit niet hier in huis want heb deze setup inmiddels 7 jaar draaien en werkte met ziggo (zakelijk/statisch ip) altijd perfect, echter na de komst van tmobile begonnen de probleempjes.. Enige wat er verandert is in de setup is de wan zijde: een vlan 300 tag en de dhcp ipv een statisch ip, voor de rest helemaal niets.
Ik ben inmiddels even de mtr (mytraceroute) aan het uitvoeren, just in case…
Toch bijzonder dat meer mensen over hetzelfde probleem klagen zodra ik iets over een instabiel t-mobile probeer te googlen… Okay?
maar het maakt uit waar of hoe want de dns aanvragen blijven hetzelfde)
Zou je anders eens willen checken of het resultaat het zelfde is als je de dns-servers verander? Eventueel goede alternatieve zijn 9.9.9.9 in combinatie met 1.1.1.1
Het probleem die je omschrijft herken ik trouwens niet, misschien dat genoemde dns-servers verbetering brengen? Zelf gebruik ik al een aardig lange tijd Pi-Hole → Bind9 waarbij de Pi-Hole alles filtert, en Bind9 lokale TLD's afhandelen en vervolgens alles wat onbekend is direct via de root-servers resolven.
Ik heb hier overigens ook nog een wifi-lijntje van de buurman welke ik gebruik om dns aanvragen te volgen middels traceroutes omdat ik een aantal servers beheer en kijk welke dns de aanvragen het snelst update na een wijziging.
Voor een bepaalde wijziging gewoon de TTL niet te hoog zetten, 300 of 900sec.
Heb je een paar voorbeelden qua domeinnamen? Misschien kan ik hier ook eens kijken.
Toch bijzonder dat meer mensen over hetzelfde probleem klagen zodra ik iets over een instabiel t-mobile probeer te googlen… Okay?
De berichten die je aanhaalt zijn ook zelfs binnen zeer korte tijd teruggedraaid. In de DTAG-periode was het internet helemaal niet vooruit te branden en liep alles over Duitsland. Het issue die je aanhaalt is hierom niet te vergelijken met het DTAG-debacle.
maar het maakt uit waar of hoe want de dns aanvragen blijven hetzelfde)
Zou je anders eens willen checken of het resultaat het zelfde is als je de dns-servers verander? Eventueel goede alternatieve zijn 9.9.9.9 in combinatie met 1.1.1.1
Het probleem die je omschrijft herken ik trouwens niet, misschien dat genoemde dns-servers verbetering brengen? Zelf gebruik ik al een aardig lange tijd Pi-Hole → Bind9 waarbij de Pi-Hole alles filtert, en Bind9 lokale TLD's afhandelen en vervolgens alles wat onbekend is direct via de root-servers resolven.
Goed antwoord! Ik gebruik in de WAN al de dns van google (8.8.8.8) en die van CF (1.1.1.1) Daarnaast had ik AdGuard altijd lopen, maar die heb ik juist omwille van dit probleem ertussen uit gehaald en de dns rechtstreeks via de usg laten lopen.
Ik heb hier overigens ook nog een wifi-lijntje van de buurman welke ik gebruik om dns aanvragen te volgen middels traceroutes omdat ik een aantal servers beheer en kijk welke dns de aanvragen het snelst update na een wijziging.
Voor een bepaalde wijziging gewoon de TTL niet te hoog zetten, 300 of 900sec. Heb je een paar voorbeelden qua domeinnamen? Misschien kan ik hier ook eens kijken.
I know, die ttl is beslissend voor de update rate, time to live, maar dat wil niet zeggen dat een de updates ook daadwerkelijk opgepakt worden na wijziging.. Althans, dat is mijn ervaring, en dan heb ik het veelal over dyn.dns urls welke ik aan een vhost gekoppeld heb op mijn servers..
In de tussentijd….
Gek genoeg deze keer geen 10.x die lopen te emmeren maar het ip daarna… Het is ook niet continue zoals ik aangaf, het is wellicht ook tijd gebonden (net wanneer ik wellicht thuis ben, ha.. ha.. ) maar op dit moment ervaar ik ook weinig problemen moet ik zeggen.. afgelopen weekend was het echt dramatisch!
Goed antwoord! Ik gebruik in de WAN al de dns van google (8.8.8.8) en die van CF (1.1.1.1)
Dan gebruik je de USG nu als resolver? En als je ze direct inklopt op je PC of laptop dus de resolver in je USG ontzien?
I know, die ttl is beslissend voor de update rate, time to live, maar dat wil niet zeggen dat een de updates ook daadwerkelijk opgepakt worden na wijziging.. Althans, dat is mijn ervaring, en dan heb ik het veelal over dyn.dns urls welke ik aan een vhost gekoppeld heb op mijn servers..
In principe hanteert Dyn een vrij lage TTL maar is het de ISP die deze TTL moet respecteren (en die laten soms te wensen over met hun resolvers)
Goed antwoord! Ik gebruik in de WAN al de dns van google (8.8.8.8) en die van CF (1.1.1.1)
Dan gebruik je de USG nu als resolver? En als je ze direct inklopt op je PC of laptop dus de resolver in je USG ontzien?
Het is juist de bedoeling dat ik de usg als resolver gebruik, aangezien ik alle cliënts in mijn lokale netwerk aan een hostname heb hangen en dus niet wil dat mijn dns aanvragen buiten de usg gebeuren.
Reden is overigens ook dat ik momenteel adblocking op de usg heb lopen aangezien ik adguard uit heb staan en het verschrikkelijk is om te surfen zonder enige vorm van blocking.. lol
I know, die ttl is beslissend voor de update rate, time to live, maar dat wil niet zeggen dat een de updates ook daadwerkelijk opgepakt worden na wijziging.. Althans, dat is mijn ervaring, en dan heb ik het veelal over dyn.dns urls welke ik aan een vhost gekoppeld heb op mijn servers..
In principe hanteert Dyn een vrij lage TTL maar is het de ISP die deze TTL moet respecteren (en die laten soms te wensen over met hun resolvers)
Mee eens!
Reden is overigens ook dat ik momenteel adblocking op de usg heb lopen aangezien ik adguard uit heb staan en het verschrikkelijk is om te surfen zonder enige vorm van blocking.. lol
Adblocking op de USG?
Maargoed, even ontopic;
Het hele verhaal interne dns resolving gaat dus begrijp ik niet op?
Ik heb mij afgelopen weekend het hele weekend voor niks druk gemaakt om te achterhalen waarom de verbinding zo flabby was?
Hmm... Zou haast het Ziggo modem weer uit de kast trekken en het weer laten activeren om te kijken wat er dan gebeurd!
Ik kan mij echt niet voorstellen dat er opeens bij ons intern iets niet goed zou zitten terwijl ik al jaren met hetzelfde systeem werk en nooit problemen heb ervaren.. enige dat verandert is, is dus de tag 300 in de wan en dhcp ipv een statisch ip..
Reden is overigens ook dat ik momenteel adblocking op de usg heb lopen aangezien ik adguard uit heb staan en het verschrikkelijk is om te surfen zonder enige vorm van blocking.. lol
Werkt overigens perfect. Vanmiddag dus weer even geïnstalleerd aangezien er issues waren en ik adguard uit heb gezet om te testen of het daarmee te maken had, maar dat was het dus niet..
Maargoed, even ontopic;
Het hele verhaal interne dns resolving gaat dus begrijp ik niet op?
Die 10-range heeft sowieso geen reverse records, dus daar zit het niet in. De z.g.n. timeouts op routers zijn ook normaal zolang alle verzonden en ontvangen pakketjes gewoon verzonden worden en arriveren daar zit het dus ook niet in.
Ik heb mij afgelopen weekend het hele weekend voor niks druk gemaakt om te achterhalen waarom de verbinding zo flabby was?
Dat heb ik niet gezegd, maar de resolving en tracerts zien er gewoon goed uit.
Ik kan mij echt niet voorstellen dat er opeens bij ons intern iets niet goed zou zitten terwijl ik al jaren met hetzelfde systeem werk en nooit problemen heb ervaren.. enige dat verandert is, is dus de tag 300 in de wan en dhcp ipv een statisch ip..
Dan zouden er eigenlijk meer klachten moeten zijn, het enige wat mij te binnenschiet is mogelijk een misselijke firmware. Hier draait de USG op 4.4.51 omdat iedere versie erna steeds wel weer wat mankeerde. Ook anderen hier op het forum hebben tot een paar maanden nog wel eens last gehad van een ineens wegvallende verbinding. Diverse fora bevatten genoeg problemen met Firmwares erna.
Werkt overigens perfect. Vanmiddag dus weer even geïnstalleerd aangezien er issues waren en ik adguard uit heb gezet om te testen of het daarmee te maken had, maar dat was het dus niet..
Ik zou het nog even in de gaten houden, ik weet niet of je normaliter ook die AdBlocking op de USG erbij hebt draaien? Het uit 2015-stammende beestje zou in dat geval ook nog wel eens moeite kunnen hebben met die blocklist (net zoals met Threat Management, Traffic Management, DPI, Geo Blocking).
Deze settings wel goed staan in je USG?
MSS Clamping heb ik momenteel disabled, dat zou standaard (disabled) 1500mtu (-48=1452) moeten staan wat de juiste zou moeten zijn.
Btw, ook daar heb ik naar gekeken afgelopen weekend, auto/1452/disabled, maar maakte alle 3 helaas geen verschil.
Ik blijf erbij, die timeouts in de traces zijn exact op de momenten wanneer wij problemen ervaren.
Maargoed, even ontopic;
Het hele verhaal interne dns resolving gaat dus begrijp ik niet op?
Die 10-range heeft sowieso geen reverse records, dus daar zit het niet in. De z.g.n. timeouts op routers zijn ook normaal zolang alle verzonden en ontvangen pakketjes gewoon verzonden worden en arriveren daar zit het dus ook niet in.
Ik heb mij afgelopen weekend het hele weekend voor niks druk gemaakt om te achterhalen waarom de verbinding zo flabby was?
Dat heb ik niet gezegd, maar de resolving en tracerts zien er gewoon goed uit.
Ik kan mij echt niet voorstellen dat er opeens bij ons intern iets niet goed zou zitten terwijl ik al jaren met hetzelfde systeem werk en nooit problemen heb ervaren.. enige dat verandert is, is dus de tag 300 in de wan en dhcp ipv een statisch ip..
Dan zouden er eigenlijk meer klachten moeten zijn, het enige wat mij te binnenschiet is mogelijk een misselijke firmware. Hier draait de USG op 4.4.51 omdat iedere versie erna steeds wel weer wat mankeerde. Ook anderen hier op het forum hebben tot een paar maanden nog wel eens last gehad van een ineens wegvallende verbinding. Diverse fora bevatten genoeg problemen met Firmwares erna.
Zou kunnen overwegen om een fw terug te downgraden, maar waarom het dan bij Ziggo wel altijd goed gewerkt heeft en bij tmobile niet?
Werkt overigens perfect. Vanmiddag dus weer even geïnstalleerd aangezien er issues waren en ik adguard uit heb gezet om te testen of het daarmee te maken had, maar dat was het dus niet..
Ik zou het nog even in de gaten houden, ik weet niet of je normaliter ook die AdBlocking op de USG erbij hebt draaien? Het uit 2015-stammende beestje zou in dat geval ook nog wel eens moeite kunnen hebben met die blocklist (net zoals met Threat Management, Traffic Management, DPI, Geo Blocking).
Zal ik zeker ff doen..
Alles in de usg staat uit, zelfs de dpi.
Het is een oud beestje, maar werkte altijd prima.
Ook de snelheid word gewoon gehaald (989/992) op de laptop met een draadje.
Deze settings wel goed staan in je USG?
Staan identiek, echter de mss dus uit..
Zou kunnen overwegen om een fw terug te downgraden, maar waarom het dan bij Ziggo wel altijd goed gewerkt heeft en bij tmobile niet?
Ik zou het niet weten waar het 'm in zit, maar kijkende naar de fora van Tweakers en hier is het wel opgevallen dat de problemen na een downgrade snel verdwenen waren.
Ik heb geen ervaring met USG achter een modem in bridge (lees; Ziggo), maar wat misschien zou kunnen is dat de USG nu teveel voor z'n kiezen krijgt omdat deze direct aan het internet hangt en niet achter een modem die de klappen opvangt (?). Misschien de load van de USG eens in de gaten houden??
Wat misschien ook nog kan is de USG een reset geven en opnieuw adopten in de hoop dat alle instellingen opnieuw binnen harken iets oplost.
Ook de snelheid word gewoon gehaald (989/992) op de laptop met een draadje.
Zeker niet slecht, hier veelal tussen de 930-945.
Zou kunnen overwegen om een fw terug te downgraden, maar waarom het dan bij Ziggo wel altijd goed gewerkt heeft en bij tmobile niet?
Ik zou het niet weten waar het 'm in zit, maar kijkende naar de fora van Tweakers en hier is het wel opgevallen dat de problemen na een downgrade snel verdwenen waren.
Ga ik mee aan de slag, al heb ik zo mijn twijfels..
Laat het je weten.
Ik heb geen ervaring met USG achter een modem in bridge (lees; Ziggo), maar wat misschien zou kunnen is dat de USG nu teveel voor z'n kiezen krijgt omdat deze direct aan het internet hangt en niet achter een modem die de klappen opvangt (?). Misschien de load van de USG eens in de gaten houden??
Wat misschien ook nog kan is de USG een reset geven en opnieuw adopten in de hoop dat alle instellingen opnieuw binnen harken iets oplost.
CPU is gemiddeld tussen 4 en 15%, in rust zo'n 4% en bij audio/video streaming zo'n 15%.
De pieken die het vandaag had was omdat ik het een keer of 3 heb verwijdert uit de controller om het vervolgens opnieuw te adopten...
Ook de snelheid word gewoon gehaald (989/992) op de laptop met een draadje.
Zeker niet slecht, hier veelal tussen de 930-945.
Over de snelheid hoor je mij ook niet klagen! ;)
Ik ga vanavond de firmware van de usg downgraden naar 4.4.51, ik hou jullie hier op de hoogte of dat het geval is geweest.
Goedemorgen allemaal,
Bedankt voor alle reacties.
Het probleem is inmiddels verholpen na een paar dagen te hebben getest.
Usg firmware staat nog gewoon op 4.4.56, alle access points nog steeds op 4.3.20 (beste stable versie ooit) en de rest niks bijzonders.
Pi-Hole zit er weer tussen en is tevens als dhcp ingezet. Dns adressen op de usg voor zowel de WAN als LAN Pi-Hole ingezet, dhcp in de usg uitgezet en werkt alleen nog maar als firewall, vpn, dyn.dns (hostname) en wan dhcp connectie..
Alle problemen lijken hiermee te zijn verholpen.
Pi-Hole dns ingesteld op Google, cloudflare, comodo, opendns en quad9, de cache verhoogt van 10k naar 50k, en vanaf het moment as we speak laden de sites ook echt supersnel (binnen 10/50ms, ipv 150/250ms voorheen) en lijkt de verbinding ook weer super stabiel.
Nu weet ik ook weer waarom ik ooit pihole ertussen had zitten, wat een verademing.
Sites laden bloedjesnel en ook geen timeouts meer gehad sindsdien!
Toch vermoed ik een routing probleem ergens in de dns resolver van t-mobile, maar helemaal zeker kan ik het niet zeggen, al werkt het nu perfect en ben ik dik tevreden.
Ook wel leuk om te vermelden, tot het moment dat ik pihole heb ingezet kreeg ik veel 'Client is having trouble resolving a domain name to an IP address (DNS timeout)' fouten in de unifi controller, maar heb er daarna geen 1 meer gehad! Zegt wellicht ook genoeg
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.
