BGP למד את הקידומת, אבל התעבורה עדיין עוקפת את המנהרה
קידומת בטבלת BGP היא חדשות של מישור הבקרה, לא החלטת העברה. עברו על קליטה, בחירה, התקנה והתאמה לפני שאתם מאשימים את המנהרה.
שער הסניף מציג את קידומת הענן בטבלת ה-BGP שלו, החיבור לספק מוקם, ואף על פי כן בקשת המשתמש לאותה קידומת יוצאת דרך הממשק הלא נכון. שום דבר לא שבור כפי שהניטור מרמז, כי “BGP למד את זה” הוא אמירה על מישור הבקרה. בין הטבלה הזו לחבילה יש ארבעה מעברים נפרדים, והזרימה נעצרת באחד מהם בדיוק. עברו על השערים לפי הסדר ועצרו בראשון שנכשל.
השער הראשון: מה השכן באמת שלח
התחילו בקידומת כפי שהתקבלה, לא כפי שסוכמה. חפשו את הרשת והמסכה המדויקות בטבלת ה-BGP ורשמו את הקפיצה הבאה, את נתיב ה-AS וכל קהילה שמדיניות ייבוא עשויה להתאים לה. נתיב מסוכם בלוח בקרה עלול להסתיר את העובדה שהקידומת הספציפית מעולם לא התקבלה.
מדיניות ייבוא היא המקום הרגיל שבו נתיב נעלם בלי שגיאה. רשימת קידומות, מסנן קהילות או מפת נתיבים נכנסת יכולים להפיל את העדכון בזמן שהחיבור נשאר למעלה ובריא, ולכן נורית שכן ירוקה מוכיחה כל כך מעט. היעדר שורת לוג אינו היעדר החלטה. בדרך כלל פירושו שההחלטה התקבלה בשקט, בדיוק כפי שהוגדר.
show ip bgp 10.60.20.0/24 show ip bgp neighbors 203.0.113.5 advertised-routes show ip route 10.60.20.0 show ip cef 10.60.20.0
קראו את הפלט לפי הסדר הזה. שתי הפקודות הראשונות אומרות אם המידע הגיע ומה העמית אומר ששלח; שתי האחרונות אומרות אם משהו הגיע לטבלאות הניתוב וההעברה. קידומת שקיימת בפקודה הראשונה וחסרה בשלישית היא בעיית בחירה או התקנה, לא בעיית קישוריות.
השער השני: בחירה, ואז התקנה
BGP בוחר את הנתיב הטוב ביותר, והנתיב הנבחר אינו מותקן אוטומטית. הקפיצה הבאה חייבת להיפתר, ומקור נתיבים אחר עשוי כבר להחזיק בקידומת הזו עם מרחק ניהולי טוב יותר. נתיב סטטי שנותר מההגירה ינצח בקלות נתיב BGP תקף וישלח את התעבורה למקום אחר.
RFC 4271 מחזיק שלושה רעיונות בנפרד: מה עמית שלח, מה הדובר הזה בחר כטוב ביותר, ומה הוא יפרסם הלאה. אלו תפקידים מושגיים ולא שלושה מסדי נתונים פיזיים שספק חייב לחשוף, אבל דווקא ההפרדה הזו הופכת את “זה ב-BGP” לתשובה חלקית.
בדקו גם איזה הקשר ניתוב אתם קוראים. נתיב שמותקן ב-VRF שהממשק של המשתמש אינו שייך אליה אינו נראה לחבילות של אותו משתמש, והטבלה נראית תקינה כל הזמן.
השער השלישי: החיפוש שחל על הזרימה הזו
עכשיו הפסיקו לשאול על הנתיב והתחילו לשאול על החבילה. רשמו את כתובת המקור של המשתמש, את היעד, הפרוטוקול, הפורט וממשק הכניסה, כי כל אחד מאלה יכול לבחור מדיניות אחרת. אחר כך הביטו בחיפוש שחל על הצירוף הזה ולא בטבלת הניתוב הכללית.
ip route get 10.60.20.25 from 10.60.10.40 ip rule show sudo tcpdump -ni tun0 'host 10.60.20.25'
קידומת ספציפית יותר היא ההפתעה הנפוצה כאן, ונתיב מדיניות הוא השנייה. שניהם גוברים על הצבירה שהסתכלתם עליה, ואף אחד מהם אינו נראה בסיכום של טבלת ה-BGP.
פינג שנשלח מהשער עצמו אינו ראיה לגבי החיבור של משתמש. כתובת מקור אחרת, נתיב מדיניות אחר, ולעיתים קרובות תוצאה אחרת. בדקו עם אותו מקור שהאפליקציה משתמשת בו, או השלימו עם כך שהבדיקה עונה על שאלה אחרת.
השער הרביעי: החצי המרוחק של הנתיב
אם החיפוש המקומי אכן בוחר במנהרה, החבילה עדיין צריכה להתקבל על ידי מדיניות ההגנה, להיות מורשית על ידי כלל ההעברה, ולהיענות על ידי משהו בצד השני. ACL קריפטוגרפי שאינו כולל את זוג הכתובות יפיל את התעבורה בזמן שהמנהרה מדווחת על עצמה כפעילה, מה שיוצר פסק זמן שאינו ניתן להבחנה מכשל ניתוב.
נתיב החזרה חשוב כמו הנתיב היוצא. צד הענן חייב לדעת איך להגיע למקור הסניף, בין אם דרך נתיב ובין אם דרך תרגום שהגדרתם בכוונה. נתיבי חזרה א-סימטריים נפוצים בעיצובים שנבדקו מכיוון אחד בלבד.
תאמו חיבור מורשה טרי מול שלוש תצפיות: המדיניות המקומית שהתאימה, מוני המנהרה שזזו, והקליטה בצד המרוחק היכן שזה גלוי. אם המונים לא זזים, החבילה מעולם לא נכנסה למנהרה, יהיה אשר יאמר טבלת הנתיבים. אם הם זזים ושום דבר לא מגיע, הצד המרוחק מפיל או מנתב אותה לא נכון. שתי התוצאות הללו מובילות לצוותים שונים לחלוטין.
תנו שם למעבר שנכשל
כתבו את התוצאה כאחד מחמישה מצבים: לא התקבלה, לא אושרה על ידי מדיניות, לא נבחרה, לא הותקנה, או לא הותאמה לזרימה הזו. הוסיפו שישי למקרה שבו הנתיב המקומי תקין והקצה המרוחק אינו יכול לענות. המשפט הזה הוא התוצר, והוא שימושי הרבה יותר מצילום מסך של שכן מוקם.
שמרו גם בדיקה שלילית בתוכנית הקבלה: יעד שאסור לו לעבור במנהרה, מאומת לאחר השינוי. רשימת בדיקה שמוכיחה רק את המסלול המאושר לא תתפוס את כלל המדיניות הרחב שמישהו יוסיף בחלון התחזוקה הבא.