TRACEROUTE(8)

NAZWA
traceroute - drukuj trasę, którą przebiegają pakiety do hosta sieciowego

SKŁADNIA
traceroute [-m max_ttl] [-n] [-p port] [-q nqueries] [-r] [-s src_addr] [-t tos] [-w waittime] host [packetsize]

OPIS
Internet jest wielką i skomplikowaną agregacją sprzętu sieciowego, połączonego ze sobą poprzez bramki (gateways). Śledzenie trasy, którą podążają pakiety danej osoby (lub znajdywanie paskudnej bramki, odrzucającej twoje pakiety) może być trudne. Traceroute wykorzystuje pole `time to live' protokołu IP i próbuje wydobyć odpowiedź ICMP TIME_EXCEEDED od każdej bramki na drodze do określonego hosta.

Jedynym wymaganym parametrem jest nazwa hosta docelowego lub jego IP. Domyślny próbny datagram ma długość 38 bajtów, lecz może to być zwiększone przez podanie rozmiaru pakietu za nazwą hosta docelowego.

Inne opcje to:

-m max_ttl
    Ustaw maksymalny time-to-live (ttl - `czas życia' maksymalna liczba skoków - hops) używany w wychodzących pakietach próbnych. Domyślnie używa się wartości 30 (podobnie jak dla połączeń TCP ).

-n  Drukuj adresy skoków (hops) numerycznie zamiast symbolicznie i numerycznie (oszczędza szukania w DNS skojarzenia adres-nazwa dla każdej napotkanej po drodze bramki).

-p port
    Ustaw podstawowy numer portu UDP używanego w próbkach (domyślnie 33434). Traceroute ma nadzieję, że nic nie nasłuchuje na portach UDP od base do base+nhops-1 na hoście docelowym (tak, że zwracany będzie komunikat ICMP PORT_UNREACHABLE , kończący śledzenie trasy). Jeśli coś nasłuchuje na porcie w domyślnym zakresie, opcja ta może być użyta do wybrania nieużywanego zakresu.

-q nqueries
    Ustaw liczbę prób na każde `ttl' na nqueries (domyślnie trzy próby).

-r  Obejdź normalne tablice trasowania (routingu) i wysyłaj bezpośrednio do hosta w przyłączonej sieci. Jeśli host nie znajduje się w bezpośrednio przyłączonej sieci, zwracany jest błąd. Opcja ta może być użyta do pingowania hosta lokalnego poprzez interfejs, który nie ma przez siebie żadnej trasy (route) (np. po porzuceniu interfejsu przez routed(8)).

-s src_addr
    Używaj zadanego adresu IP (który musi być podany jako numer IP, nie nazwa hosta) jako adresu źródłowego w wychodzących pakietach próbnych. Na hostach z więcej niż jednym adresem IP, opcja ta może być używana do wymuszania adresu źródłowego innego niż adres IP interfejsu, na którym posyłana jest próbka. Jeśli adres IP nie jest jednym z tych adresów interfejsowych maszyny, zwracany jest błąd i nic nie jest wysyłane.

-t tos
    Ustaw type-of-service (rodzaj usługi) w pakietach próbnych na zadaną wartość (domyślnie zero). Wartość musi być dziesiętną liczbą całkowitą z zakresu 0 do 255. Opcja ta może być używana do sprawdzania czy różne rodzaje usług powodują różne ścieżki (jeśli nie pracujesz z systemem 4.3BSD Tahoe lub późniejszym, może to być czysto akademickie, ponieważ normalne usługi sieciowe, takie jak telnet i ftp nie pozwolą ci kontrolować TOS). Nie wszystkie wartości TOS są dozwolone lub mają znaczenie - zobacz specyfikację IP. Użytecznymi wartościami są prawdopodobnie ‘-t 16’ (low delay) (małe opóźnienie) i ‘-t 8’ (high throughput) (duży przepływ).

-v  Interaktywne wyjście. Listowane są odebrane pakiety ICMP inne niż TIME_EXCEEDED i UNREACHABLEs.

-w  Ustaw czas (w sekundach) oczekiwania na odpowiedź na próbkę (domyślnie 3 sekundy).

Program ten próbuje śledzić trasę pakietów IP, którą taki pakiet przebyłby do danego hosta internetowego. Czyni to odpalając próbki UDP z małym ttl (time to live), a następnie nasłuchując od bramki odpowiedzi ICMP "time exceeded". Rozpoczynamy próbki z ttl wartości jeden i zwiększamy je, aż otrzymamy odpowiedź ICMP "port unreachable" (co znaczy, że dostaliśmy się do "hosta") lub doszliśmy do maksimum (co domyślnie odpowiada 30 skokom i może być zmienione flagą -m ). Dla każdego ttl wysyłane są trzy próbki (zmieniane flagą -q ), czego efektem jest wypisanie linijki, pokazującej ttl, adres bramki i zaokrąglony czas podróży każdej z próbek. Jeśli odpowiedzi próbek przyszły z różnych bramek, wydrukowane zostaną adresy wszystkich odpowiadających systemów. Jeśli nie było odpowiedzi podczas 3 sekundowego interwału (określanego jako `timeout' i zmienianego flagą -w ), to dla danej próbki drukowane jest "*".

