ממסלול CE RIP אל VRF מרוחק: היכן מתרחש הייצוא

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

מה ה-PE עושה עם עדכון RIP

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

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

ייצוא הוא מעשה מדיניות, לא תוצאה של פרוטוקול

כדי לצאת מה-VRF, מסלול חייב להיות מופץ מחדש אל תהליך ה-MP-BGP שנושא מסלולי VPN, והוא זקוק לקהילה מורחבת של יעד מסלול שמזהה אילו VRF מרוחקים רשאים לייבא אותו. הארכיטקטורה ב-RFC 4364 שומרת על החלפות אלה נפרדות מהפרוטוקול CE-אל-PE בדיוק מהסיבה הזו. שימוש ב-RIP בקצה אינו אומר דבר על מה שאמור לחצות את רשת הספק.

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

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

הפצה מחדש ויצירה מפורשת מתנהגות אחרת

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

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

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

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

אמתו את השרשרת בארבעה מקומות

הביטו בהכרזת ה-CE, בטבלת הניתוב של ה-VRF, בטבלת מסלולי ה-VPN עם יעד המסלול שלה, ובייבוא ל-VRF המרוחק, בסדר הזה. ב-IOS זה אומר פלט השכן של ה-CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, ואותה פקודה ב-PE המרוחק. ב-IOS-XR הפלט המקביל נמצא תחת show bgp vrf CUSTOMER ipv4 unicast. שמות הפקודות שונים, ארבע נקודות הבדיקה לא.

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

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