נתיב null ב-NX-OS EVPN: להשאיר את החסימה בתוך דייר אחד

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

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

מה השינוי צריך לייצר בפועל

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

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

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

ההצהרה המקומית עושה רק את החלק הראשון

ב-NX-OS בסדרת 10.4(x), נתיב ה-null יושב בתוך הקשר ה-VRF של הדייר ולא בפקודה אחת שמציינת את ה-VRF. הקטע קצר, והוא בהחלט אינו תצורת EVPN מלאה.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

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

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

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

ייצוא וייבוא הם הסכמים נפרדים

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

community BLACKHOLE הוא הסכם על ערך מוכר, לא הרשאה לכל שכן להשליך כל כתובת. RFC 7999 מתאר אותו במונחים האלה, וגבול האמון סביב מי רשאי להכריז עליו הוא חלק מהתכנון ולא פרט מימוש.

הצד המקבל זקוק לתצורה משלו. ב-NX-OS, נתיבי null מסוג 5 דורשים טיפול route-map ב-VTEP כדי לבחור את התנהגות ההשלכה, וזה מתועד לצד שלבי הייצוא. מכשיר שולח שמתייג נכון ומקבל שמתעלם מהתיוג יוצרים שינוי שנראה מיושם ובכל זאת מעביר את התעבורה.

עבור על ה-route-map לאיתור תופעות לוואי בזמן שאתה שם. מדיניות מגבילה חדשה עלולה לדכא נגישות חוקית לקידומות לא קשורות, והנזק הזה מופיע מאוחר יותר מה-blackhole וקשה יותר לייחס אותו אליו.

כתוב את הנסיגה לפני ההוספה

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

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

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

לקבל עם ראיות, לא עם פלט הפקודה

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

לאחר מכן הסר ובדוק שהנתיב הרגיל והשירות חוזרים. המדריך של NX-OS EVPN לנתיבי null עבור גרסה 10.4(x) מתעד את התיוג, החלוקה מחדש ומדיניות הקליטה המתוארים כאן, והוא העזר שיש להשוות מולו את הגרסה שלך.