למה ה-L2VPN שלכם מתעלם מה-RSVP-TE LSP שזה עתה בניתם

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

תווית אחת נותנת שם לשירות, השנייה מזיזה חבילה

תווית ה-pseudowire, שמסומנת על ידי LDP ממוקד כמתואר ב-RFC 4447, אומרת לקצה הספק המקבל איזה מעגל חיבור אמור לקבל את הפריים. היא לא אומרת דבר על איך הפריים הגיע לשם. התווית שמתחת שייכת לתחבורה, והמחסנית הזו נבנית על ידי מה שהכריז על נגישות ל-loopback של העמית, בין אם LDP, RSVP-TE או נתיב מנותב לפי מקטעים. מכיוון שפרוטוקולים שונים מסמנים את שתי השכבות, אחת יכולה להיות תקינה בעוד השנייה מיושנת. ההפרדה הזו היא כל מקור הבלבול.

שווה לומר בפשטות: ה-pseudowire לא בוחר את ה-LSP. הוא מוסר פריים לתחבורה, והתחבורה מחליטה לפי כתובת היעד שקיבלה.

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

אפשרות א: הצמידו את ה-pseudowire לתחבורה נבחרת

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

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

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

אפשרות ב: תנו ל-IGP לבחור ותצפו במה שקורה

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

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

קראו את ההעברה המותקנת לפני שתסמכו על מי מהן

התחילו בכתובת העמית ולא בשירות. ב-Junos, show route 203.0.113.1 detail מדפיס את הקפיצה הבאה הנבחרת ואת פעולת התווית, ו-show route table mpls.0 ממפה את התווית הנכנסת לפעולה הזו. ב-IOS XR, show mpls l2transport vc 100 detail נותן את מצב ה-pseudowire יחד עם המחסנית המוטלת.

אשרו את ה-LSP שהתחבורה באמת משתמשת בו, ולא את זה שמסמך התכנון שלכם נוקב בשמו. traceroute mpls ipv4 203.0.113.1/32 ב-IOS XR הולך לאורך הנתיב המוחלף בתוויות ומפרט את התוויות וממשקי היציאה שלאורכו, שזה הדבר הקרוב ביותר לצפות בנתיב בעצמכם. אחר כך חזרו על התרגיל מקצה הספק המרוחק, כי כיוון החזרה נפתר באופן עצמאי וחוסר סימטריה נפוץ לאחר פריסה חלקית של מדיניות. נתיב שנכון בכיוון אחד ושגוי בכיוון השני גרוע מנתיב שגוי באופן אחיד, כי מחצית מהבדיקות שלכם יעברו.

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

בחרו לפי אופן הכשל, לא לפי העדפה

הצמדה מתאימה לשירותים עם אילוץ שה-IGP לא יכול לבטא, ולצוותים שיכולים לתחזק את המדיניות בכל שינוי. השארת זה ל-IGP מתאימה לשירותים שחייבים לשרוד כל כשל בודד בלי אדם בלולאה.

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