מארח EVPN שקט לעולם אינו נפתר: עקבו אחרי ה-ARP עד לקישור

נקודת הקצה מחוברת, הפורט שלה פעיל, ומארח הניטור עדיין אינו מצליח להגיע אליה. מישהו מריץ ping מהצד השני וזה מתחיל לעבוד, מה שגורם לבעיה להיראות לסירוגין ול-fabric להיראות נקי. התבנית הזו היא החתימה של מארח שקט: הוא שולח לעיתים רחוקות, ולכן התנהגות הגילוי והרענון של ה-fabric חשובה יותר ממצב החיבור שלו. התחילו עם IP, MAC ו-bridge domain מיועדים אחדים ועקבו אחרי חילופי הפתרון הבאים.

עקבו אחרי חילופי ה-ARP או ה-ND הבאים

עבור IPv4, התבוננו בחילופי ה-ARP של המארח המבקש; עבור IPv6, עקבו אחרי ה-Neighbor Solicitation וה-Advertisement. ודאו שהבקשה נכנסת למקטע המקומי המיועד ול-VNI המיועד, כי בקשה שלעולם אינה מגיעה ל-bridge domain הנכון לא יכולה לקבל מענה מאף proxy.

לאחר מכן הביטו במה שה-fabric יודע על היעד. מסלול MAC בלבד יכול לזהות יעד Layer 2 בעוד ל-proxy עדיין אין קישור IP-to-MAC עבורו. אלה רשומות נפרדות, ובדיקת האחת אינה אומרת דבר על האחרת.

אם קיים קישור תקף, ה-proxy יכול להשיב בהתאם למדיניותו, אך ה-MAC בקישור הזה עדיין זקוק לנתיב העברה פעיל. אם הקישור חסר, הבקשה חייבת להגיע לחיבור של נקודת הקצה דרך נתיב ה-flooding או השכפול לפני שמשהו יוכל ללמוד מהתשובה.

שתי רשומות שחייבות להתלכד

מסלול ה-MAC עונה היכן נמצאת כתובת ה-Ethernet. טבלת ה-proxy עונה איזה IP ממופה לאיזה MAC. מארח שלא דיבר לאחרונה יכול להיות בעל מסלול MAC תקין לחלוטין ובלי שום רשומת proxy שמישה, וזה בדיוק המצב שמייצר כשל בפתרון על חיבור בריא.

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

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

מה התקן באמת מניח

RFC 9161 מתאר למידה דינמית של proxy ואת ברירת המחדל של flooding לבקשות ARP ו-ND לא מוכרות. דיכוי מלא של ה-flooding הזה מוגבל לפריסות שהנחות הלמידה או האספקה שלהן הופכות אותו לבטוח, שזה תנאי צר יותר ממה שרוב מדריכי התצורה מרמזים.

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

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

רענון, התיישנות והחלופה הסטטית

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

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

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

מה לתעד לפני הקריאה הבאה

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

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