المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

رسائل إعادة توجيه ICMP

مسارات دون المستوى الأمثل عبر شبكات إيثرنت

التوجيه الثابت

التوجيه القائم على السياسة

عمليات إعادة توجيه ICMP على الارتباطات من نقطة إلى نقطة

اعتبارات منصات Nexus

أدوات مراقبة حركة المرور وتشخيصها

show ip traffic

إيثاناليزر

تعطيل عمليات إعادة توجيه ICMP

ملخص

المقدمة

يصف هذا المستند وظيفة إعادة توجيه حزمة بروتوكول رسائل التحكم في الإنترنت (ICMP).

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- بنية النظام الأساسي Nexus 7000

- تكوين برنامج Cisco NX-OS

- بروتوكول رسائل التحكم في الإنترنت كما هو موثق في طلب التعليقات (RFC) 792

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

- Nexus 7000

- برنامج NX-OS من Cisco

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

يناقش هذا المستند وظيفة إعادة توجيه الحزم التي يوفرها بروتوكول رسائل التحكم في الإنترنت (ICMP). يشرح المستند ما يشير إليه عادة وجود رسائل إعادة توجيه ICMP في الشبكة، وما يمكن فعله لتقليل التأثيرات الجانبية السلبية المرتبطة بظروف الشبكة التي تتسبب في إنشاء رسائل إعادة توجيه ICMP.

رسائل إعادة توجيه ICMP

يتم شرح وظيفة إعادة توجيه ICMP في بروتوكول رسائل التحكم في الإنترنت ل RFC 792 مع هذا المثال:

ترسل البوابة رسالة إعادة توجيه إلى مضيف في هذه الحالة.

تتلقى البوابة، G1، مخطط بيانات إنترنت من مضيف على شبكة متصلة بها البوابة. تقوم البوابة، G1، بالتحقق من جدول التوجيه الخاص بها وتحصل على عنوان البوابة التالية، G2، على المسار إلى شبكة وجهة الإنترنت لمخطط البيانات، X

إذا كانت G2 والمضيف المحدد بواسطة عنوان مصدر الإنترنت لمخطط البيانات على الشبكة نفسها، يتم إرسال رسالة إعادة توجيه إلى المضيف. تنصح الرسالة المعاد توجيهها المضيف بإرسال حركة مرور البيانات الخاصة به للشبكة X مباشرة إلى البوابة G2 حيث أن هذا مسار أقصر إلى الوجهة.

تقوم البوابة بإعادة توجيه بيانات مخطط البيانات الأصلية إلى وجهة الإنترنت الخاصة بها.

ويتم توضيح هذا السيناريو في الشكل 1. المضيف وموجهان، هما G1 و G2، متصلان بمقطع إيثرنت مشترك ولهما عناوين IP في الشبكة نفسها 10.0.0.0/24

الشكل 1 عمليات إعادة توجيه ICMP في شبكات إيثرنت متعددة النقاط

عمليات إعادة توجيه ICMP في شبكات إيثرنت متعددة النقاط

المضيف لديه عنوان IP 10.0.0.100. يحتوي جدول توجيه المضيف على إدخال مسار افتراضي يشير إلى عنوان IP للموجه G1 10.0.1 كبوابة افتراضية. يستخدم الموجه G1 عنوان IP الخاص بالموجه G2 10.0.0.2 كنقطة مرور تالية عند إعادة توجيه حركة مرور البيانات إلى الشبكة الوجهة X.

هذا ما يحدث عندما يرسل المضيف حزمة إلى شبكة الوجهة X:

1. تستلم البوابة G1 ذات عنوان IP 10.0.0.1 حزمة البيانات من المضيف 10.0.0.100 على شبكة مرتبطة بها.

2. يتحقق البوابة، G1، من جدول التوجيه الخاص بها ويحصل على عنوان IP 10.0.0.2 للعبارة التالية، G2، على المسار إلى شبكة وجهة حزمة البيانات، X.

3. إذا كانت G2 والمضيف المحدد بواسطة عنوان المصدر لحزمة IP على الشبكة نفسها، يتم إرسال رسالة إعادة توجيه ICMP إلى المضيف. تنصح رسالة إعادة توجيه ICMP المضيف بإرسال حركة مرور البيانات الخاصة به للشبكة X مباشرة إلى البوابة G2 لأن هذا مسار أقصر إلى الوجهة.

4.  تقوم البوابة G1 بإعادة توجيه حزمة البيانات الأصلية إلى الوجهة الخاصة بها.

واعتمادا على تكوين المضيف، يمكن أن تختار تجاهل رسائل إعادة توجيه ICMP التي ترسلها G1 إليها. ومع ذلك، إذا كان المضيف يستخدم رسائل إعادة توجيه ICMP لضبط ذاكرة التخزين المؤقت للتوجيه الخاصة به ويبدأ في إرسال حزم البيانات اللاحقة مباشرة إلى G2، فسيتم تحقيق هذه الفوائد في هذا السيناريو

