Beantwoord

Graag weer een volledige MTR / Traceroute / Sniffing / DPI

Toon eerste reactie

110 reacties

Brian
Rank
Reputatie 7

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

Ik ben per 4-11-2021 niet meer werkzaam als Moderator op de Community. Ik zal eventuele privéberichten daarom niet meer kunnen beantwoorden maar mijn collega's helpen je graag! :)
A

ik blijf na mijn werk (onder kantoortijd geen tijd) hangen in een chatbot en verder geen mailadres bij de contact opties.

 

“Zelf gisteren maar een e-mail gestuurd naar T-Mobile nadat een klantenservice me”

 

iets om te delen ?

 

Wat ik al aangaf, staat hier onderin

Top bedankt. had ik even gemist kennelijk. heb ze gemaild. ik ben benieuwd wat het antwoord is op het manipuleren van die routes.

 

A

ik blijf na mijn werk (onder kantoortijd geen tijd) hangen in een chatbot en verder geen mailadres bij de contact opties.

 

“Zelf gisteren maar een e-mail gestuurd naar T-Mobile nadat een klantenservice me”

 

iets om te delen ?

 

Wat ik al aangaf, staat hier onderin

A

ik blijf na mijn werk (onder kantoortijd geen tijd) hangen in een chatbot en verder geen mailadres bij de contact opties.

 

“Zelf gisteren maar een e-mail gestuurd naar T-Mobile nadat een klantenservice me”

 

iets om te delen ?

 

 

A

Als Boris de t-mobile moderator meld :

“Dank jullie wel voor het aangeven van de situatie! Ik ga dit graag voor jullie oppakken”

en

“Ik heb onze experts gevraagd om dit issue te bekijken en een onderzoek uit te sturen”

 

En daarop heeft Boris dan dus ook een reactie gekregen en gegeven. Uit één van de berichten blijkt ook dat dit rechtstreeks aan IT kenbaar is gemaakt waar de BO (lees; niet de klantenservice dus), blijkbaar niet van op de hoogte was of is (gebracht).

Het is dus eerder vreemd dat de BO het tegenovergestelde zegt en zelfs bij weer een aantal achterliggende afdelingen - alwaar men contact mee gehad heeft - ook niets bekend is en er vanuit geen enkele TMT staff member sindsdien geen enkele berichtgeving meer is geweest.

A

Als Boris de t-mobile moderator meld :

“Dank jullie wel voor het aangeven van de situatie! Ik ga dit graag voor jullie oppakken”

en

“Ik heb onze experts gevraagd om dit issue te bekijken en een onderzoek uit te sturen”

 

Dan lijkt het me niet slim het nogmaals te gaan melden. toch ?

1 iemand (boris de t-mobile moderator) heeft het op zich genomen dit aan te melden voor initieel een 3 tal personen (en wat zich daar nog bijvoegt). 

 

Er word nu gesproken dat de klantenservice “van niks” weet. de 2 quotes kunnen dus de prullenbak in ?

 

Maar ik zal er eens een mooie mail van maken.

 

UPDATE: klantenservice is niet te mailen (dus benieuwd naar het adres) en rondjes in de bot draaien is nou ook niet wat ik wil.

 

 

 

 

 

A

Die gemanipuleerde routes zijn knap k…. toch echt nodig voor analyses . Heb niks meer aan tools als mtr etc. alles in 1 hop bereikt. ja ja.

Tijd om verder te gaan kijken naar een andere partij.

  

Wat let je om een e-mail te sturen en je probleem inclusief screenshots kenbaar te maken? De community is er voor en door iedereen maar niet bedoeld voor dit soort zaken - blijkt achteraf.

