אותו iESI בתוך אתר, ייחודי בין אתרים: תפירת Junos

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

שני היקפים, שני כללים

בתוך אתר, שערי ה-interconnect היתירים פועלים כנקודת קצה multihomed אחת, ולכן הם חולקים interconnect ESI יחיד. ה-peers שלהם חייבים לראות חבר לוגי אחד ולא שניים עצמאיים. זה כל הרעיון של הערך המשותף.

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

בתוך אתר: זהות אחת לקבוצה

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

המודל הנתמך הוא all-active. אותה הפניה שוללת הפעלה single-active, מזהי LACP שנגזרים אוטומטית ואפשרויות source-bmac לזהות התפירה הזו, ולכן תכנון שהניח אחד מאלה צריך להיבחן מחדש עוד לפני בחירת המזהה. האילוץ הזה הוא קלט תכנון, לא הערת שוליים.

בין אתרים: ערכים שונים, או מיזוג מכוון

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

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

הצהרת ה-peer היא חלק מהזהות

כל שער בקבוצה מפרט את ה-peers המקומיים שלו לפי כתובת loopback, והיחס הזה חי ברמת EVPN הגלובלית ולא בתוך MAC-VRF בודד. הצבה בהיררכיה הלא נכונה היא דרך נפוצה לייצר תצורה שמתבצעת אבל לעולם לא יוצרת את הקבוצה. קראו את היררכיית ההפניה פעם אחת, ואז דבקו בה.

גם שם ההצהרה עבר. Juniper שינתה את שם הצהרת interconnect peer-gateways ב-24.2R1 והחזירה את הצורה הספציפית ל-interconnect עבור interconnect של מרכזי נתונים ב-24.4R1. לכן קטע שנלקח מהגרסה הביניים עשוי להשתמש בשם שהגרסה הפרוסה אינה מקבלת, או להפך. רשמו את הגרסה שממנה הגיע הקטע לצד הקטע עצמו.

מה שיתוף iESI לא עושה

הוא לא מגדיר עבורכם route targets, VNIs או את מופע ה-EVPN המקומי. אלה נשארים תצורה נפרדת שחייבת להסכים בשני הצדדים, ו-מזהה שמתאים בעוד route target אינו מתאים מייצר קבוצה שנוצרת ולא נושאת דבר. השוו את שני הצדדים של ההגדרות האלה באותה בדיקה.

הוא גם לא מוכיח נגישות של peers או בחירה של designated forwarder. בדקו unicast ואת התנהגות ה-broadcast וה-multicast הנדרשת במקרה הרגיל, ואז חזרו על כך עם שער אחד שהוסר כדי שהחבר ששרד יישא את הקבוצה לבדו.

ההרצה השנייה היא זו שמוכיחה שהקבוצה אמיתית.

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