تنفيذ تصميم الشبكة الفرعية المتعددة DMVPN Phase3

المقدمة

يصف هذا المستند اعتبارات التوجيه في تصميم شبكة فرعية متعددة في المرحلة DMVPN3 لضمان إنشاء أنفاق اتصال مباشرة بشكل صحيح. 

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• معرفة أساسية ب Dynamic Multipoint VPN (DMVPN)
• معرفة أساسية ببروتوكول تحليل الخطوة (Hop) التالية (NHRP)

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

تتيح كل من عمليات تنفيذ المرحلة الثانية من DMVPN والمرحلة الثالثة للجهاز المتصل إمكانية بناء نفق يتم التحدث به مباشرة ولا تحتاج إلى المرور عبر الصرة. ومع ذلك، توفر المرحلة 3 من DMVPN قابلية تطوير أفضل بكثير من خلال آلية إعادة توجيه NHRP للتكلم لاكتشاف الشبكات البعيدة بشكل ديناميكي من خلال NHRP، ثم تثبيت مسارات NHRP (H) بعد ذلك في جدول التوجيه. يؤدي هذا إلى إزالة تقييد المرحلة 2 الخاص بطلب أن يكون لكل واحد من هذه الشبكات بادئات شبكة محددة للشبكات البعيدة في جدول التوجيه الخاص بها. مع المرحلة 3، يجب أن يمر الرد على قرار NHRP من نقطة الخروج الهدف (NBMA) عبر النفق المباشر. ومع ذلك، يجب إيلاء إعتبار خاص لتصميم مرحلة متعددة الشبكات الفرعية 3 حتى يمكن بناء نفق يجري الحديث إليه بشكل صحيح. تناقش هذه المقالة هذه المتطلبات بالتفصيل.

المشكلة

يمكن تنفيذ المرحلة 3 من DMVPN في تغشية شبكة فرعية واحدة أو تغشية شبكة فرعية متعددة. في مخطط شبكة فرعية واحدة، يتم تخصيص كل من الموزع وجميع عناوين نفق الموجه المكبر عبر الإنترنت من شبكة IP فرعية منطقية واحدة؛ في حين أنه في تصميم شبكة فرعية متعددة، يلزم إنشاء نفق مكبر صوت للمخططات ذات عناوين النفق الخاصة بها في شبكات IP فرعية مختلفة. الأخير هو سيناريو شائع مستخدم في تصميم DMVPN هرمي موضح في الصورة أدناه.

مخطط الشبكات الفرعية المتعددة DMVPN Phase3

تفاصيل المشكلة

باستخدام المرحلة 3 من DMVPN، من المفهوم بشكل عام أنه عند تلقي طلب تحليل NHRP، يقوم الشخص المقصود ببداية نفق IPsec إلى المصدر الذي تم التحدث عنه، ومن ثم يرسل الرد على الدقة عبر ذلك النفق. ومع ذلك، هذه هي الحالة فقط مع تغشية شبكة فرعية واحدة. عندما تكون واجهات النفق الخاصة بالمقبس في شبكات IP الفرعية المنطقية المختلفة، يمكن لحزم التحكم في NHRP المرور عبر المسار ذي المحاور الكلامية بدلا من باستخدام النفق ذي المحاور المباشر. فيما يلي تسلسل الأحداث عند إرسال Talk1 طلب حل إلى Talk2 بعد تلقي إعادة توجيه NHRP من Hub1:

1. TALK2 يستلم طلب الحل
   
   

   *Feb  7 20:57:22.272: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 144
   *Feb  7 20:57:22.272:  (F) afn: AF_IP(1), type: IP(800), hop: 252, ver: 1
   *Feb  7 20:57:22.272:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.272:      pktsz: 144 extoff: 52
   *Feb  7 20:57:22.272:  (M) flags: "router auth src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.272:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.272:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.272:  (C-1) code: no error(0)
   *Feb  7 20:57:22.272:        prefix: 32, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.272:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
   

