IPv6 ב-VPN מסוג MPLS: שלוש בחירות, לא משפחת כתובות אחת
מסלולי ה-VPN של הלקוח, סשן ה-BGP בין ה-PE ותחבורת הליבה הם החלטות נפרדות. סשן יכול לרוץ במשפחה אחת ולשאת אחרת.
אמרו „הריצו IPv6 L3VPN מעל IPv6 BGP“ בסקירת תכן, ובתוך המשפט האחד הזה מסתתרות שלוש החלטות נפרדות. אילו קידומות שייכות ל-VPN של הלקוח, אילו כתובות נושאות את סשן הניתוב בין קצות הספק, ואיזו ליבה מעבירה את החבילה המתויגת — אלה בחירות בלתי תלויות. כולן יכולות להיות IPv6, הן יכולות להיות מעורבות, ועירוב מותר בכוונה. דווקא ההפרדה בין השלוש היא שהופכת דרישה מעורפלת למשהו שאפשר לבדוק פלטפורמה מולו.
הפרידו בין שלוש המשימות
המשימה הראשונה היא מסלול הלקוח: קידומות IPv6 ששייכות להקשר ניתוב אחד של ה-VPN וחייבות להישאר מחוץ לכל הקשר אחר. השנייה היא חיבור הניתוב בין נתבי הקצה של הספק שמחליפים את הקידומות האלה. השלישית היא התחבורה שנושאת את חבילת הלקוח המתויגת דרך הליבה אל הקצה המרוחק. לנקוב רק באחת מהן אינו תכן עדיין.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
לכל משימה יש משפחת כתובות משלה, דפוסי כשל משלה ולעיתים קרובות צוות משלה. הטבלה מועילה בדיוק מפני שמשפט אחד במסמך תכן נוטה למחוק את שלוש השורות לאחת.
משפחת המסלול היא VPN-IPv6, לא IPv6 unicast
RFC 4659 מגדיר את משפחת BGP/MPLS IPv6 VPN, והשייכות אליה מדויקת יותר ממה שמרמזת המילה IPv6. מסלול שם הוא מבדיל מסלול המחובר לקידומת IPv6, מקודד תחת AFI 2 ו-SAFI 128. IPv6 unicast רגיל הוא משפחה אחרת, ולכן הכרזה שנראית כמו קידומת ב-looking glass עשויה כלל לא להיות אותו אובייקט. קריאה שגויה של המשפחה היא הדרך הראשונה שבה התכן הזה משתבש.
ההבדל נושך בקצה, שם מסלול חייב לנחות בהקשר ה-VPN הנכון לפני שהוא עושה משהו. קבלת קידומת מוכיחה שההחלפה קרתה ואינה אומרת דבר על ההתקנה. הפער הזה מייצר את הדיווח הקלאסי שבו הסשן למעלה והלקוח עדיין בחושך.
הסשן יכול לרוץ במשפחה שונה מזו של ה-VPN
שום דבר לא כופה על חיבור ה-BGP בין שני קצות להשתמש במשפחה של ה-VPN עצמו. המפרט מתיר סשן IPv4 או IPv6, ותחבורת IPv6 VPN עצמה מוגדרת מעל שני סוגי הליבה. לכן סשן IPv6 אינו אומר דבר על המשפחה של מה שהוא נושא, והוא גם לא בוחר את מישור הנתונים. שלושה ביטים בלתי תלויים, והתכן צריך לשאת את שלושתם בנפרד.
זה משחרר וקל לקרוא בו שגיאה באותה נשימה. מסלולי לקוח IPv6 יכולים לרכב על סשן בעל כתובת IPv4, ומסלולי IPv4 על סשן IPv6, כל עוד הפלטפורמה תומכת בשילוב והצעד הבא נפתר. מה שאסור שיקרה הוא שהסשן ירמוז על המטען, במסמך התכן או בניטור שמוכיח את השירות אחר כך.
לצעד הבא על ליבת IPv4 יש קידוד משלו
כשהליבה שמתחת ל-VPN היא IPv4, המסלול לא מופיע עם צעד הבא שקצה הכניסה יכול להשתמש בו ישירות. הוא מגיע בצורת IPv6 ממופה ל-IPv4, וכך המפרט מבטא את קצה היציאה כשהתחבורה שמתחת היא IPv4. נתב הכניסה צריך אז להפוך את הכתובת הממופה למשהו שהוא באמת יכול להגיע אליו דרך הליבה, והפתרון הוא הצעד שנכשל בשקט.
קראו את זה כתלות העברה ולא כמחרוזת להעתקה בין התקנים. אשרו שלושה דברים בפלטפורמה שאתם מפעילים באמת: הצעד הבא המוכרז נפתר לנתיב שמיש, מחסנית התוויות מתקבלת, והיעד נוחת בהקשר ה-VPN המיועד. כל אחד מאלה שנכשל משאיר סשן שנראה בריא ולא מעביר דבר, ולכן הבדיקה שייכת לריצת הקבלה ולא לתקרית מאוחרת.
כתבו את הדרישה בארבע שורות
דרישה שראויה לבדיקה נוקבת בארבעה דברים: משפחת ה-VPN, תחבורת הסשן, קידוד הצעד הבא וסידור הליבה. אחר כך היא נוקבת בקידומת לקוח אחת שיש לעקוב אחריה מקצה לקצה: דרך החלפה, התקנה, פתרון תוויות ונתיב חזור. „תומך ב-IPv6 BGP“ לא מכסה אף אחד מהארבעה ומסתיר היכן אי-ההתאמה באמת נמצאת.
סשן בריא בלי החלפת VPN-IPv6 הוא חסר, ומסלול VPN שהתקבל בלי העברה עובדת חסר באותה מידה. החזקתם כשורות קבלה נפרדות מקצרת את שיחת פתרון התקלות הבאה, כי השורה שנכשלת כבר כתובה.