همسایه EIGRP یا ترانزیت DMVPN؟ اول نقش را بررسی کنید

مجاورت وجود ندارد و روتر میانی بدیهی‌ترین مظنون به نظر می‌رسد. ممکن است بی‌گناه باشد. ارسال بسته‌های بیرونی تونل و مشارکت در پروتکل مسیریابی لایه پوششی دو کار متفاوت است و یک دستگاه می‌تواند اولی را بدون دومی انجام دهد. پنج بررسی زیر را به ترتیب انجام دهید و در نخستین بررسی‌ای که شکست می‌خورد متوقف شوید.

گام 1: دو نقش را رسم کنید

مجاورت موردنظر EIGRP را به‌عنوان اتصالی منطقی میان دو روتر رسم کنید، سپس روترهای لایه زیرین را که بسته‌های تونل آن را حمل می‌کنند رسم کنید. لازم نیست یک دستگاه در هر دو فهرست بیاید و اشتباه گرفتن این دو فهرست رایج‌ترین دلیل متهم شدن یک روتر ترانزیت سالم به خراب کردن مجاورت است.

روتر ترانزیت بسته‌های بیرونی را با مسیریابی و سیاست معمول IP خود ارسال می‌کند. نیازی ندارد پروتکلی را که داخل تونل محافظت‌شده حمل می‌شود اجرا کند و برای عبور این بسته‌ها به فرایند EIGRP هم نیاز ندارد.

گام 2: بررسی کنید دستگاه میانی چه چیزی را پایان می‌دهد

اگر روتر میانی تونل را پایان می‌دهد و قرار است مجاورت‌های EIGRP را با spokeها تشکیل دهد، پاسخ کاملاً تغییر می‌کند. آن دستگاه به رفتار مسیریابی پشتیبانی‌شده لایه پوششی نیاز دارد و نامیدن آن به‌عنوان ترانزیت نیاز همسایگی را از بین نمی‌برد. پیش از پیکربندی مسیریابی، پیکربندی تونل را بخوانید. همان پاسخ همه بررسی‌های بعدی را تعیین می‌کند.

پس نخستین پرسش واقعی این نیست که کدام پروتکل را تنظیم کنیم. پرسش این است که آیا جعبه یک hub، یک spoke، یک پرش صرف در لایه زیرین یا یک سرویس Layer 2 است که فریم‌ها را میان نقاط پایانی حمل می‌کند.

گام 3: صفحه کنترل همسایه را بررسی کنید

روی هر دستگاهی که باید همسایه باشد چهار چیز را تأیید کنید: نمونه EIGRP و شماره سیستم خودگردان، پارامترهای احراز هویت، رابطی که در فرایند مشارکت دارد و دستور شبکه‌ای که آن رابط را پوشش می‌دهد. ناهمخوانی در هر یک از آن‌ها مجاورت را پایین نگه می‌دارد، در حالی که رابط بالا می‌ماند و ping ادامه می‌یابد.

RFC 7868 پروتکل EIGRP را یک پروتکل IP با تبادل کنترل چندپخشی توصیف می‌کند و به همین دلیل رابطه همسایگی چیزی نیست که یک روتر میانی بتواند با مسیریابی بسته‌ها به سمت مقصد به نیابت از آن انجام دهد. یا تبادل کنترل به همتا می‌رسد یا مجاورت شکل نمی‌گیرد.

گام 4: بررسی کنید که لایه انتقال تبادل کنترل را تحویل می‌دهد

در ادامه، بررسی کنید که لایه پوششی واقعاً ترافیک کنترل را میان نقاط پایانی موردنظر حمل می‌کند. نگاشت NHRP همتا و مسیر بیرونی‌ای که به آن می‌رسد را بررسی کنید، سپس تأیید کنید که رابط تونل بالا است و ترافیک را عبور می‌دهد. ping موفق در لایه زیرین اثبات می‌کند که مسیر بیرونی وجود دارد؛ اما اثبات نمی‌کند که تبادل کنترل لایه پوششی تحویل شده است.

سرویس شفاف Layer 2، تونل نقطه‌به‌نقطه و ابر چندنقطه‌ای DMVPN چندپخشی را به شکل‌های متفاوتی تحویل می‌دهند. برای آنچه واقعاً پیاده‌سازی شده، مدل پشتیبانی‌شده رابط، NHRP و چندپخشی را دنبال کنید، نه اینکه فرض کنید هر سه یکسان رفتار می‌کنند.

گام 5: اگر نمی‌تواند مشارکت کند مرز را دوباره طراحی کنید

اگر دستگاه لایه پوششی لازم نمی‌تواند پروتکل را اجرا کند، طراحی را صریحاً تغییر دهید. در آن مرز از پروتکل یا مدل تبادل پشتیبانی‌شده استفاده کنید، یا تونلی سرتاسری مناسب ترتیب دهید تا همسایه‌ها همان نقاط پایانی باشند که واقعاً با یکدیگر گفت‌وگو می‌کنند. فرض نکنید که یک مسیر ایستا یک غیرمشارکت‌کننده را به رله‌ای برای هر بسته کنترل تبدیل می‌کند.

نقش هر دستگاه را در نمودار ثبت کنید و آن را همراه پیکربندی نگه دارید. RFC 7868 تبادل پروتکل را تعریف می‌کند و همین تعریف مرجع این موضوع است که چرا رابطه همسایگی را نمی‌توان با مسیریابی ترانزیت شبیه‌سازی کرد.

وقتی مجاورت پس از هر پنج بررسی همچنان برقرار نمی‌شود، مظنونان باقی‌مانده ویژگی‌های پلتفرم مانند نحوه مدیریت چندپخشی روی رابط تونل و سیاستی است که پروتکل 88 را فیلتر می‌کند. این‌ها علت‌های مشخص و قابل آزمون هستند و ارزششان بیش از دور دیگری از سرزنش روتر میانی است.