- تحسين مسار إعادة توجيه البيانات من خلال الشبكة؛ حركة مرور البيانات تصل إلى وجهتها بشكل أسرع

- تقليل إستخدام موارد الشبكة، مثل عرض النطاق الترددي وحمل وحدة المعالجة المركزية للموجه

الشكل 2 الخطوة التالية g2 المثبتة في ذاكرة التخزين المؤقت لتوجيه المضيف

الخطوة التالية G2 المثبتة في ذاكرة التخزين المؤقت لتوجيه المضيف

كما هو موضح في الشكل 2، بعد أن قام المضيف بإنشاء إدخال ذاكرة تخزين مؤقت للمسار للشبكة X مع G2 كجنتها التالية، يتم ملاحظة هذه الفوائد في الشبكة:

- ينقص إستخدام النطاق الترددي على الارتباط بين المحول والموجه G1 في كلا الاتجاهين.

- يقلل إستخدام وحدة المعالجة المركزية (CPU) على الموجه G1، نظرا لأن تدفق حركة مرور البيانات من المضيف إلى الشبكة X لم يعد يجتاز هذه العقدة.

- يحسن تأخر الشبكة الطرفي بين المضيف والشبكة X.

لفهم أهمية آلية إعادة توجيه ICMP، تذكر أن عمليات التنفيذ الأولى لموجهات الإنترنت كانت تعتمد بشكل أساسي على موارد وحدة المعالجة المركزية لمعالجة حركة مرور البيانات. وبالتالي، كان من المرغوب فيه تقليل حجم حركة المرور التي يجب معالجتها بواسطة أي موجه واحد وأيضا لتقليل عدد نقلات الموجه التي يجب أن يجتاز بها تدفق حركة المرور الخاص في طريقه إلى الوجهة. وفي الوقت نفسه، تم تنفيذ إعادة توجيه الطبقة 2 (المعروفة أيضا بالتبديل) بشكل رئيسي في الدوائر المتكاملة المخصصة للتطبيقات (ASIC)، ومن منظور أداء إعادة التوجيه كانت "رخيصة" نسبيا مقارنة بإعادة توجيه الطبقة 3 (والتي تسمى أيضا التوجيه)، وتم ذلك مرة أخرى في المعالجات ذات الأغراض العامة.

يمكن لأجيال ASIC الأحدث إعادة توجيه حزم الطبقة 2 والطبقة 3 على حد سواء. تساعد عملية البحث عن جدول الطبقة الثالثة التي تم إجراؤها في الأجهزة على تقليل تكلفة الأداء المرتبطة بمعالجة الحزم بواسطة الموجهات. علاوة على ذلك، عندما تم دمج وظيفة إعادة توجيه الطبقة 3 في محولات الطبقة 2 (والتي يطلق عليها الآن محولات الطبقة 3) مما جعل عملية إعادة توجيه الحزم أكثر فعالية، أدى ذلك إلى إزالة الحاجة إلى خيارات تصميم موجه واحد المسلح (يعرف أيضا باسم موجه على عصا) وتجنب القيود المقترنة بتكوينات الشبكة هذه.

يبني الشكل 3 على السيناريو الوارد في الشكل 1. والآن يتم دمج وظائف الطبقة 2 والطبقة 3، والتي يتم توفيرها في الأصل بواسطة عقدتين منفصلتين، وهما المحول والموجه G1، في محول واحد من الطبقة 3، مثل النظام الأساسي من السلسلة Nexus 7000.

الشكل 3 من الطبقة 3 يستبدل محول "الموجه الواحد" التكوين

يستبدل محول الطبقة 3 التكوين "أحادي الموجه"

هذا ما يحدث عندما يرسل المضيف حزمة إلى شبكة الوجهة X:

1. يتلقى محول L3 مع عنوان IP 10.0.0.1 حزمة بيانات من مضيف 10.0.0.100 على شبكة مرتبطة به.

2. تقوم البوابة، محول L3، بالتحقق من جدول التوجيه الخاص بها وتحصل على عنوان 10.0.0.2 للعبارة التالية، G2، على المسار إلى شبكة وجهة حزمة البيانات، X.

3. إذا كانت G2 والمضيف المحدد بواسطة عنوان المصدر لحزمة IP على الشبكة نفسها، يتم إرسال رسالة إعادة توجيه ICMP إلى المضيف. تنصح رسالة إعادة توجيه ICMP المضيف بإرسال حركة مرور البيانات الخاصة به للشبكة X مباشرة إلى البوابة G2 لأن هذا مسار أقصر إلى الوجهة.

4.  تقوم البوابة بإعادة توجيه حزمة البيانات الأصلية إلى الوجهة الخاصة بها.

