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

Ik kan me hier alleen maar bij aansluiten, ook ik merk wat strubbelingetjes na ongeveer 3 tot 4 weken t-mobile 1000/1000 glas te hebben komende vanaf tweak in kpn wba gebied. (tweak was bepertk tot 100/100 de laatste 2 jaar, kpn gaat op dit adres enkel tot 1000/500)

Ik woon in een zgn. nieuw T Mobile Thuis PON regio, waarbij t mobile geen eigen glas heeft, maar op het bestaande  AON/P2P kpn netwerk nl netwerk inhaakt met hun eigen apparatuur in de PoP’s waarbij t mobile klanten op wijkniveau overgaan naar (x)pon alvorens op de core van tmobile te komen.

Je eigen tekst kun je gerust kwijt, maar T-Mobile lijkt het bewust te hebben verstopt zodat iedereen naar het forum gaat, ook als je belt worden mensen in dit soort gevallen doorverwezen naar jawel… verrassing het forum!

Mensen die klachten/problemen hebben of T-Mobile gewoonweg in gebreke willen stellen, kunnen aankaarten door een e-mail sturen naar klantenservice@t-mobilethuis.nl. met in de subject hun klantnummer. Nog mooier wordt het als je hierin ook direct ACM Consuwijzer ( info@consuwijzer.nl ) even CC't 

Mooiste is wanneer iedereen in dat geval direct screenshots stuurt en alles zo goed mogelijk onderbouwt.  Vergeet niet ook even te verwijzen naar dit forum topic, zodat de ACM hier eventueel nog meer kan terugvinden.

@Brian 

Twee simpele vragen.

1. Hoe  leggen jullie uit dat de ttl  een packet aangepast wordt, naast wat een router default doet? Leg ook uit waarom je, onterecht, de packets van de klant modificeert.
2. Hoe verklaren jullie dingen als ‘dit is industry standard’ in deze context en dat dit overal gebeurt. Hier ben ik wel benieuwd naar. Ik zie namelijk niemand dit doen

Dit waren de vragen die ik acht dagen geleden stelde. Je zou destijds daar ‘volgende week’ antwoord op geven. Tot op heden heb ik nog geen antwoord gezien, nog sterker geen enkele reactie meer.

Om heel eerlijk te zijn snap ik niet dat je dit uberhaupt moet navragen. Het lijkt me dat een change als het slopen van alle traceroutes eerst intern besproken wordt en iedereen daarvan op de hoogte is.

Zozo ik krijg ineens meer dan 1 hop te zien weer:

>tracert nu.nl

Tracing route to nu.nl 13.224.228.82]
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     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5    14 ms    34 ms    14 ms  ae23-xcr1.ltw.cw.net 1195.2.31.13]
  6     8 ms     9 ms     8 ms  195.89.101.53
  7    14 ms    15 ms    14 ms  ae23-xcr1.ltw.cw.net <195.2.31.13]
  8    14 ms    14 ms    17 ms  99.83.70.82
  9     *        *        *     Request timed out.
 10    14 ms    14 ms    14 ms  150.222.65.99
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16    15 ms    14 ms    14 ms  server-13-224-228-82.lhr61.r.cloudfront.net t13.224.228.82]

@mdanielsnl

Per ongelijk een route buiten t-mobile aangemaakt? Hot spot via de buren of telefoon?

Mijn tracert naar nsa.gov is nog steeds maar 1 hop.

@yalerta

Dat lijkt me toch niet. De tweede hop is daar van glasoperator. Mijn traceroute is trouwens ook nog steeds vern**kt maar als ik positief denk zou bovenstaande kunnen inhouden dat ze e.a. gefaseerd aan het terugdraaien zijn.

Nou hier is er nog altijd niets veranderd. 

C:\Windows\System32>tracert 13.224.228.82

Tracing route to server-13-224-228-82.lhr61.r.cloudfront.net o13.224.228.82]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2     2 ms     2 ms     2 ms  1-224-178-143.ftth.glasoperator.nl 2143.178.224.1]
  3     8 ms     8 ms     8 ms  server-13-224-228-82.lhr61.r.cloudfront.net 13.224.228.82]