Nie chcemy, by docelowy host przetwarzał próbki pakietów UDP , więc docelowy port jest ustawiany na wartość niespotykaną (jeśli jakiś prostak na hoście docelowym używa jednak tej wartości, można ją zmienić flagą -p ).

Przykładem użycia i wyjścia może być:

    [yak 71]% traceroute nis.nsf.net.
    traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
    1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
    2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
    3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
    4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
    5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
    6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
    7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
    8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
    9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
    10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
    11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms

Zauważ, że linie 2 i 3 są takie same. Stało się to z powodu zapluskwionego jądra na systemie odwiedzonym w drugim skoku - lbl-csam.arpa, które przekazuje pakiety o zerowym ttl (błąd w rozpowszechnianej wersji BSD 4.3 ). Zauważ, że musisz zgadywać, którą konkretnie ścieżkę obierają pakiety, ponieważ NSFNet (129.140) nie dostarcza translacji adres-na-nazwę dla swoich NSSów.

Ciekawszym przykładem jest:

    [yak 72]% traceroute allspice.lcs.mit.edu.
    traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
    1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
    2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
    3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
    4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
    5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
    6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
    7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
    8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
    9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
    10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
    11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
    12  * * *
    13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
    14  * * *
    15  * * *
    16  * * *
    17  * * *
    18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms

Zauważ, że bramki 12, 14, 15, 16 i 17 albo nie przesyłają komunikatów ICMP "time exceeded" lub przesyłają je z ttl zbyt małym by nas osiągnąć. 14 - 17 pracują pod kontrolą kodu MIT C Gateway, który nie wysyła "time exceeded"s. Bóg jeden wie, co dzieje się na 12.

Cicha bramka 12 w powyższym może być wynikiem błędu w kodzie sieciowym 4.[23] BSD (i jego pochodnych): 4.x (x <= 3) wysyła nieosiągalne komunikaty, używając ttl pozostałego w oryginalnych datagramach. Zatem, dla bramek, pozostały ttl wynosi zero, ICMP "time exceeded" nie ma szans dojść z powrotem do nas. Zachowanie tego błędu jest trochę ciekawsze kiedy pojawi się na systemie docelowym:

    1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
    2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  39 ms
    3  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  39 ms  19 ms
    4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  19 ms
    5  ccn-nerif35.Berkeley.EDU (128.32.168.35)  39 ms  39 ms  39 ms
    6  csgw.Berkeley.EDU (128.32.133.254)  39 ms  59 ms  39 ms
    7  * * *
    8  * * *
    9  * * *
    10  * * *
    11  * * *
    12  * * *
    13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !

Zauważ, że jest tu 12 bramek (13 jest ostatecznym celem), a dokładnie ostatniej połowy listy "brakuje". Co naprawdę się dzieje to to, że rip (Sun-3 pracujący pod Sun OS3.5) używa ttl z naszych przychodzących datagramów jako ttl w swoich odpowiedziach ICMP. Tak więc odpowiedź nie dojdzie, bo przekroczy zadany czas (timeout) na drodze powrotnej (bez wysyłania ostrzeżeń do kogokolwiek, bo dla ICMP nie są wysyłane ICMP). Zmieni się to, gdy użyjemy ttl o długości co najmniej dwa razy większej niż długość ścieżki. Np. rip jest w rzeczywistości odległy tylko o 7 skoków. Odpowiedź, która wraca z ttl o wartości 1 jest śladem, że istnieje taki problem. Gdy ttl jest <=1 Traceroute za czasem podróży pakietu drukuje dodatkowo znak!. Ponieważ dystrybutorzy sprzedają sporo oprogramowania przestarzałego (DEC's Ultrix, Sun 3.x) lub niestandardowego (HPUX) , oczekuj że możesz spotkać ten problem często i uważaj, wybierając host docelowy twoich próbek. Innymi możliwymi adnotacjami, występującymi po wydrukowanym czasie, są !H, !N,!P (otrzymałem niedostępność hosta, sieci (network) lub protokołu),!S lub!F (zawiodła trasa źródła lub niezbędna jest fragmentacja - żadne z tych nie powinno nigdy się pojawić). Jeśli prawie wszystkie próbki dadzą w wyniku jakiś rodzaj nieosiągalności, traceroute podda się i wyjdzie.

Program ten jest przeznaczony do stosowania w testowaniu, pomiarach i zarządzaniu siecią. Powinien być używany głównie do ręcznego izolowania błędów. Nie zaleca się wykorzystywania traceroute w automatach (skryptach), gdyż powoduje on duże obciążenie sieci.

AUTOR
Zaimplementowane przez Vana Jacobsona wg pomysłu Steve Deering. Na wyróżnienie zasługuje Philip Wood, Tim Seaver i Ken Adelman.

ZOBACZ TAKŻE
netstat(1), ping(8)

HISTORIA
Komenda traceroute jest obecnie w testach.