TRACEROUTE(8) دستورات مدیریت سیستم TRACEROUTE(8)

traceroute - ردیابی مسیر حرکت بسته‌ها به سوی میزبان شبکه

traceroute [-46dFITUnreAV] [-f first_ttl] [-g gate,...]
[-i device] [-m max_ttl] [-p port] [-s src_addr]
[-q nqueries] [-N squeries] [-t tos]
[-l flow_label] [-w waittimes] [-z sendwait] [-UL] [-D]
[-P proto] [--sport=port] [-M method] [-O mod_options]
[--mtu] [--back]
host [packet_len]
traceroute6 [options]

دستور traceroute مسیر حرکت بسته‌ها را در یک شبکه IP در مسیرشان به سوی یک میزبان مشخص ردگیری می‌کند. این ابزار از فیلد زمان حیات (TTL) در پروتکل IP بهره می‌برد و تلاش می‌کند از هر دروازه (gateway) در طول مسیر به سمت میزبان، یک پاسخ ICMP از نوع TIME_EXCEEDED دریافت نماید.

دستور traceroute6 معادل دستور traceroute به همراه گزینه -6 است.

تنها پارامتر الزامی، نام یا نشانی IP میزبان مقصد (host) است. پارامتر اختیاری packet_len اندازه کل بسته کاوشگر است (به‌طور پیش‌فرض ۶۰ بایت برای IPv4 و ۸۰ بایت برای IPv6). اندازه تعیین‌شده در برخی شرایط ممکن است نادیده گرفته شود یا تا یک مقدار حداقل افزایش یابد.

این برنامه با ارسال بسته‌های کاوشگر با مقدار TTL (زمان حیات) اندک و سپس گوش فرا دادن به پاسخ ICMP «زمان به پایان رسید» ("time exceeded") از سوی یک دروازه، تلاش می‌کند مسیری را که یک بسته IP تا یک میزبان اینترنتی طی می‌کند، ردیابی نماید. کاوش‌ها با مقدار TTL برابر با یک آغاز شده و یکی‌یکی افزایش می‌یابند تا زمانی که یک پیام ICMP «پورت در دسترس نیست» ("port unreachable") یا بازنشانی TCP (یا TCP reset) دریافت شود که به معنی رسیدن به «میزبان» است، یا اینکه به حداکثر تعداد مجاز گام‌ها برسد (که به‌طور پیش‌فرض ۳۰ گام یا hop است). در هر تنظیم TTL، سه کاوشگر (به‌طور پیش‌فرض) ارسال می‌شود و سطری چاپ می‌گردد که مقدار TTL، نشانی دروازه و زمان رفت و برگشت (round trip time) هر کاوش را نمایش می‌دهد. در صورت درخواست، نشانی می‌تواند با اطلاعات تکمیلی همراه شود. اگر پاسخ‌های کاوش از دروازه‌های متفاوتی دریافت شوند، نشانی هر سامانه پاسخ‌دهنده چاپ خواهد شد. چنانچه در مهلت زمانی مشخص پاسخی دریافت نشود، علامت «*» (ستاره) برای آن کاوش چاپ می‌شود.

پس از زمان رفت و برگشت، ممکن است برخی نشانه‌ها و توضیحات تکمیلی چاپ شود: !H، !N یا !P (میزبان، شبکه یا پروتکل در دسترس نیست)، !S (مسیریابی مبدأ ناموفق بود)، !F (قطعه‌بندی یا fragmentation لازم است)، !X (ارتباط به دلایل مدیریتی مسدود شده است)، !V (نقض اولویت میزبان)، !C (قطع اولویت اعمال شده است) یا !<num> (کد عدم دسترسی ICMP شماره <num>). اگر تقریباً تمام کاوش‌ها منجر به نوعی از عدم دسترسی شوند، traceroute متوقف شده و خارج خواهد شد.

ما نمی‌خواهیم میزبان مقصد بسته‌های کاوشگر UDP را پردازش کند، بنابراین پورت مقصد روی مقداری نامحتمل تنظیم می‌شود (می‌توانید با فلگ -p آن را تغییر دهید). در ردیابی مسیر با ICMP یا TCP چنین مشکلی وجود ندارد (برای TCP از تکنیک نیمه‌باز یا half-open استفاده می‌کنیم که مانع دیده شدن بسته‌های کاوش ما توسط برنامه‌های کاربردی روی میزبان مقصد می‌شود).

