חלק מנתיבי L2VPN נעלמים לאחר הוספת משקפי נתיבים

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

האובדן סלקטיבי, וזה מצמצם את החיפוש

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

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

מה השיקוף באמת משנה

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

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

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

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

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

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

התנגד להפיכת כל שכן ללקוח

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

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

בדוק את משפחת הכתובות לפני שאתה מאשים את השיקוף

חיבור TCP בפורט 179 מוכיח ששני הדוברים יכולים לדבר, ושום דבר על האם משפחת הכתובות של VPN החליפה ולו נתיב אחד. קבע את מצב החיבור, אחר כך את המשפחה, ואחר כך את הקידומת הבודדת.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

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

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