ومع قدرة محولات الطبقة 3 الآن على تنفيذ إعادة توجيه حزم الطبقة 2 والمستوى 3 على حد سواء على مستوى ASIC، يمكن الاستنتاج بأن كلتا فئتي وظيفة إعادة توجيه ICMP، (أ) تحسين التأخير من خلال الشبكة و(ب) تقليل إستخدام موارد الشبكة، قد تم تحقيقهما، ولا توجد حاجة أكثر إلى إيلاء اهتمام كبير لتقنيات تحسين المسار في أجزاء إيثرنت متعددة النقاط.

ومع ذلك، مع تمكين وظيفة إعادة توجيه ICMP على واجهات الطبقة 3، تستمر إعادة التوجيه دون الأمثل من خلال أجزاء إيثرنت متعددة النقاط في تقديم نقاط ضعف محتملة في الأداء، حتى ولو لسبب مختلف، كما هو موضح في قسم اعتبارات الأنظمة الأساسية من Nexus لاحقا في هذا المستند.

ملاحظة: يتم تمكين عمليات إعادة توجيه ICMP بشكل افتراضي على واجهات الطبقة 3 في برنامج Cisco IOS و NX-OS.

ملاحظة: ملخص الشروط عند إنشاء رسائل إعادة توجيه ICMP: يقوم محول الطبقة 3 بإنشاء رسالة إعادة توجيه ICMP مرة أخرى إلى مصدر حزمة البيانات، إذا كانت حزمة البيانات سيتم إعادة توجيهها خارج واجهة الطبقة 3 التي يتم تلقي هذه الحزمة عليها.

مسارات دون المستوى الأمثل عبر شبكات إيثرنت

تم تصميم بروتوكولات العبارة الداخلية (IGP)، مثل فتح أقصر مسار أولا (OSFP) وبروتوكول التوجيه المحسن للعبارة الداخلية من Cisco (EIGRP)، لمزامنة معلومات التوجيه بين الموجهات، ولتوفير سلوك إعادة توجيه حزم متناسق ويمكن التنبؤ به على جميع عقد الشبكة التي تحترم هذه المعلومات. على سبيل المثال، مع شبكات الإيثرنت متعددة النقاط، إذا كانت جميع عقد الطبقة 3 على مقطع ما تستخدم نفس معلومات التوجيه وتتفق على نفس نقطة الخروج إلى الوجهة، فإن إعادة التوجيه دون الأمثل عبر هذه الشبكات نادرا ما تكون هي الحال.

لفهم الأسباب التي تؤدي إلى مسارات إعادة توجيه دون المستوى الأمثل، تذكر أن عقد الطبقة 3 تتخذ قرارات إعادة توجيه الحزم بشكل مستقل عن بعضها البعض. وهذا يعني، أن قرار إعادة توجيه الحزم الذي تم إتخاذه بواسطة الموجه B لا يعتمد على قرار إعادة توجيه الحزم الذي تم إتخاذه بواسطة الموجه A. هذا هو أحد المبادئ الأساسية التي يجب تذكرها عند أستكشاف أخطاء إعادة توجيه الحزم وإصلاحها من خلال شبكات IP، وهو أحد المبادئ المهمة التي يجب وضعها في الاعتبار عند التحقق من مسار إعادة التوجيه دون الأمثل في شبكات الإيثرنت متعددة النقاط.

وكما تمت الإشارة مسبقا، في الشبكات التي تعتمد فيها جميع الموجهات على بروتوكول توجيه ديناميكي واحد لتقديم حركة مرور البيانات بين النقاط الطرفية، يجب ألا يحدث إعادة التوجيه دون الأمثل من خلال شرائح إيثرنت متعددة النقاط. ومع ذلك، في الشبكات الواقعية، من الشائع للغاية العثور على مزيج من آليات توجيه وإعادة توجيه الحزم المختلفة. ومن أمثلة هذه الآليات مختلف بروتوكولات العبارة الداخلية، والتوجيه الثابت، والتوجيه المستند إلى السياسات. وعادة ما يتم إستخدام هذه الميزات معا لتحقيق إعادة توجيه حركة المرور المطلوبة من خلال الشبكة.

وعلى الرغم من أن الاستخدام المدمج لهذه الآليات يمكنه المساعدة على ضبط تدفق حركة مرور البيانات والوفاء بمتطلبات تصميم شبكة معين، إلا أنها تتجاهل التأثيرات الجانبية التي قد تتسبب فيها هذه الأدوات معا في شبكات إيثرنت متعددة النقاط مما قد يؤدي إلى أداء شبكة معدوم بشكل عام.

التوجيه الثابت

ولتوضيح ذلك، تأملوا في السيناريو الوارد في الشكل 4. الموجه A لديه مسار ثابت إلى الشبكة X مع الموجه B كالخطوة التالية له. في نفس الوقت يستخدم الموجه B الموجه C كالخطوة التالية في المسار الثابت إلى الشبكة Network X.

