מעבדת MPLS L3VPN לא מגיבה ל-ping? בדקו את חמש הנקודות האלה

שני נתבים של הלקוח, זוג התקני provider edge ו-ping שמת בלי הודעת שגיאה. במעבדת MPLS L3VPN קטנה התקלה יושבת כמעט תמיד באחת מחמש נקודות הבקרה, ולכל אחת מהן יש פקודה שמראה אם התלות עובדת או חסרה. הטעות היא להפעיל מחדש את BGP בכל פעם שה-ping נכשל במקום לבדוק את התלות לפי הסדר. אם קופצים ישר לתצורת ה-VRF, אפשר לבזבז שעה על בעיה שהתחילה ב-next hop לא פתור שני התקנים משם.

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

נקודת בקרה אחת: ה-PE מגיעים זה לזה

כל PE צריך מסלול ל-loopback של ה-PE האחר, והמסלול הזה חייב להיפתר דרך משהו אמיתי. Interior gateway protocol הוא הדרך הרגילה לשם, אבל גם מסלול סטטי עובד כל עוד החיפוש הרקורסיבי נוחת על adjacency חי. בהתקנים בסגנון IOS, show ip route 10.0.0.2 ואחריו show ip cef 10.0.0.2 מראים אם הקידומת קיימת ואם יש adjacency פתור מאחוריה. מסלול בטבלה בלי adjacency מאחוריו אינו נגישות.

בדקו את שני הכיוונים. עלויות IGP א-סימטריות, passive interface בצד הלא נכון או distribute list שמסנן את ה-loopback שוברים כל אחד רק כיוון אחד, וכיוון אחד מספיק כדי להרוג את הסשן. אם ה-loopback מגיבים ל-ping אבל סשן ה-BGP עומד ב-Active, הסתכלו על ה-update source לפני שנוגעים במשהו אחר.

נקודת בקרה שתיים: קיים נתיב תוויות

מסלול IP ל-loopback המרוחק לא מוכיח שהתעבורה תדחוף תווית. בתכנון LDP ודאו של-loopback המרוחק יש כריכה מקומית וכריכה מרוחקת, ושהתווית היוצאת מופיעה בטבלת ה-forwarding. show mpls ldp bindings 10.0.0.2 32 מציג את זוגות התוויות, ו-show mpls forwarding-table 10.0.0.2 מציג מה ה-line card באמת ידחוף. כשהפקודה השנייה לא מציגה שום תווית או נופלת חזרה ל-IP, התעבורה לא נושאת את תעבורת ה-VPN כפי שהתכנון מניח.

ההבחנה נובעת מאיך ש-MPLS מפריד forwarding state מקידומות יעד, המודל שמתואר ב-RFC 3031. אם המעבדה שלכם משתמשת ב-RSVP-TE או בתוויות סמוכות ל-BGP במקום ב-LDP, בדקו את המצב של אותו מנגנון עצמו; להניח ש-LDP מפיץ כל תווית של השכבה התחתונה היא דרך נפוצה לרדוף אחרי באג רפאים. נתיב תוויות שבור מופיע בדרך כלל מאוחר יותר כמסלול VPN שקיים אך אינו שמיש.

נקודת בקרה שלוש: מסלול ה-VPN הגיע שלם

הסתכלו על מסלול ה-VPNv4 או VPNv6 של הקידומת המדויקת של הלקוח, לא על סיכום הסשן. show bgp vpnv4 unicast all 10.10.1.0/24 אמור להראות את ה-route distinguisher, את ה-next hop שהוגדר ל-loopback של ה-PE המרוחק ותווית. אם הקידומת חסרה, החשוד הראשון הוא מדיניות הייצוא ב-PE המקור או מדיניות היבוא ב-PE הקולט, וה-route target הם האשם הרגיל.

קראו את בדיקת ה-route target בנפרד מקליטת ה-BGP. מסלול יכול להגיע עם next hop נכון ובכל זאת לא לנחות ב-VRF כי ה-importtarget לא מתאים. ב-PE הקולט, show ip route vrf CUSTOMER 10.10.1.0 הוא המבחן שמשנה; טבלת ה-BGP רק מוכיחה שהמסלול חצה את מישור הבקרה.

נקודת בקרה ארבע: ה-interface נמצא ב-VRF

הגדרת VRF עם route distinguisher ו-route target לא מעבירה שום interface לתוכה. ה-interface בצד ה-CE צריך את הקצאת ה-VRF, ו-show ip vrf interfaces או show ip interface brief אמורים לרשום אותו תחת המופע הנכון. זו נקודת הבקרה שבה תצורה מועתקת נכשלת הכי הרבה, כי בלוק ה-VRF נראה שלם בזמן שה-interface עדיין יושב בטבלה הגלובלית.

אחר כך ודאו שה-PE למד את קידומת הלקוח המקומית לתוך ה-VRF הזה, ושה-CE יש מסלול חזרה דרך החיבור. default סטטי ב-CE שמצביע ל-PE מספיק למעבדה, בתנאי שב-VRF של ה-PE יש מסלול ל-LAN של ה-CE. אם אחד משני החצאים חסר, ה-ping נכשל לפני שמונחת תווית כלשהי.

נקודת בקרה חמש: התשובה מוצאת דרך הביתה

עקבו אחרי החבילה קדימה ואחר כך אחרי חבילת התשובה, כי הן משתמשות בטבלאות שונות. ב-PE הכניסה, מקור הלקוח צריך להיפתר בתוך ה-VRF לקידומת המרוחקת עם התווית המרוחקת. ב-PE היציאה, היעד צריך להיפתר בתוך אותו VRF ל-interface בצד ה-CE. ping שמקורו ב-PE עצמו אינו הוכחה: הוא יכול לצאת דרך הטבלה הגלובלית או דרך כתובת מקור אחרת, ולכן ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 הוא המבחן שצריך להריץ.

חומות האש של המארחים, reverse-path filtering ורשימות הגישה ב-CE עדיין חלות. אם הנתיב קדימה עובד והתשובה מתה, הבעיה היא מסלול או מסנן בצד החזרה, לא בתעבורת ה-MPLS.

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