מדוע נתיב תת-רשת ב-AWS VGW אינו יכול לבחור מנהרת VPN אחת

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

שתי שכבות נמצאות במשחק: נתיב ה-VPC שאומר איזה שער, ובחירת המנהרה של השער עצמו. ערבוב ביניהם מייצר עריכות שנראות נכונות בטבלת הנתיבים ולעולם אינן מזיזות חבילה.

שתי שכבות שנראות כאחת

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

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

מה VGW באמת משווה

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

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

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

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

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

נתיבים סטטיים מתעלמים מכל הטיעון

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

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

מדוע שער מעבר הוא תשובה אחרת

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

בחרו את המודל לפני המנגנון: פעיל וגיבוי עם העדפה מקובעת, או פעיל ופעיל עם ECMP.

מה לאמת לאחר שהגדרתם

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

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