סשן BGP פעיל, הנתיב של הלקוח שבור: MPLS מעל DMVPN

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

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

מה הסשן באמת מוכיח

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

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

ארבעה מנגנונים, לא אחד

התיעוד של Cisco ל-MPLS מעל DMVPN מפריד את החלקים בבירור. MP-BGP מפיץ את תוויות שכבת העל של הלקוח בין התקנים בקצה הספק. MPLS משתמש בתוויות האלה כדי לבחור את הקשר ההעברה של מנה. NHRP ממפה כתובת שכבת על לנקודת הקצה של התעבורה שמנה דינמית זקוקה לה. IPsec מגן על נתיב העמיתים היכן שהוא חל.

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

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

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

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

שמרו את בדיקות ה-loopback בתא נפרד

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

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

טענות גרסה וטענות פגם זקוקות לראיות משלהן

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

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