אותו /24 לשני לקוחות? VPNv4 זקוק ל-RD ולתווית
שני שוכרים יכולים לפרסם את אותו /24 רק מפני שה-RD נותן לכל מסלול זהות משלו. התווית עונה על שאלה אחרת: איך להעביר.
שני שוכרים ממספרים את הסניף שלהם באותו 10.50.0.0/24, ולאחר שינוי המסלול של אחד מהם נעלם מקצה הספק ואילו האחר ממשיך לעבוד. הפישוט שמאחורי הפנייה הזו הוא בדרך כלל לוותר על מבדיל המסלול (RD) בטענה ש„התווית כבר מזהה את הלקוח“. היא לא. ה-RD והתווית עונים על שתי שאלות שונות, והפער נהיה גלוי רק כשכתובות חופפות כופות אותו.
מסלול אחד במקום שבו צריכים להיות שניים
IPv4 unicast רגיל משווה שני נתיבים לאותו קידומת ומתקין את הטוב מביניהם. 10.50.0.0/24 משוכר A ו-10.50.0.0/24 משוכר B הם מפתח אחד, ולכן אחד מנצח והשני שורד רק כמסלול גיבוי. הפרוטוקול עשה את מה שנאמר לו; ממישור הבקרה התבקש לאחסן שני מסלולים שונים תחת מזהה אחד.
התוצאה נראית כמו מסלול חסר ולא כמו שגיאה: ה-PE שהפסיד בתחרות עדיין מעביר את השוכר שלו באופן מקומי, ולכן פינג בתוך האתר מצליח והבדיקה בין האתרים נכשלת. ספרו את הרשומות של אותה קידומת בטבלת VPNv4 לפני שנוגעים במדיניות כלשהי.
ה-RD הופך מפתח אחד לשניים
מבדיל מסלול באורך שמונה בייטים מוצמד לפני קידומת IPv4, והאובייקט ש-BGP נושא הופך לכתובת VPN-IPv4 במקום לקידומת IPv4. שני שוכרים יכולים להחזיק באותם 32 ביטים מפני ש-64 הביטים שלפניהם שונים. קיימים סוגי תבנית ל-RD מבוסס AS ול-RD מבוסס כתובת, והבחירה שייכת ל-PE המקורי. RD מבוסס AS נפוץ כשאותם PE חולקים AS, ומבוסס כתובת כשהם לא חולקים.
אל תקראו את ה-RD כתג חברות. יעדי מסלול שולטים בייבוא ובייצוא והם קובעים אילו VRF רשאים להתקין את המסלול; ה-RD רק מבטיח שלמסלול יש זהות משלו. מתן RD נפרד לכל VRF הוא הנוהג הרווח מפני שהוא שומר על המיפוי הזה קריא בכלי צפייה במסלולים.
התווית היא הוראת העברה מקומית
כל פרסום נושא גם תווית MPLS, ומשמעותה מוגבלת לנתב שהקצה אותה. PE אחר עשוי להנפיק את אותו מספר ליעד לא קשור. בדיוק משום כך התווית אינה יכולה למלא את מקום זהות הלקוח: המספר נכון רק לצד הקפיצה הבאה ומצב ההעברה שהתקין אותו.
פירוט ההקצאה משתנה לפי מימוש ותכן: יש פלטפורמות שמקצות תווית אחת לכל VRF, אחרות לכל קידומת, והתווית עשויה לזהות פעולת העברה ולא לקוח. שתי תוויות שונות שמגיעות לאותו יעד אינן סתירה, וגם אותו מספר תווית בשני PE אינו סתירה.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
למה האחד לא יכול להחליף את השני
לקרוא פרסום פירושו להסתכל על ארבעה דברים יחד: הקידומת עם ה-RD, יעדי המסלול, הקפיצה הבאה והתווית. לקרוא חבילת משתמש פירושו להסתכל על המחסנית שהותקנה מאותו מידע. תכן בריא מראה ששני הצדדים תואמים, ותכן שבור בדרך כלל מציג צד אחד נכון והשני מיושן. ההשוואה הזו מפרידה בין בעיית זהות לבעיית העברה.
הניגוד המסודר בין מישור הבקרה למישור הנתונים הוא אמצעי הוראה, לא תיאור של הקידוד. RFC 8277 מציב את התווית בתוך ה-NLRI המתויג, ולכן הפרסום עצמו נושא את הקישור; שימוש בה להעברה הוא השלב המאוחר והנפרד.
כשמסלול של שוכר חסר, בדקו בסדר הזה: שתי רשומות VPNv4 לקידומת, יעד מסלול נכון בכל אחת, קפיצה הבאה שאפשר לפתור, ותווית שלה ל-PE המקבל יש מצב. תיקון זהות בעזרת ערך העברה, או ההפך, יעבור בדיקה אחת וייכשל בשנייה.