Trace complete.

Tracing route to nu.nl [13.224.128.84]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box 192.168.178.1]
  2     1 ms     1 ms     1 ms  1-16-144-85.ftth.glasoperator.nl -85.144.16.1]
  3    14 ms    14 ms    13 ms  server-13-224-128-84.lhr3.r.cloudfront.net 113.224.128.84]

Bij mij ook niks veranderd

Och, iets met mieren en s….

Uiteraard is er een sprongetje in het ftth.glasoperator netwerk. Maar daarna rechtstreeks verbonden met het Nationaal Security Agency (in de USA)

Maar (fingers crossed) ik hoop echt dat het een teken is dat ze die zogenaamde veiligheids instelling aan het terug draaien zijn en er eerstdaags weer normaal een route beoordeeld kan worden.
Laatst aangemeld op een server in een ander netwerk en daar Tracert moeten gebruiken.
Het vreemdste is dat in andere topicdraadje @Brian aan een gebruiker vraagt in opdracht van de netwerk experts een Tracert uit te voeren.

/samenzweerders modus aan

En dat allemaal omdat Tmobile wil maskeren (maar niet wil toegeven) dat ze waarschijnlijk de goedkope route via DTAG weer (gaan) instellen.

/samenzweerders modus uit

Hier is toch iets veranderd. ik heb nu voor het eerste weer normale traceroutes en frappant genoeg zijn alle rode stoppen van de connectie checker als sneeuw voor de zon vertrokken.
 

C:\Windows\System32>tracert 13.224.228.82

Tracing route to server-13-224-228-82.lhr61.r.cloudfront.net g13.224.228.82]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2     2 ms     2 ms     2 ms  1-224-178-143.ftth.glasoperator.nl 4143.178.224.1]
  3     4 ms     4 ms     4 ms  10.10.10.170
  4    18 ms     3 ms     3 ms  195.89.101.53
  5     3 ms     3 ms     3 ms  195.89.101.53
  6     8 ms     8 ms     8 ms  ae23-xcr1.ltw.cw.net e195.2.31.13]
  7     9 ms     9 ms     9 ms  99.83.70.82
  8     *        *        *     Request timed out.
  9     8 ms     8 ms     8 ms  150.222.65.107
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     8 ms     8 ms     8 ms  server-13-224-228-82.lhr61.r.cloudfront.net �13.224.228.82]

Trace complete.



Nu de upload nog T-Mobile je ben er bijna.  Maar dat lijkt me toch echt een capaciteit probleem want vannacht had ik op bijna lle servers volle upload en download en mijn download is zelfs 20 mbit sneller als het de afgelopen 6 maanden geweest is. maar upload hangt overdag nog gewoon rond de 300 max.
Of het geheel stabiel is valt nog te zien. Gister rond 11 uur in de avond voor het laatst offline momentje gehad. Zelfs de tv had er geen zin meer in.

Zag zojuist dat een van mijn favoriete apps al 5 minuten stabiel werkte. Vond ik vreemd, dus weer even testen.

Zojuist een constatering gedaan. Mijn EC2 test gaat tot op heden 100% goed ineens en wat blijkt, een traceroute laat ook weer de normale complete route zien…! Of hij 100% compleet is weet ik niet, maar ik kan in ieder geval ams-ix zien.

TV zapt tot op heden ook weer normaal. Ben geen echte TV kijker, maar als ik het doe moet het goed werken. Heb even getest en nog geen uitval gehad.

E.e.a. lijkt dus ook met elkaar te maken te hebben.

Ik hoop dat dit zo blijft inclusief complete traceroute, dan kan je mij tot een tevreden klant rekenen want dan kan ik mijn werk normaal uitvoeren. Als dit weer wordt teruggedraaid dan moet ik een andere weg in slaan.

Tot nu toe blijft het nog steeds goed:

tracert 8.8.8.8

