در DMVPN phase 2 برخلاف DMVPN phase 1 ارتباط بین Spoke ها به صورت مستقیم و بدون دخالت Hub صورت می گیرد. چه تفاوتهایی در پیاده سازی DMVPN phase 2 منجر به ارتباط مستقیم بین Spoke ها می شود؟ پاسخ به این سوال در قالب چند نکته در ذیل آمده است:

    • هم در روتر Hub و هم در روترهای Spoke اینترفیس Tunnel از نوع mGRE ایجاد می شود. بنابراین هر یک از روترهای Hub و یا Spoke جهت ارتباط با هر مقصدی، با کمک پروتکل nhrp آدرس فیزیکی روتر مقصد را استخراج نموده و به صورت dynamic تونل ایجاد می نماید.
  •  در صورت استفاده از پروتکل مسیریابی Static، مسیر به مقصد شبکه های متصل به هر یک از روترهای Spoke، آدرس اینترفیس تونل روتر Spoke تعیین می شود. به عبارت دیگر از دید Spoke آدرس next-hop روتر Hub نیست. آدرس next-hop برای رسیدن به شبکه های متصل به روتر Spoke آدرس اینترفیس Tunnel روتر Spoek است. بنابراین ترافیک بین Spoke ها از روتر Hub عبور نمی کند.
  • در صورت استفاده از پروتکل مسیریابی EIGRP پیاده سازی دو نکته ضروری است:
  • ویژگی split-horizon را روی اینترفیس Tunnel در روتر Hub با دستور no ip split-horizon eigrp غیر فعال کنید تا روتر Hub روی همان اینترفیسی که مسیر شبکه های Spoke را یاد می گیرد، مجددا روی همان اینترفیس، مسیرهای یاد گرفته شده را به دیگر روترهای Spoke ارسال نماید.

b.با دستور no ip next-hop-self eigrp در اینترفیس Tunnel روتر Hub، مانع از تغییر next-hop در روتر Hub شوید. بدین ترتیب علی رغم اینکه مسیر شبکه های Spoke از طریق روتر Hub یاد گرفته می شود اما آدرس روتر بعدی به روتر Hub اشاره نمی کند بلکه آدرس روتر بعدی به اینترفیس Tunnel روتر Spoke اشاره می کند.

          4 .در صورت استفاده از پروتکل مسیریابی OSPF در DMVPN phase 2 توجه به دو نکته زیر ضروری است.

  • نوع شبکه را در پروتکل OSPF برخلاف DMVPN phase 1، broadcast و یا non-broadcast در نظر بگیرید تا روتر HUB به عنوان DR مسیر های یاد گرفته شده از روترهای Spoke را بدون تغییر next-hop به دیگر روترهای Spoke یاد بدهد. انتخاب broadcast پیشنهاد می شود تا همسایگی به صورت اتوماتیک ایجاد شود.
  • برای اطمینان از اینکه روتری غیر از روتر Hub نقش DR را به خود نمی گیرد، مقدار priority در روترهای Spoke را به مقدار صفر (0) تغییر دهید. مقدار priority به صورت پیش فرض 1 است که در روتر Hub تغییر نمی دهیم.

در سناریوی مرتبط با شکل زیر، DMVPN phase 2 پیاده سازی و اجرا شده و نتایج آن در ادامه آورده شده است.

Spoke to Spoke

پیاده سازی DMVPN Phase 2

 

!!! HUB

interface Tunnel0

 ip address 172.16.1.10 255.255.255.0

 no ip next-hop-self eigrp 1 

 no ip split-horizon eigrp 1

 ip nhrp authentication rayka

 ip nhrp map multicast dynamic

 ip nhrp network-id 123

 tunnel source Serial2/0

 tunnel mode gre multipoint

!

router eigrp 1

 network 10.10.10.10 0.0.0.0

 network 172.16.0.0

!

!!! SPOKE1

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

 tunnel source Serial2/0

 tunnel mode gre multipoint

!

router eigrp 1

 network 1.1.1.1 0.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

 tunnel source Serial2/0

 tunnel mode gre multipoint

!

router eigrp 1

 network 2.2.2.2 0.0.0.0

 network 172.16.0.0

پیاده سازی DMVPN phase 2 با پروتکل مسیریابی EIGRP

خروجی جدول مسیریابی در روتر Spoke1 نشان می دهد که آدرس next-hop در مسیر مربوط به مقصد شبکه متصل به روتر Spoke2 آدرس اینترفیس Tunnel روتر Spoke2 است و نه روتر Hub. لذا ترافیک بین Spoke ها از روتر Hub عبور نمی کند. همچنین قبل از ارسال داده ما بین دو روتر Spoke1 و Spoke2، جدول HSRP روتر Spoke1 نیز نشان داده شده است. خروجی HSRP نشان می دهد که این روتر هیچ اطلاعی از آدرس فیزیکی Spoke مقصد ندارد. 

 

  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.2, 00:04:01, Tunnel0

     10.0.0.0/32 is subnetted, 1 subnets

