تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند وظيفة إعادة توجيه الحِزمة التي يوفرها بروتوكول التحكم برسائل الإنترنت (ICMP).
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
يناقش هذا المستند وظيفة إعادة توجيه الحزم التي يوفرها بروتوكول رسائل التحكم في الإنترنت (ICMP). يشرح المستند ما يشير إليه عادة وجود رسائل إعادة توجيه ICMP في الشبكة، وما يمكن فعله لتقليل التأثيرات الجانبية السلبية المرتبطة بظروف الشبكة التي تتسبب في إنشاء رسائل إعادة توجيه ICMP.
يتم شرح وظيفة إعادة توجيه ICMP في بروتوكول رسائل التحكم في الإنترنت ل RFC 792 مع هذا المثال:
ترسل البوابة رسالة إعادة توجيه إلى مضيف في هذه الحالة.
تتلقى البوابة، G1، مخطط بيانات إنترنت من مضيف على شبكة متصلة بها البوابة. تقوم البوابة، G1، بالتحقق من جدول التوجيه الخاص بها وتحصل على عنوان البوابة التالية، G2، على المسار إلى شبكة وجهة الإنترنت لمخطط البيانات، X
إذا كانت G2 والمضيف المحدد بواسطة عنوان مصدر الإنترنت لمخطط البيانات على الشبكة نفسها، يتم إرسال رسالة إعادة توجيه إلى المضيف. تنصح الرسالة المعاد توجيهها المضيف بإرسال حركة مرور البيانات الخاصة به للشبكة X مباشرة إلى البوابة G2 حيث أن هذا مسار أقصر إلى الوجهة.
تقوم البوابة بإعادة توجيه بيانات مخطط البيانات الأصلية إلى وجهة الإنترنت الخاصة بها.
ويتم توضيح هذا السيناريو في الصورة 1. يتم توصيل المضيف وموجهين، الجيل1 و G2، بمقطع الإيثرنت المشترك ولهما عناوين IP في الشبكة نفسها الإصدار 10.0.0.0/24
IMAGE1 - عمليات إعادة توجيه ICMP في شبكات إيثرنت متعددة النقاط
عمليات إعادة توجيه ICMP في شبكات إيثرنت متعددة النقاط
للمضيف عنوان IP 10.0.0.100. يحتوي جدول توجيه المضيف على إدخال مسار افتراضي يشير إلى عنوان IP للموجه G1 10.0.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 كنقطة الوصول التالية، يتم رؤية هذه الفوائد في الشبكة:
لفهم أهمية آلية إعادة توجيه 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® و Cisco NX-OS.
ملاحظة: ملخص الشروط عند إنشاء رسائل إعادة توجيه ICMP: يقوم محول الطبقة 3 بإنشاء رسالة إعادة توجيه ICMP مرة أخرى إلى مصدر حزمة البيانات، إذا كانت حزمة البيانات سيتم إعادة توجيهها خارج واجهة الطبقة 3 التي يتم تلقي هذه الحزمة عليها.
تم تصميم بروتوكولات العبارة الداخلية (IGP)، مثل فتح أقصر مسار أولا (OSPF) وبروتوكول التوجيه المحسن للعبارة الداخلية من 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 لمعالجتها بشكل إضافي.
حتى الآن، يشير هذا المستند إلى شبكات إيثرنت التي تحتوي على ثلاث (أو أكثر) عقد من الطبقة 3 متصلة، وبالتالي اسم شبكات إيثرنت متعددة النقاط. ومع ذلك، كن على علم بأنه يمكن إنشاء رسائل إعادة توجيه ICMP على إرتباطات إيثرنت من نقطة إلى نقطة أيضا.
ضع السيناريو على الصورة 5. يستخدم الموجه A المسار الافتراضي الثابت لإرسال حركة المرور إلى الموجه B، بينما الموجه B لديه مسار ثابت إلى الشبكة X التي تشير إلى الموجه A.
الصورة 5 - عمليات إعادة توجيه ICMP على الارتباطات من نقطة إلى نقطة
مسار دون الأمثل مع التوجيه الثابت
يعد خيار التصميم هذا، المعروف أيضا باسم الاتصال أحادي الإتجاه، خيارا شائعا عندما تقوم بتوصيل بيئات المستخدمين الصغيرة بشبكات مزود الخدمة. الموجه B هنا هو جهاز حافة الموفر (PE)، والموجه A هو جهاز حافة المستخدم (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.
عند تمكين عمليات إعادة توجيه ICMP على واجهة الطبقة 3 وحزمة بيانات واردة تستخدم هذه الواجهة لدخول محول الطبقة 3 والخروج منه، يتم إنشاء رسالة إعادة توجيه ICMP. بينما يتم إعادة توجيه حزم الطبقة 3 في الأجهزة على نظام Cisco Nexus 7000، فإنها لا تزال مسؤولية وحدة المعالجة المركزية للمحول عن إنشاء رسائل إعادة توجيه ICMP. للقيام بذلك، تحتاج وحدة المعالجة المركزية على وحدة 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) نتيجة لاستثناءات إعادة توجيه الحزم بشدة بواسطة هذه الآليات.
في حين توفر أدوات تحديد معدل الأجهزة policing
وآليات CoPP إستقرار مستوى التحكم في المحول، ويرجى بشدة تمكينها دائما، فإنها يمكن أن تكون أحد الأسباب الرئيسية لحالات إسقاط حزم البيانات وتأخر النقل والأداء الضعيف عموما للتطبيق عبر الشبكة. ولهذا السبب من المهم فهم المسارات التي تسلكها حركة مرور البيانات عبر الشبكة واستخدام الأدوات لمراقبة أجهزة الشبكة التي يمكن و/أو من المتوقع إستخدام وظيفة إعادة توجيه ICMP.
يوفر كل من برنامج Cisco IOS وبرنامج Cisco NX-OS طريقة للتحقق من إحصائيات حركة مرور البيانات التي تتم معالجتها بواسطة وحدة المعالجة المركزية. ويتم ذلك باستخدام show ip traffic
الأمر. يمكن إستخدام هذا الأمر للتحقق من إستلام و/أو إنشاء رسائل إعادة توجيه 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
للمحول وإليها، المعروفة باسم Ethanalyzer.
ملاحظة: لمزيد من المعلومات حول الإيثاناليزر، ارجع إلى الإيثاناليزر في دليل أستكشاف أخطاء 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. التالي هو تقسيم لكل حزمة من مجموعة الحزم هذه
2018-09-15 23:45:40.128348 10.0.100 -> طلب 192.168.0.1 ICMP Echo (Ping)
2018-09-15 23:45:40.128611 10.0.0.1 -> إعادة توجيه 10.0.0.100 ICMP (إعادة التوجيه للمضيف)
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)
...
إذا كان تصميم الشبكة يتطلب توجيه تدفق حركة مرور البيانات من واجهة الطبقة 3 نفسها التي دخلت المحول أو الموجه عليها، فمن الممكن منع التدفق من التوجيه من خلال وحدة المعالجة المركزية إذا قمت بتعطيل وظيفة إعادة توجيه ICMP على واجهة الطبقة 3 التي تطابقه.
وفي الواقع، بالنسبة لمعظم الشبكات، من الممارسات الجيدة تعطيل عمليات إعادة توجيه ICMP بشكل استباقي على جميع واجهات الطبقة 3، المادية، مثل واجهة إيثرنت، والافتراضية، مثل واجهات Port-Channel و SVI على السواء. أستخدمno ip redirects
الأمر Cisco NX-OS interface-level لتعطيل عمليات إعادة توجيه ICMP على واجهة الطبقة 3. للتحقق من تعطيل وظيفة إعادة توجيه ICMP:
Nexus7000#show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
Nexus7000#show ip interface vlan 10 | include redirects IP icmp redirects: disabled
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
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 والموجهات عندما يكون هناك مسار إعادة توجيه أفضل من خلال مقاطع الشبكة متعددة النقاط.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
4.0 |
14-May-2025
|
تم تحديث التنسيق. |
3.0 |
31-Oct-2023
|
تحديث متطلبات العلامة التجارية والتنسيق وقائمة المساهمين. |
2.0 |
22-Sep-2022
|
تقويم |
1.0 |
17-Oct-2018
|
الإصدار الأولي |