DMVPN שלב 3: קריאת הקיצור בשני הכיוונים
פינג ישיר אחד אינו מוכיח קיצור ב-DMVPN שלב 3. עברו את מסלול ההלוך והחזור, ואז קראו בנפרד את מצב NHRP, הניתוב ו-IPsec.
אתם רואים פינג אחד עובר מ-spoke ל-spoke, הוא הולך בדרך הארוכה דרך ה-hub, והשני עובר ישירות. מפתה להכריז שהקיצור עובד בנקודה הזו. המסקנה הזו חצי נכונה. מסלול ההלוך יכול להיות קיצור בעוד מסלול החזור עדיין עובר דרך ה-hub, והמצב שמוכיח כל כיוון הוא מצב אחר. עברו את שני הכיוונים וקראו שלוש טבלאות לפני שתקבלו את התכנון כבריא.
התחילו במסלול החבילה שאתם באמת רואים
התחילו ב-spoke עם יעד שאמור להיות ישיר. עקבו אחרי החבילה הראשונה: היא עוקבת אחרי הנתיב של ה-spoke לכיוון ה-hub, כי עדיין אין קיצור. ה-hub מעביר אותה הלאה ובתכנון שלב 3 גם שולח הפניה למקור שאומר שיש מסלול טוב יותר.
ההפניה הזו היא הטריגר, לא ההוכחה. היא אומרת שה-hub ראה תעבורה שאפשר לייעל. היא לא אומרת שהמקור בנה את הקיצור, שהיעד ענה לפתרון, או שמסלול התשובה משתמש בו.
אז התצפית השימושית הראשונה היא לפני ואחרי: הזרימה הראשונה דרך ה-hub, הזרימה המאוחרת ישירות.
שלושה מצבים שנראים כמו מנהרה אחת
הקיצור תלוי בשלושה חלקי מצב, ולכל אחד יש אורך חיים משלו ופקודה משלו.
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
רשומת מטמון NHRP ממפה כתובת overlay לכתובת תעבורה NBMA. נתיב או קיצור קובע לאן מועבר יעד פנימי אחד. אגודת IPsec מגנה על כל תעבורה שתיווצר. תשובה חסרה יכולה לבוא מכל אחד מהשלושה, והפקודות אומרות לכם איזה מהם חסר.
קראו אותם בסדר הזה, כי מיפוי חסר הופך את השניים האחרים ללא מעניינים.
עברו את הבקשה והתשובה בנפרד
מ-spoke A בקשו את הפתרון וראו מה חוזר. הבקשה עוברת במסלול ההעברה הנתמך של NHRP, והיעד יכול לענות ישירות במקום דרך ה-hub. האסימטריה הזו רגילה, ולכן התשובה היא החצי המעניין של החליפין.
כעת הפכו את התפקידים. שלחו מ-B ל-A וחזרו על אותן שלוש קריאות. תכנון שעושה קיצור בכיוון אחד ולא בשני אינו סימטרי, והאסימטריה מגיעה בדרך כלל מקידומת חסרה בצד אחד או מפתרון שמעולם לא קיבל תשובה.
התשובה של העמית לא חייבת לעבור דרך ה-hub רק מפני שהבקשה עברה. אל תקראו בזה שגיאה ואל תתחילו לרדוף אחרי תקלת ניתוב שאינה קיימת.
קראו את ההפניה של ה-hub, לא רק את הנתיב שלו
טבלת הנתיבים של ה-hub אומרת לכם לאן ה-hub היה שולח חבילה. ההפניה אומרת לכם מה ה-hub ביקש מהמקור לעשות בנידון. אלה עובדות שונות, ו-hub עם נתיב נכון ובלי הפניות יחזיק כל זרימה במסלול הארוך ללא הגבלה. בדקו את אירועי ה-NHRP של ה-hub וודאו שמופקות הפניות לתעבורה שמעניינת אתכם.
שלב 3 משנה גם את משמעות הסיכום. עם התנהגות קיצור, spokes לא צריכים את הסט המלא של נתיבים מרוחקים ספציפיים שתכנון שלב 2 ציפה לו, ולכן נתיב מסוכם ב-spoke אינו אוטומטית רשת חסרה. ודאו את השלב ואת מדיניות הניתוב לפני שאתם קוראים לסיכום תקלה.
אי ההבנה האחד הזה יוצר יותר קריאות DMVPN מכל דבר אחר.
רשמו את המסקנה כאובייקט חסר
סיימו בזרימת אפליקציה מורשית והתשובה שלה, וציינו לכל כיוון אם השתמש במסלול הישיר. אחר כך כתבו את המסקנה כאובייקט שהיה חסר: מיפוי, קיצור העברה, אגודת הגנה או תגובת אפליקציה.
שכנות ניתוב ואגודת אבטחה משותפת הם עדות לבריאות, לא עדות למסלול. שניהם יכולים להיות מושלמים בעוד כל חבילה עדיין עושה את הסיבוב הארוך. בדקו קודם את החלטת ההעברה, ואחר כך את האגודה שנושאת אותה. הסדר חשוב, כי האגודה נוצרת בכל מקרה.
ההרגל הזה משתלם בקריאה הבאה. «המנהרה למעלה אבל איטית» הופך ל«ל-B אין קיצור למארח של A», והמשפט השני הוא תיקון של חמש דקות. שמרו את פלט הפקודות עם המסקנה, ושמרו את מדריך שלב 3 של הספק לצידו.