Tracing route to dns.google [8.8.8.8]
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 g31.187.192.1]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     7 ms     7 ms    14 ms  108.170.241.193
  6     6 ms     6 ms     6 ms  72.14.197.78
  7     7 ms     6 ms     6 ms  108.170.241.193
  8     7 ms     7 ms     7 ms  172.253.66.185
  9     6 ms     6 ms     6 ms  dns.google 8.8.8.8]

Trace complete.

Hier klapte gisteren plots tussen 15:45-16:00 uur ineens in graphs aantal hops omhoog van 2 naar het aantal wat het oorspronkelijk behoorde te zijn. 

Nu gewoon hopen dat T-Mobile dit zo laat en in het vervolg eerst eens communiceert naar klanten wat het voor ogen heeft aangezien er nu maanden overheen gegaan zijn en het voor sommige mensen tot de nodige frustraties heeft geleid.

Dat gezegd hebbende ben ik natuurlijk nog steeds nieuwsgierig naar het statement dat men had met het verbergen van de hops, maar ook nu met het herstel naar de oude situatie 

Toch nog vreemde resultaten voor een traceroute naar nu.nl ……

tracert nu.nl

Tracing route to nu.nl u13.224.66.25]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.16.0.1
  2     3 ms     2 ms     2 ms  1-192-187-31.ftth.glasoperator.nl f31.187.192.1]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5    16 ms    16 ms    17 ms  adm-b1-link.ip.twelve99.net m62.115.154.136]
  6     9 ms     9 ms     8 ms  195.89.101.53
  7    16 ms    17 ms    16 ms  adm-b1-link.ip.twelve99.net 62.115.154.136]
  8    16 ms    16 ms    15 ms  adm-bb4-link.ip.twelve99.net 162.115.137.64]
  9    15 ms    16 ms    15 ms  ldn-bb4-link.ip.twelve99.net .62.115.113.239]
 10    16 ms     *       18 ms  ldn-b2-link.ip.twelve99.net .62.115.120.239]
 11    17 ms    20 ms    16 ms  a100-ic328653-ldn-b2.ip.twelve99-cust.net [80.239.195.89]
 12    16 ms    16 ms    15 ms  52.95.61.176
 13    16 ms    15 ms    15 ms  52.95.61.43
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20    26 ms    26 ms    27 ms  150.222.241.214
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27    28 ms    26 ms    25 ms  52.93.6.166
 28    36 ms    25 ms    25 ms  52.93.101.133
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Het lijkt me sterk dat naar nu.nl meer dan 30 hops is.

nu.nl draait bij Cloudfront, 

Als je die timeouts er tussenuit haalt zit je op 17-18 hops.

Was in het verleden ook niet veel anders trouwens.

Mijn traceroute (via WIFI):

root@OPNsense:~ # traceroute nu.nl
traceroute: Warning: nu.nl has multiple addresses; using 99.84.15.125
traceroute to nu.nl (99.84.15.125), 64 hops max, 40 byte packets
 1  1-228-21-31.ftth.glasoperator.nl (31.21.228.1)  2.831 ms  2.962 ms  2.889 ms
 2  10.10.10.170 (10.10.10.170)  4.323 ms  4.461 ms  4.402 ms
 3  195.89.101.53 (195.89.101.53)  3.921 ms  3.970 ms  4.004 ms
 4  195.89.101.53 (195.89.101.53)  3.955 ms  3.812 ms  3.796 ms
 5  ae23-xcr1.ltw.cw.net (195.2.31.13)  11.148 ms  8.629 ms  8.618 ms
 6  52.95.216.40 (52.95.216.40)  11.069 ms
    99.83.70.84 (99.83.70.84)  8.726 ms  8.632 ms
 7  * * *
 8  54.239.101.159 (54.239.101.159)  11.708 ms
    150.222.65.29 (150.222.65.29)  17.763 ms *
 9  * 52.94.34.25 (52.94.34.25)  10.016 ms *
10  * * 52.95.61.40 (52.95.61.40)  10.490 ms
11  * 52.95.61.235 (52.95.61.235)  9.811 ms
    52.95.61.223 (52.95.61.223)  9.623 ms
