لب عملی: پیکربندی DMVPN دو-Hub برای افزونگی

این لب عملی توپولوژی DMVPN فاز ۳ از لب قبلی را با یک hub دوم گسترش می‌دهد، هر spoke را طوری پیکربندی می‌کند که هم‌زمان با هر دو hub ثبت شود، و failover خودکار وقتی hub اصلی غیرقابل‌دسترسی می‌شود را تأیید می‌کند.

DMVPN دو-Hubپیکربندی NHS چندگانهFailover افزونگی Hub

~4 min read · Updated Sep 26, 2026

هدف لب

افزودن یک hub دوم به ابر DMVPN موجود، پیکربندی هر spoke با هر دو hub به‌عنوان سرورهای گام-بعدی NHRP، تأیید ثبت‌شدن spoke ها با هر دو هم‌زمان، و تأیید اینکه ترافیک به‌طور خودکار از طریق hub ثانویه وقتی اصلی غیرقابل‌دسترسی می‌شود ادامه می‌یابد.

هدف لب (چرا مهم است)

توپولوژی تک-hub استفاده‌شده در سراسر لب‌های DMVPN قبلی در این مجموعه یک ضعف بدیهی دارد: hub یک نقطه شکست واحد برای کل overlay است. پیکربندی هر spoke با چند ورودی NHS اجازه افزونگی واقعی hub می‌دهد، یک ملاحظه طراحی ضروری برای هر استقرار DMVPN تولیدی.

توپولوژی لب

Hub1 ---- Tunnel0: 172.16.200.1/24 (اصلی)
Hub2 ---- Tunnel0: 172.16.200.4/24 (ثانویه)

Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24

هر دو hub دسترس‌پذیری به همان زیرشبکه‌های
LAN spoke را از طریق یک پروتکل مسیریابی در
حال اجرا روی تونل تبلیغ می‌کنند

وظیفه ۱: پیکربندی Hub2 به‌عنوان یک Hub دوم

اینترفیس تونل Hub2 را از نظر ساختاری یکسان با Hub1 پیکربندی کن، و به همان ابر DMVPN بپیوندد.

وظیفه ۲: پیکربندی هر Spoke با هر دو Hub به‌عنوان NHS

یک عبارت دوم ip nhrp nhs روی هر spoke که به Hub2 اشاره می‌کند، در کنار عبارت موجود برای Hub1، اضافه کن.

وظیفه ۳: تأیید ثبت‌شدن هر دو Spoke با هر دو Hub

تأیید کن کش NHRP هر hub هر دو spoke را ثبت‌شده نشان می‌دهد.

وظیفه ۴: تأیید جریان معمولی ترافیک از طریق Hub اصلی

تأیید کن ترافیک spoke-به-spoke یا spoke-به-hub در حال حاضر Hub1 را بر اساس معیارهای مسیریابی ترجیح می‌دهد.

وظیفه ۵: شبیه‌سازی شکست Hub1 و تأیید Failover به Hub2

اینترفیس تونل Hub1 را خاموش کن و تأیید کن spoke ها بدون مداخله دستی از طریق Hub2 به عملیات ادامه می‌دهند.

راه‌حل و تأیید

Hub2(config)# interface tunnel0
Hub2(config-if)# ip address 172.16.200.4 255.255.255.0
Hub2(config-if)# tunnel source gigabitethernet0/1
Hub2(config-if)# tunnel mode gre multipoint
Hub2(config-if)# ip nhrp network-id 1
Hub2(config-if)# ip nhrp redirect

Spoke1(config)# interface tunnel0
Spoke1(config-if)# ip nhrp nhs 172.16.200.4 nbma [IP عمومی Hub2]

Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip nhrp nhs 172.16.200.4 nbma [IP عمومی Hub2]

-- هر spoke اکنون دو عبارت nhs دارد -- یکی
-- به‌ازای هر hub -- و مستقلاً با هر دو ثبت
-- خواهد شد

Hub1# show ip nhrp | include Tunnel0
172.16.200.2/32 via 172.16.200.2 ... Tunnel0
172.16.200.3/32 via 172.16.200.3 ... Tunnel0

Hub2# show ip nhrp | include Tunnel0
172.16.200.2/32 via 172.16.200.2 ... Tunnel0
172.16.200.3/32 via 172.16.200.3 ... Tunnel0
-- هر دو hub به‌طور مستقل هر دو spoke را
-- ثبت‌شده نشان می‌دهند، و ثبت دوگانه موفق را
-- تأیید می‌کنند

Spoke1# show ip route 192.168.12.0

O    192.168.12.0/24 [110/65] via 172.16.200.1
-- Hub1 در حال حاضر بر اساس معیار پروتکل
-- مسیریابی ترجیح داده می‌شود

Hub1(config)# interface tunnel0
Hub1(config-if)# shutdown

