Provided by: manpages-pl_20051117-1_all bug

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.