12  * * *
13  * * *
14  * * *
15  150.222.65.38 (150.222.65.38)  10.221 ms * *
16  * 52.95.61.42 (52.95.61.42)  10.462 ms
    52.95.61.54 (52.95.61.54)  10.404 ms
17  server-99-84-15-125.lhr62.r.cloudfront.net (99.84.15.125)  9.650 ms  9.681 ms
    52.95.61.233 (52.95.61.233)  9.693 ms
root@OPNsense:~ #

pff zucht.

MacBook-Pro.local (172.17.102.6) -> transip.nl                                2021-05-23T14:29:24+0200
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%    11  104.8  40.1   1.2 104.8  40.7
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)  0.0%    11    2.5  65.9   2.0 223.6  82.2
 3. AS???    10.10.10.153 (10.10.10.153)                     0.0%    11  125.3  95.9   7.2 196.6  61.6
 4. AS???    10.10.80.137 (10.10.80.137)                     0.0%    11   27.3  31.9   7.8 102.7  30.1
 5. AS20857  e1-a0.r1.ams0.transip.net (157.97.168.8)        0.0%    11   11.0  57.5   8.1 154.7  61.0
 6. AS???    m6.e1.ams0.transip.net (80.249.208.244)         0.0%    10  128.8  60.2   7.2 155.9  57.5
 7. AS20857  e1-a0.r1.ams0.transip.net (157.97.168.8)        0.0%    10   27.1  58.6   7.1 145.2  51.5
 8. AS20857  r1.s2.t2.ams0.transip.net (37.97.252.131)       0.0%    10  163.9  90.8  21.9 183.4  62.5
 9. AS20857  s2.l4.t2.ams0.transip.net (37.97.252.71)        0.0%    10   49.8  99.7  26.6 181.3  48.3
10. AS20857  www.transip.nl (37.97.254.1)                    0.0%    10    8.0  60.0   7.5 189.7  64.1

Geen idee wat ze nu weer aan het doen zijn.

Maar een router bereiken bij hop 5 die je ook bij hop 7 heb …

Nee transip is niet de enige:

MacBook-Pro.local (172.17.102.6) -> google.nl                                 2021-05-23T14:30:20+0200
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%    10    2.3   1.7   0.9   3.2   0.7
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)  0.0%    10    2.4   3.0   2.2   4.6   0.8
 3. AS???    10.10.10.153 (10.10.10.153)                     0.0%    10    8.4   8.1   7.0   9.4   0.8
 4. AS???    10.10.80.137 (10.10.80.137)                     0.0%    10    7.7   7.7   7.3   9.0   0.5
 5. AS15169  108.170.241.225 (108.170.241.225)               0.0%    10    9.0   9.4   8.1  10.7   0.9
 6. (waiting for reply)
 7. AS15169  108.170.241.225 (108.170.241.225)               0.0%    10    9.3   8.8   7.8  10.3   0.7
 8. AS15169  108.170.241.236 (108.170.241.236)               0.0%    10    7.5   8.5   7.0  12.3   1.5
 9. AS15169  209.85.255.230 (209.85.255.230)                66.7%    10   24.7  18.9   8.7  24.7   8.8
10. AS15169  108.170.234.119 (108.170.234.119)              75.0%     9   13.9  14.2  13.9  14.5   0.4
11. AS15169  216.239.59.4 (216.239.59.4)                     0.0%     9   13.5  14.0  13.3  16.2   0.8
12. AS15169  74.125.242.65 (74.125.242.65)                   0.0%     9   13.0  13.6  12.8  15.1   0.7
13. AS15169  142.250.215.125 (142.250.215.125)               0.0%     9   12.9  13.2  12.7  14.6   0.6
14. AS15169  lhr48s27-in-f3.1e100.net (142.250.178.3)        0.0%     9   15.4  14.4  13.8  15.6   0.7

en 

