جيران EIGRP لا يظهرون على طبقة DMVPN العلوية

النفق قائم، ويمكن لفرع أن ي ping فرعًا آخر، ومع ذلك لا يعرض EIGRP أي جار على المحور. هذه التركيبة طبيعية لا غامضة: فالـ ping يثبت إمكانية الوصول unicast عبر NHRP، ورسائل hello الخاصة بـ EIGRP هي multicast. على طبقة DMVPN العلوية يُعدّ نموذج تسليم بروتوكول التوجيه سطح إعداد ثانٍ، وهو السطح الذي يتخطاه الناس لأن السطح الأول يبدو سليمًا أصلًا. كل طبقة أدناه تُفحص بأمرها الخاص، لذا لا يعيدك فشل في طبقة إلى أعلى القائمة.

اكتب التجاورات التي تتوقعها

قبل أي أمر show، اكتب قائمة قصيرة: أي فرع يجب أن يجاور أي محور، عبر أي واجهة نفق، وفي أي نظام مستقل لـ EIGRP. تصاميم المحاور المتعددة تفشل في الفراغات بين المحاور، والقائمة تحوّل «EIGRP معطوب» إلى «الفرع 3 لا يسجل نفسه عند المحور 2». أدرج شبكات النفق الفرعية التي تتوقعها على كل وصلة، لأن عدم تطابق العنوانين بين الطرفين يبدو تمامًا كفشل بروتوكول. اكتب القائمة في التذكرة، حتى تقارن الوردية التالية بالتصميم لا بآخر لقطة شاشة.

افحص NHRP ثم مسار multicast

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

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

إن السطر ip nhrp map multicast هو ما يسمح للفرع بإرسال رسائل hello إلى المحور كـ multicast مكرر عبر الطبقة العلوية، وما يسمح لـ multicast الخاص بالمحور بالوصول إلى الفروع المسجلة لديه. من دونه يعمل unicast عبر NHRP ولا يعمل multicast، وهذا بالضبط الفصل الذي يجعل الـ ping يبدو دليلًا. يوثّق دليل Cisco IOS XE DMVPN سلوك multicast بين المحور والفروع لكل طور، لذا طابق إعدادك مع الطور الذي نشرته فعلًا بدل نسخ جزء من طوبولوجيا أخرى.

افحص سياسة الواجهة الخاصة بـ EIGRP

النفق غير المضمّن في عملية EIGRP أو المضبوط كـ passive لن يشكّل تجاورًا أبدًا مهما كانت الطبقة العلوية سليمة. اقرأ مشاركة الواجهة وجدول الجيران معًا، لأن الأول يفسر الثاني.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

يجب أن تتطابق المصادقة وأوزان القياس على الطرفين. سلسلة مفاتيح بوضع خاطئ، أو عدم تطابق في قيمة K، تُسقط رسائل hello دون سطر syslog واضح عند المستقبل. إذا كان التصميم يستخدم جيران unicast مُعرّفين صراحةً، فاتبع ذلك النموذج بالكامل بدل إضافته فوق إعدادات multicast حتى يظهر شيء.

افصل نقل GRE عن حماية IPsec

يحمل DMVPN الـ multicast داخل GRE، ويحمي IPsec حزم GRE لا الـ multicast الداخلي مباشرة. لهذا فإن الادعاء العام بأن IPsec لا يستطيع حمل multicast خاطئ في هذا التصميم ولا يفيد كتشخيص. افحص ملف IPsec على النفق، وارتباطات الأمان لكل نظير، وحالة واجهة النفق كثلاث حقائق منفصلة.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

ارتباط SA قائم مع عدادات تتحرك بينما يبقى EIGRP معطلًا يعيد تحقيقك إلى أعلى المكدس: فالحزم تُحمى وتُسلَّم، لذا المشكلة في أي حزم يختار البروتوكول إرسالها.

تحقق من المسارات لا من عدد الجيران فقط

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

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

سجّل التصميم المرحلي وتعيين multicast وسياسة EIGRP في مكان واحد. المهندس التالي سيحتاج التصميم، لا النص الحرفي.