بیشتر بحث‌های OSPF در برابر EIGRP فرض می‌کنند که تونل از قبل می‌تواند پروتکل را حمل کند، و در ASA همین فرض بخشی است که ارزش دارد ابتدا بررسی شود. مقایسه تنها پس از تأیید ایمیج، نوع VTI و مسیر multicast جالب می‌شود. اگر این ترتیب را اشتباه کنید، یک بعدازظهر را صرف تنظیم تایمرها روی تونلی می‌کنید که هرگز همسایگی تشکیل نمی‌دهد. من هر یک از این طراحی‌ها را با یادداشت‌های نسخه و پیکربندی در حال اجرا آغاز می‌کنم، نه با ترجیح پروتکل.

نسخه پیش از پروتکل تصمیم می‌گیرد

راهنمای VTI سیسکو برای ASA 9.24 یک پایه مستندات قابل استفاده است: VTIهای ثابت و پویا را توصیف می‌کند و مسیریابی ثابت، BGP، OSPF و EIGRP را فهرست می‌کند. تاریخچه قابلیت‌های آن پشتیبانی OSPFv2 و EIGRP روی VTI را در 9.19(1) قرار می‌دهد. هر چیزی قدیمی‌تر از آن گفت‌وگوی دیگری است.

پس دو پرسش نخست خسته‌کننده و تعیین‌کننده‌اند:

CheckWhat decides it
Image and releaseWhether the feature history lists OSPFv2 or EIGRP on VTI for the version you run
VTI typeStatic or dynamic, and which routing context the platform permits
Multicast on the tunnelWhether it is enabled, and whether the group limits are respected

این ادعا که ASA نمی‌تواند از VTI استفاده کند یا نمی‌تواند IGP را حمل کند، برای برخی ایمیج‌های قدیمی درست بود و ماتریس پشتیبانی کنونی نیست. به همین ترتیب، راهنمای 9.24 دستور ارتقای هر دستگاهی نیست. می‌گوید آن نسخه چه چیزی را پشتیبانی می‌کند، و نسخه مستقر شما باید خودش پاسخ دهد.

عبور unicast به معنای تشکیل IGP نیست

همان راهنما اشاره می‌کند که unicast به طور پیش‌فرض عبور می‌کند و multicast باید برای OSPFv2 یا EIGRP روی VTI فعال شود، با محدودیت‌های مستند برای گروه‌های multicast. همان یک جمله بیشتر همسایگی‌های ناموفقی را که در این طراحی دیده‌ام توضیح می‌دهد. پینگ کارآمد از میان تونل، یا وضعیت سبز IPsec، فقط مسیر unicast را اثبات می‌کند. کشف پروتکل به مسیر multicast نیاز دارد و این دو جداگانه پیکربندی می‌شوند.

پیش از دست زدن به تایمرهای hello یا hold، پیکربندی رابط تونل را برای آن تنظیم multicast بررسی کنید. اگر تنظیم وجود نداشته باشد، همسایگی کند نیست، غیرممکن است.

OSPF و EIGRP کنار هم روی همان تونل

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

تله کپی کردن دستورهای همسایه از مدل تونل دیگر است. توصیه درباره همسایه‌های ثابت در طراحی بدون VTI برای پرهیز از multicast وجود داشت و به VTIای که انتظار می‌رود پروتکل را به‌صورت بومی حمل کند منتقل نمی‌شود. رفتار پشتیبانی‌شده رابط را پیکربندی کنید و سپس بگذارید پروتکل همسایگی خودش را تشکیل دهد.

سپس روی محورهایی مقایسه کنید که واقعاً برای توپولوژی شما متفاوت‌اند: هم‌کنش‌پذیری با طرف مقابل، رفتار همگرایی که می‌توانید آزمایش کنید، و دانش عملیاتی تیم شما. حکایت تاریخی درباره سریع‌تر یا سبک‌تر بودن یک پروتکل، اندازه‌گیری شبکه شما نیست.

همسایه‌ها با مسیرهای نصب‌شده برابر نیستند

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

show ospf neighbor و show eigrp neighbors به شما می‌گویند که نشست زنده است. show route به شما می‌گوید آیا پیشوند شعبه رسیده است، و این‌ها پرسش‌های متفاوتی هستند.

مسیر برنامه دوباره پرسش سوم است. رابطه همسایگی دسترس‌پذیری را توزیع می‌کند؛ مجوز عبور از فایروال نمی‌دهد و اثبات نمی‌کند که انتخابگرهای ترافیک و قواعد فیلتر هم‌راستا هستند. جریان مجاز و مسیر پاسخ آن را با آزمون تأییدشده بررسی کنید، نه با فرض اینکه مسیر یعنی سیاست.

مقایسه کامل باید چه چیزی را ثبت کند

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

اگر هر یک از آن چهار مورد نباشد، شما ترجیح دارید نه طراحی. اول واقعیت غایب را درست کنید؛ انتخاب پروتکل بخش آسان است.

مقالات مرتبط