traceroute - отпечатайте пакетите маршрути, които приемате за мрежовия хост
резюме
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g шлюз ]
[ -i iface ] [ -m max_ttl] [ -p порт ]
[ -q nqueries ] [ -s src_addr ] [ -t tos ]
[ -w изчакване ] [ -z pausemsecs ]
домакин [ пакетлен ]
описание
Интернет е голямо и сложно обединяване на мрежовия хардуер, свързани помежду си чрез шлюзове. Проследяването на пакетите на маршрута, които следвате (или намирането на недобросъвестния портал, който изхвърля пакетите ви) може да бъде трудно. Traceroute използва IP протокола `time to live 'и се опитва да извлече ICMP TIME_EXCEEDED отговор от всеки шлюз по пътя към някой хост.
Единственият задължителен параметър е името на хоста на получателя или IP адреса . Дължината на дейтаграмата на сондата по подразбиране е 40 байта , но това може да се увеличи, като се укаже дължината на пакета (в байтове) след името на хост на целевата група.
Другите опции са:
-f
Задайте началното време за изпълнение, използвано в първия пакет от изходящи сонди.
-F
Задайте бита "не фрагментирай".
-д
Активирайте отстраняването на грешки на ниво гнездо.
-g
Посочете шлюз на маршрут за свободен източник (максимум 8).
-i
Посочете мрежов интерфейс, за да получите IP адреса на източника за пакети от изходящи сонди. Това обикновено е полезно само за хост с множество хостове. (Вижте флага -s за друг начин за това.)
-I
Използвайте ICMP ECHO вместо UDP дейтаграми.
-м
Задайте максималната продължителност на живот (максимален брой хмел), използвана в пакетите за изходящи сонди. По подразбиране е 30 хмела (същото се използва за TCP връзки).
-н
Отпечатва се хомейно адресно число, а не символично и числено (запазва търсене на адрес от имейл адреса до име за всеки шлюз, намерен в пътя).
-p
Задайте номера на базовия UDP порт, използван в сондите (по подразбиране е 33434). Traceroute се надява, че нищо не слуша на базата на UDP портове до базата + nhops - 1 на целевия хост (така че съобщение ICMP PORT_UNREACHABLE ще бъде върнато, за да прекрати проследяването на маршрута). Ако нещо се слуша на порт в обхвата по подразбиране, тази опция може да се използва за избор на неизползван обхват на портове.
-r
Прескочите нормалните таблици за маршрутизиране и изпратете директно до хост на прикачена мрежа. Ако хостът не е в директно свързана мрежа, връща се грешка. Тази опция може да се използва за пинг на локален хост чрез интерфейс, който няма маршрут през него (напр. След като интерфейсът е бил отхвърлен от маршрутизирания (8C)).
-с
Използвайте следния IP адрес (който обикновено се посочва като IP адрес, а не като име на хост) като изходен адрес в пакетите за изходящи сонди. На хостовете с множество хостове (тези с повече от един IP адрес) тази опция може да се използва, за да принуди източника на адреса да бъде нещо различно от IP адреса на интерфейса, на който се изпраща пакета сонда. Ако IP адресът не е един от адресите на интерфейса на машината, се връща грешка и нищо не се изпраща. (Вижте флага -i за друг начин за това.)
-T
Задайте типа услуга в пакетите сонди на следната стойност (нула по подразбиране). Стойността трябва да е десетично число в диапазона от 0 до 255. Тази опция може да се използва, за да видите дали различните типове услуги водят до различни пътища. (Ако не използвате 4.4bsd, това може да е академично, тъй като нормалните мрежови услуги като telnet и ftp не ви позволяват да контролирате TOS). Не всички стойности на TOS са законни или смислени - вижте спесификациите за IP. Полезни стойности вероятно са " -t 16 " (ниско забавяне) и " -t 8 " (висока производителност).
-V
Подробен изход. Посочени са ICMP пакети, различни от TIME_EXCEEDED и UNREACHABLEs.
-w
Задайте време (в секунди) да изчакате отговор на дадена сонда (по подразбиране 5 сек.).
-х
Превключване на ip checksums. Обикновено това предотвратява изчисляването на контролни суми от traceroute. В някои случаи операционната система може да презапише части от изходящия пакет, но да не преизчисли контролната сума (така че в някои случаи по подразбиране не трябва да се изчисляват контролните суми и използването на -x ги кара да бъдат изчислени). Обърнете внимание, че обикновено са необходими контролни суми за последния хоп, когато използвате ICMP ECHO сонди ( -I ). Така че те винаги се изчисляват при използване на ICMP.
-Z
Задайте време (в милисекунди) за пауза между сонди (по подразбиране 0). Някои системи като Solaris и маршрутизатори, като Ciscos, ограничават скоростта на съобщенията. Добрата стойност, която можете да използвате с това, е 500 (например 1/2 секунда).
Тази програма се опитва да проследи пътя, който IP пакетът ще последва до някой интернет хост, като стартира UDP пробни пакети с малко TTL (време за живеене), след което слуша за ICMP "време надхвърлен" отговор от шлюз. Започваме сондите с един толт и се увеличаваме с един, докато не получим ICMP "порт недостижим" (което означава, че имаме "хост") или удари макс (който по подразбиране е 30 хмела и може да бъде променен с -m флаг). При всяка настройка ttl се изпращат три сонди (променят се с флага -q ) и се отпечатва линия, показваща ttl, адреса на шлюза и времето за зареждане на всяка сонда. Ако отговорите на сондата идват от различни шлюзове, ще се отпечата адреса на всяка отговорена система. Ако няма отговор в рамките на 5 сек. интервал на изчакване (променен с флага " -w" ), за тази сонда се отпечатва "*".
Не искаме хостът на местоназначението да обработи пакетите с протоколи UDP, така че пристанището на целта да е настроено на невероятна стойност (ако някакво clod в дестинацията използва тази стойност, то може да бъде променено с флага -p ).
Една примерна употреба и изход може да са:
[yak 71]% traceroute nis.nsf.net. traceroute към nis.nsf.net (35.1.1.48), 30 хмела максимум, 38 байта пакет 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 (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Имайте предвид, че линиите 2 и 3 са еднакви. Това се дължи на бъг-ядрото на втората хоп система lbl-csam.arpa, която изпраща пакети с нула ttl (грешка в разпределената версия на 4.3BSD). Обърнете внимание, че трябва да отгатнете какъв е пътят, по който пакетите преминават, тъй като NSFNet (129.140) не предоставя преводи от име на име за неговите NSSes.
По-интересен пример е:
[yak 72]% traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 хмела 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Обърнете внимание, че шлюзовете 12, 14, 15, 16 и 17 се отдръпват или не изпращат ICMP съобщения "превишени" време, нито ги изпращат с твърде малък TTL, за да стигнат до нас. 14 - 17 изпълняват кода на MIT C Gateway, който не изпраща "превишено време" s. Бог само знае какво става с 12.
Безшумен шлюз 12 в горния може да е резултат от грешка в 4. [23] BSD мрежовия код (и неговите производни): 4.x (x <= 3) изпраща съобщение, което не може да се достигне, използвайки каквото остава ttl в оригинала дейтаграма. Тъй като за шлюзовете, оставащата ttl е нула, ICMP "времето превишено" е гарантирано, че няма да ни върне обратно. Поведението на тази грешка е малко по-интересно, когато се появява на целевата система:
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) Госпожица ! 39 ms! 39 ms!Забележете, че има 12 "портала" (13 е крайната дестинация) и точно последната половина от тях са "липсващи". Това, което наистина се случва, е, че rip (Sun-3, работещ със Sun OS3.5) използва ttl от нашата пристигаща дейтаграма като ttl в своя ICMP отговор. Така че отговорът ще изтече по пътя за връщане (без предупреждение, изпратено до никого, тъй като ICMP не се изпраща за ICMP), докато не проследим с TTL, което е най-малко два пъти по-голямо от дължината на пътя. Т.е., rip е наистина само 7 хмела далеч. Отговор, който се връща с TTL от 1, е улика, че този проблем съществува. Traceroute отпечатва "!" след времето, когато ttl е <= 1. Тъй като продавачите изпращат доста остарели (DECtrips Ultrix, Sun 3.x) или нестандартни (HPUX) софтуер, очакват да видят този проблем често и / домакин на вашите сонди.
Други възможни пояснения след времето са : H , N , или ! P (хост, мрежа или протокол не могат да се достигнат), S (източник на маршрута не е успял),! F- (необходимо е фрагментацията - се показва стойността на RFC1191 MTU Discovery) ! X (комуникация, забранена административно) ,! V (нарушение на приоритет на хоста) ,! C (преклузивен ефект в сила), или ! (ICMP недостижим код). Те се определят от RFC1812 (което замества RFC1716). Ако почти всички сонди водят до някакъв вид недостиг, трасерът ще се откаже и ще излезе.
Тази програма е предназначена за използване при тестване, измерване и управление на мрежата. Той трябва да се използва основно за ръчна изолация на повредите. Поради натоварването, което може да наложи в мрежата, не е разумно да се използва traceroute по време на нормални операции или от автоматизирани скриптове.
Вижте също
pathchar (8), netstat (1), пинг (8)