מסירת L3VPN: נתיבים פרטיים, נתיב ברירת מחדל או טבלה מלאה?

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

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

התחילו בתעבורה שאיש לא תכנן

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

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

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

רשמו את הקידומות הפרטיות יחד עם מקרה הכשל שלהן

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

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

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

בדקו מה ה-CE באמת התקין

כוונת התצורה ומצב ההעברה נבדלים לעתים קרובות מספיק כדי שהאימות יהיה חלק מהמסירה ולא מסקירת האירוע. בצד לקוח של IOS-XE שלוש הפקודות שלמטה עונות על שלוש שאלות שונות: מה הוצע, מה התקבל ומה באמת בשימוש.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

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

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

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

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

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

מפרט BGP/MPLS IP VPN דן בכמה הסדרי גישה לאינטרנט לצד שירות ה-VPN עצמו, והוא אינו מכריז שטבלה מלאה או נתיב ברירת מחדל הם חובה לכל לקוח, וזה הקטע ששווה להצביע עליו כשמופיעה טענה על "נוהג מקובל": RFC 4364.

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