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

התסמין: תעבורת spoke ישירה חזרה ל-hub

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

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

צבירה אחת, שתי טבלאות

שתי הפעולות נראות כך:

OperationWhat it actually changes
Routing summaryAggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs
NHRP summary mapChanges the network returned in a resolution reply, so a requesting spoke resolves to a different address
Protection pathIPsec state for the peer you actually resolved; neither aggregation changes it

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

אף אחת מהפעולות אינה הצהרה על מסלול ההגנה, משום שהוא מנוהל במשא ומתן עבור ה-peer שאותו פתרת בפועל.

מה הסיכום ב-hub באמת משנה

המדריך של Cisco למפות סיכום NHRP בין spokes מתאר סידור Phase 3 שבו ה-hub מפרסם סיכום ונשאר הקפיצה הבאה בניתוב. הפניה מחדש ופתרון NHRP שלאחריה מספקים אז מסלול העברה ישיר יותר. לכן קריאה של המסלול המצובר בלבד אינה מתארת את כל מצב ההעברה, והיא אינה אומרת שכל מנה חייבת לעבור דרך ה-hub לנצח. הסיכום עוסק בנגישות, לא במסלול.

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

אם אינך יכול לומר איזה משלושת אלה השתנה, לא סיימת את השינוי.

מה מפת סיכום NHRP משנה

קח spoke שמחזיק ב-10.32.0.0/19 דרך כמה מסלולי LAN ספציפיים יותר, בעוד ה-hub מפרסם צבירה גדולה יותר לשאר ה-spokes. בקשה ל-10.32.12.10 הייתה מקבלת אחרת מידע פתרון עבור הרשת הקטנה המתאימה. תכונת מפת סיכום NHRP המתועדת מאפשרת ל-spoke להחזיר במקום זאת את קידומת הכיסוי שהוגדרה אצלו, מה שיכול להפחית עבודת פתרון חוזרת עבור רשתות השייכות לאותו spoke. היא אינה הופכת את סיכום המסלולים של ה-hub ואת סיכום הפתרון של ה-spoke לאותו אובייקט.

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

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

השווה את היעד הראשון ואחד בתוך הסיכום

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

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

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

מאמרים קשורים