تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يوضح هذا المستند كيفية عمل traceroute
الأمر على أنظمة مختلفة.
يجب أن يكون لدى قراء هذا المستند معرفة أساسية بواحد من أنظمة التشغيل هذه:
برامج® أنظمة تشغيل Cisco
لينكس
مايكروسوفت ويندوز
تنطبق المعلومات الواردة في هذا المستند على إصدارات البرامج والمكونات المادية التالية:
الموجه الذي يشغل برنامج Cisco IOS الإصدار 12
كمبيوتر يعمل بنظام التشغيل Red Hat Linux
كمبيوتر يعمل بنظام التشغيل MS Windows
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
يسمح الأمر traceroute
أنت أن يحدد المسار الذي تسلكه الحزمة للوصول إلى وجهة من مصدر معين بإرجاع تسلسل الخطوات التي قطعتها الحزمة. تأتي هذه الأداة المساعدة مع نظام التشغيل المضيف (على سبيل المثال، Linux أو Microsoft (MS) Windows)، بالإضافة إلى برنامج Cisco IOS.
إذا قمت بتنفيذ الأمر traceroute ip-address
على جهاز مصدر (مثل مضيف، أو موجه يعمل كمضيف)، فإنه يرسل حزم IP نحو الوجهة مع قيم مدة البقاء (TTL) التي تتزايد حتى الحد الأقصى لعدد الخطوات المحددة. هذا 30 افتراضيا. عادة، يقوم كل موجه في المسار نحو الوجهة بخفض حقل TTL بمقدار وحدة واحدة أثناء إعادة توجيه هذه الحزم. عندما يجد الموجه في منتصف المسار حزمة مع TTL = 1، فإنه يستجيب مع رسالة "تجاوز الوقت" لبروتوكول رسالة التحكم في الإنترنت (ICMP) إلى المصدر. تتيح هذه الرسالة للمصدر معرفة أن الحزمة تجتاز الموجه المعين كخطوة
هناك بعض الاختلافات مع طريقة تنفيذ traceroute
الأمر في أنظمة التشغيل المختلفة التي يتناقش فيها هذا المستند.
يتم تعيين مدة البقاء (TTL) لمتحقق مخطط بيانات بروتوكول مخطط بيانات المستخدم (UDP) الأولي على 1 (أو الحد الأدنى ل TTL، كما هو محدد بواسطة المستخدم في traceroute
الأمر الموسع. تم تعيين منفذ UDP للوجهة من مستكشف مخطط البيانات الأولي على 33434 (أو كما هو محدد في إخراج traceroute
الأمر الموسع). الأمر الموسع traceroute
هو تنوع من الأمر العادي traceroute
الذي يسمح بتعديل القيم الافتراضية للمعلمات المستخدمة من قبل العملية traceroute
مثل TTL ورقم منفذ الوجهة. لمزيد من المعلومات حول كيفية إستخدام traceroute
الأمر الموسع، ارجع إلى فهم أوامر ping الموسع و traceroute الموسعة. يتم تقسيم منفذ UDP المصدر الخاص بمسبار مخطط البيانات الأولي بشكل عشوائي ويحتوي على المشغل المنطقي OR مع 0x8000 (يضمن منفذ مصدر أدنى وهو 0x8000). توضح هذه الخطوات ما يحدث عند تشغيل مخطط بيانات UDP:
ملاحظة: المعلمات قابلة للتكوين. يبدأ هذا المثال ب n = 1 وينتهي ب n = 3.
يتم إرسال مخطط بيانات UDP مع TTL = 1، والوجهة UDP port= 33434، ومنفذ المصدر عشوائيا.
تتم زيادة منفذ وجهة UDP، ويتم توزيع منفذ UDP المصدر عشوائيا، ويتم إرسال مخطط البيانات الثاني.
يتم تكرار الخطوة 2 لما يصل إلى ثلاثة مستكشفات (أو عدد المرات المطلوب في إخراج traceroute
أمر موسع). لكل إختبار من الاختبارات التي تم إرسالها، تتلقى رسالة "TTL Exceeded"، والتي يتم إستخدامها لبناء مسار خطوة بخطوة إلى مضيف الوجهة.
ويتم زيادة مدة البقاء (TTL)، وتكرر هذه الدورة باستخدام أرقام منافذ الوجهة التزايدية، إذا تم تلقي رسالة تجاوز وقت بروتوكول التحكم برسائل الإنترنت (ICMP). يمكنك أيضا الحصول على واحدة من هذه الرسائل:
رسالة من نوع ICMP 3، الرمز 3 (الوجهة التي يتعذر الوصول إليها، المنفذ الذي يتعذر الوصول إليه)، والتي تشير إلى أنه تم الوصول إلى مضيف.
مضيف يتعذر الوصول إليه، net unreachable، maximum TTL تجاوز، أو مهلة نوع الرسالة، مما يعني أن المسبار مستاء.
ترسل موجهات Cisco حزم تحقيق UDP باستخدام منفذ مصدر عشوائي ومنفذ وجهة تزايدي (لتمييز المستكشفات المختلفة). ترسل موجهات Cisco وقت رسالة ICMP الذي تم تجاوزه مرة أخرى إلى المصدر من حيث تم تلقي حزمة UDP/ICMP.
إن أمر Linux traceroute
مشابه لتنفيذ موجه Cisco. مهما، يستعمل هو ثابت مصدر ميناء. يتم إستخدام -n
الخيار في traceroute
الأمر لتجنب طلب خادم اسم.
يستخدم الأمر MS Windowstracert
مخططات بيانات طلبات ICMP Echo بدلا من مخططات بيانات UDP كأدوات بحث. يتم تشغيل طلبات صدى ICMP مع زيادة مدة البقاء (TTL)، وتظهر نفس العملية كما هو موضح في Cisco IOS و Linux. تتمثل أهمية إستخدام مخططات بيانات طلب صدى ICMP في أن الخطوة النهائية لا تعتمد على إستجابة رسالة ICMP الذي يتعذر الوصول إليه من مضيف الوجهة. ويعتمد بدلا من ذلك على رسالة رد ICMP Echo.
صياغة الأمر هي:
tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name
يشرح هذا الجدول معلمات الأوامر:
بارامتر | الوصف |
---|---|
-د | يحدد عدم تحليل العناوين إلى أسماء الكمبيوتر. |
-h maximum_hops | يحدد الحد الأقصى لعدد الخطوات التي سيتم البحث فيها عن هدف. |
-j قائمة حاسوب | تحديد مسار مصدر غير محكم على طول قائمة الكمبيوتر. |
مهلة -w | ينتظر عدد المللي ثانية المحددة بواسطة المهلة لكل رد. |
target_name | اسم الكمبيوتر الهدف. |
يتم تحديد بروتوكولات ICMP التي يتعذر الوصول إليها على حزمة واحدة لكل 500 مللي ثانية (كحماية لهجمات رفض الخدمة (DoS)) في موجه Cisco. من برنامج Cisco IOS الإصدار 12.1 والإصدارات الأحدث، تكون قيمة المعدل هذه قابلة للتكوين. الأمر الذي تم تقديمه هو:
Router(config)#ip icmp rate-limit unreachable ? <1-4294967295> Once per milliseconds DF code 4, fragmentation needed and DF set
ويكون هذا القيد خاصا بالمعدل الإجمالي لجميع بروتوكولات ICMP التي يتعذر الوصول إليها، كما يظهر هذا الإخراج. راجع RFC 792 للحصول على مزيد من المعلومات.
type = 3, code 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed.
لا يؤثر هذا التحديد على الحزم الأخرى مثل طلبات صدى ICMP أو الرسائل التي تتجاوز وقت ICMP.
يتم إستخدام مخطط الشبكة هذا للأمثلة:
في كل من الأمثلة الثلاثة، يتم إستخدام جهاز مختلف A. من الجهاز A، traceroute 10.1.4.2
يتم تنفيذ الأمر إلى الجهاز 7C.
في كل مثال، debug ip packet detail
يتم تشغيل الأمر على الجهاز 11a.
يوضح مثال traceroute
الأمر الموسع هذا الخيارات التي يمكنك تغييرها عند تنفيذ أمر traceroute
من موجه Cisco. في هذا المثال، كل شيء يترك بشكل افتراضي:
rp-10c-2611#traceroute Protocol [ip]: Target IP address: 10.1.4.2 Source address: 10.1.1.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.1.4.2 1 10.1.1.2 4 msec 0 msec 4 msec 2 10.1.2.2 4 msec 4 msec 0 msec 3 10.1.3.2 0 msec 0 msec 4 msec 4 10.1.4.2 4 msec * 0 msec rp-11a-7204# *Dec 29 13:13:57.060: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 13:13:57.060: ICMP type=11, code=0 *Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 13:13:57.064: ICMP type=11, code=0 *Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 13:13:57.068: ICMP type=11, code=0
في إخراج تصحيح الأخطاء هذا، يرسل الجهاز 11A رسائل تجاوز وقت بروتوكول ICMP إلى مصدر الاختبارات (10.1.1.1). وتأتي رسائل ICMP هذه إستجابة للاستكشافات الأولية التي كان لها TTL=1. يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى صفر، ويجيب مع الرسائل التي تم تجاوز الوقت بها.
ملاحظة: لا ترى مستكشفات UDP في إخراج تصحيح الأخطاء هذا لسببين:
ليس الجهاز 11A هو الوجهة من مستكشفات UDP.
يتم تقليل مدة البقاء (TTL) إلى صفر، ولا يتم توجيه الحزمة أبدا. لذلك، لا يتعرف تصحيح الأخطاء أبدا على الحزمة.
*Dec 29 13:13:57.068: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.068: UDP src=40309, dst=33437 *Dec 29 13:13:57.068: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.068: ICMP type=11, code=0 *Dec 29 13:13:57.072: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.072: UDP src=37277, dst=33438 *Dec 29 13:13:57.072: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.072: ICMP type=11, code=0 *Dec 29 13:13:57.076: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.076: UDP src=36884, dst=33439 *Dec 29 13:13:57.076: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.076: ICMP type=11, code=0
يعرض إخراج تصحيح الأخطاء هذا تحقيق UDP من المصدر 10.1.1.1 الموجه إلى 10.1.4.2.
ملاحظة: في هذه الاختبارات ال TTL=2 (لا يمكن رؤية هذا مع debug). يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى 1 وإعادة توجيه حزم UDP على الجهاز 7A. يقوم الجهاز 7A بخفض مدة البقاء (TTL) إلى صفر، ويجيب باستخدام رسائل تجاوز وقت بروتوكول ICMP.
*Dec 29 13:13:57.080: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.080: UDP src=37479, dst=33440 *Dec 29 13:13:57.080: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.080: ICMP type=11, code=0 *Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.084: UDP src=40631, dst=33441 *Dec 29 13:13:57.084: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.084: ICMP type=11, code=0 *Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.088: UDP src=39881, dst=33442 *Dec 29 13:13:57.088: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.088: ICMP type=11, code=0
يمكنك مشاهدة مستكشفات UDP الثلاثة التالية في إخراج تصحيح الأخطاء هذا. مدة البقاء (TTL) لهذه المسابير هي 3. يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى 2 وإعادة توجيهها إلى الجهاز 7A. يقوم الجهاز 7A بخفض مدة البقاء (TTL) إلى 1 وإعادة توجيه الحزم على الجهاز 7B، والذي يقلل تدريجيا من مدة البقاء (TTL) إلى الصفر والاستجابة باستخدام رسائل تجاوز وقت بروتوكول التحكم برسائل الإنترنت (ICMP).
*Dec 29 13:13:57.088: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.088: UDP src=39217, dst=33443 *Dec 29 13:13:57.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.092: ICMP type=3, code=3 *Dec 29 13:13:57.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.096: UDP src=34357, dst=33444 *Dec 29 13:14:00.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:14:00.092: UDP src=39587, dst=33445 *Dec 29 13:14:00.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:14:00.092: ICMP type=3, code=3
يمكنك رؤية مستكشفات UDP الثلاثة الأخيرة في إخراج تصحيح الأخطاء هذا. وكانت مدة البقاء (TTL) الأصلية لهذه المسابير هي 4. تم تقليل مدة البقاء (TTL) إلى 3 حسب الجهاز 11A، ثم تم تقليصها إلى 2 حسب الجهاز 7A، ثم تم تقليصها إلى 1 حسب الجهاز 7B. يستجيب الجهاز 7C باستخدام رسائل منفذ ICMP الذي يتعذر الوصول إليه، نظرا لأنه كان وجهة المسابير.
ملاحظة: يرسل الجهاز 7C رسالتين فقط لمنفذ ICMP الذي يتعذر الوصول إليه بسبب تحديد المعدل.
[root#linux-pc]#traceroute -n 10.1.4.2 traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets 1. 10.1.1.2 1.140 ms 0.793 ms 0.778 ms 2. 10.1.2.2 2.213 ms 2.105 ms 3.491 ms 1. 10.1.3.2 3.146 ms 2.314 ms 2.347 ms 1. 10.1.4.2 3.579 ms * 2.954 ms rp-11a-7204# *Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Jan 2 07:17:27.894: ICMP type=11, code=0 *Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Jan 2 07:17:27.894: ICMP type=11, code=0 *Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Jan 2 07:17:27.894: ICMP type=11, code=0
في إخراج تصحيح الأخطاء هذا، يرسل الجهاز 11A رسائل تجاوز وقت بروتوكول ICMP إلى مصدر الاختبارات (10.1.1.1). وتأتي رسائل ICMP هذه إستجابة للاستكشافات الأولية التي كان لها TTL=1. يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى صفر، ويجيب مع الرسائل التي تم تجاوز الوقت بها.
لا ترى مستكشفات UDP في إخراج تصحيح الأخطاء هذا لسببين:
ليس الجهاز 11A هو الوجهة من مستكشفات UDP.
يتم تقليل مدة البقاء (TTL) إلى صفر، ولا يتم توجيه الحزمة أبدا. لذلك، لا يتعرف تصحيح الأخطاء أبدا على الحزمة.
*Jan 2 07:17:27.894: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.894: UDP src=33302, dst=33438 *Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.898: ICMP type=11, code=0 *Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.898: UDP src=33302, dst=33439 *Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.898: ICMP type=11, code=0 *Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.898: UDP src=33302, dst=33440 *Jan 2 07:17:27.902: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.902: ICMP type=11, code=0
ملاحظة: في إخراج تصحيح الأخطاء هذا، ترى الآن تحقيق UDP من المصدر 10.1.1.1 الموجه إلى 10.1.4.2.
ملاحظة: في هذه الاختبارات ال TTL=2 (لا يمكن رؤية هذا مع debug). يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى 1 وإعادة توجيه حزم UDP على الجهاز 7A. يقوم الجهاز 7A بخفض مدة البقاء (TTL) إلى صفر، ويجيب باستخدام رسائل تجاوز وقت بروتوكول ICMP.
*Jan 2 07:17:27.902: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.902: UDP src=33302, dst=33441 *Jan 2 07:17:27.906: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.906: ICMP type=11, code=0 *Jan 2 07:17:27.906: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.906: UDP src=33302, dst=33442 *Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.910: ICMP type=11, code=0 *Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.910: UDP src=33302, dst=33443 *Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.910: ICMP type=11, code=0
تظهر مستكشفات UDP الثلاثة التالية الآن في إخراج تصحيح الأخطاء هذا. مدة البقاء (TTL) لهذه المسابير هي 3. يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى 2 وإعادة توجيهها إلى الجهاز 7A. يقوم الجهاز 7A بخفض مدة البقاء (TTL) إلى 1 وإعادة توجيه الحزم على الجهاز 7B، والذي يقلل تدريجيا من مدة البقاء (TTL) إلى الصفر والاستجابة باستخدام رسائل تجاوز وقت بروتوكول التحكم برسائل الإنترنت (ICMP).
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.910: UDP src=33302, dst=33444 *Jan 2 07:17:27.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.914: ICMP type=3, code=3 *Jan 2 07:17:27.914: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.914: UDP src=33302, dst=33445 *Jan 2 07:17:32.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:32.910: UDP src=33302, dst=33446 *Jan 2 07:17:32.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:32.914: ICMP type=3, code=3
يعرض إخراج تصحيح الأخطاء هذا مستكشفات UDP الثلاثة الأخيرة. وكانت مدة البقاء (TTL) الأصلية لهذه المسابير هي 4. تم تقليل مدة البقاء (TTL) إلى 3 حسب الجهاز 11A، ثم تم تقليصها إلى 2 حسب الجهاز 7A، ثم تم تقليصها إلى 1 حسب الجهاز 7B.
يستجيب الجهاز 7C بعد ذلك مع رسائل منفذ ICMP الذي يتعذر الوصول إليه، نظرا لأنه كان وجهة المسابير.
ملاحظة: يرسل الجهاز 7C رسالتين فقط لمنفذ ICMP الذي يتعذر الوصول إليه بسبب تحديد المعدل.
C:\>tracert 10.1.4.2 1 <10 ms <10 ms <10 ms 10.1.1.2 1 <10 ms <10 ms <10 ms 10.1.2.2 1 <10 ms <10 ms <10 ms 10.1.3.2 1 <10 ms 10 ms 10 ms 10.1.4.2 Trace complete rp-11a-7204# *Dec 29 14:02:22.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 78, forward *Dec 29 14:02:22.236: UDP src=137, dst=137 *Dec 29 14:02:22.240: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:22.240: ICMP type=3, code=3 *Dec 29 14:02:23.732: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 78, forward *Dec 29 14:02:23.732: UDP src=137, dst=137 *Dec 29 14:02:23.736: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:23.736: ICMP type=3, code=3 *Dec 29 14:02:25.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 78, forward *Dec 29 14:02:25.236: UDP src=137, dst=137 *Dec 29 14:02:25.236: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:25.240: ICMP type=3, code=3 *Dec 29 14:02:26.748: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 14:02:26.748: ICMP type=11, code=0 *Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 14:02:26.752: ICMP type=11, code=0 *Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 14:02:26.752: ICMP type=11, code=0
في إخراج تصحيح الأخطاء هذا، يرسل الجهاز 11A رسائل تجاوز وقت بروتوكول ICMP إلى مصدر الاختبارات (10.1.1.1). وتأتي رسائل ICMP هذه كاستجابة لعمليات التحقق الأولية، والتي هي حزم طلب صدى ICMP مع TTL=1. يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى صفر والاستجابة مع رسائل ICMP.
ملاحظة: في الأعلى ترى طلبات اسم NetBIOS. يتم إعتبار هذه الطلبات كحزم UDP ذات منافذ المصدر والوجهة رقم 137. لأسباب الوضوح، تتم إزالة حزم NetBIOS من بقية إخراج تصحيح الأخطاء. يمكنك إستخدام الخيار -d
في الأمر tracert
لتعطيل سلوك NetBIOS.
لا ترى مستكشفات ICMP في إخراج تصحيح الأخطاء هذا لسببين:
ليس الجهاز 11A هو وجهة مستكشفات ICMP.
يتم تقليل مدة البقاء (TTL) إلى صفر، ولا يتم توجيه الحزمة أبدا. لذلك، لا يتعرف تصحيح الأخطاء أبدا على الحزمة.
*Dec 29 14:02:32.256: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:32.256: ICMP type=8, code=0 *Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:32.260: ICMP type=11, code=0 *Dec 29 14:02:32.260: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:32.260: ICMP type=8, code=0 *Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:32.260: ICMP type=11, code=0 *Dec 29 14:02:32.264: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:32.264: ICMP type=8, code=0 *Dec 29 14:02:32.264: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:32.264: ICMP type=11, code=0
في إخراج تصحيح الأخطاء هذا، ترى الآن تحقيق ICMP من المصدر 10.1.1.1 الموجه إلى 10.1.4.2.
ملاحظة: في هذه المسابير، ال TTL=2 (لا يمكن رؤية ذلك مع debug). يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى 1 وإعادة توجيه حزم UDP إلى الجهاز 7A. يقوم الجهاز 7A بخفض مدة البقاء (TTL) إلى صفر، ويجيب باستخدام رسائل تجاوز وقت بروتوكول ICMP.
*Dec 29 14:02:37.776: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:37.776: ICMP type=8, code=0 *Dec 29 14:02:37.776: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:37.776: ICMP type=11, code=0 *Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:37.780: ICMP type=8, code=0 *Dec 29 14:02:37.780: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:37.780: ICMP type=11, code=0 *Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:37.780: ICMP type=8, code=0 *Dec 29 14:02:37.784: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:37.784: ICMP type=11, code=0
يمكنك مشاهدة مستكشفات ICMP الثلاثة التالية في إخراج تصحيح الأخطاء هذا. مدة البقاء (TTL) لهذه المسابير هي 3. يقوم الجهاز 11A بخفض مدة البقاء (TTL) إلى 2 وإعادة توجيهها إلى الجهاز 7A. يقوم الجهاز 7A بخفض مدة البقاء (TTL) إلى 1 وإعادة توجيه الحزم على الجهاز 7B، والذي يقلل تدريجيا من مدة البقاء (TTL) إلى الصفر والاستجابة باستخدام رسائل تجاوز وقت بروتوكول التحكم برسائل الإنترنت (ICMP).
*Dec 29 14:02:43.292: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:43.292: ICMP type=8, code=0 *Dec 29 14:02:43.296: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 92, forward *Dec 29 14:02:43.296: ICMP type=0, code=0 *Dec 29 14:02:43.296: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:43.296: ICMP type=8, code=0 *Dec 29 14:02:43.300: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 92, forward *Dec 29 14:02:43.300: ICMP type=0, code=0 *Dec 29 14:02:43.300: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:43.300: ICMP type=8, code=0 *Dec 29 14:02:43.304: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 92, forward *Dec 29 14:02:43.304: ICMP type=0, code=0
يعرض إخراج تصحيح الأخطاء هذا مستكشفات ICMP الثلاثة الأخيرة. وكانت مدة البقاء (TTL) الأصلية لهذه المسابير هي 4. تم تقليل مدة البقاء (TTL) إلى 3 حسب الجهاز 11A، ثم تم تقليصها إلى 2 حسب الجهاز 7A، ثم تم تقليصها إلى 1 حسب الجهاز 7B. ويقوم الجهاز 7C بعد ذلك بالإجابة باستخدام رسائل الرد على صدى ICMP (type=0، code=0)، نظرا لأنه كان وجهة المسابير.
ملاحظة: رسائل الرد على صدى ICMP ليست محدودة حسب معدل رسائل منفذ ICMP الذي يتعذر الوصول إليه. في هذه الحالة، ترى رسائل الرد الثلاث على ICMP Echo المرسلة.
في موجهات Cisco، تكون رموز رد traceroute
الأمر:
! -- success * -- time out N -- network unreachable H -- host unreachable P -- protocol unreachable A -- admin denied Q -- source quench received (congestion) ? -- unknown (any other ICMP message)
إذا قمت بتشغيل traceroute
الأمر من UNIX، لاحظ العناصر التالية:
يمكنك تلقي traceroute: icmp socket: Permission denied
رسائل.
يعتمد البرنامج traceroute
على NIT (NIT) لمسة واجهة الشبكة. لا يمكن الوصول إلى هذا الجهاز إلا من خلال الجذر. يجب إما تشغيل البرنامج كجذر أو تعيين معرف المستخدم كجذر.
لقد عرض هذا المستند كيفية تحديد traceroute
الأمر للمسار الذي تسلكه الحزمة من مصدر معين إلى وجهة معينة باستخدام حزم UDP و ICMP. الأنواع المحتملة من رسائل ICMP في المخرجات هي:
إذا تم تجاوز مدة البقاء (TTL) في النقل، النوع=11، الرمز=0، فسيتم إعادة الحزمة بواسطة موجه النقل في جميع الحالات التي تنتهي فيها مدة البقاء (TTL) لحزم التحقيق قبل أن تصل الحزم إلى الوجهة.
إذا كان المنفذ غير قابل للوصول، type=3، code=3، حينئذ يتم إرسال الحزمة مرة أخرى كاستجابة لحزم تحقيق UDP عندما تصل إلى الوجهة (تطبيق UDP غير معرف). تقتصر هذه الحزم على حزمة واحدة لكل 500 مللي ثانية. وهذا يفسر لماذا فشلت الاستجابة من الوجهة (راجع مخرجات موجه Cisco و Linux) في الاستجابات الزوجية. لا يقوم الجهاز 7C بإنشاء رسالة ICMP، traceroute
وينتظر إخراج الأمر في كل جهاز لأكثر من ثانية واحدة. في حالة إخراج الأمر MS Windows tracert
، يتم إنشاء رسالة ICMP لأن منفذ UDP 137 غير موجود في موجه Cisco.
إذا كان هناك صدى، نوع=8، رمز=0، ثم يتم إرسال حزمة مسبار الارتداد بواسطة MS Windows pc.
إذا كان هناك رد صدى، اكتب=0، code=0، ثم يتم إرسال رد على الحزمة السابقة عندما يتم الوصول إلى الوجهة. لا ينطبق هذا إلا على الأمر MS Windows tracert
.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
2.0 |
16-Oct-2023 |
تقويم |
1.0 |
11-Apr-2002 |
الإصدار الأولي |