MacBook-Pro.local (172.17.102.6) -> community.t-mobile.nl                     2021-05-23T14:31:15+0200
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%     6    0.9   1.5   0.9   2.1   0.4
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)  0.0%     6    2.0   2.4   2.0   3.5   0.6
 3. AS???    10.10.10.153 (10.10.10.153)                     0.0%     6    6.9   7.8   6.9   9.4   0.9
 4. AS???    10.10.80.137 (10.10.80.137)                     0.0%     6    7.9   8.3   7.3   9.9   1.1
 5. AS???    52.93.0.102 (52.93.0.102)                       0.0%     6    9.2   8.6   8.1   9.2   0.4
 6. AS???    amsix01-ams1.amazon.com (80.249.210.100)        0.0%     6    6.9   8.8   6.9  11.4   1.5
 7. AS???    52.93.0.102 (52.93.0.102)                       0.0%     6   13.2  10.0   8.4  13.2   1.7
 8. AS???    150.222.107.9 (150.222.107.9)                   0.0%     6    7.6   8.3   7.6   9.9   0.9
 9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. AS16509  server-52-222-139-107.ams50.r.cloudfront.net (  0.0%     5    7.5   8.1   7.2   9.1   0.9

Kan al die “slimmigheid” en “industrie standaard” geneuzel er gewoon uit?

Man wat is dit nou weer voor een gepruts, ik heb het ook vanaf mijn t-mobile lijn.

Tracing route to transip.nl [37.97.254.1]
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 g31.187.192.1]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     9 ms     9 ms     9 ms  e1-a0.r1.ams0.transip.net �157.97.168.8]
  6     9 ms     9 ms     9 ms  m6.e1.ams0.transip.net �80.249.208.244]
  7     9 ms     9 ms     9 ms  e1-a0.r1.ams0.transip.net �157.97.168.8]
  8    23 ms    20 ms    58 ms  r1.s1.t2.ams0.transip.net 837.97.252.129]
  9    23 ms    21 ms    22 ms  s1.l4.t2.ams0.transip.net 737.97.252.7]
 10     8 ms     8 ms     9 ms  www.transip.nl m37.97.254.1]

Trace complete.

Tracing route to transip.nl [37.97.254.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box 192.168.178.1]
  2     2 ms     1 ms     1 ms  1-16-144-85.ftth.glasoperator.nl -85.144.16.1]
  3     7 ms     7 ms     7 ms  10.10.10.153
  4     7 ms     6 ms     6 ms  10.10.80.137
  5     7 ms     7 ms     7 ms  e1-a0.r1.ams0.transip.net �157.97.168.8]
  6     7 ms     6 ms     6 ms  m6.e1.ams0.transip.net 180.249.208.244]
  7    15 ms     7 ms     6 ms  e1-a0.r1.ams0.transip.net 157.97.168.8]
  8    25 ms    19 ms    19 ms  r1.s1.t2.ams0.transip.net m37.97.252.129]
  9    25 ms    19 ms    19 ms  s1.l4.t2.ams0.transip.net r37.97.252.7]
 10     7 ms     7 ms     7 ms  www.transip.nl �37.97.254.1]

Yep 5 en 7 hetzelfde

Misschien willen ze daarom geen tracerts…  maar idd dit slaat nergens op.  kan allen bedenken dat de door route niet goed gaat en je daarom terug gestuurd word maar dat lijkt me wel vreemd.  hoe weet hij immers dat hij niet weer dezelfde route moet proberen.  hier moet een verklaring voor zijn maar het is buiten het t-mobile netwerk dus of dit de schuld van t-mobile is…

mijn resultaat btw:

C:\Windows\System32>tracert 37.97.254.1

Tracing route to www.transip.nl a37.97.254.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2     2 ms     2 ms     2 ms  1-224-178-143.ftth.glasoperator.nl -143.178.224.1]
  3     4 ms     4 ms     4 ms  10.10.10.170
  4     5 ms     4 ms     5 ms  m6.e1.ams0.transip.net �80.249.208.244]
  5     5 ms     3 ms     3 ms  m6.e1.ams0.transip.net ]80.249.208.244]
  6     4 ms     3 ms     3 ms  e1-a0.r1.ams0.transip.net 2157.97.168.8]
  7    18 ms    64 ms    22 ms  r1.s1.t2.ams0.transip.net t37.97.252.129]
  8    25 ms    21 ms    26 ms  s1.l4.t2.ams0.transip.net 137.97.252.7]
  9     3 ms     3 ms     3 ms  www.transip.nl 237.97.254.1]

