OSPF או EIGRP מעל VTI ב-ASA: איזה מהם הגרסה שלך תומכת
OSPFv2 ו-EIGRP עוברים מעל VTI ב-ASA רק מגרסה 9.19(1), ורק כשמופעל multicast. השוו ביניהם בגרסה שאתם מריצים, ואז אמתו את השכנים.
רוב הוויכוחים בין OSPF ל-EIGRP מניחים שהמנהרה כבר יכולה לשאת את הפרוטוקול, וב-ASA דווקא ההנחה הזו היא החלק שכדאי לבדוק ראשון. ההשוואה נעשית מעניינת רק לאחר שאומתו התמונה, סוג ה-VTI ונתיב ה-multicast. טעות בסדר הזה תעלה לכם אחר צהריים של כיוונון טיימרים במנהרה שלעולם לא תיצור שכנות. אני מתחיל כל אחד מהתכנונים האלה בהערות הגרסה ובתצורה הרצה, ולא בהעדפת הפרוטוקול.
הגרסה מחליטה לפני הפרוטוקול
מדריך ה-VTI של Cisco ל-ASA 9.24 הוא בסיס תיעוד שמיש: הוא מתאר VTI סטטיים ודינמיים ומונה ניתוב סטטי, BGP, OSPF ו-EIGRP. היסטוריית התכונות שלו ממקמת את התמיכה ב-OSPFv2 וב-EIGRP על VTI בגרסה 9.19(1). כל דבר ישן מזה הוא שיחה אחרת.
אם כך, שתי השאלות הראשונות משעממות ומכריעות:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether 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, ושניהם מוגדרים בנפרד.
בדקו בתצורת ממשק המנהרה את הגדרת ה-multicast הזו לפני שתיגעו בטיימרי hello או hold. אם ההגדרה חסרה, השכנות אינה איטית, היא בלתי אפשרית.
OSPF ו-EIGRP זה לצד זה באותה מנהרה
על המנהרה עצמה שני הפרוטוקולים נראים כמו שהם בכל מקום אחר. OSPF זקוק לסוג רשת תואם, לאזור, לאימות ולפרמטרי שכן; EIGRP זקוק למספר ה-AS שלו ולהגדרות ברמת הממשק שנלוות לכך.
המלכודת היא העתקת הצהרות שכנים ממודל מנהרה אחר. עצות לגבי שכנים סטטיים בתכנון ללא VTI נועדו להימנע מ-multicast, והן אינן עוברות ל-VTI שאמור לשאת את הפרוטוקול באופן מקורי. הגדירו את התנהגות הממשק הנתמכת, ואז תנו לפרוטוקול ליצור את השכנות שלו.
לאחר מכן השוו בצירים שבאמת שונים בטופולוגיה שלכם: יכולת פעולה הדדית עם הצד השני, התנהגות התכנסות שאפשר לבדוק, והידע התפעולי בצוות שלכם. אנקדוטה היסטורית על כך שפרוטוקול אחד מהיר או קל יותר אינה מדידה של הרשת שלכם.
שכנים אינם שווים למסלולים מותקנים
לאחר שהשכנות עולה, הפרידו בין מה שמקורו לבין מה שמתקבל. ראו אילו קידומות סניף כל צד מודיע, אילו מתקבלות, אילו נבחרות ואילו באמת מגיעות לטבלת הניתוב. היקף היבוא, הייצוא וההפצה מחדש צריך להיות מכוון ולא פרסום גורפת של כל מה שהמכשיר יודע.
show ospf neighbor ו show eigrp neighbors אומרים לכם שהסשן חי. show route אומר לכם אם קידומת הסניף הגיעה, ואלה שאלות שונות.
נתיב האפליקציה הוא שוב שאלה שלישית. יחסי שכנות מפיצים נגישות; הם אינם מעניקים הרשאה דרך חומת האש ואינם מוכיחים שבוררי התעבורה וכללי הסינון מסכימים. אמתו את הזרימה המותרת ואת נתיב התגובה שלה בבדיקה מאושרת במקום להניח שהמסלול מרמז על המדיניות.
מה ההשוואה המוגמרת צריכה לתעד
רשמו את ממשק המנהרה, את הגרסה שתומכת בו, את חילופי הבקרה שאימתתם ואת מדיניות המסלולים שתיחלתם. הוסיפו את הגדרת ה-multicast, כי זה הפרט שקובע בשקט אם משהו מהשאר עובד. שמרו את הרשומה לצד הגרסה הפרוסה כדי שאפשר יהיה לסקור שינוי תכונה מאוחר יותר בלי להתחיל מהנחה שכבר פגה.
אם אחד מארבעת אלה חסר, יש לכם העדפה ולא תכנון. תקנו קודם את העובדה החסרה; בחירת הפרוטוקול היא החלק הקל.