AFI ו-SAFI: קראו את הזוג לפני שם השירות
AFI 25 עם SAFI 65 אינו אותו שירות כמו AFI 25 עם SAFI 70. קראו את הזוג, ואז בדקו את חילופי המשפחות, את המסלול ואת תוצאת ההעברה.
אפשר לראות הפעלה עולה, מסלול מופיע, ובכל זאת לקרוא את השירות הלא נכון. זוג המספרים בראש כל הודעה, מזהה משפחת הכתובות ומזהה משפחת הכתובות הבאה, קובע איזה מנתח קורא את המטען ואיזו טבלה מחזיקה את התוצאה. טעות בזוג והנה מדיניות הייבוא, התאמת יעד המסלול וחיפוש הקפיצה הבאה רצים כולם מול מבנה שאיש לא הודיע עליו. המהלך שלהלן מתחיל בזוג הזה ומסתיים בתוצאת ההעברה.
שני מספרים קובעים לאיזו טבלה שייך המסלול
הזוג מופיע פעמיים: בתוך יכולת ריבוי הפרוטוקולים, שם דובר מודיע על משפחה, ולפני כל NLRI שאותה משפחה נושאת. זה הופך אותו לתכונה של המסלול ולא להגדרה בקופסת המקור. ספקים מדפיסים אותו כשם כמו Address family VPNv4 Unicast, והניסוח משתנה בין מהדורות בעוד המספרים נשארים במקומם.
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
ארבעה קידודים מכסים כמעט כל מקרה ארגוני: 1 עם 128 ל-VPN-IPv4 מתויג ב-MPLS, 2 עם 128 למקבילה של IPv6, 25 עם 65 ל-VPLS מאותת ב-BGP, ו-25 עם 70 ל-EVPN. הטעות הראשונה היא להניח שכל שירות Layer 2 יושב מאחורי 25 עם 65, מה שמסתיר את EVPN. השנייה היא להתייחס לשתי משפחות ה-IP כמשפחה אחת עם כתובת ארוכה יותר, כאשר הן מנוהלות במשא ומתן בנפרד ויכולות להתקבל בעמיתים שונים. שלישית מופיעה כשמעתיקים תבנית ממהדורה שמכירה רק אחת מהן. חיפוש ברשומות מכריע את שלושתן מהר יותר מניחוש שנבנה על שם השירות.
התייחסו לארבע השורות כדוגמאות מרשומות IANA, לא כרשומות עצמן. כשמספר אינו מתאים לשום דבר שאתם מזהים, חפשו אותו לפני שאתם בונים סביבו מדיניות.
AFI 25 נושא שני פורמטים של NLRI שאינם קשורים
שתי משפחות ה-Layer 2 יושבות תחת AFI 25, והדמיון נגמר שם. ה-NLRI של VPLS ב-RFC 4761 section 3.2.2 נושא אורך, מבדיל מסלול, VE ID, היסט בלוק VE, גודל בלוק VE ובסיס תוויות, אשר יחד נותנים שם לנקודת קצה של pseudowire ולתווית שלה. EVPN שומר על AFI 25 ועובר ל-SAFI 70, שם המטען הוא סוג מסלול: גילוי אוטומטי של Ethernet, הודעת MAC/IP, multicast כוללני, מקטע Ethernet, קידומת IP. לכן אותו היסט בייטים משמעו דברים שונים בשתי המשפחות. מנתח שנכתב לאחת קורא את האחרת בלי תלונה ומייצר שטויות. הזוג הוא האזהרה היחידה שהפרשנות שגויה.
לשדה שמשמעו היסט בלוק VE במשפחה אחת אין מקבילה בשנייה, ומסלול הודעת MAC/IP קיים רק ב-EVPN. ציטוט של מאפיין כאילו חל על שתיהן הוא הדרך שבה סקירת לכידה משתבשת.
כשמישהו מוסר לכם לכידה או טבלת ספק, שאלו לאיזו משפחה שייך המאפיין. אחר כך אשרו שהמימוש המקבל תומך באותה משפחה, לא בשם השירות בגיליון הנתונים. שתי פלטפורמות יכולות שתיהן להצהיר על תמיכת VPLS בעודן מיישמות משפחות איתות שונות. הזוג מפריד ביניהן; תווית המוצר לא.
משפחת הכתובות של הסשן עצמו היא שאלה נפרדת
VPN-IPv6 מוכרז בדרך כלל דרך סשן שחיבור ה-TCP שלו רץ מעל IPv4, וזה תכנון נתמך, לא תקלה. לכן קריאה של סיכום הסשן בלבד אינה אומרת דבר על אילו משפחות VPN מחליפים העמיתים.
משפחת NLRI, משפחת התעבורה ומשפחת ההעברה הן שלוש החלטות בלתי תלויות. נתב יכול לדבר IPv4 עם העמית שלו, לקבל נגישות של VPN-IPv6 ולהתקין מסלול שהקפיצה הבאה שלו היא כתובת IPv6 שנגישה בנתיב שלא התכוונתם לו. כל שכבה זקוקה לאישור משלה. אתרים שמדווחים על יעדים לא נגישים של IPv6 בזמן שההודעות נראות תקינות איבדו בדרך כלל את פתרון הקפיצה הבאה, לא את משא ומתן המשפחות.
בדקו את משפחת הכתובות של הסשן בנפרד, אחר כך את המשפחות שהוא נושא, ואחר כך מה שהליבה יכולה להעביר. החזקת השלושה בנפרד מונעת את האבחון השגוי הנפוץ שבו הודעה נכונה נקראת כהוכחה ש-IPv6 עובד מקצה לקצה. היא מוכיחה רק שעמית אחד סיפר לאחר על קידומת.
נוהל משא ומתן, התקבל, יובא, הותקן
עבור מסלול צפוי אחד, ארבעה מצבים חייבים להתקיים לפי הסדר, וכל אחד ניתן לצפייה. המשפחה חייבת להיות במשא ומתן עם אותו עמית, המסלול חייב להגיע, יעד מסלול חייב לייבא אותו להקשר המיועד, והקפיצה הבאה חייבת להיפתר כדי שהמסלול יותקן. דילוג על המצב הראשון הופך את שלושת האחרים לבלתי ניתנים למענה, כי משפחה ללא משא ומתן אינה מייצרת מסלולים לבדיקה. בפלטפורמות בסגנון Cisco סיכומי המשפחות והיכולות לפי עמית הם פקודות נפרדות.
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address familyהמשא ומתן נראה בחילופי היכולות המודפסים לפי עמית, וסשן מבוסס בלי שום משפחה רשומה אינו נושא דבר ממה שביקשתם. הייבוא נקבע על ידי יעדי מסלול הנישאים כקהילות מורחבות, כך שזוג נכון עם יעד שהוקלד בטעות משאיר את הטבלה ריקה. לאחר מכן ההתקנה תלויה בפתרון הקפיצה הבאה בהקשר המקבל, שעלול להיכשל בזמן שכל הודעה נראית מושלמת.
אשרו את מישור הנתונים אחרון, כי מסלול בטבלה הוא הצהרה, לא מסירה. אותם ארבעה מצבים חלים על כל משפחה; רק הפקודות ושמות הטבלאות משתנים.
מה שזוג משפחות לעולם אינו מוכיח
קריאה נכונה של הזוג אומרת לכם כיצד לפרש את פרטי הניתוב שלאחריו, וזו כל ההצהרה. הוא אינו אומר דבר על נגישות, לא על מדיניות ולא על בריאות מישור הנתונים. ערבוב השניים מייצר הצהרות בטוחות על רשת שאיש לא אימת. אי התאמה של יעד מסלול וקפיצה הבאה שבורה נראים זהים מן הזוג בלבד. הזוג הוא הוראת קריאה, לעולם לא פסק דין.
כשאתם מסלימים, שימו את הזוג, יעד המסלול והקפיצה הבאה שנפתרה באותה הערה. אז יש למהנדס הבא שלושה דברים בלתי תלויים לבדוק במקום שם שירות לפרש מחדש. אם המשא ומתן חסר הם רואים זאת מיד, יעד שגוי משאיר את הייבוא נעדר לעין, וקפיצה הבאה שלא נפתרה משאירה את המסלול נוכח אך חסר תועלת.