جار EIGRP أم عبور DMVPN؟ افحص الدور أولاً

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

الخطوة 1: ارسم الدورين

ارسم جوار EIGRP المقصود كاتصال منطقي بين موجّهين، ثم ارسم موجّهات الطبقة السفلية التي تحمل حزم النفق الخاصة به. ليس من الضروري أن يظهر الجهاز نفسه في القائمتين، وخلط القائمتين هو السبب الأكثر شيوعاً لاتهام موجّه عبور سليم بأنه يعطّل الجوار.

يمرّر موجّه العبور الحزم الخارجية باستخدام توجيه IP وسياساته العادية. لا يحتاج إلى تشغيل البروتوكول المحمول داخل النفق المحمي، ولا يحتاج إلى عملية EIGRP لتمرير تلك الحزم.

الخطوة 2: افحص ما يُنهيه الجهاز الأوسط

إذا كان الموجّه الأوسط ينهي النفق ويُفترض أن يكوّن جوارات EIGRP مع الأطراف، فإن الإجابة تتغيّر تماماً. يحتاج ذلك الجهاز إلى سلوك التوجيه المدعوم للطبقة الفوقية، ووصفه بالعبور لا يُلغي شرط الجوار. اقرأ إعداد النفق قبل إعداد التوجيه. تلك الإجابة تحدّد كل فحص يليها.

إذن السؤال الحقيقي الأول ليس أي بروتوكول نضبط. بل ما إذا كان الصندوق محوراً أم طرفاً أم مجرد قفزة في الطبقة السفلية أم خدمة Layer 2 تحمل الإطارات بين نقاط النهاية.

الخطوة 3: تحقّق من مستوى التحكّم الخاص بالجار

في كل جهاز يُفترض أن يكون جاراً، تأكّد من أربعة أمور: نسخة EIGRP ورقم النظام المستقل، ومعاملات المصادقة، والواجهة المشاركة في العملية، وعبارة الشبكة التي تغطّي تلك الواجهة. أي عدم تطابق في واحد منها يُبقي الجوار معطّلاً بينما تظل الواجهة قائمة والـping يعمل.

يصف RFC 7868 بروتوكول EIGRP بأنه بروتوكول IP ذو تبادل تحكّم متعدد الإرسال، ولهذا فإن علاقة الجوار ليست شيئاً يمكن لموجّه وسيط أن يوكّل عنه بتوجيه الحزم نحو وجهة. إما أن يصل تبادل التحكّم إلى النظير أو لا يتشكّل الجوار.

الخطوة 4: تحقّق من أن النقل يسلّم تبادل التحكّم

بعد ذلك، تحقّق من أن الطبقة الفوقية تحمل فعلاً حركة التحكّم بين نقاط النهاية المقصودة. افحص تعيين NHRP للنظير والمسار الخارجي الذي يصل إليه، ثم تأكّد من أن واجهة النفق قائمة وتمرّر الحركة. نجاح ping في الطبقة السفلية يثبت وجود المسار الخارجي؛ لكنه لا يثبت تسليم تبادل التحكّم في الطبقة الفوقية.

خدمة Layer 2 الشفافة والنفق من نقطة إلى نقطة وسحابة DMVPN متعددة النقاط تسلّم الإرسال المتعدد بطرق مختلفة. اتبع نموذج الواجهة وNHRP والإرسال المتعدد المدعوم للنموذج المنشور فعلاً بدل افتراض أن الثلاثة تتصرف بالطريقة نفسها.

الخطوة 5: أعد تصميم الحدود إن لم يكن قادراً على المشاركة

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

سجّل دور كل جهاز في المخطّط واحتفظ به مع الإعداد. RFC 7868 يحدد تبادل البروتوكول، وهذا التعريف هو المرجع لسبب تعذّر محاكاة علاقة الجوار عبر توجيه العبور.

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