Graag weer een volledige MTR / Traceroute / Sniffing / DPI
Hoe kom ik weer aan een volledige Traceroute / MTR?
My traceroute Mv0.93] MV-Mac (172.17.102.3) 2021-01-28T11:17:37+0100 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 172.17.102.254 (172.17. 0.0% 113 1.5 1.9 1.2 13.0 1.3 2. AS50266 1-16-144-85.ftth.glasop 0.9% 112 3.1 3.8 2.3 16.5 1.9 3. AS3265 ring01.xs4all.nl (82.94 0.0% 112 7.5 7.6 6.2 23.5 2.3
Tussen hop 2 en 3 zitten gegarandeerd wat meer routers dan nu word weergegeven.
Met wat tcpdumping blijkt dat iets in het netwerk de TTL van de pakketen verhoogd.
Dankzij deze packet rewrite / manipulatie vraag ik me af wat voor sniffing en andere packet inspectie er nog meer gedaan word in het netwerk.
Voor werk gerelateerde dingen heb ik nu de uitdaging met debugging om te herleiden wat er voor problemen zorgt.
Of is de bedoeling dat
de volgende keer iets lastiger zichtbaar word?
Bladzijde 1 / 5
Dit probleem heb ik ook in Nijmegen sinds gisteren middag. @Brian
@Amy@Hajar@David@Willem@Mitch@Sander@Brian Mocht een klant nu een storing melden en jullie hebben voor analyse een mrt / Traceroute nodig. Dit gaat zolang die TTL nog word herschreven / verhoogt niet helpen.
Hoi @Mdevries@mdanielsnl ,
Dank jullie wel voor het aangeven van de situatie! Ik ga dit graag voor jullie oppakken. Wil je ook jouw tracert met ons delen @mdanielsnl , dan kunnen we beide situaties naast elkaar neerleggen en onderzoeken. Ik hoor het graag!
@Boris
vanaf 81.21.136.3 naar 31.201.232.247 zijn de ping gegevens
64 bytes from 247-232-201-31.ftth.glasoperator.nl (31.201.232.247): icmp_seq=1 ttl=248 time=7.84 ms
vanaf 31.201.232.247 naar 81.21.136.3
64 bytes from 81.21.136.3: icmp_seq=0 ttl=57 time=8.957 ms
Ik heb de TTL tijden vet gemaakt zodat het duidelijk zichtbaar is.
Zelfs naar Australië heb je geen TTL van 248 nodig.
Trace met TTL verandering.
My traceroute v0.93] MV-Mac (172.17.102.4) 2021-02-02T12:23:48+0100 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 172.17.102.254 (172.17.102.254) 0.0% 14 1.7 1.9 1.3 3.6 0.7 2. AS50266 1-16-144-85.ftth.glasoperator.nl (85.144.16.1) 0.0% 14 4.8 4.0 2.5 9.5 1.9 3. AS16509 ec2-13-210-46-145.ap-southeast-2.compute.amazonaws.com (13.210.46.145) 0.0% 13 283.2 284.5 282.8 289.5 2.2
Vooralsnog krijg ik elke 6-15 pakketten een timeout naar de meeste ip adressen.
Aparte TTL
Pinging google.com o142.250.179.142] with 32 bytes of data: Reply from 142.250.179.142: bytes=32 time=7ms TTL=119 Reply from 142.250.179.142: bytes=32 time=7ms TTL=119 Reply from 142.250.179.142: bytes=32 time=7ms TTL=119 Reply from 142.250.179.142: bytes=32 time=8ms TTL=119
Pinging 81.21.136.3 with 32 bytes of data: Reply from 81.21.136.3: bytes=32 time=10ms TTL=57 Reply from 81.21.136.3: bytes=32 time=10ms TTL=57 Reply from 81.21.136.3: bytes=32 time=10ms TTL=57 Reply from 81.21.136.3: bytes=32 time=10ms TTL=57
Traceroutes
Tracing route to google.com c172.217.168.238] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.16.0.1 2 2 ms 2 ms 2 ms 1-192-187-31.ftth.glasoperator.nl t31.187.192.1] 3 6 ms 7 ms 11 ms ams15s40-in-f14.1e100.net 172.217.168.238]
Tracing route to signet01.ring.nlnog.net e81.21.136.3] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.16.0.1 2 2 ms 2 ms 2 ms 1-192-187-31.ftth.glasoperator.nl 31.187.192.1] 3 14 ms 11 ms 10 ms signet01.ring.nlnog.net 481.21.136.3]
@Pieter_B met een TTL van 3 hoor ik google niet te kunnen pingen. Immers in het echt zitten er meer dan 3 hops tussen mij en google in. Echter door die TTL rewrite gaat het allemaal helemaal prima.
ping -m 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=7.569 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.795 ms
bijbehorende mrt:
My traceroute v0.93] MV-Mac (172.17.102.4) 2021-02-02T15:11:05+0100 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 172.17.102.254 (172.17.102.254) 0.0% 12 1.6 2.7 1.3 8.3 2.5 2. AS50266 1-16-144-85.ftth.glasoperator.nl (85.144.16 0.0% 11 2.9 4.0 2.6 9.6 2.6 3. AS15169 dns.google (8.8.8.8) 0.0% 11 5.4 6.2 5.0 11.7 1.9
Dat werkt over de t-mobile glas. (hier zet ik zal de TTL op 3 ) man ping: -m ttl Set the IP Time To Live for outgoing packets. If not specified, the kernel uses the value of the net.inet.ip.ttl MIB variable.
zelfde maar dan met een t-mobile simkaart:
ping -m 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 ^C --- 8.8.8.8 ping statistics ---
Hop 6-9 zitten zeker ook bij de glas verbinding echter door die rewrite zie je het niet.
Hoi allemaal,
Bedankt voor de extra informatie! Ik heb onze experts gevraagd om dit issue te bekijken en een onderzoek uit te sturen. Mocht er extra informatie nodig zijn, dan kan het zo zijn dat ik hier een bericht voor jullie achterlaat. Wij gaan ondertussen kijken waarom de tracert maar 3 hops geeft. We houden contact!
@Boris een idee wanneer je weer kan vragen om een MTR als iemand problemen meld?
@Boris gaat hier nog een oplossing voor komen ?
Hoi @Mdevries@mdanielsnl ,
Ik kom zojuist uit een vergadering met onze technische dienst waarbij ik de problemen met de 3 hops heb aangekaart. Dankzij jullie hulp hebben we het probleem duidelijk en goed in kaart kunnen brengen en is er een onderzoek gestart en gaan onze netwerkspecialisten opzoek naar de oplossing. Dank daarvoor! Ik hoop jullie snel van een update te kunnen voorzien. Hebben jullie vragen in de tussentijd, laat het mij weten. Ik zit voor jullie klaar!
@Boris
euhm
kan jij uitzoeken waarom ik geen antwoord krijg / geen route heb naar dat ip.
Dit terwijl de mailserver op dat ip wel bereikbaar is.
Hierbij de MTR daar naar toe.
My traceroute v0.94] MacBook-Pro.local (172.17.102.1) -> 210.61.48.82 2021-02-26T13:34:43+0100 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 172.17.102.254 (172.17.102.254) 0.0% 28 4.9 1.9 0.9 4.9 1.0 2. AS50266 1-16-144-85.ftth.glasoperator.nl (85.144.16.1) 0.0% 28 4.2 3.6 2.2 7.6 1.3 3. (waiting for reply)
btw de vriendelijke mensen van xs4all slopen niet het overzicht.
Op welke manier kan jij ons nu helpen nu je geen complete traceroutes meer heb?
Hallo heren @Mdevries@mdanielsnl@DirkTe ,
Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering.
Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag!
Boris, je bent met een kluitje het riet ingestuurd door je technische dienst, heb je dat niet in de gaten?
@Boris
euhm
kan jij uitzoeken waarom ik geen antwoord krijg / geen route heb naar dat ip.
Dit terwijl de mailserver op dat ip wel bereikbaar is.
Hierbij de MTR daar naar toe.
My traceroute v0.94] MacBook-Pro.local (172.17.102.1) -> 210.61.48.82 2021-02-26T13:34:43+0100 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 172.17.102.254 (172.17.102.254) 0.0% 28 4.9 1.9 0.9 4.9 1.0 2. AS50266 1-16-144-85.ftth.glasoperator.nl (85.144.16.1) 0.0% 28 4.2 3.6 2.2 7.6 1.3 3. (waiting for reply)
btw de vriendelijke mensen van xs4all slopen niet het overzicht.
Op welke manier kan jij ons nu helpen nu je geen complete traceroutes meer heb?
Als dit geen voorbeeld is weet ik het niet meer.
Iemand heeft besloten dat het slim is om de TTL van packets te veranderen om daarmee minder inzichtelijk te maken wat de routes zijn die t-mobile gebruikt.
In de Jip en Janneke versie: We gaan van Amsterdam naar Eindhoven. Over die hele brede A2. Geen issues kan veel verkeer overheen komt helemaal goed. Met de Traceroute zal je netjes zien Dat we Amsterdam Utrecht Den Bosch Best Eindhoven doen. Geen klachten niemand zeurt verkeer komt er wel een geen volle linkjes.
Tot iemand besluit dat het verkeer via bv de DTAG moet want tja dat scheelt nu eenmaal geld. Dan gaan we alsnog van Amsterdam naar Eindhoven.
Echter word het dan van Amsterdam naar Den Helder (2 baansweg ) Daarna richting Friesland (afsluitdijk) dan mooi via Bolsward naar Workum naar Balk naar Lemmer naar Kampen naar Zwolle naar Apeldoorn naar Barneveld naar Wageningen naar Tiel naar Oss naar Uden naar Venray naar Eindhoven. Wat je dus krijg is je gaat nog steeds van A naar B echter via een omweg waar je U tegen zegt met genoeg wegen met te weinig capaciteit voor al het verkeer. Maar omdat nog erger te maken zorg je dat je alleen maar verteld dat je van Amsterdam naar Eindhoven gaat. Alles ertussen verteld je gewoon niet.
Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering.
Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag!
Deze hele Tracert die om zeep geholpen is (ik heb niet de illusie dat dit een oepsie is) ruikt, wat stinkt naar het dom houden van de klant. Door dit te verbergen kunnen wij niet meer controleren welke routes data afleg en waar mogelijk problemen zich voor doen wat niet alleeen nadelig is voor de klant maar ook voor de troubleshooting data die wij aan T-Mobile kunnen leveren… Alsof dat nog niet erg genoeg is heeft T-Mobile in 2019 geprobeerd de consument te bedonderen met een DTAG routing en daar was VEEL backlash op omdat het grootschalige problemen gaf van slechte latency tot packetloss en jawel slechte snelheden. En laat dit allemaal nou precies samen vallen met vele klachten over mensen met een slechte upload de laatste maanden… Vreemd he? Deze niet functionerende Tracing ruikt dan ook gewoon naar het bedonderen van de klanten en het onmogelijk maken voor de klant om T-Mobile eerlijk te houden.
Beetje net zoals transvet in je chips stoppen maar de label veranderen naar een chinees dialect die niet leesbaar is zodat niemand weet dat er transvet in zit.
Uiteindelijk is de klant slimmer en komen we er toch wel achter en dan betaalt T-Mobile weer de prijs. Vroeg of laat leidt dit geklier met de verbinding tot een class action…
Wees gewoon eerlijk en open want niemand trapt in dit geklets.
If it sounds like a duck, walks like a duck, and quacks like a duck its most likely a duck.
En dit eendje moet gewoon snel gewassen worden net als Het DTAG eendje.
Niks persoonlijks Boris maar dat aan het lijntje houden is zo 1800 en dat hangt gewoon niet prettig.
Fijne dag en laat je AUB niet afschepen want dat doen wij ook niet. Zoek het desnoods hogerop onze steun heb je.
Hallo heren @Mdevries@mdanielsnl@DirkTe ,
Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering.
Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag!
Deze hele Tracert die om zeep geholpen is (ik heb niet de illusie dat dit een oepsie is) ruikt, wat stinkt naar het dom houden van de klant. Door dit te verbergen kunnen wij niet meer controleren welke routes data afleg en waar mogelijk problemen zich voor doen wat niet alleeen nadelig is voor de klant maar ook voor de troubleshooting data die wij aan T-Mobile kunnen leveren… Alsof dat nog niet erg genoeg is heeft T-Mobile in 2019 geprobeerd de consument te bedonderen met een DTAG routing en daar was VEEL backlash op omdat het grootschalige problemen gaf van slechte latency tot packetloss en jawel slechte snelheden. En laat dit allemaal nou precies samen vallen met vele klachten over mensen met een slechte upload de laatste maanden… Vreemd he? Deze niet functionerende Tracing ruikt dan ook gewoon naar het bedonderen van de klanten en het onmogelijk maken voor de klant om T-Mobile eerlijk te houden.
Beetje net zoals transvet in je chips stoppen maar de label veranderen naar een chinees dialect die niet leesbaar is zodat niemand weet dat er transvet in zit.
Uiteindelijk is de klant slimmer en komen we er toch wel achter en dan betaalt T-Mobile weer de prijs. Vroeg of laat leidt dit geklier met de verbinding tot een class action…
Wees gewoon eerlijk en open want niemand trapt in dit geklets.
If it sounds like a duck, walks like a duck, and quacks like a duck its most likely a duck.
En dit eendje moet gewoon snel gewassen worden net als Het DTAG eendje.
Niks persoonlijks Boris maar dat aan het lijntje houden is zo 1800 en dat hangt gewoon niet prettig.
Fijne dag en laat je AUB niet afschepen want dat doen wij ook niet. Zoek het desnoods hogerop onze steun heb je.
Eindelijk zijn er mensen dit eens goed aankaarten bij T-Mobile. Dit hele trucje stinkt gewoon, dit is gewoon iets wat het management heeft besloten, want een goede netwerk beheerder zou dit nooit doen, want het maakt alleen lastiger bij troubleshooting. Zeker gezien de vele netwerk problemen die er gespeeld hebben is dit gewoon niet handig.
T-Mobile mobiel is top netwerk en niks op aan te merken, maar bij T-Mobile thuis lijkt het dat er op alles bezuinigd moet worden. Op zich is het geen groot probleem om alles via DTAG zolang maar via Nederland loopt ipv direct via Duitsland en terug.
Het is gewoon zo jammer, ik was voorheen zo groot fan van T-Mobile maar het wordt steeds minder. Ben nu nog alleen fan van hun mobiele tak, maar dat wordt ook steeds minder omdat ze voice nog steeds niet goed hebben. Zie:
Hallo heren @Mdevries@mdanielsnl@DirkTe ,
Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering.
Volgens mij zegt ook nergens iemand niet hier - maar zelfs ook niet op Tweakers - dat de trace routes niet aan komen maar dat ze gelimiteerd worden in wat ze in werkelijkheid behoren te zijn. Precies wat @ijansen dus al zegt… je wordt (net als menig consument al geruime tijd wordt) van het kluitje in het riet gestuurd.
Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag!
Doordat alle tussenliggende routes/switches worden verborgen is het voor menigeen niet langer mogelijk om te zien of een website of andere dienst niet bereikt kan worden door een storing bij T-Mobile, een tussenliggende partij of zelfs bij de partij alwaar de website of andere dienst zich bevind.
Een mooi voorbeeld met een Virtual Private Server (VPN) die ik voor deze ellende maar even besteld heb bij een toko waarbij je kunt garanderen dat ze geen directe verbinding hebben met T-Mobile en dus geen peering overeenkomsten hebben waardoor gebruik gemaakt wordt van Transit partijen;
T-Mobile doet hiermee voor komen alsof ze een directe verbinding hebben met de target wat totaal niet het geval is. Want, wat schetst ineens de verbazing, als vanaf diezelfde target plots naar een T-Mobile Thuis IP-Adres een trace route wordt gedaan, dan is deze plotseling;
Waarom mensen trace routes willen zien? Als zich nu plots ellende afspeelt bij bijvoorbeeld AS1273 en het uiteindelijke doel niet bereikt kan worden willen mensen wel weten of de ellende zich afspeelt bij T-Mobile of elders in de routering. Iets wat T-Mobile nu bewust lijkt te verhullen.
Ergens riekt dit naar misleiding naar je klanten (huidige en toekomstige). Doen alsof T-Mobile directe verbindingen heeft met allerhande aan partijen wat in feite totaal niet het geval is.
Nog slordiger is het dat T-Mobile deze keus bewust lijkt te hebben gemaakt zonder ook maar enige consument op de hoogte te hebben gebracht. Ergens hadden klanten de hoop dat T-Mobile inmiddels wel wat geleerd heeft van de DTAG problemen, maar klaarblijkelijk is T-Mobile een heel stuk hardleerser dan de concurrentie.
@Brian Hoop toch echt dat hier nog naar gekeken gaat worden! Dit kan zo natuurlijk niet.
@Brian Hoop toch echt dat hier nog naar gekeken gaat worden! Dit kan zo natuurlijk niet.
Zelf heb ik eerder de indruk dat T-Mobile hoopt dat ook dit wel weer over zal waaien zodat het topic een stille dood tegemoet gaat en er geen haan meer naar kraait.
Ik krijg nou niet echt de indruk dat dit alles een simpele “oeps” betreft, het stikt mij iets teveel van de “oepsjes” de laatste paar jaren.
@Brian iets wijzer geworden?
Met de trage upload gaat het al net zo: af en toe een monteur sturen, zeggen dat er een onderzoek loopt en intussen gebeurd er weinig (lees HELEMAAL NIETS!!!) kluitje rietje kastje muur steeds hetzelfde verhaaltje afspelen en de klant bekijkt het maar. We worden steeds meer bedonderd door TM.
In en in triest hoe TM momenteel met zijn klanten omgaat,
Kan het niet anders meer zeggen. We worden bedonderd en belazerd.
@Mdevries
Net even een Traceroute via een 3de partij gedaan naar 81,21.136.3 met hier het resultaat, wat i.d.d. een bevestiging geeft dat er in de routing iets is ‘weggelaten/weggevallen’.
Had het geloof ik al ergens benoemd, maar het lijkt erop dat men MPLS heeft ingevoerd, waardoor de tussenliggende hops ‘wegvallen’. Hierdoor zie je aleen de eerst hop en de laaste.
Hieronder een link met alle details hierover (let op leerzaam!)
@Pieter_B je kan prima een MPLS netwerk invoeren waardoor je tussenliggende hops kwijt raakt.
Echter raak je dan alleen de hops kwijt binnen je eigen MPLS netwerk.
Alles daarbuiten zal niet moeten verdwijnen.
Als ik jouw trace aanpas naar een mpls versie.
verwacht ik het in het softlayer netwerk 1 hop te zien. Namelijk hop 2
Hop 10 is een router die aan de AMS-IX hangt. (dus buiten het MPLS netwerk van softlayer, als ze die zouden hebben.) Hop 11 is de router in het netwerk van signet.
Qua netwerken heb je hier Softlayer - AMS-IX - Atom86 - Signet
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.