D        10.10.10.10 [90/27008000] via 172.16.1.10, 00:04:38, Tunnel0

!

SPOKE1#sh ip nhrp

172.16.1.10/32 via 172.16.1.10

   Tunnel0 created 00:08:41, never expire

   Type: static, Flags: used

   NBMA address: 12.1.0.2

خروجی جدول مسیریابی روتر Spoke در DMVPN phase 2

در ذیل نشان داده شده است که اولین بسته ترافیکی بین دو روتر Spoke از Hub عبور می کند اما روتر Spoke مبدا به محض استخراج آدرس فیزیکی روتر Spoke مقصد، که از جدول HSRP روتر Hub بدست می آورد، تونلی مستقیم با روتر Spoke مقصد ایجاد می کند و از آن به بعد ترافیک بین دو روتر Spoke از روتر Hub عبور نمی کند. مشاهده جدول NHRP بعد از ارسال داده بین دو روتر Spoke نشان می دهد که روتر Spoke مبدا آدرس فیزیکی روتر Spoke مقصد را استخراج نموده است. در پایان نیز خروجی show dmvpn در روتر Spoke ایجاد تونل مستقیم بین دو روتر Spoke را تایید می کند که به صورت dynamic ایجاد شده است. حرف D به معنی dynamic بودن تونلی است که ایجاد شده است.

 

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 27 msec

    172.16.1.2 18 msec

!

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 16 msec 17 msec 25 msec

!

SPOKE1#sh ip nhrp

172.16.1.2/32 via 172.16.1.2

   Tunnel0 created 00:00:02, expire 01:59:57

   Type: dynamic, Flags: router used nhop

   NBMA address: 12.1.2.2

172.16.1.10/32 via 172.16.1.10

   Tunnel0 created 00:09:05, never expire

   Type: static, Flags: used

   NBMA address: 12.1.0.2

!

SPOKE1#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting

        UpDn Time --> Up or Down Time for a Tunnel

==========================================================================

Interface: Tunnel0, IPv4 NHRP Details

Type:Spoke, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1 12.1.2.2             172.16.1.2    UP 00:00:21     D

     1 12.1.0.2            172.16.1.10    UP 00:07:42     S

ایجاد تونل به صورت dynamic بین روترهای Spoke در DMVPN phase 2

در ذیل، اجرای پروتکل OSPF به جای پروتکل EIGRP در DMVPN phase 2 نشان داده شده است. نوع شبکه در OSPF، broadcast در نظر گرفته شده است. همچنین با صفر قرار دادن مقدار priority در روترهای Spoke از DR شدن روتر Hub اطمینان حاصل می کنیم. در پایان نیز با ارسال ترافیک مستقیم بین روترهای Spoke از صحیح بودن عملکرد DMVPN phase 2 اطمینان حاصل می کنیم.

 

!!! HUB

interface Tunnel0

 ip ospf network broadcast

!

router ospf 1

 network 10.10.10.10 0.0.0.0 area 0

 network 172.16.1.0 0.0.0.255 area 0

!

!!! Spoke1

interface Tunnel0

 ip ospf network broadcast

 ip ospf priority 0

!

router ospf 1

 network 1.1.1.1 0.0.0.0 area 0

 network 172.16.1.0 0.0.0.255 area 0

!

!!! Spoke2

interface Tunnel0

 ip ospf network broadcast

 ip ospf priority 0

!

router ospf 1

 network 2.2.2.2 0.0.0.0 area 0

 network 172.16.1.0 0.0.0.255 area 0

!

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 20 msec 28 msec 23 msec

بکارگیری پروتکل OSPF در DMVPN phase 2

همانطور که از مباحث فوق متوجه شده ایم، مزیت اصلی DMVPN phase 2 نسبت به DMVPN phase 1 این است که ترافیک بین Spoke ها از روتر Hub عبور نمی کند. اما DMVPN phase 2 نسبت به DMVPN phase 1 از یک عیب اساسی نیز برخوردار است. در DMVPN phase 1 مسیر خروجی روتر Spoke به مقصد هر یک از دیگر روترهای Spoke همواره روتر Hub است و به همین دلیل می توان به جای ارسال تعداد زیادی مسیر از روتر Hub به روتر Spoke، مسیر default و یا summary به روتر Spoke ارسال نمود. اما در DMVPN phase 2 تمام مسیرها باید به صورت مستقل به روتر های Spoke منتقل شوند. بدین معنی که اگر شبکه ای متشکل از 1000 روتر Spoke باشد، آنگاه روتر Hub باید 1000 مسیر به هر یک از روترهای Spoke، مجموعا 1.000.000 مسیر، ارسال نماید.

