mtr vs traceroute

Traceroute i mtr to narzędzia wiersza poleceń służące do diagnozowania problemów ze ścieżkami sieciowymi. Traceroute daje ci jednorazową migawkę trasy, którą pokonują twoje pakiety. mtr robi to samo, ale ciągle sonduje, budując statystyki dotyczące utraty pakietów, opóźnień i jittera w czasie. W tym poście omówiono działanie każdego z narzędzi, sposób odczytywania danych wyjściowych i kiedy należy ich używać.

Jak działa traceroute

Traceroute wykorzystuje pole Time-to-Live (TTL) w nagłówkach pakietów IP. Wysyła pakiet z TTL ustawionym na 1. Pierwszy router zmniejsza TTL do zera, porzuca pakiet i odsyła komunikat ICMP "Time Exceeded". Traceroute rejestruje adres IP routera i czas podróży w obie strony, a następnie wysyła kolejny pakiet z TTL ustawionym na 2 i tak dalej, aż pakiet dotrze do miejsca docelowego lub osiągnie maksymalny limit przeskoków (domyślnie 30, regulowany za pomocą -m).

Domyślnie traceroute wysyła trzy sondy na przeskok, dając trzy odczyty opóźnienia. Protokoły różnią się w zależności od systemu operacyjnego:

• Windows: Polecenie tracert wysyła żądania ICMP Echo.
• Linux/macOS: Polecenie traceroute wysyła datagramy UDP (porty 33434-33534). Użyj -I dla ICMP lub -T dla TCP, jeśli UDP jest zablokowany.

Dodanie flagi -n pomija odwrotne wyszukiwanie DNS, co znacznie przyspiesza działanie na ścieżkach z wieloma przeskokami.

Jak działa mtr

mtr (My Traceroute) używa tego samego wykrywania ścieżki opartego na TTL co traceroute, ale ciągle wysyła sondy, zazwyczaj jedną na sekundę. Zamiast trzech punktów danych na przeskok, otrzymujesz bieżące statystyki: procent utraty pakietów, średnie opóźnienie, najlepszy i najgorszy czas odpowiedzi oraz odchylenie standardowe (jitter).

mtr obsługuje sondy ICMP (domyślnie), UDP i TCP SYN. Tryb TCP jest przydatny, gdy zapory sieciowe blokują ICMP lub gdy chcesz przetestować określony port aplikacji:

mtr --tcp --port 443 example.com

Aby uzyskać nieinteraktywny raport, który można udostępnić zespołowi pomocy technicznej, należy użyć trybu raportu:

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

Uruchamia on 100 sond i drukuje podsumowanie. Możesz także ustawić niestandardowe rozmiary pakietów za pomocą --psize, aby przetestować MTU lub fragmentację.

mtr działa natywnie w systemach Linux i macOS. Użytkownicy systemu Windows mogą użyć WinMTR dla odpowiednika GUI.

Kluczowe różnice

Praktyczna różnica sprowadza się do sporadycznych problemów. Pojedynczy traceroute może łatwo przeoczyć router, który upuszcza 2% pakietów lub hop z 15ms jitterem. mtr wyłapuje te problemy, ponieważ stale dokonuje pomiarów.

Czytanie danych wyjściowych

Najczęstszym błędem podczas czytania danych wyjściowych traceroute lub mtr jest założenie, że problematycznie wyglądający pośredni przeskok oznacza prawdziwy problem. Zazwyczaj tak nie jest.

Gwiazdki (*) w traceroute oznaczają, że router nie odpowiedział na sondę. Wiele routerów jest skonfigurowanych do ignorowania lub ograniczania szybkości ICMP. Jeśli kolejne węzły odpowiadają normalnie, ścieżka jest w porządku.

Utrata pakietów w pojedynczym przeskoku w mtr jest zgodna z tą samą logiką. Jeśli przeskok 5 wykazuje utratę 20%, ale ostateczne miejsce docelowe wykazuje 0%, router ten po prostu depriorytetyzuje odpowiedzi sondy. Prawdziwa utrata pakietów objawia się jako wzorzec: utrata pojawia się w jednym przeskoku i utrzymuje się przez każdy kolejny przeskok do miejsca docelowego.

Skoki opóźnienia między przeskokami są normalne i oczekiwane. Skok z 10 ms do 80 ms zwykle oznacza, że pakiet przekroczył ocean lub długą trasę lądową. Należy martwić się opóźnieniami tylko wtedy, gdy są one niezwykle wysokie w stosunku do odległości (poniżej 5 ms w obszarze metra, dziesiątki milisekund w kraju, 80-150 ms w transoceanicznym) lub jeśli opóźnienie w miejscu docelowym jest niedopuszczalne.

Warto zwrócić uwagę naStDev (jitter) w mtr. Wartości powyżej 10 ms na każdym przeskoku mogą powodować problemy z VoIP, połączeniami wideo i grami. Jeśli zauważysz wysoki jitter, wykonaj co najmniej 100 cykli, aby potwierdzić, że jest to stały wzorzec, a nie krótki skok.

Kiedy używać poszczególnych narzędzi

Używaj traceroute, gdy potrzebujesz szybkiej odpowiedzi: czy miejsce docelowe jest osiągalne, a jeśli nie, to gdzie ścieżka się urywa? Jest to właściwy punkt wyjścia w przypadku awarii i weryfikacji podstawowego routingu.

Użyj mtr, gdy problem jest przerywany lub związany z wydajnością. Użytkownicy zgłaszający sporadyczne rozłączenia, problemy z jakością VoIP lub skoki opóźnień potrzebują ciągłych danych mtr. Aby uzyskać wiarygodne statystyki, należy wykonać co najmniej 50-100 cykli.

Aby uzyskać dokładną diagnozę, uruchom mtr w obu kierunkach: od komputera do serwera i od serwera z powrotem do swojego adresu IP. Routing internetowy jest asymetryczny, więc ścieżka powrotna może mieć zupełnie inną charakterystykę. Jeśli przetestujesz tylko jeden kierunek, możesz przeoczyć, gdzie faktycznie występuje problem.

Jeśli masz problemy z serwerem dedykowanym lub VPS, zespoły wsparcia FDC Servers akceptują raporty mtr jako standardowy dowód diagnostyczny dla eskalacji sieci.