Problemen met dns resolving interne (tmobile) ipadressen

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.

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.

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… 

Goh, tijdens het wachten op de mtr uitkomsten, toevallig ook nog meerdere topics hierover gevonden….:
https://www.a2b-internet.com/zit-je-bij-t-mobile-en-heb-je-opeens-last-van-een-trage-internet-verbinding/

https://gathering.tweakers.net/forum/list_messages/1953626/1

Toch bijzonder dat meer mensen over hetzelfde probleem klagen zodra ik iets over een instabiel t-mobile probeer te googlen… Okay?🤥

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.

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.

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.

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!

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?

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) 😔

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

Mee eens!

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..

Correct

https://community.ui.com/questions/DNS-Adblocking-and-Blacklisting-dnsmasq-Configuration-Integration-Package-v1-1-8-1/eb05f1b2-5316-4a80-8221-5e8b02575da4

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..

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.

Dat heb ik niet gezegd, maar de resolving en tracerts zien er gewoon goed uit.

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.

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.

Zou kunnen overwegen om een fw terug te downgraden, maar waarom het dan bij Ziggo wel altijd goed gewerkt heeft en bij tmobile niet?

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.

Gerrit078 schreef:

 

Deze settings wel goed staan in je USG?

 

Staan identiek, echter de mss dus uit..

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.

Zeker niet slecht, hier veelal tussen de 930-945.

Ga ik mee aan de slag, al heb ik zo mijn twijfels..

Laat het je weten.

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...

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.