מנהרה ללא מספר: איזו כתובת היא שואלת?

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

התייחסו לתורם כאל בחירת תכנון, לא כאל פרט תחבירי.

שלושה תפקידי כתובת, נשמרים בנפרד

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

ההפרדה הזו מסבירה בלבול נפוץ: שאילת כתובת אינה מוסרת את כל מקטע ה-Ethernet של התורם לעמית המרוחק.

בחירת ממשק התורם

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

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

להגדיר ולקרוא את המנהרה חזרה

הדוגמה למטה היא מנהרת GRE רב-נקודתית בנתבים ממשפחת IOS, ששואלת loopback ומפנה את המקור החיצוני שלה לממשק התשתית. זהות NHRP נפרדת מהכתובת המושאלת ויש להגדיר אותה במפורש.

interface Loopback0
 ip address 10.255.255.1 255.255.255.255
interface Tunnel0
 ip unnumbered Loopback0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 ip nhrp network-id 100
! verify
show interfaces Tunnel0 | include line protocol|Tunnel source
show ip interface brief | include Tunnel|Loopback
show ip nhrp

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

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

מה הכתובת המושאלת אינה מספקת

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

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

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