ניתוב סניפים ב-MPLS: מה ה-CE לומד וממי

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

מעקב אחרי חבילה אחת לאורך המסלול הוא הדרך המהירה ביותר לראות איזה חלק הוא באחריות הלקוח ואיזה חלק שייך לשירות.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

היכן נגמרת העבודה של כל קפיצה

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

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

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

על מה המסירה חייבת להסכים

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

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

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

אמתו את שתי המסירות לפני אישור

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

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

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

דעו מה השירות אינו מספק

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

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

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