שכני EIGRP לא עולים במעטפת DMVPN

unicast מעל המעטפת עובד והסמיכות עדיין נכשלת, לכן בדקו שכפול multicast של NHRP, את מדיניות EIGRP של המנהרה ואת IPsec כשלוש שכבות נפרדות.

המנהרה למעלה, spoke אחד יכול לעשות ping לאחר, ו־EIGRP עדיין לא מציג שום שכן ב־hub. השילוב הזה נורמלי ולא מסתורי: ping מוכיח נגישות unicast דרך NHRP, וה־hello של EIGRP הם multicast. במעטפת DMVPN מודל המסירה של פרוטוקול הניתוב הוא משטח תצורה שני, ובדיוק אותו אנשים מדלגים כי המשטח הראשון כבר נראה בריא. כל שכבה למטה נבדקת בפקודה משלה, כך שכשל בשכבה אחת לא מחזיר אתכם לראש הרשימה.

רשמו את הסמיכויות שאתם מצפים להן

לפני כל פקודת show, הכינו רשימה קצרה: איזה spoke צריך להתחבר לאיזה hub, דרך איזה ממשק מנהרה, ובאיזו מערכת אוטונומית של EIGRP. תכנונים עם כמה hubs נכשלים ברווחים שבין ה־hubs, ורשימה הופכת את «EIGRP שבור» ל«spoke 3 לא נרשם ב־hub 2». כללו את תתי־הרשתות של המנהרה שאתם מצפים להן בכל קישור, כי אי־התאמה בכתובות בין שני הקצוות נראית בדיוק כמו כשל פרוטוקול. כתבו את הרשימה בכרטיס, כדי שהמשמרת הבאה תשווה לתכנון ולא לצילום המסך האחרון.

בדקו NHRP, ואחר כך את נתיב ה־multicast

התחילו במצב הרישום ובמיפויים שה־hub באמת מחזיק. spoke בלי רשומה דינמית ב־hub לא נרשם, ואף פרוטוקול ניתוב לא יתקן זאת. אחר כך ודאו שה־spoke מקבל multicast מכתובת ה־NBMA של ה־hub, שזו שורה נפרדת מרשומת ה־NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

השורה ip nhrp map multicast היא זו שמאפשרת ל־spoke לשלוח את ה־hello שלו ל־hub כ־multicast משוכפל מעל המעטפת, וזו שמאפשרת ל־multicast של ה־hub להגיע ל־spokes שהוא רשם. בלעדיה unicast דרך NHRP עובד ו־multicast לא, וזה בדיוק הפיצול שגורם ל־ping להיראות כהוכחה. המדריך של Cisco IOS XE DMVPN מתעד את התנהגות ה־multicast של ה־hub וה־spokes לכל שלב, אז התאימו את התצורה שלכם לשלב שבאמת פרסתם ולא להעתקת קטע מטופולוגיה אחרת.

בדקו את מדיניות הממשק של EIGRP עצמו

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

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

האימות ומשקולות המדד חייבים להתאים בשני הקצוות. שרשרת מפתחות במצב שגוי, או אי־התאמה בערך K, מפילה hello בלי שורת syslog ברורה אצל המקבל. אם התכנון משתמש בשכני unicast שהוגדרו במפורש, פעלו לפי המודל הזה במלואו במקום להעמיס אותו על הגדרות multicast עד שמשהו יעלה.

הפרידו בין נשיאת GRE להגנת IPsec

DMVPN נושא multicast בתוך GRE, ו־IPsec מגן על חבילות ה־GRE ולא על ה־multicast הפנימי ישירות. לכן הקביעה הגורפת ש־IPsec אינו יכול לשאת multicast שגויה בתכנון הזה וחסרת תועלת כאבחון. בדקו את פרופיל ה־IPsec במנהרה, את אסוציאציות האבטחה לכל peer ואת מצב ממשק המנהרה כשלוש עובדות נפרדות.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

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

אמתו נתיבים, לא רק מספר שכנים

לאחר שהסמיכות נוצרת, קראו מה היא מכריזה ומתקינה. במנהרת ריבוי נקודות, split horizon והתנהגות next-hop קובעים אם spoke יכול להגיע ל־spoke אחר דרך ה־hub, וסיכום יכול להסתיר prefix גם כשקשר השכנות מושלם.

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

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

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