Jak czytać traceroute: dlaczego straty na 5. skoku zwykle nic nie znaczą

Jak czytać traceroute: dlaczego straty na 5. skoku zwykle nic nie znaczą

Strona działa wolno, ktoś uruchamia traceroute i proszę: 40 procent strat na skoku 5. Wygląda na odpowiedź. Prawie nigdy nią nie jest, a działanie na jej podstawie wysyła ludzi w pogoń za routerem, który pracuje bez zarzutu.

Traceroute to naprawdę przydatne narzędzie zbudowane na sztuczce, i właśnie ta sztuczka sprawia, że tak łatwo źle odczytać jego wynik.

Co traceroute robi naprawdę

Wysyła pakiety z celowo małym TTL. Pierwszy router zmniejsza je do zera, poddaje się i odsyła komunikat ICMP Time Exceeded. To z tej odpowiedzi dowiadujesz się, że router istnieje. TTL 2 daje drugi i tak dalej, aż pakiety dotrą do celu.

Każdy wiersz poza ostatnim nie mierzy więc twojego ruchu. Mierzy, jak szybko router zechciał wygenerować komunikat o błędzie dotyczący twojego ruchu. To dwie różne rzeczy, a routery traktują je różnie.

Dlaczego środkowe skoki kłamią

Generowanie odpowiedzi ICMP nie jest zadaniem routera. Przekazywanie pakietów odbywa się sprzętowo; odpowiadanie na wygasły TTL obsługuje warstwa sterowania, czyli znacznie słabszy procesor z ważniejszymi zadaniami. Większość routerów ogranicza tempo takich odpowiedzi, a część odrzuca je w całości.

Efekt to skok pokazujący 40 procent strat przy przepuszczaniu 100 procent ruchu. Wynikają z tego dwie zasady, które od ręki zamykają większość takich zgłoszeń:

• Strata, która nie utrzymuje się do końca, nie jest stratą. Jeśli skok 5 pokazuje czterdzieści procent, a skoki od 6 do 12 zero, nic nie przepadło. Skok 5 po prostu nie miał ochoty odpowiadać.
• Liczy się tylko ostatni wiersz. Utrzymująca się strata na celu jest prawdziwa. To ta liczba zasługuje na eskalację.

Skok z wysokim opóźnieniem zachowuje się tak samo. Router, który wolno odpowiada na własne ICMP, niekoniecznie wolno przekazuje ruch.

Połowa, której nie widzisz

Traceroute pokazuje drogę tam. O drodze powrotnej nie mówi nic, a bywają one różne: twoje pakiety mogą wychodzić przez jednego operatora tranzytowego, a odpowiedzi wracać przez innego. W internecie to normalne i nie jest usterką.

Ma to znaczenie, bo szukany problem może w całości leżeć na drodze powrotnej, której twój traceroute w ogóle nie widzi. Dlatego jednokierunkowy pomiar zwykle kończy się prośbą wsparcia o więcej danych zamiast naprawą: brakuje połowy dowodów.

Z tego samego powodu rozwiązanie czasem leży w sieci, która nie jest ani twoja, ani nasza. Gdy prowadzi się własny AS i sesje BGP, drogę powrotną ruchu można poprawić u operatorów wyżej, a nie tylko wyjaśnić.

Sięgnij po mtr

mtr to traceroute i ping w jednym. Wysyła bez przerwy, więc widzisz stratę jako procent w czasie, a nie zgadywankę z trzech prób:

mtr -rwzbc 200 dcxv.com

• -r tryb raportu, drukuje raz i kończy
• -w szeroki wynik, żeby długie nazwy nie były ucinane
• -z pokazuje numer AS każdego skoku, czyli czyja to sieć
• -b pokazuje nazwę i IP naraz
• -c 200 wysyła 200 prób, bo 10 nic nie powie o stratach przerywanych

W Windows tę samą robotę wykonuje WinMTR. Daj mu pracować kilka minut, zanim cokolwiek z niego wyczytasz.

Co wysłać do wsparcia

Najbardziej przydatną rzeczą do załączenia jest mtr w obie strony: jeden z twojej maszyny do serwera i jeden z serwera do twojego adresu, zrobione w tym samym czasie. Ta para zmienia jednostronny domysł w coś, co da się przypisać konkretnej sieci.

Dołóż docelowe IP, swój publiczny adres, godzinę wraz ze strefą czasową oraz to, czy problem jest stały, czy pojawia się i znika. Jeśli pojawia się i znika, napisz kiedy. Straty z dobowym rytmem to zwykle przeciążenie gdzieś po drodze, a znajomość godziny szybko zawęża poszukiwania.

Co nie pomaga: zrzut jednego traceroute z czerwonym kółkiem wokół środkowego skoku. To najczęstszy załącznik i najmniej użyteczny.

Podsumowanie

Czytaj ostatni wiersz, nie środkowe. Strata, która nie utrzymuje się do celu, to router odmawiający odpowiedzi, a nie sieć gubiąca twój ruch. Kiedy naprawdę coś jest nie tak, mtr w obie strony zamienia skargę w raport, z którym da się pracować.

Serwery cloud i dedykowane w Czechach i Portugalii, we własnej sieci AS204057: dcxv.com/data-center#cloud