Zelf heb ik gisteren weer contact gehad met T-Mobile, waarna vanuit de backoffice is gecommuniceerd dat webcare hen nimmer een ticket gestuurd heeft en deze mogelijk rechtstreeks bij IT schijnt te zijn ingeschoten. Dat soort tickets zijn vaak “storingsmeldingen” die op een andere wijze en prioriteit worden opgepakt dan wanneer dit via de 1e en 2e lijn backoffice gaat. Storingsmelding is, dienst {abc} werkt of dienst {abc} werkt niet. Werkt het? “No issues, ticket closed!". In principe had de geen (webcare) die het ticket had ingeschoten, dit op voorhand moeten weten!

Blijkbaar wordt er intern ook niet echt (veel) waarde gehecht aan de community aangezien er wel vaker issues blijven liggen die - wanneer de juiste weg zou zijn bewandeld - allang opgelost hadden kunnen zijn. Tussen neus en lippen door werd mij ook verteld dat; “de community is ooit in gebruik genomen om een enorme druk op de klantenservice te beperken/voorkomen omdat mensen onder elkaar vaak een voor hun passende oplossing kunnen vinden”. Of te wel, interpreteer het op deze wijze: Het is een stuk goedkoper als mensen elkaar onderling helpen dan extra mankracht in te zetten op de klantenservice. Advies hierin was dan dus ook om bij dit soort zaken “nooit” het forum te gebruiken maar gewoon een e-mail te sturen.

 

Maar feit blijft, als niemand verder een e-mail stuurt naar de klantenservice (zodat ze dit kunnen doorsturen naar de BO), dan kan het probleem nog wel enige tijd blijven liggen. Zoals men in deze thread tenslotte ziet, zit T-Mobile er nou niet echt serieus bovenop.

A

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! 

 

hahaha. die is goed. de traceroutes die komen aan dus er is niks aan de hand. Komt het probleem:

Het woord “traceroute” is om de route te tracen. En de route is door aanpassingen niet meer te tracen. Dus ja de traceroute komt aan, maar tracet niet meer.  ;-)

Dus je kan beter zeggen, als de andere kant icmp toelaat dan werk Ping nog en komt aan. Maar een traceoute laat geen route meer zien= STUK. 

 

Een traceroute “komt niet aan”  en als je het dan toch zo slecht wil verwoorden. Dan spreken we dus overt een traceroute die op zijn route de tussenliggende punten niet meer aankomt en zo die niet laat zien. Dus in deze lijn. “nee hij komt niet meer aan”, te slecht dit….

 

Sinds kort is Nieuw Zeeland voor mij in een hop bereikbaar. ;-) ben benieuwd hoe ik daar technisch in een hop kom.

 

Maar het technische antwoord zegt genoeg. de vertaling is “we willen hier niet over communiceren”. Dat had alles wel duidelijker gemaakt.

 

Niks te klagen hoor. prijs is goedkoop, verbinding is goed. (in mijn geval) maar verder blijven dit vreemde dingen. En als netwerkbeheerder zie ik graag hoe de routes vanaf thuis naar de door mij beheerde netwerken lopen. 

 

Maja Ziggo ook lekker bezig met hun DS-lite implementaties, zo loopt er bij elke provider wel wat…. 

 

 

 

 

 

 

A

Die gemanipuleerde routes zijn knap k…. toch echt nodig voor analyses . Heb niks meer aan tools als mtr etc. alles in 1 hop bereikt. ja ja.

Tijd om verder te gaan kijken naar een andere partij.

 

 

A

@Brian iets wijzer geworden?

Zelf gisteren maar een e-mail gestuurd naar T-Mobile nadat een klantenservice medewerkster mij erop attendeerde dat dit een stuk beter zou zijn.

Ergens ook te begrijpen, de community is tenslotte voor en door klanten dus echt hulp of ondersteuning van een T-Mobile medewerker hoef je niet te verwachten.

Mijn e-mail bestond uit een grafiek alwaar te zien was wat het aantal hops betrof naar diverse targets en dat deze in Januari compleet instortte. Daaropvolgend ook een aantal traceroutes toegevoegd… deze traceroutes betroffen zowel van mijn T-Mobile Thuis verbinding naar diverse servers. Maar ook vanaf die servers naar mijn T-Mobile Thuis verbinding.

