Beantwoord

Tracepath (Traceroute) gaat niet verder dan de gateway? gefiltert ?

  • 25 January 2021
  • 12 reacties
  • 310 Bekeken

Ik ben even aan het testen waar ik af en toe vertraging ervaar. Ik gebruik eerst een tracepath/route ( Linux) als eerste stap, maar merk dat vermoedelijk binnen de gateway een filter staat die dat verder filtert?

 

 tracepath www.solcon.nl
 1?: [LOCALHOST]                      pmtu 1500
 1:  home                                                  1.871ms
 1:  home                                                 21.172ms
 2:  1-224-20-31.ftth.glasoperator.nl                     85.930ms
 3:  no reply
 4:  no reply

 

 

icon

Beste antwoord door Pieter_B 25 January 2021, 11:48

Bekijk origineel

12 reacties

Reputatie 7
Badge +3

Hallo @Galactus6 

Bij mijn weten is er geen filtering op bepaalde netwerk discovery tools, maar het zou kunnen zijn dat er gewoon geen response terug komt.

Zelf gebruik ik vaker nmap, omdat die op meer detail zaken kan laten zien over de host welke je probeert aan te roepen.

NMAP output

Starting Nmap 7.60 ( https://nmap.org ) at 2021-01-25 11:26 CET
….
Initiating Traceroute at 11:27
Completed Traceroute at 11:27, 0.02s elapsed
….

TRACEROUTE (using port 443/tcp)
HOP RTT     ADDRESS
1   0.18 ms de pfsense box
2   2.84 ms xx-xx-143.ftth.glasoperator.nl (143.xx-xx
3   6.37 ms www.solcon.nl (212.45.32.29)

/NMAP output

Tracepath is een afgeleide van traceroute, maar kijkt ook naar de MTU. Denk dat daar het probleem ook door komt dat hij op hops ‘no reply’ geeft, omdat hij geen MTU kan vaststellen.

Lukt het wel met traceroute?

Hallo @Pieter_B , dank voor je tip.

 

Ik heb NMAP geinstalleerd hier zijn de test resultaten , bedraad direct op de router:

 

 ping 1-224-20-31.ftth.glasoperator.nl
PING 1-224-20-31.ftth.glasoperator.nl (31.20.224.1) 56(84) bytes of data.
64 bytes from 1-224-20-31.ftth.glasoperator.nl (31.20.224.1): icmp_seq=1 ttl=254 time=3.15 ms
64 bytes from 1-224-20-31.ftth.glasoperator.nl (31.20.224.1): icmp_seq=2 ttl=254 time=26.9 ms
64 bytes from 1-224-20-31.ftth.glasoperator.nl (31.20.224.1): icmp_seq=3 ttl=254 time=3.49 ms
64 bytes from 1-224-20-31.ftth.glasoperator.nl (31.20.224.1): icmp_seq=4 ttl=254 time=35.8 ms
64 bytes from 1-224-20-31.ftth.glasoperator.nl (31.20.224.1): icmp_seq=5 ttl=254 time=3.34 ms
64 bytes from 1-224-20-31.ftth.glasoperator.nl (31.20.224.1): icmp_seq=6 ttl=254 time=4.02 ms

 

sudo nmap -p 443 --traceroute www.google.com

TRACEROUTE (using port 443/tcp)
HOP RTT      ADDRESS
1   27.67 ms home (192.168.1.1)
2   48.22 ms 1-224-20-31.ftth.glasoperator.nl (31.20.224.1)
3   50.07 ms ams15s40-in-f4.1e100.net (172.217.168.228)

Nmap done: 1 IP address (1 host up) scanned in 0.49 seconds

 

TRACEROUTE (using port 443/tcp)
HOP RTT      ADDRESS
1   1.56 ms  home (192.168.1.1)
2   4.28 ms  1-224-20-31.ftth.glasoperator.nl (31.20.224.1)
3   27.34 ms ams15s40-in-f4.1e100.net (172.217.168.228)

Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds

 

(Google servers zijn bij uitstek geschikt ivm hun capaciteit in zowel bandbreedte als bechikbare sessies)

 

Ik denk dat dit er wel goed uit ziet. ( op een paar uitschieters na).

 

 

 

Reputatie 7
Badge +3

@Galactus6 

Tijden zijn afhankelijk van de drukte binnen het netwerk, hierdoor ontstaan altijd schommelingen.

Mijn pfSense box 24/7 ping deamon, met eigenlijk een constante RTT rond de 2.8ms.

@Pieter_B, wat mij ook verder opviel is dat de DNS servers die standaard in de Router staan ingesteld regelmatig een time-out geven. ( op het moment van DNS timeout dan reageren ze nog wel op een ping maar de DNS service zelf reageert dan op dat moment niet).

 

Ik heb nu de Google DNS servers ingevoerd .

Stukken beter, geen time-outs meer!

Misschien is de vraag niet helemaal hier op zijn plek.

Heb een website draaien die ik verhuisd heb naar een andere host.
Er zijn wat hindernissen die opgelost moeten worden echter mijn vraag gaat over het volgende:

 1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    14 ms    12 ms    14 ms  1-24-174-82.ftth.glasoperator.nl [82.174.24.1]
  3    17 ms    17 ms    17 ms  varnish3.zxcs.nl [185.104.28.118]

Volgens mijn hostingprovider missen hier een paar hops.

Glasoperator -> server varnish3.zxcs.nl. Dat klopt niet, dat kan niet. Er mist een hop naar hun router, en naar de router van hun internetprovider.

Klopt het hier bovenstaande?

Hoor het graag.

Mvgr,

Rense

Misschien is de vraag niet helemaal hier op zijn plek.

Heb een website draaien die ik verhuisd heb naar een andere host.
Er zijn wat hindernissen die opgelost moeten worden echter mijn vraag gaat over het volgende:

 1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    14 ms    12 ms    14 ms  1-24-174-82.ftth.glasoperator.nl [82.174.24.1]
  3    17 ms    17 ms    17 ms  varnish3.zxcs.nl [185.104.28.118]

Volgens mijn hostingprovider missen hier een paar hops.

Glasoperator -> server varnish3.zxcs.nl. Dat klopt niet, dat kan niet. Er mist een hop naar hun router, en naar de router van hun internetprovider.

Klopt het hier bovenstaande?

Hoor het graag.

Mvgr,

Rense

Ik heb het zelfde euvel..

Als je ergens naartoe pingt krijg je alleen de hop naar de Tmobile gateway te zien, daarna kom je meteen op de destination uit.

Kan het zijn dat Tmobile de traceroutes manipuleert? Dit is nog niet lang het geval namelijk..

Reputatie 7
Badge +3

@Miguel44 

Neem aan dat er aktieve klachten of problemen zijn op je verbinding, of is het gewoon een constatering die je deelt?

Dus het probleem op je verbinding is mij / ons niet helemaal duidelijk?

Komt verkeer niet aan, of websites onbereikbaar?

@Miguel44

Neem aan dat er aktieve klachten of problemen zijn op je verbinding, of is het gewoon een constatering die je deelt?

Dus het probleem op je verbinding is mij / ons niet helemaal duidelijk?

Komt verkeer niet aan, of websites onbereikbaar?

Ik ervaar geen problemen op dit moment.

Het valt me wel op dat het sinds ongeveer een maand niet meer mogelijk is om traceroutes te doen.
Dit maakt het soms wel lastig om dingen te troubleshooten.

Is er een reden dat Tmobile dit aangepast heeft?

Reputatie 7
Badge +3

@Miguel44

Reden is mij onbekend.

Maar als er een device op de route zit die de TTL niet verlaagt , zal je hem dus niet zien verschijnen in je route.

Maar ik krijg het gevoel dat ze zijn overgestapt op MPLS … dat zou het in mijn zin kunnen verklaren naar mijn bescheiden mening.

Hier een huis tuin en keuken uitleg van ‘de basis’ hoe MPLS werkt

 

@Miguel44

Reden is mij onbekend.

Maar als er een device op de route zit die de TTL niet verlaagt , zal je hem dus niet zien verschijnen in je route.

Maar ik krijg het gevoel dat ze zijn overgestapt op MPLS … dat zou het in mijn zin kunnen verklaren naar mijn bescheiden mening.

Hier een huis tuin en keuken uitleg van ‘de basis’ hoe MPLS werkt

 

Jep.. zon vermoeden kreeg ik ook al.

@Miguel44

Neem aan dat er aktieve klachten of problemen zijn op je verbinding, of is het gewoon een constatering die je deelt?

Dus het probleem op je verbinding is mij / ons niet helemaal duidelijk?

Komt verkeer niet aan, of websites onbereikbaar?

Pieter,

In sommige gevallen komt ligt de site ineens plat, niet vanuit de hosting kant, en na een paar minuten is het er weer.
Dat was eerder de reden dat ik een paar keer een traceroute heb gedaan en constateerde dat er een aantal hops er gewoon niet waren. (en nog steeds niet)
Feit blijft dus dat er een paar hops niet zijn wat wel zo hoort te zijn.

Reputatie 7
Badge +3

@Rense01 

Die HOPS zijn er ook wel, maar als ze zijn overgestapt / of upgraded naar MPLS, dan verklaart dat een hoop waarom je alleen het begin .. en het eind nog maar ziet.

De TTL counter staat dus kompleet los van MPLS, hierdoor kun je dus ergens zijn met een TTL van 3 .. terwijl er een tig tal hops tussen zitten. Dit geeft aan dat de device onderweg dit pakket dus niet aanpassen, maar min of meer ‘ongezien’ doorsturen naar het eindadres.

Dat je site plat ligt, ligt deze dan alleen plat voor TMT klanten of ook via andere ISP’s? Als het alleen maar via TMT thuis verbindingen is, dan zou je i.d.d. eens met TMT in de bocht moeten hoe dat kan.

Reageer