mtr vs traceroute

Traceroute och mtr är båda kommandoradsverktyg för att diagnostisera problem med nätverksvägar. Traceroute ger dig en ögonblicksbild av den väg som dina paket tar. mtr gör samma sak men fortsätter att sondera och bygger upp statistik över paketförlust, latens och jitter över tid. Det här inlägget beskriver hur varje verktyg fungerar, hur man läser utdata och när man ska använda vilket.

Hur traceroute fungerar

Traceroute använder TTL-fältet (Time-to-Live) i IP-paketens huvuden. Den skickar ett paket med TTL inställt på 1. Den första routern minskar TTL till noll, släpper paketet och skickar tillbaka ett ICMP-meddelande "Time Exceeded". Traceroute registrerar routerns IP och tur- och returtiden, skickar sedan ett nytt paket med TTL inställd på 2, och så vidare tills paketet når destinationen eller når den maximala hoppgränsen (30 som standard, justerbar med -m).

Som standard skickar traceroute tre prober per hopp, vilket ger dig tre latensavläsningar. Protokollen skiljer sig åt beroende på operativsystem:

• Windows: Kommandot tracert skickar ICMP Echo Requests.
• Linux/macOS: Kommandot traceroute skickar UDP-datagram (portarna 33434-33534). Använd -I för ICMP eller -T för TCP om UDP är blockerat.

Om du lägger till flaggan -n hoppar du över omvända DNS-uppslagningar, vilket snabbar upp saker och ting märkbart på vägar med många hopp.

Hur mtr fungerar

mtr (My Traceroute) använder samma TTL-baserade sökväg som traceroute, men den fortsätter att skicka prober, vanligtvis en per sekund. I stället för tre datapunkter per hopp får du löpande statistik: procentuell paketförlust, genomsnittlig latens, bästa och sämsta svarstid samt standardavvikelse (jitter).

mtr stöder ICMP- (standard), UDP- och TCP SYN-prober. TCP-läget är användbart när brandväggar blockerar ICMP eller när du vill testa en specifik applikationsport:

mtr --tcp --port 443 example.com

För en icke-interaktiv rapport som du kan dela med ett supportteam använder du rapportläget:

mtr --report --report-cycles 100 example.com

Detta kör 100 prober och skriver ut en sammanfattning. Du kan också ställa in anpassade paketstorlekar med --psize för att testa MTU- eller fragmenteringsproblem.

mtr körs inbyggt på Linux och macOS. Windows-användare kan använda WinMTR för en GUI-ekvivalent.

Viktiga skillnader

Den praktiska skillnaden handlar om intermittenta problem. En enda traceroute kan lätt missa en router som tappar 2% av paketen eller en hop med 15 ms jitter. mtr fångar upp dessa eftersom den fortsätter att mäta.

Läsning av utdata

Det vanligaste misstaget när man läser traceroute- eller mtr-utdata är att man antar att ett mellanliggande hopp som ser problematiskt ut innebär att det finns ett verkligt problem. Det gör det vanligtvis inte.

Asterisker (*) i traceroute betyder att routern inte svarade på proben. Många routrar är konfigurerade att ignorera eller hastighetsbegränsa ICMP. Om hoppen efter det svarar normalt är vägen bra.

Paketförlust vid ett enda hopp i mtr följer samma logik. Om hopp 5 visar 20% förlust men slutdestinationen visar 0%, nedprioriterar den routern bara sondsvar. Verklig paketförlust visar sig som ett mönster: förlust visas vid ett hopp och kvarstår genom varje efterföljande hopp till destinationen.

Latencyhopp mellan hopp är normala och förväntade. Ett hopp från 10 ms till 80 ms betyder vanligtvis att paketet har korsat ett hav eller en lång landväg. Oroa dig bara för latensen om den är ovanligt hög för avståndet (under 5 ms inom ett tunnelbaneområde, tiotals millisekunder över land, 80-150 ms över havet) eller om latensen vid slutdestinationen är oacceptabel.

StDev (jitter) i mtr är värt att uppmärksamma. Värden över 10 ms vid varje hop kan orsaka problem för VoIP, videosamtal och spel. Om du ser hög jitter, kör minst 100 cykler för att bekräfta att det är ett ihållande mönster och inte en kort spik.

När ska du använda respektive verktyg?

Använd traceroute när du behöver ett snabbt svar: går det att nå destinationen, och om inte, var bryts vägen? Det är rätt utgångspunkt vid avbrott och för att verifiera grundläggande routing.

Använd mtr när problemet är intermittent eller prestandarelaterat. Användare som rapporterar enstaka frånkopplingar, problem med VoIP-kvalitet eller latensökningar behöver mtr:s kontinuerliga data. Kör minst 50-100 cykler för att få tillförlitlig statistik.

För en noggrann diagnos bör du köra mtr i båda riktningarna: från din maskin till servern och från servern tillbaka till din IP. Internet-routning är asymmetrisk, så returvägen kan ha helt andra egenskaper. Om du bara testar i en riktning kan du missa var problemet faktiskt finns.

Om du har problem med din dedikerade server eller VPS accepterar FDC Servers supportteam mtr-rapporter som standarddiagnostiska bevis för nätverkseskaleringar.