Zo heb ik bijvoorbeeld een traceroute gedaan vanaf mijn aansluiting naar 23.94.101.88 en met behulp van de Looking Glass van diezelfde server naar mijn thuis verbinding. Zelfde kun je overigens ook doen als je ergens een server hebt natuurlijk, mtr naar die server en mtr vanaf die server naar jezelf.

 

Vandaag al teruggebeld (nog geen 24 uur later) 

 

De mail heb ik trouwens gestuurd naar het klantenservice e-mail adres die sommigen inmiddels wel kennen of kunnen vinden in de Algemene Voorwaarden. (E-mail adres vermeld ik niet in dit topic om spam e.a. ellende te voorkomen).

M
Reputatie 3

@Pieter_B je kan prima een MPLS netwerk invoeren waardoor je tussenliggende hops kwijt raakt.

Echter raak je dan alleen de hops kwijt binnen je eigen MPLS netwerk.

Alles daarbuiten zal niet moeten verdwijnen.

Als ik jouw trace aanpas naar een mpls versie.

verwacht ik het in het softlayer netwerk 1  hop te zien. Namelijk hop 2

Hop 10 is een router die aan de AMS-IX hangt. (dus buiten het MPLS netwerk van softlayer, als ze die zouden hebben.)
Hop 11 is de router in het netwerk van signet.

 

Qua netwerken heb je hier Softlayer -  AMS-IX - Atom86 - Signet

 

Heen weg:

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

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

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

Terug weg:

                             My traceroute  [v0.93]
MV-Mac (172.17.102.2)                                  2021-03-19T12:11:34+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.  0.0%    11    7.6   4.3   1.3   7.8   3.2
 2. AS50266  1-16-144-85.ftth.glasop  0.0%    11    2.5   2.7   2.4   4.2   0.5
 3. AS28878  signet01.ring.nlnog.net  0.0%    10   16.2  12.9   8.9  16.2   3.3

 

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

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

find / replace signet door wie dan ook.

 

voorbeeld naar een node in Japan.

                                          My traceroute  [v0.93]
MV-Mac (172.17.102.2)                                                            2021-03-19T12:21:20+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                 Packets               Pings
 Host                                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS???    172.17.102.254 (172.17.102.254)                    0.0%    63    1.5   2.1   1.3   9.1   1.8
 2. AS50266  1-16-144-85.ftth.glasoperator.nl (85.144.16.1)     0.0%    63    2.7   3.9   2.4   9.4   2.1
 3. AS2914   61.200.92.132 (61.200.92.132)                      0.0%    62  239.6 250.1 235.4 347.9  35.6

vs

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

 

Pieter_B
Rank
Reputatie 7
Badge +3

@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

LET OP gewoon Medeklant. Glasvezel sinds 2016 (1Gb and never needs more) - Linux gebruiker sinds 2006 ( Current: Kubuntu mantic 23.10 )- DIY Router/Firewall: pfSense 2.7.0 met 4 port INTEL NIC & Switch Unifi 8 poort 60w POE & Switch Unifi 8 poort & Wifi Unifi AP-AC Pro
R

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.

M
Reputatie 3

@Brian iets wijzer geworden?

A

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

M
Reputatie 1

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

A

Hallo heren @Mdevries @mdanielsnl @DirkTe  ,

Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering. 

Volgens mij zegt ook nergens iemand niet hier - maar zelfs ook niet op Tweakers - dat de trace routes niet aan komen maar dat ze gelimiteerd worden in wat ze in werkelijkheid behoren te zijn. Precies wat @ijansen dus al zegt… je wordt (net als menig consument al geruime tijd wordt) van het kluitje in het riet gestuurd.

 

Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag! 

 

Doordat alle tussenliggende routes/switches worden verborgen is het voor menigeen niet langer mogelijk om te zien of een website of andere dienst niet bereikt kan worden door een storing bij T-Mobile, een tussenliggende partij of zelfs bij de partij alwaar de website of andere dienst zich bevind.

