סוג נתיב OSPF דרך VPN: לא תמיד חיצוני

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

מודל PE-CE נושא די הקשר כדי שה-PE המקבל יוכל לשחזר הודעת OSPF במקום להמציא אותה.

מה נוסע עם הנתיב

RFC 4577 מגדיר את תכונות ה-OSPF שמלוות נתיב VPN: מזהה התחום, המטריקה וסוג הנתיב מהאתר המקורי. ה-PE המקבל משתמש בהן כדי להחליט כיצד קידומת מתאימה אמורה להיראות לתהליך ה-OSPF המקומי שלו. בלי התכונות האלה לא היה ל-PE המרוחק שום בסיס לשום דבר מלבד חלוקה מחדש חיצונית. לכן נתיב יכול להגיע כ-LSA בין-אזורי למרות ש-BGP נשא אותו בדרך.

גם סוג האזור חשוב. אזור stub או NSSA מגביל אילו LSA-ים רשאים להיכנס, כך שאותו נתיב VPN יכול להיות מוצג אחרת בהתאם למקום שבו נמצאת מופע ה-OSPF המקבל. מדיניות ייצוא מוגדרת יכולה גם היא לעקוף את ההצגה המוגדרת כברירת מחדל, וזו בחירה מכוונת ולא תופעת לוואי.

אותו תחום, הצגה אחרת

נתיב בתוך אזור או בין אזורים מאותו תחום מגיע בדרך כלל לאתר המרוחק כנתיב בין-אזורי, LSA מסוג 3. קידומת מתחום אחר, מקור שמעולם לא דיבר OSPF או הודעת OSPF חיצונית מלכתחילה הולכים במקום זאת לפי הכללים החיצוניים, ושם מופיעים סוג 5 והמקבילה שלו ב-NSSA. שתי ההתנהגויות נכונות; הקלט שונה. השוו מזהי תחום ותכונות מוכרזות לפני שנוגעים בערכי העדפה.

המרחק הניהולי בוחר בין מקורות בנתב אחד. הוא אינו כותב מחדש סוג LSA ואינו יוצר את יחסי התחום החסרים.

מתי sham link הוא התשובה הנכונה

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

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

אל תשברו את הגנת הלולאה

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

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

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