Spoke1# show ip route 192.168.12.0

O    192.168.12.0/24 [110/65] via 172.16.200.4
-- پروتکل مسیریابی به‌طور خودکار دوباره همگرا
-- شد تا Hub2 را وقتی Hub1 غیرقابل‌دسترسی شد
-- ترجیح دهد، بدون نیاز به بازپیکربندی دستی
-- روی هیچ spoke

Spoke1-LAN-PC> ping 192.168.12.10

!!!!!
Success rate is 100 percent (5/5)
-- اتصال بین LAN های spoke با وجود شکست Hub1
-- کاملاً عملکردی باقی می‌ماند

نکته کلیدی

افزونگی DMVPN دو-hub به دو لایه مستقل که با هم کار می‌کنند تکیه دارد: ثبت NHRP به چند ورودی NHS تضمین می‌کند هر spoke اطلاعات نگاشت را با هر دو hub هم‌زمان نگه می‌دارد، در حالی که یک پروتکل مسیریابی پویا در حال اجرا روی تونل تصمیم failover واقعی را بر اساس مقایسه معیار استاندارد مدیریت می‌کند — خود DMVPN تصمیم نمی‌گیرد کدام hub "فعال" است، صرفاً اتصال overlay را فراهم می‌کند که پروتکل مسیریابی سپس از آن برای گرفتن آن تصمیم دقیقاً همان‌طور که در سراسر هر مجموعه دیگری از لینک‌های افزونه انجام می‌داد استفاده می‌کند.

Written & researched by Dr. Shahin Siami

Related Articles

لب عملی: چالش عیب‌یابی جامع نهایی CCNP (یکپارچگی BGP، DMVPN، و QoS)

این لب عملی یک شکست پیچیده چندلایه در سراسر یک توپولوژی یکپارچه BGP-روی-DMVPN ترکیب‌شده با علامت‌گذاری QoS ارائه می‌دهد، و نیازمند تشخیص سیستماتیک یک پیکربندی نادرست route reflector، یک شکست ثبت NHRP، و یک سیاست QoS نادرست‌اعمال‌شده که هم‌زمان روی همان شبکه تأثیر می‌گذارند است.

Continue

لب عملی: پیکربندی BGP روی DMVPN

این لب عملی iBGP را به‌عنوان پروتکل مسیریابی در سراسر همان توپولوژی hub-and-spoke DMVPN استفاده‌شده در دو لب قبلی اجرا می‌کند، hub را به‌عنوان یک route reflector BGP پیکربندی می‌کند طوری‌که spoke ها مسیرهای یکدیگر را بدون یک mesh کامل iBGP یاد بگیرند، و دو مفهوم قبلاً جداگانه را در یک طراحی یکپارچه ترکیب می‌کند.

Continue

لب عملی: پیکربندی OSPF روی DMVPN

این لب عملی OSPF را به‌عنوان پروتکل مسیریابی پویا در سراسر همان توپولوژی hub-and-spoke DMVPN اجرا می‌کند، و اینترفیس تونل را به‌عنوان یک نوع شبکه OSPF point-to-multipoint پیکربندی می‌کند تا الگوی همسایگی hub-and-spoke را به‌درستی بدون نیاز به انتخاب DR/BDR نوع شبکه broadcast مدیریت کند.

Continue

لب عملی: پیکربندی EIGRP روی DMVPN

این لب عملی EIGRP را به‌عنوان پروتکل مسیریابی پویا در سراسر توپولوژی hub-and-spoke DMVPN ساخته‌شده در لب‌های قبلی اجرا می‌کند، و تأیید می‌کند روابط همسایه به‌درستی در سراسر تونل چندنقطه‌ای شکل می‌گیرند و مسیرها بدون نیاز به پیکربندی ایستای هر-spoke روی hub منتشر می‌شوند.

Continue

لب عملی: پیکربندی احراز هویت MD5 در HSRP

این لب عملی احراز هویت MD5 را روی یک گروه HSRP پیکربندی می‌کند، و تأیید می‌کند دو روتر با رشته‌های احراز هویت منطبق یک رابطه active/standby معمولی تشکیل می‌دهند در حالی که یک روتر با رشته نامنطبق کاملاً از گروه مستثنی می‌شود.

Continue

لب عملی: پیکربندی امنیت DNS به‌سبک-Cisco Umbrella از طریق تغییرمسیر Forwarding DNS

این لب عملی یک روتر را برای رهگیری هر پرس‌وجوی DNS کلاینت و تغییرمسیر آن به‌سمت یک resolver DNS امنیت-محور با استفاده از رهگیری forwarding DNS پیکربندی می‌کند، و اعمال امنیت DNS تحویل‌شده-با-ابر را بدون نیاز به تغییرات پیکربندی به‌ازای-هر-کلاینت تقریب می‌زند.

Continue