מעבר WAN ב-DMVPN: מדיניות ניתוב או לכבות את המנהרה?

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

ההחלטה באה לפני התצורה

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

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

רשמו את התשובה, כי התצורה היא החלק הקל.

מה מדיניות הניתוב באמת משנה

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

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

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

מה כיבוי המנהרה משנה

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

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

פקודת שחזור מקודדת קשיח יכולה גם לעקוף כיבוי תחזוקה שמישהו אחר ביצע.

גרמו לבדיקה לנסוע בנתיב שאתם חושבים

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

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

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

החליטו על שחזור, ואז אמתו

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

אם המעבר עובד אבל היישום עדיין נשבר, הבעיה נמצאת מעל שכבת הניתוב ושום כמות של מעקב לא תתקן אותה.

שמרו את הראיות מאותו חלון, כי השינוי הבא יושווה אליהן.