الشكل 4 مسار دون الأمثل مع التوجيه الثابت

مسار دون الأمثل مع التوجيه الثابت

بينما تدخل حركة المرور هذه الشبكة في الموجه A، وتتركها من خلال الموجه C، ويتم تسليمها في نهاية المطاف إلى الشبكة الوجهة X، يجب على الحزم أن تعبر شبكة IP هذه مرتين في طريقها إلى الوجهة. لا يعد هذا إستخداما فعالا لموارد الشبكة. وبدلا من ذلك، فإن إرسال الحزم من الموجه A مباشرة إلى الموجه C سوف يحقق نفس النتائج، بينما يستهلك موارد شبكة أقل.

ملاحظة: على الرغم من أنه في هذا السيناريو، يتم إستخدام الموجه A والموجه C كعقد مدخل ومخرج من الطبقة 3 لمقطع شبكة IP هذا، يمكن إستبدال كلا العقد بأجهزة الشبكة (مثل موازن التحميل أو جدران الحماية) إذا كان لهذه الأخيرة تكوين توجيه ينتج عنه نفس سلوك إعادة توجيه الحزمة.

التوجيه القائم على السياسة

التوجيه المستند إلى السياسة (PBR) هو آلية أخرى يمكن أن تتسبب في مسار دون الأمثل من خلال شبكات الإيثرنت. ومع ذلك، على عكس التوجيه الثابت أو الديناميكي، لا يعمل PBR على مستوى جدول التوجيه. وبدلا من ذلك، فإنه يقوم بتطبيق قائمة التحكم في الوصول (ACL) التي تعيد توجيه حركة مرور البيانات مباشرة في أجهزة المحول. ونتيجة لذلك، لتحديد تدفقات حركة المرور، تتجاوز عملية البحث عن إعادة توجيه الحزم على بطاقة خط الدخول معلومات التوجيه التي يتم الحصول عليها عبر التوجيه الديناميكي أو الثابت.

في الشكل 4، يتبادل الموجهان A و B معلومات التوجيه حول شبكة الوجهة X مع أحد بروتوكولات التوجيه الديناميكية. يتفق كلاهما على الموجه B هو أفضل خطوة تالية لهذه الشبكة.

ومع ذلك، باستخدام تكوين PBR على الموجه B الذي يتخطى معلومات التوجيه المستلمة من بروتوكول التوجيه ويعين الموجه C كخطوة تالية إلى الشبكة X، يتم استيفاء شرط تشغيل وظيفة إعادة توجيه ICMP ويتم إرسال الحزمة إلى وحدة المعالجة المركزية للموجه B لمعالجتها بشكل إضافي.

عمليات إعادة توجيه ICMP على الارتباطات من نقطة إلى نقطة

حتى الآن، يشير هذا المستند إلى شبكات إيثرنت التي تحتوي على ثلاث (أو أكثر) عقد من الطبقة 3 متصلة، وبالتالي اسم شبكات إيثرنت متعددة النقاط. ومع ذلك، كن على علم بأنه يمكن إنشاء رسائل إعادة توجيه ICMP على إرتباطات إيثرنت من نقطة إلى نقطة أيضا.

تأملوا في السيناريو في الشكل 5. الموجه A يستخدم المسار الافتراضي الثابت لإرسال حركة مرور البيانات إلى الموجه B، بينما الموجه B لديه مسار ثابت إلى الشبكة X التي تشير إلى الموجه A.

الشكل 5 عمليات إعادة توجيه ICMP على الارتباطات من نقطة إلى نقطة

مسار دون الأمثل مع التوجيه الثابت

يعد خيار التصميم هذا، المعروف أيضا باسم الاتصال أحادي الإتجاه، خيارا شائعا عندما تقوم بتوصيل بيئات المستخدمين الصغيرة بشبكات مزود الخدمة. هنا يمثل الموجه B جهاز Provider Edge (PE)، والموجه A هو جهاز User Edge (CE).

لاحظ أن تكوين CE النموذجي يتضمن تجميع المسار (المسارات) الثابتة إلى كتل عناوين IP للمستخدم التي تشير إلى واجهة Null0. هذا التكوين هو أفضل ممارسة موصى بها لخيار اتصال CE-PE أحادي الإتجاه مع التوجيه الثابت. ومع ذلك، لأغراض هذا المثال، يفترض عدم وجود هذا التكوين.

افترض أن الموجه A يفقد الاتصال بالشبكة X كما هو موضح في الشكل. عندما تحاول الحزم من شبكة المستخدم Y أو الشبكة البعيدة Z الوصول إلى الشبكة X، يمكن للموجهات A و B تقييد حركة المرور بين بعضها البعض، وتقليل حقل مدة بقاء IP في كل حزمة حتى تصل قيمتها إلى 1، وعند هذه النقطة لا يمكن توجيه الحزمة بشكل إضافي.

