Graag weer een volledige MTR / Traceroute / Sniffing / DPI

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

Trace zonder TTL verandering

                                                             My traceroute  [v0.92]
signet01.ring.nlnog.net (81.21.136.3)                                                                                  2021-02-02T11:24:45+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                       Packets               Pings
 Host                                                                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. son-er-dc1.signet.nl                                                                              0.0%     7    3.9   3.6   0.4   8.2   3.2
 2. ams-cr2-sara.v92.signet.nl                                                                        0.0%     7   13.4   5.5   1.8  13.4   4.2
 3. ams-cr1-gls.tc.signet.nl                                                                          0.0%     7    2.6   2.5   2.3   2.6   0.1
 4. be10-300.cr1.nkf.as49685.net                                                                      0.0%     7    4.0   4.3   2.6  11.8   3.4
 5. a3718.as49685.atom86.net                                                                          0.0%     7    3.8   3.3   2.4   5.4   1.1
 6. available.atom86.net                                                                              0.0%     7    2.5   3.6   2.4   6.4   1.6
 7. ???
 8. i-1008.ulcn-core01.telstraglobal.net                                                              0.0%     7   16.9  16.8  16.7  16.9   0.1
 9. 202.84.249.174                                                                                    0.0%     7   83.1  81.7  80.3  83.1   1.2
10. i-10748.paix-core02.telstraglobal.net                                                             0.0%     7  147.0 148.3 147.0 149.0   0.7
11. i-37.sydo-core03.telstraglobal.net                                                                0.0%     7  286.8 287.1 286.4 288.1   0.7
12. bundle-ether3.oxf-gw11.sydney.telstra.net                                                         0.0%     7  285.4 286.0 285.4 286.5   0.4
13. bundle-ether1.chw-core10.sydney.telstra.net                                                       0.0%     7  287.3 287.3 286.6 287.7   0.3
14. bundle-ether1.chw-edge903.sydney.telstra.net                                                      0.0%     7  286.1 286.3 286.1 286.6   0.2
15. ama3305026.lnk.telstra.net                                                                        0.0%     7  286.3 286.5 286.2 287.1   0.3
16. ???
17. ???
18. ???
19. ???
20. ???
21. ???
22. ???
23. ???
24. ???
25. ???
26. ???
27. amazon08.ring.nlnog.net                                                                           0.0%     6  286.9 286.9 286.9 287.0   0.0

@Boris Hierbij wat meer informatie vanuit mij.

Vooralsnog krijg ik elke 6-15 pakketten een timeout naar de meeste ip adressen.

Aparte TTL

Pinging google.com [142.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 [172.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 [31.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 [81.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 [81.21.136.3]

Hoop dat je hier wat aan hebt.

@mdanielsnl 

TTL is bepaald door de OS of type device.

Common TTL values

• Router - 255
• Windows - 128
• Linux-Mac - 64

Default Time To Live (TTL) values

Hier ook hetzelfde issue:

 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. fritz.box                                             0.0%     9    0.4   0.4   0.4   0.5   0.0
 2. 1-224-145-85.ftth.glasoperator.nl                     0.0%     9    2.0   1.9   1.7   2.2   0.2
 3. dns.google                                            0.0%     9    6.6   6.6   6.4   7.0   0.2

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

met als mrt:

                                       My traceroute  [v0.93]
MV-Mac (192.168.206.70)                                                    2021-02-02T15:10:34+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                           Packets               Pings
 Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    192.168.206.216 (192.168.206.216)            0.0%     3   13.1  14.7   3.6  27.5  12.0
 2. (waiting for reply)
 3. (waiting for reply)
 4. (waiting for reply)
 5. (waiting for reply)
 6. AS31615  84.241.225.42 (84.241.225.42)                0.0%     2  156.3 156.3 156.3 156.3   0.0
 7. AS15169  72.14.196.142 (72.14.196.142)                0.0%     2   52.0  52.0  52.0  52.0   0.0
 8. AS15169  108.170.241.193 (108.170.241.193)            0.0%     2  510.3 510.3 510.3 510.3   0.0
 9. AS15169  108.170.236.139 (108.170.236.139)            0.0%     2  404.9 404.9 404.9 404.9   0.0
10. AS15169  dns.google (8.8.8.8)                         0.0%     2  299.6 299.6 299.6 299.6   0.0

is.

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 ?

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

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?

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

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:

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.

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;

Start: 2021-03-08T16:33:26+0100
HOST: anonymous                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS50266  143.178.32.1         0.0%     4    2.8   2.9   2.7   3.0   0.1
  2. AS35916  173.82.121.xxx       0.0%     4  155.3 155.8 155.3 156.7   0.7

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;

Start: 2021-03-08T16:37:21+0100
HOST: ns2                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS35916  72.44.73.193         0.0%     4    0.3   2.9   0.3  10.3   4.9
  2. AS35916  72.44.66.201         0.0%     4    0.9   1.3   0.9   2.1   0.5
  3. AS174    38.99.219.57         0.0%     4    0.7   0.7   0.7   0.9   0.1
  4. AS174    154.54.40.146        0.0%     4   12.9  13.0  12.9  13.1   0.1
  5. AS174    154.54.5.102         0.0%     4   13.4  13.5  13.4  13.6   0.1
  6. AS174    154.54.11.206        0.0%     4   11.1  13.1  11.0  19.0   3.9
  7. AS1273   195.2.24.98          0.0%     4  153.0 152.9 152.6 153.0   0.2
  8. AS1273   195.2.31.6           0.0%     4  155.1 155.0 154.3 155.3   0.5
  9. AS1273   195.2.28.37          0.0%     4  145.2 145.5 145.2 145.6   0.2
 10. AS1273   195.2.3.245          0.0%     4  157.0 157.8 154.8 160.6   2.5
 11. AS1273   217.161.69.142       0.0%     4  154.8 154.9 154.8 154.9   0.0
 12. AS???    ???                 100.0     4    0.0   0.0   0.0   0.0   0.0
 13. AS50266  143.178.xxx.xxx       0.0%     4  155.7 155.3 155.1 155.7   0.3

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.

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

Traceroutes in MPLS Networks: TTL Propagation & ICMP Tunneling

@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