DMVPN فاز 3: خواندن میان‌بر در هر دو جهت
یک ping مستقیم به‌تنهایی میان‌بر DMVPN فاز 3 را اثبات نمی‌کند. مسیر رفت و برگشت را طی کنید، سپس حالت NHRP، مسیریابی و IPsec را جداگانه بخوانید.
می‌بینید که یک ping از یک 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 از مبدأ خواسته چه کاری درباره آن انجام دهد. این‌ها واقعیت‌های متفاوتی هستند و hubی با مسیر درست و بدون تغییرمسیر، هر جریان را نامحدود روی مسیر طولانی نگه می‌دارد. رویدادهای NHRP در hub را بررسی کنید و تأیید کنید که برای ترافیک مورد نظر شما تغییرمسیر تولید می‌شود.
فاز 3 معنای خلاصه‌سازی را هم تغییر می‌دهد. با رفتار میان‌بر، spokeها به مجموعه کامل مسیرهای از راه دور مشخص که طراحی فاز 2 انتظار داشت نیاز ندارند، پس مسیر خلاصه‌شده در spoke به‌طور خودکار شبکه گمشده نیست. پیش از خواندن خلاصه به‌عنوان نقص، فاز و سیاست مسیریابی را تأیید کنید.
همین یک سوءتفاهم بیش از هر چیز دیگری تیکت DMVPN ایجاد می‌کند.
نتیجه را به‌عنوان شیء گمشده ثبت کنید
با یک جریان مجاز برنامه و پاسخ آن تمام کنید و برای هر جهت یادداشت کنید که آیا از مسیر مستقیم استفاده کرده است. سپس نتیجه را به‌عنوان شیئی که گمشده بود بنویسید: یک نگاشت، یک میان‌بر هدایت، یک انجمن محافظت، یا یک پاسخ برنامه.
همسایگی مسیریابی و انجمن امنیتی مشترک شواهد سلامت هستند، نه شواهد مسیر. هر دو می‌توانند بی‌عیب باشند در حالی که هر بسته هنوز راه طولانی را دور می‌زند. اول تصمیم هدایت را بررسی کنید، سپس انجمنی که آن را حمل می‌کند. ترتیب مهم است، چون انجمن در هر حال شکل می‌گیرد.
این عادت در تیکت بعدی جبران می‌شود. «تونل بالا است اما کند» تبدیل به «B میان‌بری برای میزبان A ندارد» می‌شود و جمله دوم یک اصلاح پنج‌دقیقه‌ای است. خروجی فرمان را همراه نتیجه نگه دارید و راهنمای فاز 3 فروشنده را کنار آن بگذارید.