בנו את גבול ה-EVPN סביב מדיניות הייצוא, לא סביב החיבורים

ההנחה הנפוצה היא שמודל חיבור ה-Layer 2 בגבול קובע את כל מה שמעליו, ולכן התכנון מתחיל בזוג vPC ועולה כלפי מעלה. בדרך כלל זה נגמר בהחלטות ניתוב שהתקבלו במקרה. גבול EVPN הוא קודם כול גבול ניתוב: הקשר ניתוב של דייר פוגש תחום ניתוב חיצוני, ומה שחוצה את הקו הזה הוא הצהרת מדיניות. בחרו את המסלולים, את יחסי ה-ASN ואת נתיבי הכשל לפני שמישהו מתחיל להתווכח על port-channels. מודל החיבור מגיע לאחר כך מדרישה במקום להכתיב אותה.

התחילו במה שחוצה את הגבול

רשמו את המסלולים שאמורים להיות נראים בכל צד, את הכיוון שאליו הם נעים ואת מי שמאשר שינוי ברשימה הזאת. גבול שמקבל הכול ומכריז על הכול אינו בעל מדיניות, אלא רק כבל.

לאחר מכן תנו שם לכשל שאתם מתכוונים לתפעל: uplink אחד למטה, border leaf אחד למטה או כל התחום החיצוני בלתי נגיש. כל תשובה משנה אם דרושים שני שכנים בלתי תלויים, חיבור Layer 2 משותף או שניהם.

רק לאחר ששתי הרשימות קיימות השאלה של החיבור נעשית ניתנת למענה. לפני כן כל מנגנון נראה תקף באותה מידה. אחרי כן רובם פוסלים את עצמם. זה כל הטיעון לעשות את עבודת הניתוב ראשונה.

קבעו את גבול ה-ASN וה-peering

פבריקה עם AS פרטיים עושה בדרך כלל peering עם תחום הגבול הציבורי דרך eBGP, והחלק המעניין הוא המדיניות בשני הצדדים. החליטו אילו קידומות מתקבלות, אילו מוכרזות ואיזה AS path צריך ה-upstream לקבל.

RFC 6996 משמר טווח ASN לשימוש פרטי, ואותם ASN לא אמורים להופיע בהכרזות גלובליות. הפעילו את מדיניות ההסרה או הסינון שהפלטפורמה תומכת בה ואמתו את ההכרזה המתקבלת במקום להניח שהמכשיר עשה זאת. השלב הזה גם לא מעניק לכם סמכות להכריז על קידומת ציבורית שרירותית, זהו שיחה נפרדת עם בעל הכתובת.

קונפדרציה או תכונת local-AS היא בחירת תכנון לטופולוגיה מסוימת. אף אחת מהן אינה חובה רק מפני שהפבריקה וה-upstream משתמשים בתפקידי ASN שונים, ואימוץ אחת מהן בלי הדרישה מוסיף חלקים נעים לכל שינוי עתידי.

קישורי uplink של Layer 3 אינם זקוקים ל-multichassis LAG

ממשקים מנותבים עצמאיים עם שכני BGP משלהם נותנים שני נתיבים ברורים ושני תחומי כשל ברורים. vPC או multichassis LAG אחר משרת דרישת חיבור Layer 2, והוא הכלי הנכון כאשר הדרישה הזו קיימת.

כלל גורפי שכל זוג גבול חייב להשתמש ב-vPC, או חייב להימנע ממנו, מסתיר את התנאים שבאמת מכריעים את המקרה. שאלו מה החיבור צריך לשאת, ואז בחרו את המנגנון שנושא אותו עם המעטה במצבי כשל משותפים.

מדיניות הניתוב שכתבתם ראשונה אינה משתנה כשמנגנון החיבור משתנה, וזה סימן טוב שהסדר היה נכון.

ייצאו רק את מה שהדייר צריך

דייר עשוי להזדקק למסלול ברירת מחדל, לקבוצה של קידומות חיצוניות נבחרות או לטבלה גדולה בהרבה. בחרו את ההיקף הזה לפי קיבולת העברה ומישור בקרה אמיתית, ולא לפי ספירה ישנה של מסלולי אינטרנט שאיש לא מדד מחדש.

מסלול EVPN IP Prefix, הנקרא בדרך כלל Type 5 ומוגדר ב- RFC 9136, נושא מידע קידומת ב-overlay. המימוש עדיין זקוק למדיניות ייצוא וייבוא תואמת בתוספת פתרון next-hop, כך שקבלת מסלול BGP חיצוני בגבול אינה אומרת שכל VRF של דייר מייבא אותו.

לא כל leaf זקוק לטבלה המלאה רק מפני שהגבול מחזיק בה. הפיצו את מה שהתעבורה של הדייר דורשת, ותנו לגבול להחזיק את השאר.

אמתו קידומת אחת מקצה לקצה

בחרו קידומת חיצונית מייצגת ועקבו אחריה דרך ה-VRF המיועד של הגבול, מדיניות הייצוא, הקשר ההעברה של ה-leaf המקבל ונתיב החזרה למקור של הדייר. קידומת שמופיעה במקום אחד ולא במקום הבא מאתרת את הטעות מיד.

ודאו כיצד ה-next hop נפתר דרך ה-overlay, משום שמסלול שקיים עם next hop לא פתור אינו מעביר דבר. לאחר מכן חזרו על הבדיקה אחרי שינוי uplink, שכן אז המדיניות ופתרון ה-next-hop חלוקים לרוב.

סדר העבודה: פרטו את המסלולים החוצים, הסכימו על מדיניות ASN, בחרו את החיבור לתפקידו האמיתי, הגדירו את היקף הייצוא לכל דייר, ואז אמתו קידומת אחת ואת נתיב החזרה שלה.