מיפוי פורט גישה ללא תג אל ה-EVPN VNI הנכון

מארח Ethernet רגיל שולח מסגרות ללא תג, ורשת ה-EVPN עדיין חייבת להעביר אותן בשירות הדייר הנכון. פורט הגישה מסווג את המסגרת למקטע מקומי, ה-VTEP ממפה את המקטע ל-VNI, והחיבור המרוחק מציג את המסגרת כפי שהמארח שלה מצפה. ה-VLAN וה-VNI מזהים חלקים שונים של אותו נתיב ואינם חייבים לחלוק מספר. הפעילו את ה-runbook שלהלן לפי הסדר, כי טעות בכל שלב מייצרת את אותו סימפטום: מארח ששולח ואינו מקבל דבר.

מעקב אחר מסגרת אחת דרך הרשת

עבור שירות פשוט מבוסס VLAN, נתיב להמחשה נראה כך:

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

מספרי ה-VLAN וה-VNI הם דוגמאות, לא כלל. ה-VLAN המקומי הוא סיווג כניסה שקיים במתג אחד; ה-L2VNI הוא מזהה שירות ה-overlay ששני ה-VTEP-ים מבינים. מפרט ה-overlay RFC 8365 מחזיק את מזהה השירות בנפרד מן האופן שבו מחובר המארח, ומכנה שלוש צורות: מבוססת VLAN, מאוגדת ומודעת VLAN.

הגדרת סיווג הכניסה

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

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

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

הגדרת ה-VTEP ומיפוי ה-VNI

ה-VTEP מוסיף את עטיפת ה-VXLAN ואת ה-VNI. המארח אינו יוצר את הכותרת הזו ואינו צריך לדעת שהשירות קיים.

מפו את ה-VLAN המקומי ל-L2VNI בצורת הפקודה שהפלטפורמה תומכת בה, ושמרו על המיפוי הזה עקבי בשני קצות השירות. L2VNI של דייר וה-L3VNI המשמש לניתוב בין תת-רשתות הם אובייקטים שונים, וערבוב המספרים שלהם שובר את הניתוב בלי לגעת בנתיב ה-L2; וזכרו שנתיב underlay עובד אל ה-VTEP המרוחק שייך לשכבה נוספת של ההתקנה.

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

הגדרת ההצגה ביציאה

בקצה המרוחק יש להפוך את השירות המתקבל חזרה למה שהמארח מצפה לו: Ethernet חשוף בפורט גישה, תג מסוים ב-trunk שאתם שולטים בו, וטיפול בתג הפנימי שמתאים למודל השירות שבחרתם. בדקו את רשימת ה-VLAN-ים המותרים ב-trunk לפני שאתם מאשימים את ה-overlay, כי תג שה-trunk היוצא אינו מתיר מושלך לאחר שה-overlay כבר עשה את עבודתו. אשרו שהמארח המרוחק מצפה להצגה שהוא מקבל ולא לזו שהתרשים שלכם הניח.

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

קראו יחד את למידת ה-MAC המקומית, את נתיב שירות ה-EVPN ואת מיפוי החיבור המרוחק, והפעילו את גילוי השכנים שהאפליקציה זקוקה לו ולא רק ping. כתובת MAC שנלמדה בדומיין גשר אחר יכולה להיות תקפה לגמרי שם ובכל זאת להצביע על השירות הלא נכון.

אימות עם זוג מארחים אחד

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

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

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