traceroute – program służący do badania trasy pakietów w sieci IP.

Program traceroute jest szeroko dostępny we wszystkich uniksowych systemach operacyjnych; jest także dostępny program mtr, który łączy funkcjonalność traceroute z narzędziem ping. Istnieje również program tracert o podobnej funkcjonalności, zawarty w systemach z rodziny Microsoft Windows.

Działanie traceroute opiera się na protokołach komunikacyjnych UDP oraz ICMP.

• Na początku wysyłany jest pakiet z polem TTL (Time To Live) ustawionym na 1. Wartość ta jest zmniejszana przy przechodzeniu przez kolejne routery na trasie. Jeżeli pole TTL osiągnie wartość 0, to pakiet jest odrzucany przez router, który wysyła wtedy informację zwrotną w postaci komunikatu ICMP typu „Time Exceeded”. W ten sposób komputer źródłowy uzyskuje adres IP pierwszego routera na trasie.
• W następnym wysyłanym pakiecie z komputera źródłowego pole TTL ma wartość 2. Pierwszy router zmniejszy tę wartość do 1 i przekaże do drugiego routera na trasie. Drugi router zachowa się podobnie jak ten pierwszy poprzednio, czyli zmniejszy TTL do 0 i odrzuci pakiet, wysyłając komunikat „Time Exceeded” do komputera źródłowego.
• Informacje o kolejnych routerach na trasie uzyskuje się w sposób analogiczny jak w dwóch powyższych punktach. Po prostu zwiększa się wartość pola TTL stopniowo o 1 w wysyłanych pakietach.
• Jeżeli pakiet dotrze w końcu do hosta docelowego, to najprawdopodobniej zostanie odesłany komunikat ICMP „Port Unreachable”. Dzieje się tak dlatego, że uniksowe implementacje programu traceroute świadomie wysyłają pakiety UDP z numerem portu powyżej 30000. Zazwyczaj na porcie o tak wysokim numerze nie działają żadne usługi, więc żaden proces w komputerze docelowym nie będzie chciał obsłużyć nadchodzącego pakietu. W tej sytuacji badanie trasy zostaje zakończone.

Podobne narzędzia jak mtr oraz w systemach z rodziny Microsoft Windows program tracert są zaimplementowane nieco inaczej. Główna zasada działania polegająca na stopniowym zwiększaniu pola TTL w wysyłanych pakietach pozostaje taka sama. Różnica polega na tym, że wysyłane pakiety to nie datagramy UDP, lecz komunikaty ICMP typu „Echo Request”. Jeżeli taki komunikat osiągnie swoje przeznaczenie, to zawsze zostanie odesłana odpowiedź „Echo Reply”. Dzięki temu nie trzeba polegać na założeniu związanym z wysokimi numerami portów dla datagramów UDP oraz można ominąć niektóre firewalle.

Przykład działania w systemie GNU/Linux – szukanie trasy z jednego z polskich SDI do pl.wikipedia.org:

$ traceroute pl.wikipedia.org
traceroute to pl.wikipedia.org (130.94.122.197), 30 hops max, 38 byte packets
 1  80.50.212.174 (80.50.212.174)  27.925 ms  21.351 ms  21.806 ms
 2  80.50.212.173 (80.50.212.173)  25.908 ms  30.111 ms  34.078 ms
 3  do.wro-ar3.z.wro-r1.tpnet.pl (213.25.5.153)  26.904 ms  27.311 ms  27.473 ms
 4  z.kat-r2.do.wro-r1.tpnet.pl (194.204.175.177)  29.976 ms  29.846 ms  33.366 ms
 5  z.kat-r1.do.kat-r2.tpnet.pl (194.204.175.187)  26.626 ms  25.030 ms  29.527 ms
 6  z.kra-r1.do.kat-r1.tpnet.pl (194.204.175.132)  39.916 ms  35.171 ms  33.626 ms
 7  z.war-r1.do.kra-r1.tpnet.pl (194.204.175.169)  45.120 ms  38.519 ms  39.890 ms
 8  war-b2-pos5-0.telia.net (213.248.79.233)  31.025 ms  31.040 ms  38.829 ms
 9  hbg-bb1-pos1-2-0.telia.net (213.248.64.201)  49.928 ms  49.095 ms  52.451 ms