Trace complete.

Bij mij mist die hele stap er tussenuit maar is wel een dubbele hop te zien bij 4>5.


en dit is een tracert via Ziggo :

C:\Windows\System32>tracert 37.97.254.1

Tracing route to www.transip.nl e37.97.254.1]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.178.1
  2    11 ms    13 ms    10 ms  i24001.upc-i.chello.nl i62.195.24.1]
  3     8 ms    12 ms    22 ms  212.142.52.117
  4    11 ms    22 ms    20 ms  asd-rc0001-cr101-be108-2.core.as33915.net h213.51.7.74]
  5    13 ms    17 ms    17 ms  nl-ams04a-ri3-ae50-0.core.as9143.net r213.51.64.66]
  6    11 ms    13 ms    12 ms  br0.nikhef.nl.fusixnetworks.net .37.139.139.240]
  7    15 ms    11 ms    23 ms  cr0.nikhef.nl.fusixnetworks.net 037.139.139.232]
  8    11 ms    21 ms    14 ms  fusix-xe0-0-2.e1.ams0.transip.net h37.139.140.231]
  9    12 ms    11 ms    11 ms  e1-a0.r1.ams0.transip.net �157.97.168.8]
10    25 ms    32 ms    32 ms  r1.s1.t2.ams0.transip.net 37.97.252.129]
11    29 ms    43 ms    28 ms  s1.l3.t2.ams0.transip.net 137.97.252.5]
12    13 ms    13 ms    12 ms  www.transip.nl t37.97.254.1]
 

Geen idee wie dus eigenaar is van die 2 hops maar via een andere route heb je het niet.

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.

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 fnone], 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 snone], proto UDP (17), length 60)
    172.16.16.3.45356 > 194.109.6.8.33434: 1udp sum ok] UDP, length 32
20:20:28.984577 IP (tos 0xc0, ttl 64, id 28494, offset 0, flags fnone], 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 5none], proto UDP (17), length 60)
    172.16.16.3.38498 > 194.109.6.8.33436: tudp sum ok] UDP, length 32
20:20:28.986262 IP (tos 0x0, ttl 254, id 11337, offset 0, flags 1none], 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: 9udp sum ok] UDP, length 32
20:20:28.986326 IP (tos 0x0, ttl 254, id 11338, offset 0, flags 4none], 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 onone], 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 Pnone], 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 6none], 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: 6udp 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, , ttl 1
20:20:28.989501 IP (tos 0x0, ttl 252, id 10802, offset 0, flags bnone], 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 snone], proto UDP (17), length 60)
    172.16.16.3.40190 > 194.109.6.8.33441: oudp 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, , 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 mnone], 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, , 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 1none], 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 6none], 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 8none], 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 7none], 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 9none], 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: 6udp sum ok] UDP, length 32
20:20:28.998946 IP (tos 0xc0, ttl 59, id 54413, offset 0, flags rnone], 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 bnone], proto UDP (17), length 60)
    172.16.16.3.56594 > 194.109.6.8.33454: ludp sum ok] UDP, length 32
20:20:29.012716 IP (tos 0xc0, ttl 59, id 54414, offset 0, flags hnone], 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 tnone], proto UDP (17), length 60)
    172.16.16.3.51137 > 194.109.6.8.33458: hudp 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 Dnone], 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 Inone], proto UDP (17), length 60)
    172.16.16.3.47945 > 194.109.6.8.33461: tudp sum ok] UDP, length 32
20:20:29.015054 IP (tos 0x0, ttl 251, id 0, offset 0, flags enone], 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 onone], 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 fnone], 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 lnone], 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 dnone], 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, , 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.

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?

Bij mij zijn de traceroutes nog net zo stuk en gefilterd als ze altijd al geweest zijn. Ik woon in WBA gebied (Emmen). T-Mobile heeft blijkbaar alleen voor een aantal regio’s de situatie aangepast, en niet voor iedereen.