لب عملی: پیکربندی تونل‌های Spoke-به-Spoke در DMVPN فاز ۳

هدف لب

گسترش hub پایه DMVPN پیکربندی‌شده در یک لب قبلی برای شامل‌شدن یک spoke دوم، پیکربندی سوئیچینگ shortcut و redirect NHRP روی hub و spoke ها، و تأیید اینکه ترافیک بین دو spoke در ابتدا از میان hub عبور می‌کند اما سپس به یک تونل مستقیم spoke-به-spoke تغییر می‌یابد.

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

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

توپولوژی لب

Hub ---- Tunnel0 (mGRE): 172.16.200.1/24

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

LAN Spoke1: 192.168.11.0/24
LAN Spoke2: 192.168.12.0/24
(هر دو spoke از قبل با hub ثبت شده‌اند
همان‌طور که در لب پایه DMVPN قبلی)

وظیفه ۱: افزودن Spoke2 به ابر DMVPN موجود

اینترفیس تونل Spoke2 را با ثبت NHRP به‌سمت hub، منطبق با پیکربندی موجود Spoke1، پیکربندی کن.

وظیفه ۲: فعال‌کردن NHRP Redirect روی Hub

اینترفیس تونل hub را طوری پیکربندی کن که پیام‌های redirect NHRP را وقتی ترافیک غیربهینه بین دو spoke تشخیص می‌دهد بفرستد.

وظیفه ۳: فعال‌کردن سوئیچینگ Shortcut NHRP روی هر دو Spoke

اینترفیس تونل هر spoke را طوری پیکربندی کن که با ساختن یک تونل shortcut مستقیم روی پیام‌های redirect عمل کند.

وظیفه ۴: تولید ترافیک بین دو LAN Spoke

از LAN Spoke1 به‌سمت LAN Spoke2 ترافیک تولید کن و مسیر اولیه از میان hub را مشاهده کن.

وظیفه ۵: تأیید شکل‌گیری تونل مستقیم Spoke-به-Spoke

پس از اینکه ترافیک اولیه redirect را فعال کرد، تأیید کن ترافیک بعدی به‌جای آن از یک مسیر مستقیم spoke-به-spoke استفاده می‌کند.

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

Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip address 172.16.200.3 255.255.255.0
Spoke2(config-if)# tunnel source gigabitethernet0/1
Spoke2(config-if)# tunnel mode gre multipoint
Spoke2(config-if)# ip nhrp network-id 1
Spoke2(config-if)# ip nhrp nhs 172.16.200.1 nbma [IP عمومی hub]

Hub(config)# interface tunnel0
Hub(config-if)# ip nhrp redirect

-- hub ترافیک عبورکننده از میان خودش را نظارت
-- می‌کند و یک پیام redirect NHRP به spoke منبع
-- می‌فرستد هروقت متوجه شود ترافیک مقصدش شبکه
-- spoke دیگری مسیر طولانی‌تر رله‌شده-توسط-hub
-- را می‌گیرد

Spoke1(config)# interface tunnel0
Spoke1(config-if)# ip nhrp shortcut

Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip nhrp shortcut

-- "shortcut" به هر spoke می‌گوید واقعاً روی یک
-- redirect دریافتی با آغاز حل‌کردن NHRP برای
-- آدرس واقعی spoke دیگر و ساختن یک تونل
-- مستقیم عمل کند

Spoke1-LAN-PC> ping 192.168.12.10

-- بسته‌های اولیه از میان hub عبور می‌کنند:

Hub# show ip nhrp traffic
-- (شمارنده پیام‌های redirect فرستاده‌شده
--  همان‌طور که hub متوجه این مسیر غیربهینه
--  می‌شود افزایش می‌یابد)

Spoke1# show ip nhrp

172.16.200.3/32 via 172.16.200.3
   Tunnel0 created, expire 01:59:50
   Type: dynamic, Flags: router rib nho
   NBMA address: [IP عمومی واقعی Spoke2]
-- یک ورودی NHRP پویای جدید برای Spoke2 ظاهر
-- شد، یادگرفته‌شده از طریق فرآیند حل shortcut
-- به‌جای فقط شناخته‌شدن از طریق hub

Spoke1-LAN-PC> ping 192.168.12.10

-- ترافیک ادامه‌یافته/بعدی اکنون یک مسیر
-- مستقیم spoke-به-spoke می‌گیرد

Spoke1# show ip nhrp shortcut

172.16.200.3/32 via 172.16.200.3
   Tunnel0 created, expire 01:59:20
   Type: shortcut, Flags: router rib
-- صراحتاً به‌عنوان نوع "shortcut" علامت‌گذاری
-- شده، که تأیید می‌کند این یک تونل مستقیم
-- به‌طور پویا برقرار‌شده است نه ترافیکی که
-- همچنان از میان hub رله می‌شود

نکته کلیدی

ip nhrp redirect فاز ۳ DMVPN (پیکربندی‌شده روی hub) و ip nhrp shortcut (پیکربندی‌شده روی spoke ها) به‌عنوان یک جفت منطبق کار می‌کنند — hub ترافیک رله‌شده-توسط-hub ناکارآمد را متوجه می‌شود و یک مسیر بهتر پیشنهاد می‌کند، در حالی که spoke ها واقعاً آن تونل مستقیم را در پاسخ می‌سازند — و این رفتار shortcut دقیقاً چیزی است که فاز ۳ را از DMVPN فقط-hub-and-spoke پایه پیکربندی‌شده در یک لب قبلی متمایز می‌کند، جایی که هر ترافیک بین-spoke برای همیشه مجبور بود از میان hub عبور کند بدون هیچ مکانیزمی برای بهبودش.