2. TALK2 يضيف إدخال ذاكرة تخزين مؤقت NHRP ضمني ل 10.0.1.101 بتطفل حزمة طلب الحل.
3. يضيف TALK2 تجاورا ل 10.0.1.101 ل Tunnel0 مع عنوان NBMA ل Talk1.
4. رد ٪2 على القرار. إشعار عند هذه النقطة، يشير مسار عنوان النفق الذي تم التحدث إليه لطلب الشراء إلى Hub2:
   
   

   Spoke2#show ip route 10.0.1.101
   Routing entry for 10.0.1.0/24
     Known via "eigrp 1", distance 90, metric 3609600, type internal
     Redistributing via eigrp 1
     Last update from 10.0.2.1 on Tunnel0, 00:17:44 ago
     Routing Descriptor Blocks:
     * 10.0.2.1, from 10.0.2.1, 00:17:44 ago, via Tunnel0
         Route metric is 3609600, traffic share count is 1
         Total delay is 41000 microseconds, minimum bandwidth is 1000 Kbit
         Reliability 255/255, minimum MTU 1400 bytes
         Loading 1/255, Hops 3
   Spoke2#
   Spoke2#
   Spoke2#show ip cef 10.0.1.101
   10.0.1.0/24
     nexthop 10.0.2.1 Tunnel0
   

   نظرا لإعادة توجيه حزمة التحكم في NHRP عبر المسار الموجه، فإنها يتم إرسالها إلى Hub2 بدلا من النفق الذي تم إنشاؤه حديثا "تحدث" إلى Talk1:
   
   

   *Feb  7 20:57:22.360: NHRP: Send Resolution Reply via Tunnel0 vrf global(0x0), packet size: 172
   *Feb  7 20:57:22.360:  src: 10.0.2.101, dst: 10.0.1.101
   *Feb  7 20:57:22.360:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
   *Feb  7 20:57:22.360:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.360:      pktsz: 172 extoff: 60
   *Feb  7 20:57:22.360:  (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.360:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.360:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.360:  (C-1) code: no error(0)
   *Feb  7 20:57:22.360:        prefix: 24, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.360:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
   *Feb  7 20:57:22.360:        client NBMA: 172.16.2.1
   *Feb  7 20:57:22.360:        client protocol: 10.0.2.101
   *Feb  7 20:57:22.360: NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 172.17.0.5

من الناحية النظرية، طالما يمكن لجميع الموزع (الموجهات) الوسيط توجيه حزمة التحكم في NHRP مرة أخرى إلى نفق Talk1، فيجب أن يظل كل شيء يعمل. ولكن هذه ليست الحال بالضرورة. إذا تعذر إعادة توجيه الرد على الحل مرة أخرى إلى Talk1، فلا يمكن إنشاء نفق Direct Talk إلى Talk. 

باستخدام تغشية شبكة فرعية واحدة، لا تمثل هذه المشكلة لأن كل محادثة تحتوي على مسار متصل مباشرة بشبكة النفق. وهذا ينتج عنه بحث عن التجاور لعنوان النفق الذي تم التحدث به قبل إرسال الرد على الحل مرة أخرى. في شبكة فرعية متعددة، نظرا لأن عناوين النفق الخاصة بالخوادم ليست على شبكة IP الفرعية نفسها، فليس من المؤكد إرسال حزمة الرد على الدقة عبر نفق التحدث المباشر.

الحل

بالنسبة لتصميم DMVPN في المرحلة 3 متعدد الشبكات الفرعية، يوصى بأن يحتوي الشخص الذي يتم التحدث عنه على إدخال توجيه يشير إلى واجهة النفق لأي شبكة فرعية نفق يتم التحدث عنه عن بعد تحتاج إليها لإنشاء نفق يتم التحدث إليه مباشرة. على سبيل المثال:

Spoke2#show run | in ip route
ip route 10.0.101.0 255.255.255.0 Tunnel0

وهذا يسمح للذي تم التحدث بمحاولة حل التجاور لعنوان النفق الذي تم التحدث عنه بالطلب، ثم إرسال الرد على الحل عبر النفق الذي تم التحدث به. 

وبدلا من ذلك، يمكن للرد على القرار إجتياز الأنفاق التي يتم التحدث بها عبر موزع البيانات. في مثل هذه الحالة، يجب أن يكون لجميع الصرة (الموجهات) الوسيطة مسار إلى الشبكة الفرعية للنفق المتكلم الطالب لضمان إمكانية تسليم حزم التحكم في NHRP من نهاية إلى نهاية.

ملاحظة: تم فتح تحسين للخطأ لاستكشاف الخيارات الخاصة بإرسال "الرد على الدقة" عبر النفق المباشر حتى بدون مسار ثابت صريح. معرف تصحيح الأخطاء من Cisco CSCvo02022 - التحسين: يجب أن يرسل NHRP الرد على الحل عبر نفق TALK ل DMVPN متعدد الشبكات الفرعية.

ملاحظة: يمكن فقط لعملاء Cisco المسجلين الوصول إلى معلومات وأدوات الأخطاء الداخلية من Cisco.

معلومات ذات صلة

• الدعم التقني والتنزيلات من Cisco