بينما تنعكس حركة المرور إلى الشبكة X ذهابا وإيابا بين موجهات PE و CE، تزيد بشكل كبير (وليس بالضرورة) من إستخدام عرض النطاق الترددي لارتباط CE-PE، تزداد المشكلة سوءا إذا تم تمكين عمليات إعادة توجيه ICMP على جانب واحد أو كلا جانبي الاتصال من نقطة إلى نقطة PE-CE. في هذه الحالة، تتم معالجة كل حزمة في التدفق موجهة إلى الشبكة X في وحدة المعالجة المركزية على كل موجه عدة مرات للمساعدة في إنشاء رسائل إعادة توجيه ICMP.

اعتبارات منصات Nexus

عند تمكين عمليات إعادة توجيه ICMP على واجهة الطبقة 3 واستخدام حزمة البيانات الواردة هذه الواجهة لكل من دخول محول الطبقة 3 والخروج منه، يتم إنشاء رسالة إعادة توجيه ICMP. بينما يتم إعادة توجيه حزم الطبقة 3 في الأجهزة على النظام الأساسي Cisco Nexus 7000، فإنها لا تزال من مسؤولية وحدة المعالجة المركزية للمحول إنشاء رسائل إعادة توجيه ICMP. للقيام بذلك، تحتاج وحدة المعالجة المركزية (CPU) على وحدة Nexus 7000 Supervisor إلى الحصول على معلومات عنوان IP للتدفق الذي يمكن تحسين المسار الخاص به عبر مقطع الشبكة. هذا هو السبب وراء إرسال حزمة البيانات بواسطة بطاقة خط الدخول إلى الوحدة النمطية للمشرف.

إذا تجاهل مستلمو رسالة إعادة توجيه ICMP هذه الرسالة واستمر في إعادة توجيه حركة مرور البيانات إلى واجهة الطبقة 3 للمحول Nexus الذي تم تمكين عمليات إعادة توجيه ICMP عليه، فسيتم تشغيل عملية إعادة توجيه ICMP لكل حزمة بيانات.

عند مستوى بطاقة الخط، تبدأ العملية في شكل إستثناء إعادة توجيه الأجهزة. يتم رفع الاستثناءات على ASICs عندما لا يمكن إكمال عملية إعادة توجيه الحزمة بنجاح بواسطة الوحدة النمطية لبطاقة الخط. في هذه الحالة، يلزم إرسال حزمة البيانات إلى الوحدة النمطية Supervisor (المشرف) لمعالجة الحزمة بشكل صحيح.

ملاحظة: لا تقوم وحدة المعالجة المركزية (CPU) على الوحدة النمطية للمشرف بإنشاء رسائل إعادة توجيه ICMP فقط، بل تتعامل مع العديد من إستثناءات إعادة توجيه الحزم الأخرى، مثل حزم IP التي تم تعيين قيمة مدة البقاء (TTL) على 1، أو حزم IP التي تحتاج إلى إجراء التجزئة قبل إرسالها إلى الخطوة التالية.

بعد أن قامت وحدة المعالجة المركزية (CPU) على الوحدة النمطية "المشرف" بإرسال رسالة إعادة توجيه ICMP إلى المصدر، فإنها تكمل معالجة الاستثناء عن طريق إعادة توجيه حزمة البيانات إلى الخطوة التالية من خلال الوحدة النمطية لبطاقة خط الخروج.

في حين تستخدم الوحدات النمطية للمشرف على Nexus 7000 معالجات قوية لوحدة المعالجة المركزية (CPU) التي يمكنها معالجة كميات كبيرة من حركة المرور، تم تصميم النظام الأساسي لمعالجة معظم حركة مرور البيانات على مستوى بطاقة الخط دون الحاجة إلى إشراك معالج وحدة المعالجة المركزية (CPU) المشرف في عملية إعادة توجيه الحزم. وهذا يسمح لوحدة المعالجة المركزية (CPU) بالتركيز على مهامها الأساسية، ويترك عملية إعادة توجيه الحزم لمحركات الأجهزة المخصصة على بطاقات الخط.

في الشبكات المستقرة، من المتوقع أن تحدث إستثناءات إعادة توجيه الحزم، في حالة حدوثها، بأسعار منخفضة بدرجة معقولة. ومن خلال هذا الافتراض، يمكن لوحدة المعالجة المركزية (CPU) المشرف التعامل معها دون التأثير بشكل ملحوظ على أدائها. ومن ناحية أخرى، قد يكون لإستخدام وحدة المعالجة المركزية (CPU) التي تتعامل مع إستثناءات إعادة توجيه الحزم التي تحدث بمعدل مرتفع للغاية تأثير سلبي على إستقرار النظام ككل ومدى إستجابته.

