Трасіроўку - Linux Command - Unix каманднага

трасіроўка - друк маршруту пакетаў да сеткі хаста

канспект

трасіроўка [-dFInrvx] [-f first_ttl] [-g шлюз]

[-i IFACE] [-m max_ttl] [-p порт]

[-q nqueries] [-s src_addr] [-t TOS]

[-w WaitTime] [-z pausemsecs]

гаспадарыць [packetlen]

апісанне

Інтэрнэт з'яўляецца вялікай і складанай агрэгацыі сеткавага абсталявання, злучаных паміж сабой шлюзамі. Адсочванне пакетаў на маршрут свайго прытрымлівацца (або знайсці нягодніка шлюз, які адкідаючы свае пакеты) можа быць абцяжарана. Трасіроўка выкарыстоўвае пратакол IP - `час жыць» поля і спробы , каб выклікаць адказ ICMP TIME_EXCEEDED ад кожнага шлюза па шляху да якога - гаспадара.

Адзіным абавязковым параметрам з'яўляецца імя хаста прызначэння або нумар IP . Даўжыня зонда дейтаграмм па змаўчанні складае 40 байт , але гэта можа быць павялічана шляхам заданні даўжыні пакета (у байтах) пасля імя хаста прызначэння.

Іншыя варыянты:

-f

Усталюйце пачатковы час да жыцця, якая выкарыстоўваецца ў першым выходнага пакета зонда.

-F

Усталюйце "не фрагментаваць» біт.

-d

Ўключэнне адладкі ўзроўню сокета.

-g

Пакажыце друзлы шлюз крыніца маршруту (8 максімуму).

-i

Пазначыць сеткавай інтэрфейс для атрымання IP-адрасы крыніцы для выходных пакетаў зонда. Гэта, як правіла, выкарыстоўваецца толькі на многодомной хасце. (Глядзі сцяг -s іншы спосаб зрабіць гэта.)

-I

Выкарыстанне ICMP ECHO замест UDP датаграмм.

-m

Усталюйце максімальны час да жыцця (максімальны лік транзітных участкаў), якое выкарыстоўваецца ў выходных пакетаў зонда. Значэнне па змаўчанні складае 30 хмель (тое ж па змаўчанні выкарыстоўваецца для TCP-злучэнняў).

-n

Друк хмель адрасу колькасна, а не сімвалічна і колькасна (захоўвае пошук адрасы сервера імёнаў-к-імя для кожнага шлюза знойдзенага на шляху).

-p

Усталюйце базавы UDP нумар порта, які выкарыстоўваецца ў зонда (па змаўчанні 33434). Трасіроўка спадзяецца , што нічога не праслухоўвае парты UDP базы грунтаваць + nhops - 1 на хасце прызначэння (так што PORT_UNREACHABLE паведамленне ICMP будзе вернуты спыніць трасіроўку маршруту). Калі нешта праслухоўвае порт у дыяпазоне па змаўчанні, гэты параметр можа быць выкарыстаны, каб выбраць невыкарыстоўваны дыяпазон партоў.

-r

Абыход звычайных табліц маршрутызацыі і пасылаць непасрэдна да хасту на падключаную сетку. Калі гаспадар не на непасрэдна далучаную сетку, вяртаецца памылка. Гэтая опцыя можа выкарыстоўвацца для праверкі лакальнага хаста праз інтэрфейс , які не мае ніякага маршруту праз яго (напрыклад, пасля таго , як інтэрфейс быў скінуты маршрутизируемым (8C)).

-s

Выкарыстоўваць наступны IP-адрас (які звычайна даецца як нумар IP, а не імя хаста) у якасці адрасу крыніцы ў выходных пакетаў зонда. На многодомных хастоў (тыя з больш чым адным IP-адрасам), гэты параметр можа быць выкарыстаны, каб прымусіць адрас крыніцы, каб быць чымсьці іншым, чым IP-адрас інтэрфейсу пробны пакет адпраўляецца далей. Калі IP-адрас не адзін з адрасоў інтэрфейсу гэтай машыны, вяртаецца памылка і нічога не пасылаецца. (Глядзі сцяг -i іншы спосаб зрабіць гэта.)

-t

Усталюйце тып-службы ў зондавага пакетах на наступнае значэнне (нуль па змаўчанні). Значэнне павінна быць дзесятковым лікам у дыяпазоне ад 0 да 255. Гэты варыянт можа быць выкарыстаны, каб убачыць, калі розныя тыпы ў абслугоўванні вынік у розных шляхоў. (Калі вы не карыстаецеся 4.4BSD, гэта можа быць акадэмічным, так як звычайныя сеткавыя сэрвісы, такія як Telnet і FTP не дазваляюць кантраляваць TOS). Не ўсе значэння TOS законныя ці сэнс - гл IP спецыфікацыі для азначэнняў. Карысныя значэння, верагодна , `-t 16 '(нізкая затрымка) і` -t 8' (высокая прапускная здольнасць ).