مشکل دیگری که در DMVPN phase 2 وجود دارد، اینکه اولین بسته ارسالی بین هر دو روتر Spoke مبتنی بر CEF مسیریابی نمی شود به این دلیل که آدرس next-hop در جدول CEF که به آدرس اینترفیس تونل Spoke مقصد اشاره می کند، از دید CEF معتبر نیست و نیاز به ترجمهدارد. اولین بسته ارسالی توسط CPU ارسال می گردد و پروتکل nhrp را فعالمی کند. پروتکل nhrp در روتر Spoke با ارسال درخواست nhrp request به روتر Hub آدرس فیزیکی Spoke مقصد را استخراج می کند و جدول CEF را به روز می نماید. یعد از استخراج آدرس فیزیکی روتر Spoke مقصد، ترافیک های بین این دو Spoke بر اساس CEF مسیریابی می شوند.

در ذیل خروجی جدول cef و adjacency قبل از ارسال هر گونه ترافیک بین دو روتر Spoke نشان داده شده است. خروجی نشان می دهد که وضعیت adjacency برای آدرس next-hop کامل نیست. اولین بسته ارسالی توسط CPU و از طریق Hub ارسال می گردد. با توجه به کامل نبودن adjacency برای آدرس next-hop، درخواست nhrp request به روتر Hub ارسال می شود. روتر Hub آدرس فیزیکی Spoke مقصد را بر می گرداند و جدول adjacency کامل می شود.

 

SPOKE1#sh ip cef 2.2.2.2

2.2.2.2/32

  nexthop 172.16.1.2 Tunnel0

!

SPOKE1#sh adjacency 172.16.1.2

Protocol Interface                 Address

IP       Tunnel0                   172.16.1.2(5) (incomplete)

 اولین بسته بین هر دو Spoke در DMVPN phase 2 با توجه به کامل نبودن adjacency در CEF توسط CPU ارسال می گردد

در ذیل نشان داده شده است که بعد از ارسال ترافیک بین دو روتر Spoke جدول adjacency مرتبط با CEF کامل شده است.

SPOKE1#ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 25/35/45 ms

!

SPOKE1#sh adjacency 172.16.1.2

Protocol Interface                 Address

IP       Tunnel0                   172.16.1.2(11)

پیکربندی ‏8 27 کامل شدن adjacency در CEF بعد از ارسال ترافیک بین دو Spoke

اما شاید یکی از اصلی ترین مشکلاتی که در DMVPN phase 2 وجود دارد، عدم قابلیت اجرای DMVPN به صورت سلسله مراتبی است. بدین معنی که در مقیاس های بزرگ شبکه به چندین ناحیه تقسیم می شود و در هر ناحیه یک DMVPN و یک Hub مجزا وجود دارد که مسئول نگهداری جدول NHRP برای روترهای Spoke همان ناحیه است. همچنین Hub های هر ناحیه نیز با یک Hub مرکزی تشکیل DMVPN مجزایی را می دهند که در آن Hub مرکزی مسئول nhrp و یا به عبارت دیگر مسئول نگهداری ادرس فیزیکی Hub های نواحی است در این صورت اگر Spoke در یک ناحیه بخواهد با Spoke ای در ناحیه دوم ارتباط برقرار کند، Spoke مبدا، ترافیک را به روتر بعدی که Hub ناحیه خودش است، تحویل می دهد. Hub ناحیه اول با کمک DMVPN phase 2 ترافیک را مستقیما و بدون گذر از Hub مرکزی تحویل Hub ناحیه مقصد می دهد و نهایتا نیز Hub ناحیه مقصد ترافیک را به Spoke مقصد تحویل می دهد. با توجه به مباحث فوق ترافیک بین دو Spoke در ساختار سلسله مراتبی به صورت مستقیم جابجا نمی شود و از Hub های محلی عبور می کند.

بنابراین پیاده سازی DMVPN phase 2 به صورت سلسله مراتبی امکان پذیر نیست. در بخش های بعدی خواهیم دید چنانچه DMVPN phase 2 را به صورت سلسله مراتبی اجرا کنیم ترافیک بین روترهای Spoke به صورت مستقیم بین یکدیگر جابجا نخواهند شد و از روترهای Hub مربوط به  Spoke مبدا و Spoke مقصد عبور خواهد کرد.. پیاده سازی DMVPN phase 2 به صورت سلسله مراتبی را در بخش های بعدی نشان خواهیم داد.

نوشتن دیدگاه


تصویر امنیتی
تصویر امنیتی جدید