در بخش قبل طراحی و پیاده سازی DMVPN phase 2 و البته مزایا و معایب آن را مورد بررسی قرار دادیم. DMVPN phase 3 مزایای DMVPN phase 1 و DMVPN phase 2 را به یکجا در کنار یکدیگر قرار می دهد. در صورت وجود ویژگی DMVPN phase 3 دلیلی به استفاده از DMVPN phase 2 وجود ندارد.
در ذیل به مزایای DMVPN phase 3 اشاره شده است:
- DMVPN phase 3 همانند DMVPN phase 2 از مدل Spoke-to-Spoke تبعیت می کند. بنابراین ترافیک بین Spoke ها از Hub عبور نمی کند. اگر بدلیل مسائل امنیتی لازم باشد تا ترافیک بین Spoke ها از Hub عبور کند، حتما باید از DMVPN phase 1 استفاده کنید.
- در DMVPN phase 3 همانند DMVPN phase 1 کافی است تا فقط یک مسیر default و یا summary که آدرس next-hop آن روتر Hub است، به روترهای Spoke ارسال شود و به همین دلیل لازم نیست تا روترهای Spoke مسیر شبکه های متصل به دیگر روترهای Spoke را به تفکیک در جدول مسیریابی نگه دارند. بدیهی است که این موضوع می تواند به مقیاس پذیری DMVPN کمک کند. اینکه چرا DMVPN phase 3 چنین قابلیتی دارد را در ادامه بررسی خواهیم کرد.
- آدرس next-hop در روترهای Spoke همواره به روتر Hub اشاره می کند که نگاشت بین آدرس تونل و آدرس فیزیکی ان قبلا در روتر Spoke تعریف شده است. بنابراین جدول adjacency در مکانیزم CEF کامل است و حتی اولین بسته ارسالی بین هر دو روتر Spoke با مکانیزم CEF ارسال می شود.
- امکان پیاده سازی DMVPN phase 3 به صورت سلسله مراتبی وجود دارد بدون آنکه ترافیک بین روترهای Spoke از روترهای Hub محلی عبور نمایند. همانطور که قبلا دیدیم، قابلیت پیاده سازی DMVN به صورت سلسله مراتبی در DMVPN Phase 2 وجود ندارد. چگونگی پیاده سازی DMVPN phase 3 به صورت سلسله مراتبی را در ادامه مورد بررسی قرار خواهیم داد.
حتما این سوال اساسی در ذهن شما ایجاد می شود که DMVPN phase 3 چگونه کار می کند. در ادامه با توجه به شکل زیر DMVPN phase 3 را تحلیل و بررسی می کنیم.
پیاده سازی DMVPN phase 3
خواهیم دید که در DMVPN phase 3، برخلاف دو فاز قبلی که روتر HUB مسئول پاسخ به درخواست های nhrp است، خود روترهای Spoke درخواست های nhrp را پاسخ می دهند. بنابراین نقش روتر Hub به عنوان تنها منبع پاسخ به درخواست های nhrp کاهش می یابد.
پروسه DMVPN phase 3 به شرح ذیل است:
- روی روترهای Spoke مسیر default و یا summary به آدرس اینترفیس تونل روتر Hub اشاره می کند. بنابراین روتر Spoke ترافیک های به مقصد هر یک از Spoke ها را به Hub تحویل می دهد. در شکل فوق اگر ترافیکی از مبدا 1.1.1 به مقصد 2.2.2.2 ارسال شود، آدرس next-hop در روتر Spoke1 روتر Hub است.
- همه ترافیک های ارسالی از روترهای Spoke بر اساس CEF مسیریابی می شوند. به عبارت دیگر همسایگی incompelete، invalid و یا glean در CEF وجود ندارد. این بدان دلیل است که آدرس next-hop در روترهای Spoke آدرس تونل روتر hub است و نگاشت بین آدرس تونل و آدرس فیزیکی روتر Hub نیز قبلا در روترهای Spoke وجود دارد که به صورت دستی توسط مدیر شبکه در روترهای Spoke وارد می شود. در شکل فوق هر دو روتر Spoke1 و Spoke2 نگاشت بین آدرس تونل و آدرس فیزیکی روتر Hub را در اختیار دارند. البته این موضوع علاوه بر آنکه یک مزیت است چالش جدیدی نیز ایجاد می کند. در DMVPN phase 2 همسایگی incomplete باعث ارسال درخواست nhrp می شود. در DMVPN phase 3 که همسایگی کامل است، چگونه درخواست nhrp ارسال می گردد؟ پاسخ به این سوال مکانیزم nhrp redirect است که در ادامه آن را بررسی می کنیم.
- برای درک بهتر nhrp redirect بهتر است مروری بر icmp redirect داشته باشید. اگر ترافیک IP روی یکی از اینترفیس های روتر دریافت شود و مسیر خروجی ترافیک، همان اینترفیس ورودی باشد، روتر علاوه بر ارسال ترافیک به روتر بعدی پیغام icmp redirect به مبدا ارسال می کند مبنی بر آنکه مسیر ارسالی شما غیر بهینه است و باید ترافیک را مستقیم به روتر بعدی ارسال نمایید. در DMVPN phase 3 وقتی روتر Spoke ترافیک را تحویل روتر Hub می دهد، روتر Hub ترافیک را روی اینترفیس تونل mGRE دریافت می کند و مسیر خروجی ترافیک برای رسیدن به هر یک از دیگر Spoke های شبکه همان اینترفیس تونلی است که ترافیک روی آن دریافت شده است. لذا روتر علاوه بر ارسال و خارج کردن ترافیک روی اینترفیس mGRE، پیغام nhrp redirect به روتر Spoke مبدا ارسال می کند. این پیغام به Spoke مبدا اعلام می کند که مسیر ارسالی غیر بهینه است و بهتر است ترافیک را مستقیم به روتر Spoke مقصد تحویل بدهد. در شکل فوق روتر Hub بعد از دریافت ترافیک روی اینترفیس mGRE، با توجه به آنکه مسیر خروجی آن همان اینترفیس mGRE است، ضمن ارسال ترافیک، پیغام nhrp redirect به Spoke1 ارسال می کند مبنی بر آنکه مسیر ارسالی به مقصد 2.2.2 غیر بهینه است
- روتر Spoke مبدا با دریافت پیغام nhrp redirect درخواست nhrp را به آدرس مقصد ترافیک redirect شده ارسال می کند. توجه کنید که آدرس مقصد پیغام nhrp request روتر nhrp server نیست. آدرس مقصد nhrp request معادل آدرس مقصد بسته ای است که redirect شده است. پیغام nhrp request همانند ترافیک داده از مسیر روتر Hub، که اتفاقا nhrp server نیز هست، به روتر Spoke مقصد هدایت می شود اما هیچ پردازشی در روتر Hub روی آن صورت نمی گیرد و فقط به سمت Spoke مقصد هدایت می شود. در مثال فوق آدرس مقصد بسته nhrp request آدرس 2.2.2 است و این ترافیک نیز همانند ترافیک داده از روتر Hub به سمت مقصد هدایت می شود.
- حال این روتر Spoke مقصد است که به درخواست nhrp پاسخ می دهد. این برخلاف DMVPN phase 1 و DMVPN phase 2 است که روتر Hub، که nhrp server است، به درخواست های nhrp پاسخ می دهد. آز انجایی که آدرس فیزیکی روتر Spoke مبدا در پیغام nhrp request وجود دارد، Spoke مقصد تونلی به صورت dynamic با Spoke مبدا ایجاد می کند و پاسخ nhrp را مستقیما و بدون عبور از روتر Hub به Spoke مبدا ارسال می کند. در شکل فوق Spoke2 با دریافت درخواست nhrp آدرس 1.1.2 را از بسته nhrp request استخراج می کند و تونلی به صورت مستقیم با Spoke1 ایجاد کرده و پاسخ nhrp reply را مستقیما به Spoke1 ارسال می کند. نکته دیگر اینکه پاسخ nhrp فقط برای آدرسی که درخواست nhrp برای آن ارسال شده است، ارائه نمی گردد بلکه پاسخ nhrp برای prefix ای ارسال می گردد که در جدول مسیریابی Spoke مقصد با آدرس مورد درخواست match شده است. در مثال فوق درخواست nhrp برای آدرس 2.2.2.2 ارسال شده است اما پاسخ nhrp برای شبکه 2.2.2.0/24 ارسال می گردد. Spoke مبدا با دریافت پاسخ nhrp آدرس فیزیکی Spoke مقصد را استخراج می کند. در این مثال Spoke1 آدرس 12.1.2.2 از روی بسته nhrp reply استخراج می کند. با استخراج آدرس فیزیکی Spoke مقصد، روتر Spoke مبدا، Shortcut ای در جدول nhrp برای شبکه مقصد (2.2.2.0/24) ایجاد می کند و همچنین آدرس روتر بعدی در جدول CEF از Hub به Spoke مقصد تغییر داده می شود. به این ویژگی اصطلاحا nhrp shortcut گفته می شود.
- با توجه به استخراج آدرس فیزیکی Spoke مقصد، تونلی به صورت dynamic با spoke مقصد ایجاد می گردد و از این به بعد تمام ترافیک های به مقصد شبکه ای که در جدول CEF ایجاد شده است، به صورت مستقیم و بدون عبور از Hub ارسال می گردد. اگر چه همانند DMVPN phase 2 اولین بسته به مقصد هر شبکه از Hub عبور می کند اما دو تفاوت اصلی دارد اول آنکه همه ترافیک ها از جمله اولین بسته ارسالی توسط CEF مسیریابی می شود و CPU را درگیر نمی کند. علاوه بر آن این تفاوت وجود دارد که در DMVPN phase 2 اولین بسته به مقصد هر آدرس از روی Hub عبور می کند اما در DMVPN phase 3 اولین بسته به مقصد هر شبکه از Hb عبور می کند. در مثال فوق بسته های به مقصد هر یک از دیگر آدرس های 2.2.0/24 نیز به صورت مستقیم ارسال می گردند. در محیط های واقعی نیز مقصد معمولا یک آدرس نیست بلکه شبکه ای را در بر می گیرد.
بنابراین به صورت خلاصه می توان گفت که DMVPN phase 3 دارای ویژگی های ذیل است:
- در DVPN phase 3 برخلاف DMVPN phae 2 درخواست nhrp به واسطه همسایگی incomplete در جدول CEF فعال نمی گردد. بنابراین امکان خلاصه سازی مسیر و یا ارسال مسیر default به روتر Spoke ایجاد می گردد.
- در DMVPN phae 3 پاسخ nhrp را روتر nhrp server ارسال نمی کند بلکه همه روترهای Spoke در ارسال پاسخ nhrp نقش دارند. بنابراین در DMVPN phase 3 مدل nhrp به صورت client-serever نیست بلکه بیشتر شبیه به peer-to-peer است.
- پاسخ nhrp فقط مربوط به یک آدرس خاص، که مقصد ترافیک ارسالی است، نمی باشد. بلکه کل شبکه متصل به Spoke مقصد را در بر می گیرد.
در ذیل پیاده سازی DMVPN phase 3 نشان داده شده است. مهمترین نکته در پیاده سازی DMVPN phase 3 دستور ip nhrp redirect روی روتر Hub و دستور ip nhrp shortcut روی روترهای Spoke است. در ضمن اجرای پروتکل مسیریابی همانند DMVPN Phase 1 است بدین معنی که در صورت استفاده از پروتکل EIGRP فقط کافی است تا Split Horizon روی HUB غیر فعال شود. در صورت استفاده از پروتکل مسیریابی OSPF حتما از نوع point-to-multipoint استفاده شود.
|
!!! HUB ! interface Tunnel0 ip address 172.16.1.10 255.255.255.0 no ip redirects no ip split-horizon eigrp 1 ip nhrp authentication rayka ip nhrp map multicast dynamic ip nhrp network-id 123 ip nhrp shortcut ip nhrp redirect tunnel source Serial2/0 tunnel mode gre multipoint ! router eigrp 1 network 10.0.0.0 network 172.16.0.0 ! !!! Spoek1 ! interface Tunnel0 ip address 172.16.1.1 255.255.255.0 no ip redirects ip nhrp authentication rayka ip nhrp map 172.16.1.10 12.1.0.2 ip nhrp map multicast 12.1.0.2 ip nhrp network-id 123 ip nhrp nhs 172.16.1.10 ip nhrp shortcut tunnel source Serial2/0 tunnel mode gre multipoint ! router eigrp 1 network 1.0.0.0 network 172.16.0.0 ! !!!Spoke2 interface Tunnel0 ip address 172.16.1.2 255.255.255.0 no ip redirects ip nhrp authentication rayka ip nhrp map 172.16.1.10 12.1.0.2 ip nhrp map multicast 12.1.0.2 ip nhrp network-id 123 ip nhrp nhs 172.16.1.10 ip nhrp shortcut tunnel source Serial2/0 tunnel mode gre multipoint ! router eigrp 1 network 2.0.0.0 network 172.16.0.0 |
پیاده سازی DMVPN phase 3
در ذیل خروجی جدول nhrp و جدول مسیریابی قبل از هر گونه ارتباط بین دو روتر Spoke نشان داده شده است. خروجی nhrp در روتر Spoke1 نشان می دهد که روتر Spoke1 هیچ اطلاعی از آدرس فیزیکی روتر Spoke2 ندارد. همچنین جدول مسیریابی روتر Spoke1 نشان می دهد که روتر برای ترافیک های به مقصد شبکه متصل به روتر Spoke2، ترافیک را به روتر Hub تحویل می دهد. همچنین نشان داده شده است که اولین ترافیک بین Spoke1 و Spoke2 از طریق Hub برقرار می شود. به محض دریافت ترافیک در روتر Hub، روتر Hub پیغام nhrp redirect به مقصد 1.1.1.1 تولید می کند. زیرا روتر Hub ترافیک را روی اینترفیس Tunnel0 دریافت می کند و روی همان اینترفیس نیز ترافیک را تحویل Spoke2 می دهد. پیغام nhrp redirect حاوی آدرس 2.2.2.2 است بدین معنی که پیغام nhrp redirect برای ترافیکی تولید شده است که مقصد آن 2.2.2.2 بوده است. روتر Spoke1 به محض دریافت nhrp redirect پیغام nhrp request به مقصد 2.2.2.2 تولید می کند. بسیار توجه کنید که پیغام nhrp request به مقصد nhrp server ارسال نشده است بلکه مقصد ترافیک nhrp request آدرس 2.2.2.2 است یعنی مقصد همان ترافیکی که پیغام nhrp redirect برای آن ارسال شده است. به این ترتیب روتر Spoke2 درخواست nhrp را برای آدرس 2.2.2.2 دریافت می کند. روتر Spoke2 پاسخ را فقط برای آدرس 2.2.2.2 ارسال نمی کند بلکه پاسخ را، که همان آدرس فیزیکی روتر Spoke2 است، برای کل شبکه 2.2.2.0/24 آماده کرده و به روتر Spoke1 ارسال می کند. جالب است بدانید که پاسخ nhrp از طریق hub ارسال نمی شود زیرا روتر Spoke2 از روی آدرس مبدا درخواست nhrp که از روتر Spoke1 دریافت کرده است به آدرس فیزیکی روتر Spoke1 دسترسی پیدا می کند و پاسخ را مستقیما به Spoke1 بر می گرداند. روتر Spoke1 نیز به محض دریافت پاسخ nhrp برای شبکه 2.2.2.0/24، shortcut ای در جدول nhrp ایجاد کرده و معادل آدرس فیزیکی روتر Spoke2 را ذخیره می کند. در ذیل جدول nhrp بعد از ارسال اولین ترافیک از Spoke1 به Spoke2 نشان داده شده است. خروجی نشان می هد که روتر Spoke1 آدرس فیزیکی روتر Spoke2 را برای محدوده آدرس 2.2.2.0/24 بدست اورده است. جالب تر اینکه حال اگر به جدول مسیریابی روتر Spoke1 توجه کنید متوجه می شوید که در جدول مسیریابی همچنان آدرس روتر بعدی به مقصد 2.2.2.0/24 همان Hub است اما کنار آن علامت % قرار داده شده است که به معنی “% - next hop override” است. به عبارت دیگر در جدول CEF آدرس روتر بعدی تغییر داده شده است. برخلاف جدول مسیریابی که آدرس روتر بعدی برای مقصد 2.2.2.0/24 آدرس 172.16.1.10 یا Hub است، در جدول CEF آدرس روتر بعدی 172.16.1.2 یا Spoke2 است. در پایان نیز ارتباط مستقیم بین دو روتر Spoke1 و Spoke2 بدون عبور از Hub نشان داده شده است.
|
Spoke1#sh ip nhrp 172.16.1.10/32 via 172.16.1.10 Tunnel0 created 00:01:39, never expire Type: static, Flags: used NBMA address: 12.1.0.2 ! Spoke1#sh ip route eigrp !!! بخشی از خروجی حذف شده است 2.0.0.0/24 is subnetted, 1 subnets D 2.2.2.0 [90/28288000] via 172.16.1.10, 00:00:09, Tunnel0 10.0.0.0/24 is subnetted, 1 subnets D 10.10.10.0 [90/27008000] via 172.16.1.10, 00:02:28, Tunnel0 ! Spoke1#traceroute 2.2.2.2 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 2.2.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.1.10 23 msec 18 msec 16 msec 2 172.16.1.2 46 msec 53 msec 22 msec ! !!! HUB !!! ما قبل و ما بعد خروجی زیر حذف شده است *Feb 14 15:45:21.737: NHRP: inserting (12.1.1.2/2.2.2.2) in redirect table *Feb 14 15:45:21.738: NHRP: Attempting to send packet through interface Tunnel0 via DEST dst 1.1.1.1 *Feb 14 15:45:21.738: NHRP: Send Traffic Indication via Tunnel0 vrf 0, packet size: 97 *Feb 14 15:45:21.738: src: 172.16.1.10, dst: 1.1.1.1 ! !!! Spoke1 !!! ما قبل و ما بعد خروجی زیر حذف شده است *Feb 14 15:45:21.747: NHRP: Receive Traffic Indication via Tunnel0 vrf 0, packet size: 97 ... *Feb 14 15:45:21.758: NHRP: Sending NHRP Resolution Request for dest: 2.2.2.2 to nexthop: 2.2.2.2 using our sr c: 172.16.1. Spoke1# ! Spoke1#sh ip nhrp 1.1.1.0/24 via 172.16.1.1 Tunnel0 created 00:05:19, expire 01:54:40 Type: dynamic, Flags: router unique local NBMA address: 12.1.1.2 (no-socket) 2.2.2.0/24 via 172.16.1.2 Tunnel0 created 00:05:19, expire 01:54:40 Type: dynamic, Flags: router rib nho NBMA address: 12.1.2.2 172.16.1.2/32 via 172.16.1.2 Tunnel0 created 00:05:19, expire 01:54:40 Type: dynamic, Flags: router used nhop rib NBMA address: 12.1.2.2 172.16.1.10/32 via 172.16.1.10 Tunnel0 created 00:10:07, never expire Type: static, Flags: used NBMA address: 12.1.0.2 ! Spoke1#sh ip route eigrp !!! بخشی از خروجی حذف شده است 2.0.0.0/24 is subnetted, 1 subnets D % 2.2.2.0 [90/28288000] via 172.16.1.10, 00:07:50, Tunnel0 10.0.0.0/24 is subnetted, 1 subnets D 10.10.10.0 [90/27008000] via 172.16.1.10, 00:10:09, Tunnel0 ! Spoke1#sh ip cef 2.2.2.0 internal 2.2.2.0/24, epoch 0, flags rib only nolabel, rib defined all labels, RIB[I], refcount 5, per-destination sharing sources: RIB feature space: IPRM: 0x00028000 ifnums: Tunnel0(23): 172.16.1.2 path B3557E90, path list B355E72C, share 1/1, type attached nexthop, for IPv4 nexthop 172.16.1.2 Tunnel0, adjacency IP midchain out of Tunnel0, addr 172.16.1.2 B3556898 output chain: IP midchain out of Tunnel0, addr 172.16.1.2 B3556898 IP adj out of Serial2/0 B4F3E9E8 ! Spoke1#traceroute 2.2.2.2 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 2.2.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.1.2 28 msec 22 msec 25 msec |
مکانیزم Query and Reply در EIGRP 
مکانیزم Feasible Successor در EIGRP 
مروری بر GRE Tunnel و پیاده سازی آن 
آدرس دهی IPv6 
مدیریت MTU در GRE Tunnel