تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند وظيفة إعادة توجيه حزمة بروتوكول رسائل التحكم في الإنترنت (ICMP).
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
يناقش هذا المستند وظيفة إعادة توجيه الحزم التي يوفرها بروتوكول رسائل التحكم في الإنترنت (ICMP). يشرح المستند ما يشير إليه عادة وجود رسائل إعادة توجيه ICMP في الشبكة، وما يمكن فعله لتقليل التأثيرات الجانبية السلبية المرتبطة بظروف الشبكة التي تتسبب في إنشاء رسائل إعادة توجيه ICMP.
يتم شرح وظيفة إعادة توجيه ICMP في بروتوكول رسائل التحكم في الإنترنت ل RFC 792 مع هذا المثال:
ترسل البوابة رسالة إعادة توجيه إلى مضيف في هذه الحالة.
تتلقى البوابة، G1، مخطط بيانات إنترنت من مضيف على شبكة متصلة بها البوابة. تقوم البوابة، G1، بالتحقق من جدول التوجيه الخاص بها وتحصل على عنوان البوابة التالية، G2، على المسار إلى شبكة وجهة الإنترنت لمخطط البيانات، X
إذا كانت G2 والمضيف المحدد بواسطة عنوان مصدر الإنترنت لمخطط البيانات على الشبكة نفسها، يتم إرسال رسالة إعادة توجيه إلى المضيف. تنصح الرسالة المعاد توجيهها المضيف بإرسال حركة مرور البيانات الخاصة به للشبكة X مباشرة إلى البوابة G2 حيث أن هذا مسار أقصر إلى الوجهة.
تقوم البوابة بإعادة توجيه بيانات مخطط البيانات الأصلية إلى وجهة الإنترنت الخاصة بها.
ويتم توضيح هذا السيناريو في الصورة 1. المضيف وموجهان، هما G1 و G2، متصلان بمقطع إيثرنت مشترك ولهما عناوين IP في الشبكة نفسها 10.0.0.0/24
IMAGE1 - عمليات إعادة توجيه 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 المثبتة في ذاكرة التخزين المؤقت لتوجيه المضيف
كما هو موضح في الصورة 2، بعد أن قام المضيف بإنشاء إدخال ذاكرة تخزين مؤقت للمسار للشبكة X مع G2 كنقطة الوصول التالية، يتم رؤية هذه الفوائد في الشبكة:
لفهم أهمية آلية إعادة توجيه ICMP، تذكر أن عمليات التنفيذ الأولى لموجهات الإنترنت كانت تعتمد بشكل أساسي على موارد وحدة المعالجة المركزية لمعالجة حركة مرور البيانات. وبالتالي، كان من المرغوب فيه تقليل حجم حركة المرور التي يجب معالجتها بواسطة أي موجه واحد وأيضا لتقليل عدد نقلات الموجه التي يجب أن يجتاز بها تدفق حركة المرور الخاص في طريقه إلى الوجهة. وفي الوقت نفسه، تم تنفيذ إعادة توجيه الطبقة 2 (المعروفة أيضا بالتبديل) بشكل رئيسي في الدوائر المدمجة المخصصة للتطبيقات (ASIC)، ومن منظور أداء إعادة التوجيه كانت رخيصة نسبيا مقارنة بإعادة توجيه الطبقة 3 (والتي تسمى أيضا التوجيه)، وتم ذلك مرة أخرى في المعالجات ذات الأغراض العامة.
يمكن لأجيال ASIC الأحدث إعادة توجيه حزم الطبقة 2 والطبقة 3 على حد سواء. تساعد عملية البحث عن جدول الطبقة الثالثة التي تم إجراؤها في الأجهزة على تقليل تكلفة الأداء المرتبطة بمعالجة الحزم بواسطة الموجهات. علاوة على ذلك، عند دمج وظائف إعادة توجيه الطبقة 3 في محولات الطبقة 2 (التي تسمى الآن محولات الطبقة 3)، فإنها جعلت عملية إعادة توجيه الحزم أكثر فعالية. وقد أدى ذلك إلى التخلص من الحاجة إلى خيارات تصميم موجه واحد المسلحة (المعروف أيضا باسم موجه على عصا) وإلى تجنب القيود المرتبطة بتكوينات الشبكة هذه.
تعتمد الصورة 3 على السيناريو الوارد في الصورة 1. والآن يتم دمج وظائف الطبقة 2 والطبقة 3، والتي يتم توفيرها في الأصل بواسطة عقدتين منفصلتين، وهما المحول والموجه G1، في محول واحد من الطبقة 3، مثل النظام الأساسي من السلسلة Nexus 7000.
الصورة 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)، مثل فتح أقصر مسار أولا (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. للقيام بذلك، تحتاج وحدة المعالجة المركزية (CPU) على وحدة Nexus 7000 Supervisor إلى الحصول على معلومات عنوان IP للتدفق الذي يمكن تحسين المسار الخاص به عبر مقطع الشبكة. هذا هو السبب وراء إرسال حزمة البيانات بواسطة بطاقة خط الدخول إلى الوحدة النمطية للمشرف.
إذا تجاهل مستلمو رسالة إعادة توجيه ICMP هذه الرسالة واستمر في إعادة توجيه حركة مرور البيانات إلى واجهة الطبقة 3 للمحول Nexus الذي تم تمكين عمليات إعادة توجيه ICMP عليه، فسيتم تشغيل عملية إعادة توجيه ICMP لكل حزمة بيانات.
عند مستوى بطاقة الخط، تبدأ العملية في شكل إستثناء إعادة توجيه الأجهزة. يتم رفع الاستثناءات على ASICs عندما لا يمكن إكمال عملية إعادة توجيه الحزمة بنجاح بواسطة الوحدة النمطية لبطاقة الخط. في هذه الحالة، يلزم إرسال حزمة البيانات إلى الوحدة النمطية Supervisor (المشرف) لمعالجة الحزمة بشكل صحيح.
ملاحظة: لا تقوم وحدة المعالجة المركزية على الوحدة النمطية للمشرف بإنشاء رسائل إعادة توجيه 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.
يوفر كل من برنامج 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. التالي هو تقسيم لكل حزمة من مجموعة الحزم هذه
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 لتعطيل عمليات إعادة توجيه 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
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 والموجهات عندما يكون هناك مسار إعادة توجيه أفضل من خلال مقاطع الشبكة متعددة النقاط.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
3.0 |
31-Oct-2023 |
تحديث متطلبات العلامة التجارية والتنسيق وقائمة المساهمين. |
2.0 |
22-Sep-2022 |
تقويم |
1.0 |
17-Oct-2018 |
الإصدار الأولي |