يوفر تصميم النظام الأساسي Nexus 7000 عدد من الآليات لحماية وحدة المعالجة المركزية للمحول من كميات كبيرة من حركة المرور. وتنفذ هذه الآليات في نقاط مختلفة من المنظومة. على مستوى بطاقة الخط، توجد أدوات تحديد معدل الأجهزة ومستوى التحكم Policing ميزة (CoPP). ويقوم كلا منهما بتعيين حدود معدل حركة المرور، التي تتحكم بشكل فعال في مقدار حركة المرور التي سيتم إعادة توجيهها إلى المشرف من كل وحدة نمطية لبطاقة الخط.

وتعطي آليات الحماية هذه تفضيلا لحركة مرور بروتوكولات التحكم المختلفة التي تعد حيوية لاستقرار الشبكة وقابلية إدارة المحول، مثل OSPF أو BGP أو SSH، وفي الوقت نفسه تقوم هذه البروتوكولات بتصفية أنواع حركة المرور التي لا تشكل أهمية بالغة للتحكم في وظائف مستوى المحول. يتم تنظيم معظم حركة مرور البيانات، إذا تمت إعادة توجيهها إلى وحدة المعالجة المركزية (CPU) نتيجة لاستثناءات إعادة توجيه الحزم بشدة بواسطة هذه الآليات.

بينما أدوات تحديد معدل الأجهزة و CoPP policing توفر الآليات إستقرار مستوى التحكم للمحول ويوصى بشدة بتمكينها دائما، ويمكن أن تكون هذه الآليات أحد الأسباب الرئيسية لحالات إسقاط حزم البيانات وتأخر النقل والأداء الضعيف عموما للتطبيق عبر الشبكة. ولهذا السبب من المهم فهم المسارات التي تسلكها حركة مرور البيانات عبر الشبكة واستخدام الأدوات لمراقبة أجهزة الشبكة التي يمكن و/أو من المتوقع إستخدام وظيفة إعادة توجيه ICMP.

أدوات مراقبة حركة المرور وتشخيصها

show ip traffic

يوفر كل من برنامج Cisco IOS وبرنامج Cisco NX-OS طريقة للتحقق من إحصائيات حركة مرور البيانات التي تتم معالجتها بواسطة وحدة المعالجة المركزية. هذا تم مع  show ip traffic  erasecat4000_flash:. يمكن إستخدام هذا الأمر للتحقق من إستلام و/أو إنشاء رسائل إعادة توجيه ICMP بواسطة محول أو موجه الطبقة 3.

Nexus7000#show ip traffic | begin ICMP

ICMP Software Processed Traffic Statistics

------------------------------------------

Transmission:

Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,

<output omitted for brevity>

ICMP originate Req: 0, Redirects Originate Req: 1000

Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0

Reception:

Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,

<output omitted for brevity>

Nexus7000#

جري show ip traffic قم بإصدار الأمر عدة مرات وتحقق مما إذا كانت زيادة عدادات إعادة توجيه ICMP أم لا.

إيثاناليزر

يحتوي برنامج NX-OS من Cisco على أداة مدمجة لالتقاط حركة مرور البيانات flowing وحدة المعالجة المركزية (CPU) الخاصة بالمحول (المعروفة باسم الإيثاناليزر) وإليها.

ملاحظة: لمزيد من المعلومات حول الإيثاناليزر، ارجع إلى الإيثاناليزر في دليل أستكشاف أخطاء Nexus 7000 وإصلاحها.

الشكل 6 يوضح سيناريو مماثل للسيناريو الموجود في الشكل 3. هنا يتم إستبدال شبكة X بشبكة 192.168.0.0/24.

شكل 6 تشغيل التقاط الإيثاناليزر

تشغيل التقاط الإيثاناليزر

يرسل المضيف 10.0.0.100 تدفقا متصلا من طلبات ICMP Echo إلى عنوان IP للوجهة 192.168.0.1. يستخدم المضيف الواجهة الظاهرية للمحول (SVI) 10 من محول Nexus 7000 كنقلة تالية للشبكة البعيدة 192.168.0.0/24. لأغراض العرض التوضيحي، يتم تكوين المضيف لتجاهل رسائل إعادة توجيه ICMP.

أستخدم هذا الأمر التالي لالتقاط حركة مرور ICMP التي يتم استقبالها وإرسالها بواسطة وحدة المعالجة المركزية (CPU) من Nexus 7000:

Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000

Capturing on inband

2018-09-15 23:45:40.124077   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.124477     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.124533   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.126344   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.126607     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.126655   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.128348   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.128611     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.128659   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.130362   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.130621     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.130669   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.132392   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.132652     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.132700   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.134347   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.134612     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.134660   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.136347   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.136598     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.136645   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.138351   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

