همسایگان EIGRP روی لایهٔ DMVPN بالا نمیآیند
unicast از طریق لایه کار میکند و همجواری همچنان شکست میخورد، پس تکرار multicast در NHRP، سیاست EIGRP تونل و IPsec را بهعنوان سه لایهٔ جداگانه بررسی کنید.
تونل بالا است، یک spoke میتواند دیگری را ping کند، و EIGRP هنوز هیچ همسایهای روی hub نشان نمیدهد. این ترکیب عادی است و نه مرموز: ping دسترسی unicast را از طریق NHRP اثبات میکند و helloهای EIGRP از نوع multicast هستند. در لایهٔ DMVPN، مدل تحویل پروتکل مسیریابی یک سطح پیکربندی دوم است و همان سطحی است که افراد از آن میگذرند، چون سطح اول از قبل سالم به نظر میرسد. هر لایهٔ زیر با فرمان خودش بررسی میشود، بنابراین شکست در یک لایه شما را به ابتدای فهرست برنمیگرداند.
همجواریهایی را که انتظار دارید بنویسید
پیش از هر فرمان show، فهرست کوتاهی بسازید: کدام spoke باید با کدام hub همتا شود، از طریق کدام رابط تونل و در کدام سیستم خودگردان EIGRP. طرحهای چند-hub در فاصلههای میان hubها شکست میخورند، و یک فهرست «EIGRP خراب است» را به «spoke 3 در hub 2 ثبت نمیشود» تبدیل میکند. زیرشبکههای تونلی را که روی هر پیوند انتظار دارید وارد کنید، چون ناسازگاری نشانی میان دو سر دقیقاً مانند شکست پروتکل به نظر میرسد. فهرست را در تیکت بنویسید تا شیفت بعدی با طرح مقایسه کند و نه با آخرین تصویر صفحه.
ابتدا NHRP و سپس مسیر multicast را بررسی کنید
با وضعیت ثبت و نگاشتهایی که hub واقعاً نگه میدارد شروع کنید. spokeای که روی hub ورودی پویا ندارد ثبت نشده است و هیچ پروتکل مسیریابی آن را درست نمیکند. سپس تأیید کنید که spoke multicast را از نشانی NBMA مربوط به hub میپذیرد، که خطی جدا از ورودی 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 است که به spoke اجازه میدهد helloهای خود را بهصورت multicast تکرارشده روی لایه به hub بفرستد و به multicast مربوط به hub اجازه میدهد به spokeهای ثبتشده برسد. بدون آن، unicast از طریق NHRP کار میکند و multicast نه، و همین شکاف است که ping را شبیه اثبات نشان میدهد. راهنمای Cisco IOS XE DMVPN رفتار multicast مربوط به hub و spokeها را برای هر فاز مستند میکند، پس پیکربندی خود را با فازی که واقعاً مستقر کردهاید تطبیق دهید، نه با کپی کردن بخشی از توپولوژی دیگر.
سیاست رابط خود 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 روی تونل، انجمنهای امنیتی هر peer و وضعیت رابط تونل را بهعنوان سه واقعیت جداگانه بررسی کنید.
show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast
SAای که بالا است و شمارندههایش حرکت میکنند در حالی که EIGRP پایین میماند، بررسی شما را به بالای پشته برمیگرداند: بستهها حفاظت و تحویل میشوند، پس مشکل این است که پروتکل کدام بستهها را برای ارسال انتخاب میکند.
مسیرها را بررسی کنید، نه فقط شمار همسایهها
بهمحض اینکه همجواری شکل بگیرد، بخوانید چه چیزی را اعلام و نصب میکند. روی تونل چندنقطهای، split horizon و رفتار next-hop تعیین میکند که آیا یک spoke میتواند از طریق hub به spoke دیگری برسد، و خلاصهسازی میتواند یک پیشوند را پنهان کند حتی وقتی رابطهٔ همسایگی بیعیب است.
با یک برنامهٔ مجاز میان دو سایت تمام کنید و مسیری را که طی میکند تأیید کنید. میانبرهای مستقیم spoke به spoke یک الزام ارسالاند با وضعیت NHRP و امنیتی خودشان، و افزودن آنها برای بهتر نشان دادن شمار همسایهها معمولاً مشکل دومی میسازد.
طرح فازبندیشده، نگاشت multicast و سیاست EIGRP را در یک جا ثبت کنید. مهندس بعدی به طرح نیاز دارد، نه به رونوشت.