در محیط شبکه‌های امروزی، به دلیل استفاده گسترده از دیوارهای آتش (فایروال‌ها)، روش‌های سنتی traceroute همواره کارآمد نیستند. این دیوارهای آتش پورت‌های «نامحتمل» UDP یا حتی بسته‌های ICMP echo را فیلتر می‌کنند. برای حل این مشکل، چند روش دیگر برای ردیابی مسیر پیاده‌سازی شده است (از جمله tcp)، بخش فهرست روش‌های موجود (LIST OF AVAILABLE METHODS) در ادامه را ببینید. این روش‌ها تلاش می‌کنند از پروتکل خاص و پورت مبدأ/مقصد مشخصی برای دور زدن دیوارهای آتش استفاده کنند (به گونه‌ای که از دید دیوار آتش صرفاً مانند آغاز یک نشست شبکه مجاز به نظر برسند).

چاپ اطلاعات راهنما و خروج.
-4, -6
اجبار صریح به ردیابی مسیر با IPv4 یا IPv6. به‌طور پیش‌فرض، برنامه تلاش می‌کند نام ارائه‌شده را تحلیل کند و پروتکل مناسب را به‌طور خودکار انتخاب نماید. اگر تحلیل نام میزبان هر دو نشانی IPv4 و IPv6 را برگرداند، traceroute از IPv4 استفاده خواهد کرد.
استفاده از ICMP ECHO برای کاوش‌ها
استفاده از TCP SYN برای کاوش‌ها
فعال کردن اشکال‌زدایی در سطح سوکت (در صورتی که هسته لینوکس از آن پشتیبانی کند)
قطعه‌بندی نکردن بسته‌های کاوشگر. (برای IPv4، بیت DF را نیز تنظیم می‌کند که به مسیریاب‌های میانی دستور می‌دهد از قطعه‌بندی از راه دور نیز خودداری کنند).

با تغییر اندازه بسته کاوشگر از طریق پارامتر خط فرمان packet_len، می‌توانید به‌طور دستی اطلاعاتی درباره MTU هر یک از گام‌های شبکه به دست آورید. گزینه --mtu (در ادامه را ببینید) تلاش می‌کند این کار را به‌طور خودکار انجام دهد.

توجه داشته باشید قابلیت‌های مربوط به عدم قطعه‌بندی (مانند -F یا --mtu) صرفاً از نسخه 2.6.22 هسته لینوکس به بعد به‌درستی کار می‌کنند. پیش از آن نسخه، IPv6 همواره قطعه‌بندی می‌شد و IPv4 فقط می‌توانست از MTU نهایی کشف‌شده (از حافظه موقت مسیرها) استفاده کند که ممکن بود از MTU واقعی دستگاه کمتر باشد.