2018-09-15 23:45:40.138607     10.0.0.1 -> 10.0.0.100   ICMP Redirect (Redirect for host)

2018-09-15 23:45:40.138656   10.0.0.100 -> 192.168.0.1      ICMP Echo (ping) request

...

تقترح الطوابع الزمنية في الإخراج السابق أنه تم التقاط ثلاث حزم مبرزة في هذا المثال في نفس الوقت، 2018-09-15 23:45:40.128. التالي هو تقسيم لكل حزمة من مجموعة الحزم هذه

- الحزمة الأولى هي حزمة بيانات الدخول، والتي في هذا المثال هي طلب صدى ICMP.

2018-09-15 23:45:40.128348 10.0.100 -> طلب 192.168.0.1 ICMP Echo (Ping)

- الحزمة الثانية هي حزمة إعادة توجيه ICMP، والتي تم إنشاؤها بواسطة البوابة. يتم إرسال هذه الحزمة مرة أخرى إلى المضيف.

2018-09-15 23:45:40.128611 10.0.0.1 -> إعادة توجيه 10.0.0.100 ICMP (إعادة التوجيه للمضيف)

- الحزمة الثالثة هي حزمة البيانات التي تم التقاطها في إتجاه الخروج، بعد أن يتم توجيهها بواسطة وحدة المعالجة المركزية. على الرغم من أنه لم يتم عرضه مسبقا، فإن هذه الحزمة تحتوي على تقليل مدة البقاء (TTL) الخاصة ب IP الخاص بها والمبلغ الاختباري الذي تمت إعادة حسابه.

2018-09-15 23:45:40.128659 10.0.100 -> طلب 192.168.0.1 لصدى ICMP (Ping)

بينما تقوم بالتنقل عبر عمليات التقاط الإيثاناليزر الكبيرة التي تحتوي على العديد من الحزم ذات الأنواع والتدفقات المختلفة، يمكن أن يكون من الصعب ربط رسائل إعادة توجيه ICMP بحركة مرور البيانات المطابقة لها.

في هذه الحالات، ركز على رسائل إعادة توجيه ICMP لاسترداد المعلومات المتعلقة بتدفقات حركة مرور البيانات التي تتم إعادة توجيهها بشكل مثالي فرعي. تتضمن رسائل إعادة توجيه ICMP رأس الإنترنت بالإضافة إلى 64 بت الأولى من بيانات مخطط البيانات الأصلية. يتم إستخدام هذه البيانات من قبل مصدر مخطط البيانات لمطابقة الرسالة بالعملية المناسبة.

أستخدم أداة التقاط حزم الإيثاناليزر مع الكلمة الأساسية التفصيلية لعرض محتوى رسائل إعادة توجيه ICMP والبحث عن معلومات عنوان IP الخاصة بتدفق البيانات الذي تتم إعادة توجيهه الفرعي

Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail

...

Frame 2 (70 bytes on wire, 70 bytes captured)

Arrival Time: Sep 15, 2018 23:54:04.388577000

[Time delta from previous captured frame: 0.000426000 seconds]

[Time delta from previous displayed frame: 0.000426000 seconds]

[Time since reference or first frame: 0.000426000 seconds]

Frame Number: 2

Frame Length: 70 bytes

Capture Length: 70 bytes

[Frame is marked: False]

[Protocols in frame: eth:ip:icmp:ip:icmp:data]

Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)

Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)

Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)

Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Type: IP (0x0800)

Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 56

Identification: 0xf986 (63878)

Flags: 0x00

0.. = Reserved bit: Not Set

.0. = Don't fragment: Not Set

..0 = More fragments: Not Set

Fragment offset: 0

Time to live: 255

Protocol: ICMP (0x01)

Header checksum: 0xadd9 [correct]

[Good: True]

[Bad : False]

Source: 10.0.0.1 (10.0.0.1)

Destination: 10.0.0.100 (10.0.0.100)

Internet Control Message Protocol

Type: 5 (Redirect)

Code: 1 (Redirect for host)

Checksum: 0xb8e5 [correct]

Gateway address: 10.0.0.2 (10.0.0.2)

Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 84

Identification: 0xf986 (63878)

Flags: 0x00

0.. = Reserved bit: Not Set

.0. = Don't fragment: Not Set

..0 = More fragments: Not Set

Fragment offset: 0

Time to live: 254

Protocol: ICMP (0x01)

Header checksum: 0xa8ae [correct]

[Good: True]

[Bad : False]

Source: 10.0.0.100 (10.0.0.100)

Destination: 192.168.0.1 (192.168.0.1)

Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0 ()

Checksum: 0x02f9 [incorrect, should be 0xcae1]

Identifier: 0xa01d

Sequence number: 36096 (0x8d00)

...

تعطيل عمليات إعادة توجيه ICMP

