Програма traceroute — це важливий інструмент для відшукування помилок маршрутизації, вивчання трафіка в Internet та досліджування топології мережі. Програма намагається визначати маршрут поміж двома хостами в мережі, примушуючи кожний проміжний маршрутизатор надсилати ICMP-повідомлення про помилку хосту-відправлячеві. На рис. 2.4 подано маршрут до хоста, який відстежує traceroute. Перше число зліва у кожному рядку — це номер проміжного вузла. За ним іде ім’я хоста або маршрутизатора у цьому вузлі й далі IP-адреса вузла. Якщо ім’я вузла виявити не вдається, traceroute видає лише IP-адресу. Така ситуація спостерігається у вузлі 13. Вочевидь, що за умовчанням програма тричі намагалась визначати ім’я хосту або маршрутизатора, а три числа, що йдуть за IP-адресою, — це періоди RTT для кожної з трьох спроб. Якщо за чергової спроби на запит ніхто не відповідає або відповідь губиться, то замість відповіді виводиться “*”.
bsd: $ traceroute ziggy. usf. edu
traceroute to ziggy. usf. edu (131. 247. 1. 40), 30 hops max,
40 byte packets
1 tam-f1-pm8. netcom. net (163. 179. 44. 15)
128. 960 ms 139. 230 ms 129. 483 ms
2 tam-f1-gw1. netcom. net (163. 179. 44. 254)
139. 436 ms 129. 226 ms 129. 570 ms
3 h1-0.mig-f1-gw1. netcom. net (165. 236. 144. 110)
279. 582 ms 199. 325 ms 289. 611 ms
4 a5-0-0-7.was-dc-gw1. netcom. net (163. 179. 235. 121)
179. 505 ms 229. 543 ms 179. 422 ms
5 h1.mae-east. netcom. net (163. 179. 220. 182)
189. 258 ms 179. 211 ms 169. 605 ms
6 s1-mae-e-f0-0. sprintlink. net (192. 41. 177. 241)
189. 999 ms 179. 399 ms 189. 472 ms
7 s1-bb4-dc-1-0-0. sprintlink. net (144. 228. 10. 41)
180. 048 ms 179. 388 ms 179. 562 ms
8 s1-bb10-rly-2-3. sprintlink. net (144. 232. 7. 153)
199. 433 ms 179. 390 ms 179. 468 ms
9 s1-bb11-rly-9-0. sprintlink. net (144. 232. 0. 46)
199. 259 ms 189. 315 ms 179. 459 ms
10 s1-bb10-or1-1-0. sprintlink. net (144. 232. 9. 62)
189. 987 ms 199. 508 ms 219. 252 ms
11 s1-gw3-or1-4-0-0. sprintlink. net (144. 232. 2. 154)
219. 307 ms 209. 382 ms 209. 502 ms
12 s1-usf-1-0-0. sprintlink. net (144. 232. 154. 14)
209. 518 ms 199. 288 ms 219. 495 ms
13 131.247.254.36 (131.247.254.36) 209.318 ms 199.281 ms 219.588 ms
14 ziggy. usf. edu (131. 247. 1. 40) 209.591 ms * 210.159 ms
Рисунок 2.4 — Маршрут до хоста
У кожній IP-дейтаграмі є поле ТТL (Time-to-Live) — тривалість життя. Це поле зменшується на одиницю кожним маршрутизатором, через який проходить дейтаграма. Коли TTL дорівнюватиме нулю, дейтаграма знищується. Офіційно TTL вимірюється в секундах, але інтерпретується маршрутизаторами як лічильник проміжних вузлів. Після знищення дейтаграми маршрутизатор надсилає джерелу ICMP-повідомлення “завершено час у путі”.
Програма tracerout використовує цю властивість. Спочатку вона надсилає одержувану UDP-дейтаграму, в якій TTL встановлено в одиницю. Перший маршрутизатор визначає одиницю в полі TTL, відкидає дейтаграму й надсилає відправлячеві ICMP-повідомлення, з якого він дізнається про перший проміжний вузол з поля ”адреса відправляча” в заголовку ICMP. Програма traceroute намагається виявити ім’я вузла за допомогою функції gethostbyaddr(3N). З метою отримання інформації про другий вузол traceroute повторює процедуру, але поле TTL встановлюється дорівнюваним двом. Маршрутизатор на першому проміжному вузлі зменшить TTL на одиницю й надішле дейтаграму на другий вузол. Другий маршрутизатор визначить одиницю в полі TTL, відкине дейтаграму та надішле ICMP-повідомлення відправлячеві.
Повторюючи ці дії, але зі збільшеним на одиницю значенням TTL кожного разу, tracerout може відстежити весь маршрут від відправляча до одержувача. Коли дейтаграма з достатньо великим початковим значенням TTL врешті надходить до отримувача, TTL дорівнюватиме одиниці. Оскільки далі передавати дейтаграму нема куди, стек TCP/IP спробує доставити її додаткові, але як порт призначення у traceroute встановлюється таке значення, що ним напевно ніхто не користується, тому хост-одержувач поверне ICMP-повідомлення “порт є неприступний”. Це і є ознакою завершення маршруту і — трасування завершується.
Програма traceroute використовує ненадійний протокол UDP, тому можлива ситуація, коли дейтаграми губляться і traceroute намагається “достукатися” до кожного проміжного хосту чи маршрутизатору неодноразово, тобто надсилає кілька дейтаграм з одним значенням TTL. За умовчанням операція повторюється тричі, але кількість повторювань можна змінити за допомогою опції -g. У traceroute за умовчанням встановлено термін очікування ICMP-повідомлення після кожної спроби 5 с, але його можна змінити за допомогою опції -w. Якщо за цей термін ICMP-повідомлення не отримано, замість значення RTT видається символ (*). Слід зауважити, що деякі маршрутизатори не надсилають ICMP-повідомлень “завершено час у путі”, й тоді виводиться одразу (*). Є такі маршрутизатори, які надсилають повідомлення, але з тим значенням TTL, яке надійшло. Якщо воно дорівнюватиме нулю, то не буде жодного результату.
Можливий випадок, коли маршрутизатори помилково спрямовують дейтаграми далі, хоча TTL дорівнює нулю. У такому разі наступний маршрутизатор, наприклад N+1, відкине дейтаграму і поверне ICMP-повідомлення “завершено час у путі”. На наступній ітерації N+1-й маршрутизатор отримає дейтаграму зі значенням TTL, що вона дорівнює одиниці, й поверне звичайне ICMР-повідомлення. Отже, маршрутизатор N+1 з’явиться на екрані двічі: вперше внаслідок помилки попереднього маршрутизатора, вдруге — після коректного відкидання дейтаграми з часом у путі, що його завершено. На екрані у певних умовах можна спостерігати різку зміну маршруту після першої спроби. Така ситуація виникає в разі спроби маршрутизатору збалансувати навантаження в мережі або в разі відмикання одного маршрутизатору після першої спроби та підмикання іншого.
Маршрутизатори, іноді зумисно, повністю блокують усі ICMP-повідомлення, побоюючись, що вони несуть небезпеку. У такому разі traceroute не можна використовувати. Наступною проблемою є асиметрія маршрутів: немає жодної гарантії, що реальна дейтаграма піде тим самим маршрутом. Статистичні дослідження свідчать про те, що асиметрія маршрутів становить 49% хоча б в одному проміжному вузлі.