Een mooi voorbeeld met een Virtual Private Server (VPN) die ik voor deze ellende maar even besteld heb bij een toko waarbij je kunt garanderen dat ze geen directe verbinding hebben met T-Mobile en dus geen peering overeenkomsten hebben waardoor gebruik gemaakt wordt van Transit partijen;

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.

joerif
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:

 

 

H
Reputatie 4

Hallo heren @Mdevries @mdanielsnl @DirkTe  ,

Ik heb zojuist vernomen dat het onderzoek wat is uitgezet bij onze IT specialisten is gesloten. De terugkoppeling die ik heb ontvangen hierover, is dat de trace routes aankomen en dat er daardoor geen problemen zijn aan de routering. 

Ik begrijp dat dit niet het antwoord is wat duidelijkheid geeft en wil daarom kijken hoe we het best het probleem kunnen aankaarten. Ik wil jullie daarom vragen om na te gaan hoe de problemen met de trace hops zich manifesteren. Hoe ervaar je het probleem en hoe zie je dit terug? Op die manier kunnen we het concreter maken voor onze specialisten en werken naar een oplossing voor jullie. Ik hoor het graag! 

 

Deze hele Tracert die om zeep geholpen is (ik heb niet de illusie dat dit een oepsie is) ruikt, wat stinkt naar het dom houden van de klant. Door dit te verbergen kunnen wij niet meer controleren welke routes data afleg en waar mogelijk problemen zich voor doen wat niet alleeen nadelig is voor de klant maar ook voor de troubleshooting data die wij aan T-Mobile kunnen leveren… Alsof dat nog niet erg genoeg is heeft T-Mobile in 2019 geprobeerd de consument te bedonderen met een DTAG routing en daar was VEEL backlash op omdat het grootschalige problemen gaf van slechte latency tot packetloss en jawel slechte snelheden.
En laat dit allemaal nou precies samen vallen met vele klachten over mensen met een slechte upload de laatste maanden… Vreemd he?
Deze niet functionerende Tracing ruikt dan ook gewoon naar het bedonderen van de klanten en het onmogelijk maken voor de klant om T-Mobile eerlijk te houden.

Beetje net zoals transvet in je chips stoppen maar de label veranderen naar een chinees dialect die niet leesbaar is zodat niemand weet dat er transvet in zit.
 

Uiteindelijk is de klant slimmer en komen we er toch wel achter en dan betaalt T-Mobile weer de prijs. Vroeg of laat leidt dit geklier met de verbinding tot een class action…

 

Wees gewoon eerlijk en open want niemand trapt in dit geklets.

If it sounds like a duck, walks like a duck, and quacks like a duck its most likely a duck. 

En dit eendje moet gewoon snel gewassen worden net als Het DTAG eendje.

Niks persoonlijks Boris maar dat aan het lijntje houden is zo 1800 en dat hangt gewoon niet prettig.

Fijne dag en laat je AUB niet afschepen want dat doen wij ook niet. Zoek het desnoods hogerop onze steun heb je.

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

I
Reputatie 2

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

Boris
Rank
Reputatie 7

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! 

 

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

Boris
Rank
Reputatie 7

Hoi @Mdevries @mdanielsnl ,

Ik kom zojuist uit een vergadering met onze technische dienst waarbij ik de problemen met de 3 hops heb aangekaart. Dankzij jullie hulp hebben we het probleem duidelijk en goed in kaart kunnen brengen en is er een onderzoek gestart en gaan onze netwerkspecialisten opzoek naar de oplossing. Dank daarvoor! Ik hoop jullie snel van een update te kunnen voorzien. Hebben jullie vragen in de tussentijd, laat het mij weten. Ik zit voor jullie klaar!

M
Reputatie 1

@Boris gaat hier nog een oplossing voor komen ?

Reageer


ForumvoorwaardenCookie instellingen