إذا كان تصميم الشبكة يتطلب توجيه تدفق حركة مرور البيانات من واجهة الطبقة 3 نفسها التي دخلت المحول أو الموجه عليها، فمن الممكن منع التدفق من التوجيه من خلال وحدة المعالجة المركزية إذا قمت بتعطيل وظيفة إعادة توجيه ICMP على واجهة الطبقة 3 التي تطابقه.

وفي الواقع، بالنسبة لمعظم الشبكات، من الممارسات الجيدة تعطيل عمليات إعادة توجيه ICMP بشكل استباقي على جميع واجهات الطبقة 3، المادية، مثل واجهة إيثرنت، والافتراضية، مثل واجهات Port-Channel و SVI على السواء. أستخدم no ip redirects أمر على مستوى واجهة Cisco NX-OS لتعطيل عمليات إعادة توجيه ICMP على واجهة الطبقة 3. للتحقق من تعطيل وظيفة إعادة توجيه ICMP:

- نضمنno ip تتم إضافة الأمر redirects إلى تكوين الواجهة.

Nexus7000#show run interface vlan 10

interface Vlan10

no shutdown

no ip redirects

ip address 10.0.0.1/24

- تأكد من أن حالة عمليات إعادة توجيه ICMP على الواجهة تظهر "معطل".

Nexus7000#show ip interface vlan 10 | include redirects

IP icmp redirects: disabled

- تأكد من تعيين علامة إعادة توجيه ICMP enable/disable على 0 بواسطة مكون برنامج Cisco NX-OS الذي يدفع تكوين الواجهة من مشرف المحول إلى بطاقة خط واحدة من المزيد.

Nexus7000#show system internal eltm info interface vlan 10 | i icmp_redirect

per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0

- تأكد من تعيين علامة إعادة توجيه ICMP enable/disable لواجهة طبقة 3 معينة على 0 في بطاقة خط واحدة أو أكثر.

Nexus7000#attach module 7

Attaching to module 7 ...

To exit type 'exit', to abort type '$.'

Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0

module-7#

!--- Optionally, jump to non-admin Virtual Device Context (VDC) if verification needs to be done in one of the custom VDCs

module-7#vdc 6

module-7#show system internal iftmc info interface vlan 10 | include icmp_redirect

icmp_redirect : 0x0 ipv6_redirect : 0x1

ملخص

تم تصميم آلية إعادة توجيه ICMP، كما هو موضح في RFC 792، لتحسين مسار إعادة التوجيه من خلال أجزاء الشبكة متعددة النقاط. وفي بداية الإنترنت، ساعد هذا التحسين في حماية موارد الشبكة باهظة الثمن مثل عرض النطاق الترددي للارتباط ودورات وحدة المعالجة المركزية للموجهات. ومع توفر عرض النطاق الترددي للشبكة بسعر مناسب بدرجة أكبر، وتطور توجيه الحزم القائم على وحدة المعالجة المركزية (CPU) البطيء نسبيا إلى إعادة توجيه أسرع للحزم من الطبقة الثالثة في بطاقات واجهة الشبكة (ASIC) المخصصة للأجهزة، انخفضت أهمية النقل الأمثل للبيانات عبر شرائح الشبكة متعددة النقاط. وبشكل افتراضي، يتم تمكين وظيفة إعادة توجيه ICMP على كل واجهة من الطبقة 3. ومع ذلك، فإن محاولاته لإعلام عقد الشبكة على مقاطع إيثرنت متعددة النقاط حول مسارات إعادة التوجيه المثلى لا يتم فهمها دائما ويتصرف عليها أفراد الشبكة. في الشبكات ذات الاستخدام المدمج لآليات إعادة التوجيه المختلفة، مثل التوجيه الثابت والتوجيه الديناميكي والتوجيه المستند إلى السياسة، إذا تركت وظيفة إعادة توجيه ICMP ممكنة ولم تقم بمراقبتها بشكل صحيح، قد يؤدي ذلك إلى إستخدام غير مرغوب فيه لوحدة المعالجة المركزية (CPU) لعقدة (عقد) النقل لمعالجة حركة مرور الإنتاج. وهذا بدوره، يمكن أن يؤدي إلى تأثير كبير على كل من تدفقات حركة مرور الإنتاج واستقرار مستوى التحكم للبنية الأساسية للشبكة.

بالنسبة لمعظم الشبكات، يعتبر تعطيل وظائف إعادة توجيه ICMP بشكل استباقي على جميع واجهات الطبقة 3 في البنية الأساسية للشبكة ممارسة جيدة. وهذا يساعد على منع سيناريوهات حركة مرور بيانات الإنتاج التي تتم معالجتها في وحدة المعالجة المركزية لمحولات الطبقة 3 والموجهات عندما يكون هناك مسار إعادة توجيه أفضل من خلال مقاطع الشبكة متعددة النقاط.