مشخص می‌کند که ردیابی با چه مقدار TTL آغاز شود. پیش‌فرض 1 است.
به traceroute دستور می‌دهد یک گزینه مسیریابی مبدأ IP به بسته خروجی اضافه کند که به شبکه می‌گوید بسته را از طریق gateway مشخص‌شده هدایت نماید (بیشتر مسیریاب‌ها به دلایل امنیتی مسیریابی مبدأ را غیرفعال کرده‌اند). به‌طور کلی، مشخص کردن چند gateway (جداشده با کاما) مجاز است. برای IPv6، قالب num,addr,addr... مجاز است، که در آن num نوع سرآیند مسیر است (پیش‌فرض نوع 2 است). توجه داشته باشید که سرآیند مسیر نوع 0 اکنون منسوخ شده است (rfc5095).
رابط شبکه‌ای را مشخص می‌کند که traceroute باید بسته‌ها را از طریق آن ارسال کند. به‌طور پیش‌فرض، رابط بر اساس جدول مسیریابی انتخاب می‌شود.
حداکثر تعداد گام‌ها (حداکثر مقدار زمان حیات یا time-to-live) را که traceroute کاوش خواهد کرد، مشخص می‌کند. مقدار پیش‌فرض 30 است.
تعداد بسته‌های کاوشگر ارسالی به‌طور هم‌زمان را مشخص می‌کند. ارسال چندین کاوش به‌صورت هم‌زمان می‌تواند سرعت traceroute را به‌میزان چشمگیری افزایش دهد. مقدار پیش‌فرض 16 است.
توجه داشته باشید که برخی مسیریاب‌ها و میزبان‌ها ممکن است از محدودسازی نرخ (rate throttling) پیام‌های ICMP استفاده کنند. در چنین شرایطی، تعیین مقداری بیش از حد بزرگ می‌تواند منجر به از دست رفتن برخی پاسخ‌ها شود.
هنگام نمایش نشانی‌های IP، برای نگاشت آن‌ها به نام میزبان تلاشی صورت نگیرد.
برای ردیابی با UDP، پورت مبنای مقصد را که traceroute استفاده خواهد کرد، مشخص می‌کند (شماره پورت مقصد با هر کاوش یک واحد افزایش می‌یابد).
برای ردیابی با ICMP، مقدار اولیه توالی ICMP را مشخص می‌کند (این مقدار نیز با هر کاوش یک واحد افزایش می‌یابد).
برای TCP و سایر روش‌ها، صرفاً پورت مقصد ثابت (constant) را برای برقراری اتصال مشخص می‌کند.
برای IPv4، مقدار نوع سرویس (TOS) و حق تقدم (Precedence) را تنظیم می‌کند. مقادیر کاربردی عبارتند از 16 (تأخیر کم) و 8 (توان عملیاتی بالا). توجه داشته باشید برای استفاده از برخی مقادیر حق تقدم TOS، باید مدیر سیستم (کاربر ارشد) باشید.
برای IPv6، مقدار کنترل ترافیک (Traffic Control) را تنظیم می‌کند.
استفاده از برچسب جریان (flow_label) مشخص‌شده برای بسته‌های IPv6.
مدت زمان انتظار برای دریافت پاسخ یک کاوش را تعیین می‌کند.

به‌طور کلی سه مقدار اعشاری هستند که با یک کاما (یا اسلش) از هم جدا می‌شوند. max حداکثر زمان انتظار (بر حسب ثانیه، پیش‌فرض 5.0) را در هر حالتی مشخص می‌کند.

پیاده‌سازی سنتی traceroute همواره برای هر کاوشگر به مدت کامل max ثانیه منتظر می‌ماند. اما اگر هم‌اکنون پاسخ‌هایی از همان گام، یا حتی از یک گام بعدی داشته باشیم، می‌توانیم از زمان رفت و برگشت چنین پاسخی به عنوان یک راهنما برای تعیین میزان معقول زمان انتظار واقعی استفاده کنیم.

مقدار اختیاری here (پیش‌فرض 3.0) ضریبی را مشخص می‌کند که در زمان رفت و برگشت پاسخ از قبل دریافت‌شده از همان گام ضرب می‌شود. مقدار حاصل به جای max (اما نه بیشتر از آن) به عنوان مهلت زمانی (timeout) کاوش استفاده می‌شود. مقدار اختیاری near (پیش‌فرض 10.0) ضریب مشابهی را برای پاسخ از یک گام بعدی مشخص می‌کند. (در هر دو حالت، زمان نخستین نتیجه به‌دست‌آمده استفاده می‌شود).

ابتدا ما به دنبال همان گام می‌گردیم (کاوشی که از اکنون به بعد در ابتدا چاپ خواهد شد). اگر چیزی یافت نشد، سپس به دنبال یک گام بعدی می‌گردیم. اگر چیزی یافت نشد، از max استفاده می‌شود. اگر here و/یا near دارای مقدار صفر باشند، محاسبات متناظر نادیده گرفته می‌شود.
اگر تنها max مشخص شده باشد، here و near همواره روی صفر تنظیم می‌شوند (جهت سازگاری با نسخه‌های پیشین).