-v

Поўны вывад. Атрыманыя акрамя TIME_EXCEEDED ICMP-пакеты і UNREACHABLEs пералічаныя.

-w

Ўстаноўка часу (у секундах), каб чакаць адказу на зонд (па змаўчанні 5 сек.).

-x

Пераключэнне IP сум. Як правіла, гэта прадухіляе трасіроўку ад вылічэнні IP-кантрольных сум. У некаторых выпадках аперацыйная сістэма можа перазапісаць часткі выходнага пакета , але не пералічыць кантрольную суму (таму ў некаторых выпадках па змаўчанні з'яўляецца ня вылічыць кантрольную суму і з дапамогай -га прымушаюць іх быць calcualted). Варта адзначыць , што кантрольныя сумы, як правіла , патрабуецца для апошняга скачка пры выкарыстанні ICMP ECHO зондаў (-I). Такім чынам, яны заўсёды разлічваюцца пры выкарыстанні ICMP.

-z

Усталюйце час (у мілісекундах) для паўзы паміж зондамі (па змаўчанні 0). Некаторыя сістэмы, такія як Solaris і маршрутызатары, такія як Ciscos хуткасць паведамлення абмежаванні ICMP. Добрае значэнне для выкарыстання з гэтым гэта 500 (напрыклад, 1/2 секунды).

Гэтая праграма спрабуе прасачыць маршрут, па якім пакет IP будзе прытрымлівацца ў некаторых інтэрнэт-хаста, запусціўшы тэставыя пакеты UDP з невялікім ТТЛ (час жыць), то для праслухоўвання ICMP «перавышаны час» адказ ад шлюза. Мы пачынаем нашы зонды з ТТЛ аднаго і павялічваецца на адзінку , пакуль не атрымліваеце ICMP «порт недаступны» (што азначае , што мы павінны «гаспадар») або ўдарыў макс (які па змаўчанні 30 хмель і можа быць зменены з -m сцяг). Тры зонда (змяненне са сцягам -q) адпраўляюцца ў кожнай ўсталёўцы ТТЛ і лінія друкуецца які паказвае ТТЛ - адрас шлюза і туды і назад падчас кожнага зонда. Калі зонд адказы з розных шлюзаў, адрас кожнай сістэмы які адказаў будзе раздрукаваны. Калі няма адказу на працягу 5 сек. Інтэрвал часу чакання (зменена са сцягам -w), сімвал «*» друкуюцца для гэтага зонда.

Мы не хочам, каб хост прызначэння апрацоўваць UDP пакетаў зондавага таму порт прызначэння ўсталёўваюцца ў малаверагоднае значэнне (калі які - то камяк ад прызначэння выкарыстоўвае гэта значэнне, яно можа быць зменена з дапамогай сцяга -p).

Прымяненне і выхад ўзору можа быць:

[ЯК 71]% трасіроўка nis.nsf.net. трасіроўку да nis.nsf.net (35.1.1.48), 30 хмель макс, 38 байт пакета 1 helios.ee.lbl.gov (128.3.112.1) 19 мс 19 мс 0 мс 2 lilac-dmc.Berkeley.EDU (128,32. 216,1) 39 мс 39 мс 19 мс 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 39 мс 19 мс 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 мс 40 мс 39 мс 5 CCN -nerif22.Berkeley.EDU (128.32.168.22) 39 мс 39 мс 39 мс 6 128.32.197.4 (128.32.197.4) 40 мс 59 мс 59 мс 7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 59 мс 8 129,140. 70.13 (129.140.70.13) 99 мс 99 мс 80 мс 9 129.140.71.6 (129.140.71.6) 139 мс 239 мс 319 мс 10 129.140.81.7 (129.140.81.7) 220 мс 199 мс 199 мс 11 nic.merit.edu (35.1 .1.48) 239 мс 239 мс 239 мс

Звярніце ўвагу, што лініі 2 і 3 з'яўляюцца аднолькавымі. Гэта звязана з багі ядром на 2-й сістэмы хмелевай - lbl-csam.arpa - што перасылае пакеты з нулявым ТТЛ (памылка ў размеркаванай версіі 4.3BSD). Звярніце ўвагу, што вы павінны адгадаць, які шлях пакеты прымаюць крос з NSFNet (129.140) не прадастаўляюць адрас у імя перакладаў для сваіх NSSes.

Больш цікавы прыклад:

[ЯК 72]% трасіроўка allspice.lcs.mit.edu. трасіроўку да allspice.lcs.mit.edu (18.26.0.115), 30 хмель макс 1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 мс 19 мс 19 мс 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 19 мс 19 мс 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 мс 39 мс 39 мс 5 CCN-nerif22 .Berkeley.EDU (128.32.168.22) 20 мс 39 мс 39 мс 6 128.32.197.4 (128.32.197.4) 59 мс 119 мс 39 мс 7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 39 мс 8 (129.140.70.13 129.140.70.13) 80 мс 79 мс 99 мс 9 129.140.71.6 (129.140.71.6) 139 мс 139 мс 159 мс 10 129.140.81.7 (129.140.81.7) 199 мс 180 мс 300 мс 11 129.140.72.17 (129.140.72.17) 300 мс 239 мс 239 мс 12 * * * 13 128.121.54.72 (128.121.54.72) 259 мс 499 мс 279 мс 14 * * * 15 * * * * * 16 * 17 * 18 * * ALLSPICE.LCS.MIT.EDU (18,26 .0.115) 339 мс 279 мс 279 мс

Звярніце ўвагу, што шлюзы 12, 14, 15, 16 і 17 скокі ад ці не пасылаць ICMP «перавышаны час» паведамленне або адправіць іх з ТТЛ занадта мала, каб дабрацца да нас. 14 - 17 працуюць код MIT C шлюза, які не пасылае «перавышана час» с. Бог ведае, што адбываецца з 12.

Маўчыць шлюз 12 у прыведзеным вышэй, можа быць вынікам памылкі ў [23] BSD сеткавай код 4. (і яго вытворныя): 4.х (х <= 3) пасылае паведамленне аб недаступнасці з выкарыстаннем любых ТТЛ застаецца ў зыходным дейтаграмм. Так, для шлюзаў, астатнія Время_жизни нуль, «Перавышаны час» ICMP гарантавана не зрабіць яго назад да нас. Паводзіны гэтай памылкі з'яўляецца трохі больш цікавым, калі ён з'яўляецца на мэтавай сістэме:

1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 19 мс 39 мс 3 lilac-dmc.Berkeley.EDU (128.32.216.1 ) 19 мс 39 мс 19 мс 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 мс 40 мс 19 мс 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 мс 39 мс 39 мс 6 csgw. Berkeley.Edu (128.32.133.254) 39 мс 59 мс 39 мс 7 * * * * * 8 * 9 * * * * * 10 * 11 * 12 * * * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 Спадарыня ! 39 мс! 39 мс!

Звярніце ўвагу на тое, што 12 «шлюзы» (13 з'яўляецца канчатковым пунктам прызначэння) і менавіта апошняя палова з іх «зніклых без вестак». Што на самой справе адбываецца тое, што плагіят (Сонца-3 працуе Sun OS3.5) выкарыстоўвае ТТЛ з нашага прыбываў дейтаграмм як ТТЛ ў сваім адказе ICMP. Такім чынам, адказ будзе тайм-аўт на зваротным шляху (без апавяшчэння, адпраўленыя каму-небудзь, так як ICMP ніколі не адпраўляюцца на ICMP-х) да таго часу, пакуль зонд з ТТЛ, што па крайняй меры ў два разы больш даўжыні шляху. Г.зн., рип сапраўды толькі 7 хмель прэч. Адказ, які вяртаецца з ТТЛ 1 з'яўляецца ключом гэтая праблема існуе. Трасіроўка друкуе «!» пасля таго, як час, калі Время_жизни <= 1. Бо вытворцы грузяць шмат састарэлых (Ultrix DEC, нд 3.x) або нестандартнага праграмнае забеспячэння (HPUX), мы чакаем убачыць гэтую праблему часта і / або клапаціцца збіраннем мэты мноства вашых зондаў.

!! Іншыя магчымыя анатацый пасля часу Н, N або P (хост, сетка або пратакол недасяжны), S (крыніца маршруту не атрымалася), F- (патрабуецца фрагментацыя - адлюстроўваецца RFC1191 Path значэнне MTU Discovery) !, ! Х (сувязь забароненая адміністратар) ,! ў (якая прымае парушэнні перавагі) ,! с (прыярытэтам адсечка дзейнічае), або! (ICMP недаступны код). Яны вызначаюцца RFC1812 (якая замяняе RFC1716). Калі амаль усе зонды прыводзяць да нейкага недасяжным, трасіроўка здасца і выхад.

Гэтая праграма прызначана для выкарыстання ў сеткі тэставання, вымярэння і кіравання. Яна павінна выкарыстоўвацца ў першую чаргу для ручной ізаляцыі няспраўнасцяў. З - за нагрузкі ён можа накласці на сетку, неразумна выкарыстоўваць трасіроўку падчас нармальнай працы ці з аўтаматызаваных сцэнарыяў.

Глядзіце таксама

pathchar (8), NetStat (1), пінг (8)