למה דייר EVPN אחד יכול להציג כמה route distinguisher
שני RD בדייר אחד אינם התנגשות. עברו מפלט ה-CLI אל ה-MAC-VRF או ה-IP-VRF שיצר את המסלול, ואז בדקו ייבוא RT ו-VNI.
אתם מסננים את טבלת ה-EVPN עבור דייר אחד, והמסלולים נושאים שני route distinguisher שונים. התגובה הראשונה היא התנגשות תצורה, והתגובה הזו בדרך כלל שגויה. שם דייר הוא תווית עסקית, לא אובייקט יחיד של מישור הבקרה, ולכן הקשר הגישור והקשר הניתוב שבתוכו יכולים להכריז כדין תחת מזהים נפרדים. עברו מסלול אחד בכל פעם מהפלט חזרה לאובייקט השירות המקומי שיצר אותו, וה-RD השני מפסיק להיראות כמו טעות.
התחילו בפלט שבלבל אתכם
בחרו מסלול אחד ולא את כל הטבלה. רשמו את סוג המסלול, את ה-RD, את ה-route target שיוצאו ואת הקפיצה הבאה. ארבעת השדות האלה מספיקים כדי לזהות איזה אובייקט מקומי הכריז עליו ואיזו מדיניות מרוחקת אמורה לייבא אותו.
בהתקן בסגנון NX-OS מגיעים לתצוגה המפורטת עם show bgp l2vpn evpn route-type 2 detail או show bgp l2vpn evpn route-type 5 detail. ב-Junos אותו מידע נמצא ב-show route table bgp.evpn.0 detail. תחביר אחר, אותם שדות.
אל תתחילו בכך שתהפכו כל מספר מוצג לשווה. השוואת RD-ים היא השינוי ששובר את מדיניות הייבוא ב-fabric שעובד.
תנו לכל מזהה את התפקיד שלו
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF מחזיק מידע העברת MAC עבור שירות גישור. IP-VRF מספק הקשר ניתוב IP עבור שירות מנותב. דייר יכול לכלול את שניהם, ולכן דייר אחד יכול להפיק יותר מ-RD אחד בלי שום שגיאת תצורה.
RFC 7432 מקצה את ה-RD של ה-MAC-VRF המכריז ל-EVPN NLRI שלו ודורש RD-ים נפרדים בין MAC-VRF-ים באותו PE. נהלי route-target נפרדים: הם מתירים מאפיין RT אחד או יותר ונשענים על מדיניות הייבוא עבור חברות. שוויון RD אינו מה שיוצר חברות משותפת, והתייחסות כזו אליו היא שורש הבלבול הזה.
עברו מסלול אחד מההכרזה עד הייבוא
עקבו אחרי המסלול בכיוון אחד. אשרו את סוג המסלול, את השירות שיצר אותו, את ה-RD, את ה-RT שיוצאו ואז את מדיניות הייבוא ב-PE המקבל. כל שלב עונה על שאלה אחרת, וכשל בכל שלב נראה כמו אותו prefix חסר בצד השני.
כשהמסלול קיים, בדקו את הקשר ההעברה המותקן ואת מיפוי ה-VNI. התאמת VNI בשני הקצוות מוכיחה שמישור הנתונים מסכים; היא אינה מוכיחה שמישור הבקרה ייבא את המסלול דרך המדיניות המיועדת.
אם המסלול מופיע ב-PE המרוחק אבל אין תעבורה, הבעיה עברה מעבר ל-EVPN. בדקו את הקישור VNI ל-VLAN או VNI ל-VRF ואת נתיב ה-underlay לפני שתערכו שוב route target. התחילו במיפוי, אחר כך ב-underlay ורק אז במישור הבקרה. החזרת שינוי route-target כדי לרדוף אחרי תקלת מישור נתונים היא דרך בטוחה לשבור ייבוא שעובד.
prefix-ים של שכבה 3 הם עדיין מסלולי EVPN
prefix IP בטבלת ה-EVPN אינו BGP רגיל של IPv4-unicast. מסלול EVPN IP Prefix הוא סוג מסלול בפני עצמו, והכרזות MAC/IP ו-prefix של IP עוברות במשפחת הכתובות EVPN, ש-RFC 7432 מזהה כ-AFI 25 ו-SAFI 70.
ההבחנה הזו חשובה כשמשווים מסלול בטבלת ה-EVPN למסלול בטבלת ה-unicast. הם יכולים לתאר את אותה מטרה ובכל זאת להיווצר, להסונן ולהייבוא על ידי מדיניות שונה. קריאה של האחד כראיה על השני היא הדרך שבה fabric תקין נראה שבור בזמן הגירה.
בדקו את הגזירה של הספק לפני השוואת מספרים
RFC 9136 מרחיב את EVPN במסלולי IP Prefix ומפרט אם ה-RD הרלוונטי מגיע מהקשר MAC-VRF או IP-VRF. לכן תווית שירות L2 ותווית שירות מנותב באותו פלט צריכות להיקרא מול האובייקטים שהן שייכות להם, ולא לצומצם ל-RD אחד לדייר.
גזירה אוטומטית של RD ו-RT תלויה בספק. קראו את התיעוד של הספק הפרוס לגבי הנוסחה שבשימוש; ערך שנוצר אוטומטית ונראה במתג אחד אינו קידוד אוניברסלי, והשוואת מספרים של שני ספקים רק לעיתים רחוקות מוכיחה משהו.
סיימו בעקבות כתובים למסלול שאיתו התחלתם: סוג, אובייקט מקור, RD, RT שיוצא, מדיניות ייבוא, VNI מותקן. שישה שדות מסבירים את ההכרזה לכל מי שיקרא את הכרטיס אחריכם, ואף אחד מהם אינו דורש שהמספרים של הדייר יתאימו.