تعداد بسته‌های کاوشگر را برای هر گام تنظیم می‌کند. پیش‌فرض 3 است.
دور زدن جدول‌های مسیریابی عادی و ارسال مستقیم به میزبانی در شبکه متصل. اگر میزبان در یک شبکه با اتصال مستقیم نباشد، یک خطا برگردانده می‌شود. از این گزینه می‌توان برای پینگ کردن یک میزبان محلی از طریق رابط شبکه‌ای که مسیری از آن تعریف نشده است استفاده کرد.
یک نشانی مبدأ جایگزین را انتخاب می‌کند. توجه داشته باشید که باید نشانی یکی از رابط‌ها را انتخاب کنید. به‌طور پیش‌فرض، نشانی رابط خروجی استفاده می‌شود.
حداقل فاصله زمانی بین کاوش‌ها (پیش‌فرض 0). اگر مقدار بیش از 10 باشد، عددی بر حسب میلی‌ثانیه را مشخص می‌کند، در غیر این صورت عددی بر حسب ثانیه است (مقادیر اعشاری نیز مجازند). زمانی مفید است که برخی مسیریاب‌ها برای پیام‌های ICMP محدودیت نرخ (rate-limit) اعمال می‌کنند.
نمایش الحاقات ICMP (مطابق با rfc4884). ساختار کلی به‌صورت CLASS/TYPE: همراه با یک دامپ هگزادسیمال است. اطلاعات MPLS (مطابق با rfc4950) به‌صورت تجزیه‌شده و با ساختار زیر نمایش داده می‌شود: MPLS:L=label,E=exp_use,S=stack_bottom,T=TTL (اشیاء بیشتر با / از یکدیگر جدا می‌شوند). اطلاعات رابط شبکه (rfc5837) نیز به همین صورت تجزیه‌شده و در قالب زیر نمایش داده می‌شود: {INC|SUB|OUT|NXT}:index,IP_addr,"name",mtu=MTU (ممکن است هر چهار فیلد وجود نداشته باشند).
انجام جستجوی مسیر سامانه خودمختار (AS path) در رجیستری‌های مسیریابی و چاپ نتایج مستقیماً پس از نشانی‌های متناظر.
چاپ نسخه برنامه و خروج.

گزینه‌های دیگری برای کاربردهای پیشرفته وجود دارند (مانند روش‌های متناوب ردیابی و غیره):

پورت مبدأ مورد استفاده را انتخاب می‌کند. مستلزم گزینه -N 1 -w 5 است. در حالت عادی، پورت‌های مبدأ (در صورت کاربرد) توسط سیستم انتخاب می‌شوند.
تنظیم نشان دیوار آتش (firewall mark) برای بسته‌های خروجی (از هسته لینوکس 2.6.25 به بعد).
استفاده از روش مشخص‌شده برای عملیات traceroute. روش سنتی و پیش‌فرض udp دارای نام default، روش icmp (-I) دارای نام icmp و روش tcp (-T) دارای نام tcp است.
گزینه‌های اختصاصی هر روش را می‌توان با -O ارسال کرد. بیشتر روش‌ها دارای کلیدهای میانبر ساده هستند (-I به معنی -M icmp، و غیره).
یک گزینه اختصاصی روش را مشخص می‌کند. گزینه‌های متعدد با کاما از هم جدا می‌شوند (یا می‌توانید چند بار از -O در خط فرمان استفاده کنید). هر روش ممکن است گزینه‌های خاص خود را داشته باشد، یا اصلاً گزینه‌ای نداشته باشد. برای چاپ اطلاعات درباره گزینه‌های موجود، از -O help استفاده کنید.
استفاده از UDP با یک پورت مقصد مشخص برای ردیابی مسیر (به جای افزایش پورت برای هر کاوش). پورت پیش‌فرض 53 (dns) است.
استفاده از UDPLITE برای ردیابی مسیر (پورت پیش‌فرض 53 است).
استفاده از درخواست‌های DCCP برای کاوش‌ها.
استفاده از بسته خام پروتکل مشخص‌شده برای ردیابی مسیر. پروتکل پیش‌فرض 253 (rfc3692) است.
کشف MTU در طول مسیر در حال ردیابی. مستلزم گزینه -F -N 1 است. مقدار جدید mtu یک بار در قالب F=NUM در نخستین کاوش از گامی چاپ می‌شود که برای رسیدن به آن چنین mtu مقداری لازم است. (در واقع، پیام icmp متناظر «frag needed» معمولاً توسط گام قبلی ارسال می‌شود).