10  kbn-bb1-pos2-0-0.telia.net (213.248.64.29)  60.254 ms  48.805 ms  50.920 ms
11  adm-bb1-pos0-1-0.telia.net (213.248.64.18)  72.432 ms  68.934 ms  70.613 ms
12  adm-b1-pos2-0.telia.net (213.248.72.138)  69.353 ms  64.607 ms  69.942 ms
13  p4-1-2-0.r00.amstnl02.nl.bb.verio.net (129.250.9.1)  69.952 ms  70.791 ms  69.018 ms
14  p4-0-3-0.r01.amstnl02.nl.bb.verio.net (129.250.2.133)  81.510 ms  77.132 ms  80.041 ms
15  p4-0-1-0.r80.nwrknj01.us.bb.verio.net (129.250.2.222)  162.401 ms  161.178 ms  159.993 ms
16  p4-0-3-0.r00.nwrknj01.us.bb.verio.net (129.250.5.39)  158.481 ms  158.957 ms  159.038 ms
17  p16-0-1-1.r20.mlpsca01.us.bb.verio.net (129.250.5.112)  229.876 ms  238.945 ms  239.979 ms
18  xe-1-2-0.r21.mlpsca01.us.bb.verio.net (129.250.3.187)  240.390 ms  230.817 ms  239.929 ms
19  p16-1-1-1.r20.lsanca01.us.bb.verio.net (129.250.5.96)  229.004 ms  228.556 ms  229.946 ms
20  p16-1-1-1.r21.lsanca01.us.bb.verio.net (129.250.2.186)  229.919 ms  230.001 ms  229.761 ms
21  p16-3-0-0.r01.sndgca01.us.bb.verio.net (129.250.2.159)  250.958 ms  239.954 ms  239.534 ms
22  ge-1-2.a03.sndgca01.us.da.verio.net (129.250.27.100)  239.401 ms  239.831 ms  240.834 ms
23  130.94.122.197 (130.94.122.197)  240.006 ms  239.888 ms  240.033 ms

Z powyższego przykładu na podstawie rekordów reverse DNS można orientacyjnie wyznaczyć, przez jakie miasta i kraje przechodziły pakiety:

1-3   Wrocław     Polska
4-6   Katowice    Polska
7     Kraków      Polska
8     Warszawa    Polska
9     Hamburg     Niemcy
10    Kopenhaga   Dania
11-14 Amsterdam   Holandia
15-16 Newark      USA, New Jersey
17-18 Milpitas    USA, Kalifornia
19-20 Los Angeles USA, Kalifornia
21-23 San Diego   USA, Kalifornia

Brak odpowiedzi na zadany pakiet sygnalizowany jest znakiem gwiazdki „*” i może wynikać z przeciążenia sieci, routera bądź z celowej konfiguracji urządzeń (ustawienia firewalla).

W niektórych sieciach nazwy ruterów mogą być nieskonfigurowane albo nieaktualne, ale mimo to na podstawie różnicy w czasie odpowiedzi pomiędzy kolejnymi krokami, można wyznaczyć ważniejsze miejsca na trasie. W powyższym przykładzie między krokami numer 14 i 15 widać wzrost czasów odpowiedzi o około 80 ms, co wskazuje na pokonanie dużej przeszkody geograficznej, w tym przypadku Ocean Atlantycki. Podobnie pomiędzy krokami 16 i 17 zwiększenie czasu odpowiedzi wynika z pokonania przez pakiet całego kontynentu amerykańskiego.

Jeżeli router zostanie skonfigurowany w taki sposób, że nie zmniejsza wartości pola TTL przetwarzanych pakietów, nie będzie uwidoczniony przez traceroute, podobnie się także stanie, jeśli pakiet pokona część trasy kapsułkowany w tunelu lub sieci MPLS.

• ping
• Time To Live
• route
• pathping

• Strona domowa traceroute dla systemów GNU/Linux
• Traceroute z kilkuset sieci na całym świecie