RD מול RT ברשת MPLS VPN: ייחודיות מול מדיניות ייבוא

מבדיל מסלול הופך קידומות חופפות לייחודיות, ומטרת מסלול קובעת אילו מסלולים VRF רשאית לייבא. עקבו אחרי מסלול MPLS אחד דרך שני התפקידים.

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

עקבו אחרי מסלול אחד מקצה הלקוח אל VRF מרוחק והחלוקה הופכת מוחשית: הזהות מוצמדת לפני שהמסלול נכנס ל-BGP, ומדיניות ההפצה נבחנת כשהמסלול מגיע לקצה הספק המקבל.

מסלול VPN-IPv4 הוא RD ועוד קידומת IPv4

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

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

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

ה-RD הופך קידומות חופפות למובחנות

שקלו שני פרסומים לאותה קידומת. אתר A נושא RD 65000:101 ואתר B נושא RD 65000:202, שניהם עבור 10.20.0.0/24. כעת ל-BGP יש שני מסלולי VPN-IPv4 שאפשר להשוות, לסנן ולבחור באופן בלתי תלוי.

ה-RD אינו אומר איזו VRF אמורה לקבל את מי מהמסלולים, והוא אינו מזהה לקוח או שירות. זהו שדה זהות של המסלול, לא רשימת חברות. ה-RD של VRF עצמו אינו חייב להתאים ל-RD של מסלול שהוא מייבא.

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

ה-RT הוא תכונת BGP, לא תגית בחבילה

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

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

מסלול עשוי לשאת כמה RT-ים, ו-VRF עשויה לייבא כמה. הקונפיגורציה נראית לעיתים קרובות כבלוק קצר:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

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

זכאות לייבוא אינה התקנה

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

בדקו את המסלול שנבחר, ולא רק את מדיניות הייבוא. VRF שמייבא RT 65000:500 ואינו מציג מסלול עבור 10.20.0.0/24 אולי קיבל את המסלול ודחה אותו בבחירה, או אולי מעולם לא קיבל אותו.

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

אתרו מסלול חסר לפי סדר מישור הבקרה

התחילו מהפרסום: האם VRF המקור מייצא את ה-RT הרצוי, והאם המסלול קיים כמסלול VPN-IPv4 במוביל המסלולים או ב-PE המקבל? לאחר מכן בדקו את התכונה כפי שהתקבלה, ולא כפי שהוגדרה אצל השולח.

בשלב הבא השוו את רשימת הייבוא של ה-VRF המקבל לערכי ה-RT בפועל של המסלול. לבסוף בדקו את המסלול שנבחר באותה VRF ואת כריכת התגית. כל שלב עונה על שאלה אחרת, וקפיצה ל-RD מדלגת בדרך כלל דווקא על השלב השגוי.

רשמו את ה-RD, את ה-RT המיוצא, את ה-RT המיובא ואת הקפיצה הבאה שנבחרה עבור האתר שעובד והאתר שנכשל. ארבעה ערכים זה לצד זה הופכים אמירה מעורפלת כמו “ה-VPN לא מעביר מסלולים” לשלב המדויק במישור הבקרה ששונה.

מאמרים קשורים