هاب DMVPN نام‌دار در برابر شماره‌دار: FQDN چه چیزی را تغییر می‌دهد

یک spoke در DMVPN می‌تواند هاب خود را با نام میزبان روی پلتفرم‌هایی که این ویژگی را پشتیبانی می‌کنند پیدا کند، و نخستین وسوسه این است که آن نام میزبان را راه دیگری برای نوشتن نشانی تونل هاب بخوانیم. این‌گونه نیست. نام به یک نقطه پایانی انتقال حل می‌شود، در حالی که نشانی پروتکل هاب گام بعدی درون overlay را مشخص می‌کند، و هر دو نقش در هر شکل پیکربندی باقی می‌مانند. همین تمایز تعیین می‌کند که تغییر نام چه چیزی را می‌تواند اصلاح کند و چه چیزی را نه.

دو نشانی، دو وظیفه

در یک مثال اعلام‌شده، hub.example.net به spoke می‌گوید ترافیک انتقال را کجا بفرستد، و 10.90.0.1 خادم NHS را درون تونل مشخص می‌کند. کشف روی اولی کار می‌کند؛ ثبت و مسیریابی روی دومی. تغییر نام بر مسیر تا نقطه پایانی اثر می‌گذارد، در حالی که تغییر نشانی پروتکل بر خود رابطه overlay اثر می‌گذارد.

جدا نگه داشتن نقش‌ها همان چیزی است که شکل نام‌دار را قابل اشکال‌زدایی می‌کند. وقتی یک spoke نمی‌تواند ثبت شود، می‌توانید دو پرسش متفاوت بپرسید: آیا نام به نشانی‌ای که انتظار داشتم حل شد، و آیا آن نشانی با نشانی پروتکلی که پیکربندی ادعا می‌کند مطابقت داشت؟ هیچ‌کدام از دو پاسخ دیگری را ایجاب نمی‌کند.

دو شکل پیکربندی را مقایسه کنید

یک شکل نشانی پروتکل NHS را به‌صراحت در کنار نام پیکربندی می‌کند. شکل دیگر به spoke اجازه می‌دهد آن نشانی پروتکل را از پاسخ ثبت بیاموزد. هر دو مستند شده‌اند و هر دو هنگام موفقیت به همان نوع رابطه NHS ختم می‌شوند.

شکل صریح محدودیتی دارد که به یاد سپردنش می‌ارزد: نشانی انتقال حل‌شده‌ای که به نشانی پروتکل پیکربندی‌شده نگاشت نشود، از ثبت جلوگیری می‌کند. این خرابی DNS نیست، هرچند نشانه بلافاصله پس از تغییر DNS ظاهر می‌شود. نام درست حل شد و نتیجه به دلیل دیگری رد شد. نشانی حل‌شده و نشانی پروتکل پیکربندی‌شده را کنار هم بخوانید.

شکل یادگیری یک گام دستی و یک منبع رانش را حذف می‌کند، به بهای وابستگی به پاسخ برای برقراری نگاشت. وقتی نشانی هاب پایدار است و می‌خواهید ناسازگاری بلند و آشکار شکست بخورد، شکل صریح را انتخاب کنید. وقتی نشانی پروتکل هاب ممکن است تغییر کند و ترجیح می‌دهید spoke از آن پیروی کند، شکل یادگیری را انتخاب کنید. در هر حال ثبت کنید که طراحی از کدام شکل استفاده می‌کند.

کش DNS را با هاب ایستا مقایسه کنید

نشانی هاب ایستا وقتی کسی پیکربندی را ویرایش می‌کند تغییر می‌کند. هاب نام‌دار وقتی DNS تغییر می‌کند تغییر می‌کند، و پاسخ‌های DNS برای طول عمرشان کش می‌شوند. مستندات خاطرنشان می‌کند که اطلاعات کش‌شده تا زمان انقضا قابل استفاده می‌ماند، و پرس‌وجوی بعدی می‌تواند نشانی جدید را برگرداند.

این تفاوت، تفاوت زمان‌بندی است، نه مهاجرت آنی. طول عمر کش بلند، پذیرش یک نقطه پایانی تغییرنام‌یافته را به تأخیر می‌اندازد، و اگر فقط رکورد DNS را تماشا کنید این تأخیر نامرئی است. تغییر نام را حول طول عمر کش و رفتار ثبت نسخه نصب‌شده برنامه‌ریزی کنید، نه با فرض اینکه هر تونل هم‌زمان جابه‌جا می‌شود.

شکل ایستا البته تأخیر خودش را دارد: تا هر spoke ویرایش نشود چیزی تغییر نمی‌کند. مقایسه میان یک فشار پیکربندی هماهنگ‌شده و یک تازه‌سازی کشف کش‌شده است، نه میان کند و آنی.

مقایسه کنید چه چیزی ثابت می‌ماند

احراز هویت همتا جابه‌جا نمی‌شود. نام میزبانی که نقطه پایانی انتقال را پیدا می‌کند، جای هویت IKE پیکربندی‌شده یا سیاست احراز هویتی که همتا را اعتبارسنجی می‌کند را نمی‌گیرد. اگر هویت اشتباه باشد، حل موفق DNS فقط شما را سریع‌تر به تونلی ردشده می‌رساند.

ترافیک محافظت‌شده نیز تغییر نکرده است. NHS پاسخ‌دهنده اثبات نمی‌کند که مسیر مشتری وجود دارد یا جریان برنامه مجاز است. ثبت، مسیریابی و سیاست سه بررسی‌اند، و نام فقط بر نخستین گامی که آن‌ها را تغذیه می‌کند اثر می‌گذارد.

مقایسه‌ای که می‌توانید بررسی کنید

Cisco مشاهدات جداگانه‌ای برای نشست و رابطه NHS مستند می‌کند. از show dmvpn برای خواندن وضعیت همتا و نشست و از show ip nhrp nhs برای خواندن نمای ثبت NHS استفاده کنید. نشانی انتقال حل‌شده، همتای overlay و وضعیت ثبت را به همین ترتیب مقایسه کنید.

فصل IOS XE FQDN-DMVPN رفتار کشف، کش و محدودیت را در پس این مقایسه مستند می‌کند. آن را در برابر نسخه نصب‌شده خود بخوانید پیش از آنکه هاب تغییرنام‌یافته را جایگزین مستقیم هاب شماره‌دار بدانید.