Beantwoord

Graag weer een volledige MTR / Traceroute / Sniffing / DPI


Reputatie 3

Hoe kom ik weer aan een volledige Traceroute / MTR?

                             My traceroute  [v0.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?

icon

Beste antwoord door Brian 29 March 2021, 12:08

Bekijk origineel

110 reacties

Reputatie 2

Boris, je bent met een kluitje het riet ingestuurd door je technische dienst, heb je dat niet in de gaten?

Reputatie 3

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

 

                                              My traceroute  [v0.86]
xs4all01.ring.nlnog.net (0.0.0.0)                                                        Fri Feb 26 12:37:06 2021
Resolver error: Received reply from unknown source: ::r of fields   quit
                                                                         Packets               Pings
 Host                                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS3265  122.irb.xrc.d12.xs4all.net (82.94.249.161)                  0.0%   156    2.0   4.3   0.3  72.8  11.1
 2. AS3265  0.ae11.xr4.1d12.xs4all.net (194.109.5.77)                   0.0%   156    0.4   1.2   0.3  39.7   4.3
 3. AS3265  0.et-7-1-0.xr1.tc2.xs4all.net (194.109.5.5)                 0.0%   156    0.7   1.1   0.5  20.3   2.2
 4. AS286   asd-s8-rou-1041.NL.as286.net (134.222.94.216)               0.0%   156    1.2   1.4   0.9  11.9   1.1
 5. AS286   ae16-100-cr6-ams1.ipv4.gtt.net (194.122.122.102)            0.0%   156    3.4   5.0   2.3  65.0   6.9
 6. AS3257  ae7.cr4-ams1.ip4.gtt.net (213.200.117.170)                  0.0%   156    2.7   4.3   2.3  28.9   4.4
 7. AS1239  sl-crs4-ams-be2.sprintlink.net (213.206.131.109)            0.0%   155    4.6   4.0   1.9  23.7   1.9
 8. AS1239  sl-crs3-ams-te0-6-2-0.sprintlink.net (217.149.32.64)        0.0%   155    6.4   5.1   3.0  26.8   2.0
 9. AS1239  sl-crs3-lon-be3.sprintlink.net (213.206.129.15)             0.0%   155    9.5  10.9   7.4  17.7   2.3
10. AS1239  sl-crs1-nyc-be7.sprintlink.net (144.232.9.113)              0.0%   155   75.2  79.1  74.9  83.4   2.6
11. AS1239  sl-crs2-nyc-be25.sprintlink.net (144.232.4.85)              0.0%   155   79.1  78.0  76.1  80.0   0.9
12. AS1239  sl-crs2-rly-be11.sprintlink.net (144.232.25.231)            0.0%   155   87.6  85.9  81.9  92.3   2.1
13. AS1239  sl-crs2-dc-be2.sprintlink.net (144.232.14.7)                0.0%   155   84.1  83.8  80.3  90.7   2.1
14. AS1239  sl-crs2-ffx-be8.sprintlink.net (144.232.13.195)             0.0%   155   99.2  96.6  92.6 102.5   2.0
15. AS1239  sl-crs2-atl-be3.sprintlink.net (144.232.13.14)              0.0%   155   98.7  97.8  93.8 104.6   2.4
16. AS1239  sl-crs2-fw-be8.sprintlink.net (144.232.22.229)              0.0%   155  115.4 114.7 112.7 121.6   1.2
17. AS1239  sl-crs2-ria-be2.sprintlink.net (144.232.13.83)              0.0%   155  147.3 145.1 141.1 149.2   2.0
18. AS1239  sl-mst31-la-be8.sprintlink.net (144.232.22.91)              0.0%   155  149.6 146.9 142.4 150.4   2.0
19. AS1239  144.232.154.206                                             0.0%   155  142.7 143.3 142.4 185.3   3.7
20. AS9680  pcpd-4001.hinet.net (202.39.91.42)                          0.0%   155  291.1 291.2 290.8 296.1   0.7
21. AS???   220-128-6-38.HINET-IP.hinet.net (220.128.6.38)              0.0%   155  290.4 290.3 290.2 294.9   0.4
22. AS???   pcpd-3212.hinet.net (220.128.7.46)                          0.0%   155  283.3 283.2 283.1 287.6   0.4
23. AS???   tpe4-3302.hinet.net (220.128.13.121)                        0.0%   155  276.9 277.2 276.7 283.8   1.0
24. AS3462  h73.s229.ts.hinet.net (168.95.229.73)                       0.0%   155  277.0 276.9 276.7 279.7   0.3
25. AS3462  mamhq.morrisonexpress.com (210.61.48.82)                    0.0%   155  277.5 277.5 277.1 279.8   0.3

 

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.

 

Op deze manier is het “lastiger” om te zien wat men in:
https://community.t-mobile.nl/t%2Dmobile%2Dthuis%2Dinternet%2D492/28%2D10%2Dlatency%2Dissues%2D316274
heeft gedaan.

 

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.

Als je het niet ziet is het er niet toch?

 

Wellicht leuk om te lezen:

https://medium.com/@rudolfvanderberg/t-mobile-nl-routed-all-internet-traffic-through-germany-and-broke-the-internet-for-small-firms-a176855d2b0

 

https://tweakers.net/nieuws/159140/t-mobile-thuis-gebruikers-klagen-over-hoge-latency-na-routering-via-duitsland.html

 

Management summery: Stop met het manipuleren van mijn internet pakketen.

 

https://www.acm.nl/nl/onderwerpen-telecommunicatie-internet/netneutraliteit
Volgens mij hebben we nu geen vrij en open internet toegang. Gezien packets worden aangepast..

Reputatie 1

Aangezien je blijkbaar nergens een lap tekst kwijt kan aan T-Mobile, probeer ik het eerst hier. Ik wil dat T-Mobile hierop gaat reageren met iets concreets:

@Brian  @Jason  < Dat zijn volgens mij in ieder geval 2 medewerkers die iets kunnen zeggen hierover….

------

Beste T-Mobile,

Ik ben pas net aangesloten (Van KPN 200 naar T-Mobile 1000), maar jullie verbinding is gewoonweg een drama gebleken.
Websites (met name via AWS hosting) haperen, laden niet of pas na refresh. Hier is op de community intussen genoeg over te vinden, dus ik ben niet de enige. Ik zit zelf ruim 22 jaar in de ICT dus ik weet redelijk goed hoe e.e.a. werkt.

Via mijn verbinding is het heel simpel te testen via de volgende site: http://ec2-reachability.amazonaws.com/ . Via mijn connectie vallen er random pakketten weg binnen met name het EU verkeer. Via andere verbindingen, zoals via mijn werk (KPN en Vodafone) heb ik gewoon een 100% goedwerkende verbinding.

Ik ben eindeloos aan het sleutelen zoeken geweest, maar het probleem ligt gewoon verderop in het T-Mobile netwerk en is sinds vorige week dinsdag toen ik ben aangesloten nog steeds niet opgelost en schijnt blijkbaar al maanden te spelen.

Normale traceroutes zijn niet meer volgen, wat mijn (thuis)werk als systeembeheerder een stuk bemoeilijkt. Ik ben nu gedwongen om via een terminal sessie via VPN op een computer op de zaak de traceroutes na te lopen via een KPN lijn om connecties te na te lopen en de rest hieruit te reconstrueren, belachelijk!

Los daarvan het belangrijkste is gewoon dat de verbinding niet stabiel is binnen het T-Mobile netwerk.

- Websites openen niet, je staat te wachten. Je refreshed 1 of 2 keer en ineens laad hij weer wél.
- Spelletjes van de kinderen die online gaan en voorheen perfect werkten, lopen nu regelmatig vast en moeten herstart worden. Als zij spelletjes spelen moet ik vrijwel de hele tijd in de buurt blijven om ze te assisteren als de boel weer onderuit gaat.
- Speedtest is 3 van de 4 keer niet uit te voeren, dan krijg je een connection error, probeer je het een aantal keer, dan loopt hij soms wel door, met gigabit snelheden.
- TV kijken is een drama geworden. Dit doen we via NLZIET. Dit ging voorheen prima, maar nu als je naar een andere zenden zapt, krijg je zwart beeld en gaat hij ‘laden’. Als je dan doorzapt en weer terug dan krijg je weer beeld, zolang dat loopt heb je beeld, maar owee als je gaat zappen.
- De hele internetervaring is gewoon ronduit slecht geworden. Ik ben eigenlijk alleen maar bezig de hele tijd te troubleshooten waarom dingen niet werken zoals ze moeten werken. Op mijn mobiel heb ik nu standaard het internet naar 4G van de KPN maar aangezet, want dan werkt alles tenminste normaal. Helaas is mijn bundel niet toereikend om dit 24/7 te doen.
- Traceroutes zijn niet meer mogelijk, alle connecties worden gemaskeerd, waardoor professioneel thuiswerk over de verbinding simpelweg niet meer mogelijk is. Zelfs verbindingen buiten het T-Mobile netwerk worden gemaskeerd. Ik denk zelfs dat dit indruist tegen de netneutraliteit aangezien het dataverkeer actief wordt gemuteerd en informatie wordt weggehaald uit de datastroom. Interne routers afschermen is zeker wel mogelijk, maar dat gaat op een heel andere manier, niet door de data actief te muteren.

Ik was een tijdje bezig familie en kennissen te overtuigen om ook naar T-Mobile over te stappen vanwege het gunstige prijspunt, maar ik heb iedereen intussen met klem verzocht dit vooralsnog niet te doen, om onder andere bovenstaande redenen. Daarbij moet gezegd worden, als deze punten opgelost zouden zijn, het een goed produkt kan zijn, maar dan moet het stabiel zijn en onbewerkt/ongefilterd. Op dit moment kan ik nog niets positiefs melden helaas.

Ik wil gewoon weer terug naar het stabiele netwerk van KPN want als ik hier een jaar aan vast zit heb ik een groot probleem! Wat gaat T-Mobile hier aan doen? Ik heb hier namelijk te maken met een ondeugdelijk product. Als ik zo op Tweakers en jullie forum kijk, zijn er veel meer mensen met precies dezelfde problemen, dus het is zeker geen geïsoleerd geval.

Ik wil ook graag horen wat T-Mobile vind van deze hele zaak, want op de community worden mensen niet wijzer van de kleine beetjes halve informtie, waarmee iedereen met een kluitje in het riet wordt gestuurd.

Als T-Mobile mij niet schriftelijk kan bevestigen dat er inderdaad problemen zijn en dat deze binnen een redelijke periode opgelost worden (inclusief de belachelijke trace-blokkade) dan wil ik met jullie in gesprek over het ontbinden van het contract.

Graag uw reactie!

Mvg,

Ferry Heibrink

Reputatie 3

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:

 

 

Reputatie 3

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

 

Bedankt voor je antwoord. Vanuit het oogpunt van veiligheid snap ik ook zeker dat jullie liever niet de tussenliggende informatie zichtbaar willen hebben in de traceroute. En dat is ook prima. Providers als KPN hebben dit ook niet zichtbaar. De ‘normale’ manier om dit te bereiken is het filteren van ICMP vanuit het corenetwerk naar hosts op het internet en klanten. Hierdoor zie je in een traceroute onbekende hops met sterretjes. Dat is zoals je benoemt de “industry standard” manier om dit te bereiken.

De manier waarop T-Mobile dit nu doet gaat nog een stap verder dan dat, door de TTL van alle IP packets zo aan te passen dat het lijkt dat de hops helemaal niet bestaan (traceroutes werken op basis van verlaging van TTL). Daarmee kunnen we de traceroute tools ook niet meer gebruiken om te kijken hoe routes buiten het T-Mobile netwerk lopen. Als systeem/netwerkbeheerder is dit iets wat ik dagelijks meerdere keren gebruik. Ik ben inderdaad niet geinteresseerd in hoe het T-Mobile netwerk inelkaar zit, maar juist in hoe routes lopen buiten het T-Mobile netwerk. Deze oplossing is alles behalve “industry standard”. Ik ken in Europa geen enkel netwerk die dit ook zo doet. Het is ook nog eens een oplossing die voor irritante routingloops of storingen kan zorgen in het T-Mobile corenetwerk. Daarnaast weet ik 100% zeker dat er binnen T-Mobile geen enkele techneut is die dit een goed idee vindt, vergeleken met de “normale” manier om dit te doen, namelijk het filteren van ICMP zoals hierboven beschreven.

Ik vraag absoluut niet om te zien hoe het T-Mobile corenetwerk in elkaar zit, maar zorg er op zijn minst voor dat mijn traceroute ‘normaal’ werkt voor hops buiten het T-Mobile netwerk, op de “industry standard" manier. Het verbergen van deze informatie zal voor mij in een ICT rol in combinatie met thuiswerken al een reden zijn om mijn abonnement niet te verlengen, en ik weet zeker dat ik niet de enige ben.

Reputatie 4

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.

Reputatie 3

Wegens niks te doen en even geen zin in Netflix ben ik zelf ook maar even gaan turen omtrent wat er aan de hand zou kunnen zijn met die dubbele hops. Om te beginnen heb ik maar eens een tcpdump van een traceroute gemaakt en daar kwam best interessante informatie uit. Hieronder de dump naar ping.xs4all.nl. Sorry, het is nogal veel.

 

20:20:28.984480 IP (tos 0xc0, ttl 64, id 28493, offset 0, flags [none], proto ICMP (1), length 88)
    172.16.16.1 > 172.16.16.3: ICMP time exceeded in-transit, length 68
    IP (tos 0x0, ttl 1, id 62558, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.48353 > 194.109.6.8.33435: [udp sum ok] UDP, length 32
20:20:28.984550 IP (tos 0xc0, ttl 64, id 28492, offset 0, flags [none], proto ICMP (1), length 88)
    172.16.16.1 > 172.16.16.3: ICMP time exceeded in-transit, length 68
    IP (tos 0x0, ttl 1, id 62557, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.45356 > 194.109.6.8.33434: [udp sum ok] UDP, length 32
20:20:28.984577 IP (tos 0xc0, ttl 64, id 28494, offset 0, flags [none], proto ICMP (1), length 88)
    172.16.16.1 > 172.16.16.3: ICMP time exceeded in-transit, length 68
    IP (tos 0x0, ttl 1, id 62559, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.38498 > 194.109.6.8.33436: [udp sum ok] UDP, length 32
20:20:28.986262 IP (tos 0x0, ttl 254, id 11337, offset 0, flags [none], proto ICMP (1), length 96)
    143.178.128.1 > 172.16.16.3: ICMP time exceeded in-transit, length 76
    IP (tos 0x0, ttl 1, id 62560, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.39817 > 194.109.6.8.33437: [udp sum ok] UDP, length 32
20:20:28.986326 IP (tos 0x0, ttl 254, id 11338, offset 0, flags [none], proto ICMP (1), length 96)
    143.178.128.1 > 172.16.16.3: ICMP time exceeded in-transit, length 76
    IP (tos 0x0, ttl 1, id 62561, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.42545 > 194.109.6.8.33438: [udp sum ok] UDP, length 32
20:20:28.986845 IP (tos 0x0, ttl 254, id 11339, offset 0, flags [none], proto ICMP (1), length 96)
    143.178.128.1 > 172.16.16.3: ICMP time exceeded in-transit, length 76
    IP (tos 0x0, ttl 1, id 62562, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.54762 > 194.109.6.8.33439: [udp sum ok] UDP, length 32
20:20:28.988912 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    80.249.208.48 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62566, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.40655 > 194.109.6.8.33443: UDP, length 32
20:20:28.989496 IP (tos 0x0, ttl 252, id 10801, offset 0, flags [none], proto ICMP (1), length 168)
    10.10.80.102 > 172.16.16.3: ICMP time exceeded in-transit, length 148
    IP (tos 0x0, ttl 1, id 62563, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.43346 > 194.109.6.8.33440: [udp sum ok] UDP, length 32
    MPLS extension v2, checksum 0x880f (correct), length 12
      MPLS Stack Entry Object (1), Class-Type: 1, length 8
        label 24165, exp 0, [S], ttl 1
20:20:28.989501 IP (tos 0x0, ttl 252, id 10802, offset 0, flags [none], proto ICMP (1), length 168)
    10.10.80.102 > 172.16.16.3: ICMP time exceeded in-transit, length 148
    IP (tos 0x0, ttl 1, id 62564, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.40190 > 194.109.6.8.33441: [udp sum ok] UDP, length 32
    MPLS extension v2, checksum 0x880f (correct), length 12
      MPLS Stack Entry Object (1), Class-Type: 1, length 8
        label 24165, exp 0, [S], ttl 1
20:20:28.989506 IP (tos 0x0, ttl 252, id 10803, offset 0, flags [none], proto ICMP (1), length 168)
    10.10.80.102 > 172.16.16.3: ICMP time exceeded in-transit, length 148
    IP (tos 0x0, ttl 1, id 62565, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.37958 > 194.109.6.8.33442: [udp sum ok] UDP, length 32
    MPLS extension v2, checksum 0x880f (correct), length 12
      MPLS Stack Entry Object (1), Class-Type: 1, length 8
        label 24165, exp 0, [S], ttl 1
20:20:28.989828 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    80.249.208.48 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62567, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.33681 > 194.109.6.8.33444: UDP, length 32
20:20:28.989836 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    80.249.208.48 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62569, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.58821 > 194.109.6.8.33446: UDP, length 32
20:20:28.989841 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    80.249.208.48 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62568, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.48061 > 194.109.6.8.33445: UDP, length 32
20:20:28.990610 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    194.109.5.0 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62572, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.40501 > 194.109.6.8.33449: UDP, length 32
20:20:28.998458 IP (tos 0xc0, ttl 59, id 54411, offset 0, flags [none], proto ICMP (1), length 88)
    194.109.6.8 > 172.16.16.3: ICMP 194.109.6.8 udp port 33452 unreachable, length 68
    IP (tos 0x0, ttl 1, id 62575, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.44329 > 194.109.6.8.33452: [udp sum ok] UDP, length 32
20:20:28.998463 IP (tos 0xc0, ttl 59, id 54412, offset 0, flags [none], proto ICMP (1), length 88)
    194.109.6.8 > 172.16.16.3: ICMP 194.109.6.8 udp port 33453 unreachable, length 68
    IP (tos 0x0, ttl 1, id 62576, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.40564 > 194.109.6.8.33453: [udp sum ok] UDP, length 32
20:20:28.998946 IP (tos 0xc0, ttl 59, id 54413, offset 0, flags [none], proto ICMP (1), length 88)
    194.109.6.8 > 172.16.16.3: ICMP 194.109.6.8 udp port 33454 unreachable, length 68
    IP (tos 0x0, ttl 1, id 62577, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.56594 > 194.109.6.8.33454: [udp sum ok] UDP, length 32
20:20:29.012716 IP (tos 0xc0, ttl 59, id 54414, offset 0, flags [none], proto ICMP (1), length 88)
    194.109.6.8 > 172.16.16.3: ICMP 194.109.6.8 udp port 33458 unreachable, length 68
    IP (tos 0x0, ttl 3, id 62581, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.51137 > 194.109.6.8.33458: [udp sum ok] UDP, length 32
20:20:29.012921 IP (tos 0xc0, ttl 59, id 54415, offset 0, flags [none], proto ICMP (1), length 88)
    194.109.6.8 > 172.16.16.3: ICMP 194.109.6.8 udp port 33460 unreachable, length 68
    IP (tos 0x0, ttl 3, id 62583, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.58196 > 194.109.6.8.33460: [udp sum ok] UDP, length 32
20:20:29.012925 IP (tos 0xc0, ttl 59, id 54416, offset 0, flags [none], proto ICMP (1), length 88)
    194.109.6.8 > 172.16.16.3: ICMP 194.109.6.8 udp port 33461 unreachable, length 68
    IP (tos 0x0, ttl 4, id 62584, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.47945 > 194.109.6.8.33461: [udp sum ok] UDP, length 32
20:20:29.015054 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    194.109.5.0 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62574, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.34245 > 194.109.6.8.33451: UDP, length 32
20:20:29.015058 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    194.109.5.0 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62573, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.42663 > 194.109.6.8.33450: UDP, length 32

 

De eerste 6 timestamps zijn normaal. Netjes 3 probes per node en allen met time exceeded terug. Vanaf hop 7 begint het interessant te worden dus deze ligt ik er hieronder nog even uit:

 

20:20:28.988912 IP (tos 0x0, ttl 251, id 0, offset 0, flags [none], proto ICMP (1), length 56)
    80.249.208.48 > 172.16.16.3: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 62566, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.40655 > 194.109.6.8.33443: UDP, length 32
20:20:28.989496 IP (tos 0x0, ttl 252, id 10801, offset 0, flags [none], proto ICMP (1), length 168)
    10.10.80.102 > 172.16.16.3: ICMP time exceeded in-transit, length 148
    IP (tos 0x0, ttl 1, id 62563, offset 0, flags [none], proto UDP (17), length 60)
    172.16.16.3.43346 > 194.109.6.8.33440: [udp sum ok] UDP, length 32
    MPLS extension v2, checksum 0x880f (correct), length 12
      MPLS Stack Entry Object (1), Class-Type: 1, length 8
        label 24165, exp 0, [S], ttl 1

 

Dit is apart, de 80.249.208.48 is de ams-ix router van XS4All en de 10.10.80.102 is van T-Mobile. Ze lijken omgedraaid te zijn want die 10.10.80.102 komt toch echt eerder voor in het path.

Uit bovenstaande is duidelijk dat er gebruik gemaakt wordt van MPLS.  Nu ben ik niet echt een router kabouter maar mijn vermoeden is dat de manier waarop ttl’s binnen het MPLS domain geproprageerd worden voor ingress en egress verschillend zijn. Cisco heeft iig een global command no mpls ip propagate-ttl fowarded. Dit zegt min of meer tegen een router van ‘blijf met je poten van de ttls af’ ;-)

@Sander misschien is het zinvol om bovenstaande even mee te nemen als je gaat praten met de techies.

@Hutjeflut ik denk dat je gelijk hebt door te zeggen dat er iets niet goed gaat met de ttl’s.

@Brian Ofwel je bent voor de 2e keer met een mooi verhaal terug gestuurd.

 

Zoals hier boven al gezegd prima als t-mobile niet wil laten zien hoe hun eigen netwerk eruit ziet.

Maar het verbergen / niet inzichtelijk maken van netwerken van andere partijen ….

Maar goed om te weten dat t-mobile zich aan de 'industry standard’ houd en de rest van de wereld niet. 

 

 

Ik dacht zelf altijd dat wanneer bij IETF een standaard vermeld werd, dit gewoon een industry standaard betreft. En daar staat voor ICMP wel enkele zaken beschreven/omschreven. Maar goed, ik begrijp dat dit dan nog niet per definitie een industry standaard betreft. Grappig want als je zoekt op internet industry standard dan is er ook niet echt op het eerste oog een standaard te vinden. Heeft T-Mobile dan niet nu plotsklaps gewoon een industry standard bedacht? :joy:

 

Zoals hier boven al gezegd prima als t-mobile niet wil laten zien hoe hun eigen netwerk eruit ziet.

Maar het verbergen / niet inzichtelijk maken van netwerken van andere partijen ….

Juist en vooral dat maakt het een zaak die stinkt. Dat je, binnen je eigen infrastructuur zaken verbergt c.q. niet wilt delen/prijsgeven snap ik dan nog wel… maar het “hele” internet is naast dat het op zwaar achterbakse wijze heeft plaatsgevonden, gewoonweg onnodig en zelfs eigenlijk gewoon onacceptabel.

 

​​​​​​Maar goed om te weten dat t-mobile zich aan de 'industry standard’ houd en de rest van de wereld niet. 

Voor een klein overzichtje van netwerken dat zich dan niet aan de 'industry standard’  houd.….

En langzaam aan leren we de ware T-Mobile NL aard kennen.

 

 

@Gerrit078 kan je delen hoever jij komt met dit verhaal. Gezien jij contact het via de mail. (een van de andere wegen die t-mobile zelf aanbied om in contact te komen..)

Volgens https://www.t-mobile.nl/klantenservice#contact heb je 3 opties tot contact. Lijkt me handig dat ze dan deze opties ook allemaal juist ondersteunen.….

 

Ik ben verder nog niet benaderd aangezien het wat tijd in beslag kon nemen. Achteraf gezien snap ik ook waarom het tijd in beslag kan nemen, van interne communicatie of een systeem waarin dergelijke wijzigingen worden bijgehouden, is dus eigenlijk gewoon geen sprake. Als het nou bij interne communicatie zou blijven zou ik het nog niet eens zo heel erg vinden, maar het feit dat bepaalde besluiten zijn genomen zonder dat de consument daarvan is geïnformeerd geeft toch wel een hele vieze nasmaak.

Dat verklaart dan ook wel waarom de persoon die ik laatst sprak redelijk gedeprimeerd over kwam… 

 

Reputatie 3

@Brian Aanvullend op wat @Thomas_R hierboven al zegt, en ik in mijn uiteenzetting hierboven:

Zoals Thomas stelt is de huidige manier een fix met schijnveiligheid. Met een IP Record Route ping kun je dit al omzeilen, met dus ook een aantal hops intern uit het T-Mobile netwerk.

jk-5@pc-jeffrey:~$ ping -R antennekaart.nl
PING antennekaart.nl (178.251.25.37) 56(124) bytes of data.
64 bytes from antennekaart.nl (178.251.25.37): icmp_seq=1 ttl=60 time=25.4 ms
RR: pc-jeffrey.vl220.7815xg-32.as64516.net (172.24.136.16)
69-101-145-85.ftth.glasoperator.nl (85.145.101.69)
10.10.10.254 (10.10.10.254)
t-mobilethuis.interxionams5.nl-ix.net (193.239.117.50)
178.251.25.2 (178.251.25.2)
antennekaart.nl (178.251.25.37)
antennekaart.nl (178.251.25.37)
interracks.previder-pdc2.nl-ix.net (193.239.116.140)
10.10.12.53 (10.10.12.53)

Omdat het 10.x.x.x adressen zijn zijn ze niet benaderbaar vanaf het internet, en vormt het in dit geval niet echt een beveiligingsrisico. Maar omdat hier wordt afgeweken van de “industry standard” manier om hops te verbergen in een traceroute, namelijk het filteren van ICMP, wordt hier iets over het hoofd gezien waardoor het gestelde doel niet wordt bereikt.

Dit is vanuit mij een extra argument om het anders op te lossen. De huidige manier werkt niet betrouwbaar en is irritant voor de klanten die dit inzicht willen hebben. In mijn ogen is het beter om deze TTL filtering op te heffen en het op de normale manier te doen, door te voorkomen dat het corenetwerk ICMP verstuurt naar klanten en naar het internet.

Reputatie 7

Dit klinkt meer naar security by obsecurity.

laten we dan ook iedereen maar niet een extern ip geven. dat is veiliger…..

Debuggen is gewoon totaal niet meer mogelijk op deze manier. en om nou te zeggen dat T-Mobile hier goed in is kan ik ook niet echt zeggen. zorg eerst er maar eens voor dat je zelf de zaken op orde heb!

ik heb hier dan ook geen goed woord voor over…. zou wel eens willen spreken met die gene die dit heeft bedacht. (die zou het eens van uit een andere hoek moeten bekijken)

Dit klinkt meer naar security by obsecurity.

laten we dan ook iedereen maar niet een extern ip geven. dat is veiliger…..

Precies wat ik al aangaf, met hoe T-Mobile zich meer en meer gedraagt zal het niet meer de vraag worden of maar wanneer T-Mobile overgaat tot NAT'ted verbindingen. Blijkbaar zijn ze tot alles toe in staat!

zorg eerst er maar eens voor dat je zelf de zaken op orde heb!

Het nadeel is, dat T-Mobile meer en meer bewijst dat het geen zaken op orde heeft en niet in staat is deze ook werkelijk in orde te hebben. Ze willen een grote speler in de markt worden maar door eigen achterlijke fouten en gebrek aan communicatie maken ze zichzelf steeds minder geliefd.

 

ik heb hier dan ook geen goed woord voor over…. zou wel eens willen spreken met die gene die dit heeft bedacht. (die zou het eens van uit een andere hoek moeten bekijken)

Kijkende naar hoe er gedacht en gehandeld wordt krijg ik sterk de indruk dat we het hebben over wat lui die ooit het woord “beveiliging” hebben horen vallen … je weet wel, wel de klok horen luiden maar niet weten waar de klepel hangt.

Weet je wat echt niet industry-standard is? Je niet houden aan je eigen gedragscode voor transparantie:

https://www.t-mobile.nl/Consumer/media/pdf/klantenservice/netwerk-en-bereik/gedragscode-transparantie-internetsnelheden.pdf

En het ergste is nog, dit is dan een gedragscode welke onderling is afgesproken voor zover ik mij kan herinneren en waar je eigenlijk in principe weinig waarde aan kunt hechten. Het is tenslotte niet zo dat er consequenties tegenover zullen staan wanneer je (zoals T-Mobile) te beroerd bent om consumenten te informeren. Wettelijk is het echter wel in de wet ‘netneutraliteit’ vastgesteld dat je bij dergelijke beslissingen verplicht bent de consument te informeren. Lees; 

Een open internet is belangrijk zodat alle consumenten vrij toegang hebben tot dezelfde informatie. Ook is het goed voor de ontwikkeling van nieuwe internetdiensten, zoals ‘video on demand’.

 

En ook dat vertikt T-Mobile !

In principe kan en mag je ICMP - het verrichten van traceroutes - als “informatie” beschouwen. Het geeft je inzicht en informatie hoe een route enigszins verloopt en kan zelfs informatie prijs geven wanneer zich ergens in die routering één of meerdere problemen voordoen.

 

 

Reputatie 4

Aangezien er Bij T-Mobile nul intentie is om het snel op te pakken heb ik zelf maar wat onderzoek gedaan en de dubbele hops lijken te komen door een slechte TTL afhaneling. Iets dat overigens ook een negatief effect op het netwerk kan hebben omdat de routers letterlijk dubbel werk staan te doen zonder enige reden daartoe door een slechte configuratie.

Iets wat ik als ik T-Mobile was dus even snel zou op pakken.  Maarja snel en T-Mobile wie houd wie voor de gek.

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is.

 

Gatverdamme, dit klinkt een beetje dezelfde smoes die providers ook veelal gebruiken wanneer ze hun jaarlijkse tarieven verhogen. Alles onder het mom van verbeteringen en beveiligen, hoewel er op T-Mobile na wereldwijd hooguit een handje vol providers zijn die dit soort (eigenlijk, schijnheilige) praktijken uithalen.

Dit alleen al zet mij eigenlijk aan het denken over hoe ver T-Mobile nog kan of juist zal gaan om onder het mom van “beveiligen” zaken door te voeren. Volgende stap wellicht iedereen achter een NAT’ted verbinding of zelfs surfen via een proxy server van T-Mobile?

. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

Zelfs met het verbergen blijven er risico's, iedere malloot die het voorziet op een gateway pakt gewoon IP-Adressen binnen de subnets die eindigen op .1 of .254.

En zelfs al is het geen industry standard, voor zover ik mij kan herinneren wordt er in de netneutraliteit niet expliciet gesproken over een standaard. Over standaarden heb ik weinig kaas gegeten, wel weet ik dat ICMP standaard onderdeel is van internet en is gespecificeerd bij de IETF. En ook dan nog geldt… dit soort zaken horen op voorhand te worden gecommuniceerd, 

Uw internetaanbieder moet zorgen dat het internetverkeer goed verloopt. Hij mag maatregelen nemen om problemen te voorkomen. Deze maatregelen moeten redelijk en begrijpelijk zijn. Ze moeten in verhouding staan tot de problemen die de aanbieder wil voorkomen.

Ze mogen geen onderscheid maken naar inhoud of toepassingen. En uw aanbieder moet u vertellen welke gevolgen deze maatregelen kunnen hebben voor de kwaliteit van uw internettoegang, uw privacy en de bescherming van uw persoonsgegevens.

 

Niet gebeurt, net zo min als de problematiek rondom DTAG of de deal met het CBS (remember). Of wat te denken van deze?

 

Internetaanbieders mogen geen diensten blokkeren, vertragen of beperken. Bijvoorbeeld als het gaat om apps waarmee je gratis kunt bellen of berichten kunt sturen. Ook moeten internetaanbieders voor het verbruik van alle data hetzelfde rekenen. Dus ze mogen er niet meer, maar ook niet minder voor vragen.

Een open internet is belangrijk zodat alle consumenten vrij toegang hebben tot dezelfde informatie. Ook is het goed voor de ontwikkeling van nieuwe internetdiensten, zoals ‘video on demand’.

 

Wellicht toch maar een paar tientjes extra per maand gaan betalen bij een provider die transparant is… Een niet transparante provider is nou niet echt iets waar ik mee door één deur kan.

Reputatie 2

@Brian, industry-standard? welke Nederlandse providers verbergen nog meer de route die data aflegt voor klanten die vreemde afwijkingen constateren in de prestaties van hun intrernetverbinding?  

 

Weet je wat echt niet industry-standard is? Je niet houden aan je eigen gedragscode voor transparantie:

 

https://www.t-mobile.nl/Consumer/media/pdf/klantenservice/netwerk-en-bereik/gedragscode-transparantie-internetsnelheden.pdf

 

 

Reputatie 3

@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

 

Heen weg:

                                           My traceroute  [v0.92]
signet01.ring.nlnog.net (81.21.136.3)                                               2021-03-19T11:09:21+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                    Packets               Pings
 Host                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS28878  son-er-dc1.signet.nl (81.21.136.254)                  0.0%    94    0.6   4.7   0.4 115.0  13.5
 2. AS28878  ams-cr2-sara.v92.signet.nl (217.21.246.50)            0.0%    93    1.9   5.7   1.8  15.7   3.9
 3. AS49685  ams-cr1-gls.tc.signet.nl (80.246.207.238)             0.0%    93    2.5   2.6   2.3   4.1   0.3
 4. AS49685  be10-300.cr1.nkf.as49685.net (80.246.207.249)         0.0%    93    3.8   2.9   2.4   5.1   0.6
 5. AS???    80.249.211.184 (80.249.211.184)                       0.0%    93    3.0   3.1   2.9   5.3   0.3
 6. ???
 7. AS50266  XXX-XXX-XXX-XXX.ftth.glasoperator.nl (XXX.XXX.XXX.XXX)  0.0%    93    7.8   8.0   7.6  24.1   1.7

Hop 4 -5 is van signet over de ams-ix naar de t-mobile thuis router die aan de ams-ix hangt.

(https://www.ams-ix.net/ams/connected-networks?search=thuis om het adres te controleren van t-mobile)

Terug weg:

                             My traceroute  [v0.93]
MV-Mac (172.17.102.2)                                  2021-03-19T12:11:34+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%    11    7.6   4.3   1.3   7.8   3.2
 2. AS50266  1-16-144-85.ftth.glasop  0.0%    11    2.5   2.7   2.4   4.2   0.5
 3. AS28878  signet01.ring.nlnog.net  0.0%    10   16.2  12.9   8.9  16.2   3.3

 

De hops die je op de terugweg niet ziet zijn in de trace erboven 1 tot 5

Het MPLS netwerk van t-mobile loopt zeker niet over de ams-ix dwars door het netwerk van signet heen alleen voor het verkeer van t-mobile naar signet.

find / replace signet door wie dan ook.

 

voorbeeld naar een node in Japan.

                                          My traceroute  [v0.93]
MV-Mac (172.17.102.2)                                                            2021-03-19T12:21:20+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%    63    1.5   2.1   1.3   9.1   1.8
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)     0.0%    63    2.7   3.9   2.4   9.4   2.1
 3. AS2914   61.200.92.132 (61.200.92.132)                      0.0%    62  239.6 250.1 235.4 347.9  35.6

vs

                                           My traceroute  [v0.92]
ntt03.ring.nlnog.net (61.200.92.132)                                               2021-03-19T11:21:42+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                   Packets               Pings
 Host                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS2914   61.200.92.129 (61.200.92.129)                       19.2%    53    0.5   1.6   0.1   9.1   2.7
 2. AS2914   ae-22.r02.tokyjp05.jp.bb.gin.ntt.net (129.250.4.7)   0.0%    53   93.1  93.2  93.1  93.4   0.1
 3. AS2914   ae-3.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.3.23)  71.7%    53    0.5   1.0   0.4   5.9   1.5
 4. AS2914   ae-5.r24.sttlwa01.us.bb.gin.ntt.net (129.250.4.142) 30.2%    53   85.6  82.8  81.5  89.5   1.7
 5. AS2914   ae-28.r05.sttlwa01.us.bb.gin.ntt.net (129.250.2.45)  0.0%    53   82.0  82.2  81.8  93.2   1.5
 6. AS2914   ae-0.level3.sttlwa01.us.bb.gin.ntt.net (129.250.9.1  0.0%    52   87.4  88.2  87.1 100.2   2.2
 7. AS3356   ae1.3115.edge7.London1.level3.net (4.69.166.2)       0.0%    52  220.7 222.3 220.4 240.5   4.3
 8. AS3356   195.16.163.234 (195.16.163.234)                      0.0%    52  229.9 229.9 229.7 230.3   0.1
 9. ???
10. AS50266  247-232-201-31.ftth.glasoperator.nl (31.201.232.247  0.0%    52  234.4 234.3 234.3 234.4   0.0

 

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

Bedankt voor het doorsturen van de uitleg van je netwerk collega’s.

Het filteren van ICMP pakketten in netwerkverkeer om zo IP adressen van jullie routers te verbergen is schijnveiligheid (“security by obscurity”). Het zal het aanvallers misschien iets lastiger maken maar er zijn voldoende andere manieren voor aanvallers om deze IP adressen van jullie routers alsnog te achterhalen zoals kijken naar de edge routers, rDNS records, oude traceroutes van jullie klanten die overal op het internet rondzwerven, (poort)scans op jullie IP reeksen, etc.

Hoe verkeer binnen jullie netwerk wordt gerouteerd maakt mij niet zoveel uit, dus prima om ICMP uit te zetten op jullie eigen routers. Het zou wel netjes zijn om ICMP verkeer dat buiten jullie netwerk komt niet actief te filteren. Dat maakt netwerkproblemen troubleshooten een stuk makkelijker.

Reputatie 1

@Boris gaat hier nog een oplossing voor komen ?

Reputatie 1

@Brian Hoop toch echt dat hier nog naar gekeken gaat worden! Dit kan zo natuurlijk niet.

Reputatie 1

Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is.

Onzin. Geen van de andere access ISP’s manipuleert TTL zodanig dat het complete pad vernaggeld wordt. Het bemoeilijkt troubleshooting en breekt applicaties. Er zijn andere manieren om dit soort risico’s te verminderen.

Oh, en jullie benadelen hier enkel jullie eigen klanten mee. Van buiten is het pad tot jullie netwerk (zelfs tot het apparaat bij de klant) gewoon zichtbaar. Daar kunnen jullie niets aan veranderen.

Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar.

Dit is geen verbetering. Dat het idee niet is teruggefloten is zorgwekkend en dat deze uitvoering uberhaupt in gang is gezet is een teken van uiterste incompetentie. 

Get your stuff together. Haal het NOC weer in-house met competente mensen die weten wat ze doen.

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

Reputatie 7

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!

Reputatie 4

Ze lijken het gevonden te hebben! De dubbele hops zijn weg. EUREKA… nu de upload nog breed aanpakken en we zijn er weer na bijna 7 maanden.

Toch mooi dat we die tracerts hebben om dit soort problemen te vinden… Vind je ook niet T-Mobile?

Reputatie 7

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

 

@Brian Dan wordt dit dus de reden dat ik het abonnementga opzeggen. 

me2

 

De route heen is niet direct de route terug.

en de route heen (uit klant oogpunt) is niet meer te zien. maar de route terug.

 

Op de route terug. (laat ik eens wat routes langs AMS-IX nemen) zie ik ook wat vreemde zaken…..

 

@Brian bedankt voor je input. Voor velen nu duidelijk dat t-mobile thuis wel het goedkoopste is maar dat je daarvoor wel wat moet inleveren. Maar voor veel huis tuin en keuken gebruikers voldoende is.

 

 

Reputatie 7

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! 

Reageer