توجه داشته باشید برخی مسیریاب‌ها ممکن است اطلاعات مربوط به قطعه‌بندی را پس از یک بار مشاهده کش کنند. بنابراین ممکن است MTU نهایی را از گام نزدیک‌تری دریافت کنید. تلاش کنید یک tos غیرمعمول را با -t مشخص کنید؛ این کار ممکن است برای یک تلاش مؤثر باشد (سپس ممکن است در آنجا نیز کش شود).
برای اطلاعات بیشتر، گزینه -F را ببینید.

چاپ تعداد گام‌های مسیر برگشت، زمانی که به نظر می‌رسد با جهت رفت متفاوت است. این عدد با این فرض تخمین زده می‌شود که گام‌های دوردست بسته‌های پاسخ را با TTL اولیه 64 یا 128 یا 255 ارسال می‌کنند (که یک رویه متداول به نظر می‌رسد). این عدد به‌صورت یک مقدار منفی در قالب '-NUM' چاپ می‌شود.

به‌طور کلی، یک روش مشخص ردیابی مسیر ممکن است لازم باشد با -M name انتخاب شود، اما بیشتر روش‌ها سوییچ‌های خط فرمان ساده خود را دارند (در صورت وجود، می‌توانید آن‌ها را پس از نام روش مشاهده کنید).

روش سنتی و قدیمی ردیابی مسیر. به‌طور پیش‌فرض استفاده می‌شود.

بسته‌های کاوشگر، دیتاگرام‌های udp با پورت‌های مقصد به‌اصطلاح «نامحتمل» هستند. پورت «نامحتمل» نخستین کاوشگر 33434 است و برای هر کاوش بعدی یک واحد افزایش می‌یابد. از آنجا که انتظار می‌رود این پورت‌ها استفاده‌نشده باشند، میزبان مقصد معمولاً پیام «icmp unreach port» را به عنوان پاسخ نهایی برمی‌گرداند. (البته هیچ‌کس نمی‌داند اگر برنامه‌ای به این پورت‌ها گوش دهد چه اتفاقی می‌افتد).

استفاده از این روش برای کاربران عادی و غیرممتاز مجاز است.

متداول‌ترین روش در حال حاضر که از بسته‌های icmp echo برای کاوش‌ها استفاده می‌کند.
اگر بتوانید میزبان مقصد را با ping(8) پینگ کنید، ردیابی مسیر با icmp نیز قابل استفاده خواهد بود.

این روش ممکن است از نسخه 3.0 هسته (برای IPv4، و برای IPv6 از 3.11) برای کاربران غیرممتاز مجاز باشد، چرا که از سوکت‌های جدید dgram icmp (یا سوکت‌های "ping") پشتیبانی می‌کند. برای مجاز ساختن چنین سوکت‌هایی، مدیر سیستم باید محدوده sysctl مربوط به net/ipv4/ping_group_range را به گونه‌ای تنظیم کند که با گروه کاربر مطابقت داشته باشد.
گزینه‌ها:

صرفاً استفاده از سوکت‌های خام (روش سنتی).
این شیوه به‌طور پیش‌فرض در ابتدا امتحان می‌شود (به دلایل سازگاری)، و سپس سوکت‌های جدید dgram icmp به عنوان جایگزین به کار می‌روند.
صرفاً استفاده از سوکت‌های dgram icmp.

روش شناخته‌شده و مدرن، با هدف دور زدن دیوارهای آتش.
از پورت مقصد ثابت استفاده می‌کند (پیش‌فرض 80، http).

اگر فیلترهایی در مسیر شبکه وجود داشته باشد، به احتمال فراوان هر پورت «نامحتمل» udp (مانند روش default) یا حتی بسته‌های icmp echo (مانند روش icmp) فیلتر می‌شوند و کل عملیات ردیابی مسیر در چنین دیوار آتشی متوقف خواهد شد. برای دور زدن فیلتر شبکه، باید صرفاً از ترکیب‌های مجاز پروتکل/پورت استفاده کنیم. اگر برای مثال در حال ردیابی یک میل‌سرور باشیم، احتمال اینکه گزینه -T -p 25 بتواند به آن برسد بیشتر است، حتی اگر گزینه -I نتواند به مقصد برسد.

