Beantwoord

Graag weer een volledige MTR / Traceroute / Sniffing / DPI

  • 28 januari 2021
  • 18 reacties
  • 646 Bekeken

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 Boris 10 februari 2021, 12:29

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! 

Bekijk origineel

18 reacties

Dit probleem heb ik ook in Nijmegen sinds gisteren middag. @Brian 

Reputatie 3

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

Reputatie 4
Badge +2

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!

Reputatie 3

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

Reputatie 7
Badge +2

@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

Reputatie 3

@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

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

Reputatie 4
Badge +2

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! 

Reputatie 3

@Boris een idee wanneer je weer kan vragen om een MTR als iemand problemen meld?

@Boris gaat hier nog een oplossing voor komen ?

Reputatie 4
Badge +2

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

Reputatie 4
Badge +2

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! 

 

Reputatie 1

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

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

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:

 

 

Reageer