این روش از «تکنیک نیمه‌باز» (half-open technique) شناخته‌شده استفاده می‌کند که از دیده شدن کاوش‌های ما توسط برنامه‌های کاربردی روی میزبان مقصد کاملاً جلوگیری می‌نماید. در حالت عادی، یک بسته tcp syn ارسال می‌شود. برای پورت‌هایی که برنامه‌ای روی آن‌ها گوش نمی‌دهد، پاسخ tcp reset دریافت می‌کنیم و کار خاتمه می‌یابد. برای پورت‌هایی با گوش دادن فعال، پاسخ tcp syn+ack دریافت می‌کنیم، اما به جای ارسال tcp ack مورد انتظار، با tcp reset پاسخ می‌دهیم؛ به این ترتیب نشست راه دور tcp حتی بدون اینکه برنامه متوجه آن شود، قطع می‌گردد.

چند گزینه برای روش tcp وجود دارد:

تنظیم پرچم‌های (flags) مشخص‌شده tcp برای بسته کاوشگر، در هر ترکیبی.
تنظیم فیلد پرچم‌ها در سرآیند tcp دقیقاً به مقدار num.
ارسال بسته syn با پرچم‌های tcp به نام‌های ECE و CWR (برای اعلان صریح ازدحام یا Explicit Congestion Notification، rfc3168).
استفاده از گزینه سرآیند tcp متناظر در بسته کاوشگر خروجی.
استفاده از تنظیمات جاری sysctl (/proc/sys/net/*) برای گزینه‌های سرآیند tcp در بالا و ecn. در صورت عدم تعیین مورد دیگر، همواره به‌طور پیش‌فرض تنظیم می‌شود.
استفاده از گزینه fastopen در tcp (هنگام syn)، صرفاً برای مذاکره اولیه کوکی.
استفاده از مقدار num (یا بدون تغییر) برای گزینه maxseg سرآیند tcp (هنگام syn)، و کشف کاهش اجباری (clamping) آن در طول مسیر ردیابی‌شده. مقدار تغییریافته جدید mss یک بار در قالب M=NUM در نخستین کاوشی که در آن تشخیص داده شد، چاپ می‌شود. توجه داشته باشید که برخی مسیریاب‌ها ممکن است در پیام اتمام مهلت زمانی (time exceeded)، قطعه اصلی بسیار کوتاهی را برگردانند که بررسی را غیرممکن می‌سازد. علاوه بر این، ممکن است پاسخ‌ها با ترتیبی متفاوت دریافت شوند. همه این موارد می‌تواند منجر به ثبت گزارش در جایگاهی دیرتر شود (استفاده از -N 1 می‌تواند به رعایت ترتیب کمک کند).
چاپ پرچم‌های tcp و گزینه‌های پشتیبانی‌شده پاسخ‌های نهایی tcp در زمان رسیدن به میزبان مقصد. امکان تشخیص اینکه آیا برنامه‌ای به پورت گوش می‌دهد و موارد مفید دیگر را فراهم می‌کند. گزینه‌های پشتیبانی‌شده tcp تمامی مواردی هستند که می‌توان با -T -O تنظیم کرد، یعنی mss، sack، timestamps، window_scaling و fastopen، با فرمت خروجی مشابه (یک مقدار برای mss و صرفاً حضور برای سایر موارد).

گزینه‌های پیش‌فرض عبارتند از syn,sysctl.

یک پیاده‌سازی اولیه از روش tcp با استفاده ساده از فراخوانی connect(2) که باز کردن کامل نشست tcp را انجام می‌دهد. برای استفاده عادی توصیه نمی‌شود، زیرا برنامه کاربردی مقصد همواره تحت تأثیر قرار می‌گیرد (و ممکن است دچار اختلال شود).

استفاده از دیتاگرام udp با پورت مقصد ثابت (پیش‌فرض 53، dns).
همچنین با هدف دور زدن دیوارهای آتش طراحی شده است.

توجه داشته باشید که بر خلاف روش tcp، برنامه متناظر در میزبان مقصد همیشه کاوش‌های ما را (با داده‌های تصادفی) دریافت می‌کند، و اکثر برنامه‌ها به آسانی ممکن است با آن‌ها دچار سردرگمی شوند. در بیشتر موارد به بسته‌های ما پاسخی نمی‌دهند، بنابراین هرگز آخرین گام را در ردیابی نخواهیم دید. (خوشبختانه به نظر می‌رسد دست‌کم سرورهای dns پاسخی خشمگینانه بازمی‌گردانند).

استفاده از این روش برای کاربران عادی و غیرممتاز مجاز است.

استفاده از دیتاگرام udplite برای کاوش‌ها (با پورت مقصد ثابت، پیش‌فرض 53).

استفاده از این روش برای کاربران عادی و غیرممتاز مجاز است.
گزینه‌ها:

تنظیم پوشش ارسال udplite به مقدار num.

استفاده از بسته‌های درخواست DCCP برای کاوش‌ها (rfc4340).

این روش از همان «تکنیک نیمه‌باز» مورد استفاده در TCP بهره می‌برد. پورت مقصد پیش‌فرض 33434 است.

گزینه‌ها:

تنظیم کد سرویس DCCP به مقدار num (پیش‌فرض 1885957735 است).

ارسال بسته خام از پروتکل proto.
هیچ سرآیند اختصاصی پروتکل استفاده نمی‌شود و صرفاً سرآیند IP به کار می‌رود.
مستلزم گزینه -N 1 -w 5 است.
گزینه‌ها:

استفاده از پروتکل IP به شماره proto (پیش‌فرض 253).

جهت افزایش سرعت کار، به‌طور معمول چندین کاوشگر به‌صورت هم‌زمان ارسال می‌شوند. از سوی دیگر، این کار باعث ایجاد یک «طوفان بسته» به ویژه در مسیر برگشت پاسخ‌ها می‌شود. مسیریاب‌ها می‌توانند نرخ پاسخ‌های icmp را محدود (throttle) کنند و ممکن است برخی از پاسخ‌ها از دست بروند. برای جلوگیری از این مشکل، تعداد کاوش‌های هم‌زمان را کاهش دهید، یا حتی آن را روی 1 تنظیم کنید (مانند پیاده‌سازی اولیه traceroute)، یعنی: -N 1

میزبان نهایی (مقصد) می‌تواند برخی از کاوش‌های هم‌زمان را دور بیندازد، و حتی ممکن است صرفاً به آخرین کاوش‌ها پاسخ دهد. این وضعیت می‌تواند منجر به ایجاد گام‌های اضافی در نزدیکی گام نهایی شود که «منقضی‌شده به نظر می‌رسند». ما از یک الگوریتم هوشمند برای تشخیص خودکار چنین وضعیتی استفاده می‌کنیم، اما اگر در مورد شما مؤثر واقع نشد، کافی است شما نیز از گزینه -N 1 استفاده کنید.

برای پایداری بیشتر می‌توانید با استفاده از گزینه -z سرعت کار برنامه را کاهش دهید، برای مثال از -z 0.5 برای ایجاد یک وقفه نیم‌ثانیه‌ای بین کاوش‌ها استفاده کنید.

برای جلوگیری از انتظار اضافی، از یک الگوریتم تطبیقی برای مهلت‌های زمانی استفاده می‌کنیم (برای اطلاعات بیشتر گزینه -w را ببینید). این کار می‌تواند منجر به انقضای زودهنگام (به‌ویژه هنگامی که زمان‌های پاسخ در مقاطع زمانی مختلف تفاوت داشته باشند) و چاپ «*» به جای زمان شود. در چنین حالتی، با تعیین گزینه -w تنها با مهلت زمانی مورد نظر، این الگوریتم را غیرفعال کنید (برای نمونه: -w 5).

اگر برای تمامی روش‌ها هیچ پاسخی از برخی گام‌ها گزارش نشد، آخرین شانس برای دستیابی به اطلاعات، استفاده از دستور ping -R است (برای IPv4، و صرفاً برای ۸ گام نزدیک‌تر).

ping(8), ping6(8), tcpdump(8), netstat(8)

11 October 2006 Traceroute