البث المتعدد من الجيل التالي - MDT GRE الافتراضي (BGP AD - PIM C: Profile 3)

المقدمة

يصف هذا المستند شجرة توزيع البث المتعدد الافتراضية (MDT) GRE (BGP AD - PIM C) للبث المتعدد عبر VPN (mVPN). وهو يستخدم مثالا والتنفيذ في Cisco IOS لتوضيح السلوك.

ما هو MDT الافتراضي؟

يتم إستخدامه لتوصيل البث المتعدد بجميع PE في تردد VRF واحد. افتراضي يعني أنه يربط جميع موجهات PE. بشكل افتراضي، يحمل كل حركة المرور. تتحكم جميع حركات مرور بيانات PIM وحركة مرور مستوى البيانات. مثال: (*،g) حركة مرور و(S،G) حركة مرور. الافتراضي هو الواجب. تقوم MDT الافتراضية بتوصيل جميع موجه PE للاتصال. يمثل هذا نقاط متعددة إلى نقاط متعددة. أي شخص يمكنه الإرسال والجميع يمكنه الإستقبال من الشجرة. 

ما هي Data MDT؟

إنه إختياري ويتم إنشاؤه عند الطلب. وهو يحمل حركة مرور معينة (S،G). في أحدث إصدار IOS، لديك حد مكون على هيئة 0 ولا نهائي. عندما تصل الحزمة الأولى إلى VRF، فإن Data MDT تتم تهيئته، وإذا ما لا نهاية فإن Data MDT لا يتم إنشاؤه، وتنتقل حركة المرور إلى الأمام في MDT الافتراضي. MDT البيانات هو دائما الشجرة المتلقية، لا ترسل أي حركة مرور. MDT للبيانات فقط لحركة المرور (S،G). 

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

ملاحظة: بعد أن يرسل موجه PE رسالة UDP، فإنه ينتظر 3 ثوان أخرى قبل التبديل؛ 13 ثانية هي أسوأ حالة يتم فيها تبديل الوقت و 3 ثوان هي أفضل حالة.

يتم إنشاء وحدات التحكم في الوصول للوسائط (MDTs) للبيانات فقط لإدخالات مسار البث المتعدد (S، G) داخل جدول توجيه البث المتعدد الخاص ب VRF. لا يتم إنشائها لإدخالات (*، g) بغض النظر عن قيمة معدل البيانات المصدر المنفرد

• السماح ل PE بالانضمام مباشرة إلى شجرة مصدر ل MDT.
  
  
• لا توجد نقاط مقابلة مطلوبة في الشبكة.
  
  
• إن إختبارات نقطة الوصول (RP) هي نقطة فشل محتملة ونفقات عامة إضافية.
  
  
• لكنها تسمح بأشجار BiDir ومشتركة (حالة أقل).
  
  
• تقليل تأخر إعادة التوجيه.
  
  
• تجنب نفقات الإدارة الإضافية لإدارة تخطيط المجموعة/RP وبرامج RP المكررة لتحقيق الموثوقية.
  
  
• فالمقايضة مطلوبة من الدولة.
  
  
• (s، g) لكل شبكة mVPN في PE.
  
  

إذا كان هناك 5 خانات توصيل لكل من mVRF أحمر، فسيكون هناك 5 إدخالات (S، G).

1. قم بتكوين الأمر ip pim ssm range على كل من موجهات P و PE (تجنب الإدخالات غير الضرورية (*، G) التي يتم إنشاؤها).
   
   
2. SSM الموصى بها ل Data-MDTs.
   
   
3. أستخدم BiDir إن أمكن ل Default-MDT (دعم BiDir محدد للنظام الأساسي).
   
   

إذا لم يتم إستخدام SSM لإعداد MDTs للبيانات:

• يحتاج كل VRF أن يكون شكلت مع مجموعة فريد من multicast p عنوان، إثنان VRF في ال نفسه MD يستطيع لا يكون شكلت مع ال نفسه مجموعة العنوان.
  
  
• يلزم توفر المزيد من عناوين P للبث المتعدد.
  
  
• عمليات وإدارة معقدة.
  
  
• تتطلب SSM PE للانضمام إلى (S، G) وليس (*، G).

G معروفة بتكوينها ولكن PE لا يعرف مباشرة قيمة S (S، G) ل MDT الافتراضي المنتشر بواسطة MP-BGP.

تتمثل ميزة SSM في أنها لا تعتمد على إستخدام بروتوكول RP لاستخلاص موجه PE المصدر لمجموعة MDT معينة.

يتم إرسال عنوان IP الخاص بمصدر PE ومجموعة MDT الافتراضية عبر بروتوكول العبارة الحدودية (BGP)

هناك طريقتان يمكن BGP من خلالها إرسال هذه المعلومات:

• المجتمع الممتد
  • حلول Cisco الخاصة
  • سمة غير عابرة (غير مناسبة ل فيما بين AS)
• BGP Address Family MDT SAFI (66)
  • draft-nalawade-idr-mdt-safi

ملاحظة: تم دعم شبكات GRE MVPN قبل إستخدام MDT SAFI؛ في الواقع، حتى قبل MDT SAFI باستخدام النوع RD 2. تقنيا، بالنسبة لملف التعريف 3، لا يجب تكوين MDT SAFI، لكن كلا من SAFI مدعوم للترحيل في نفس الوقت.

BGP

• مجموعة PE المصدر ومجموعة MDT الافتراضية المرمزة في NLRI من MP_REACH_NLRI.

• RD هو نفسه الخاص ب MVRF الذي تم تكوين مجموعة MDT الافتراضية من أجله.
  
  
• نوع RD هو 0 أو 1

تحمل سمة PMSI عنوان المصدر وعنوان المجموعة. لتشكيل نفق MT.

عنونة البث المتعدد لمجموعة SSM

232.0.0.0 - 232.255.255.255 تم حجزها لتطبيقات البث المتعدد المحددة المصدر العالمية.

239.0.0.0 - 239.255.255.255 هو نطاق مساحة عنوان البث المتعدد للإصدار الرابع من بروتوكول الإنترنت (IP) ذو النطاق الإداري

النطاق المحلي لتنظيم IPv4 - 239.192.0.0/14

النطاق المحلي هو الحد الأدنى من النطاق المرفق، وبالتالي فهو غير قابل للتقسيم.

النطاقات 239.0.0.0/10 و 239.64.0.0/10 و239.128.0.0/10 غير مخصصة ومتاحة لتوسيع هذه المساحة.

يجب ترك هذه النطاقات غير معينة حتى تصبح المساحة 239.192.0.0/14 غير كافية.

التوصيات

• يجب أن يرسم Default-MDT العناوين من مساحة 239/8 بدءا من النطاق المحدد بالنطاق المحلي التنظيمي ل 239.192.0.0/14
  
  
• يجب أن يقوم DATA-MDT بسحب العناوين من النطاق المحلي للمنظمة.
  
  
• من الممكن أيضا إستخدام النطاق العالمي لذاكرة SSM 232.0.0.0 - 232.255.255.255
  
  
• بما أن SSM تستخدم دائما حالة فريدة (S، G)، فلا توجد إمكانية للتداخل حيث سيتم بدء تدفق البث المتعدد ل SSM من قبل مصادر مختلفة (ذات عناوين مختلفة) سواء كانت داخل شبكة الموفر أو الإنترنت الأكبر.
  
  
• أستخدم نفس تجمع Data-MDT لكل mVRF ضمن مجال بث متعدد محدد (حيث يكون Default-MDT مشتركا).

على سبيل المثال، كل VRFs يستعمل تقصير-MDT 239.192.10.1 يجب أن يستعمل نفس البيانات mdt 239.232.1.0/24 مدى

إرسال إشارات التراكب

يتم عرض إشارات التغشية الخاصة ب Rosen GRE في الصورة.

طوبولوجيا

يتم عرض طبولوجيا Rosen GRE في الصورة.

توجيه إعادة توجيه VPN متعدد البث وإعادة توجيهه ومجالات البث المتعدد

MVPN يقدم معلومات توجيه البث المتعدد إلى جدول توجيه وإعادة توجيه VPN. عندما يستقبل موجه Provider Edge (PE) بيانات البث المتعدد أو حزم التحكم من موجه Customer Edge (CE)، يتم إجراء إعادة التوجيه وفقا للمعلومات الموجودة في مثيل توجيه وإعادة توجيه VPN للبث المتعدد (MVRF). لا تستخدم MVPN تحويل التسمية.

يشكل مجموعة من MVRFs أن يستطيع أرسلت multicast حركة مرور إلى بعضهم بعضا مجال multicast. على سبيل المثال، سوف يتكون مجال البث المتعدد لعميل أراد إرسال أنواع معينة من حركة مرور البث المتعدد إلى جميع الموظفين العموميين من جميع موجهات CE المقترنة بذلك المؤسسة.

مهام التكوين

1. تمكين توجيه البث المتعدد على جميع العقد.
   
   
2. تمكين الوضع المتناثر للبث المتعدد دون الاعتماد على بروتوكول محدد (PIM) في جميع الواجهة.
   
   
3. مع VRF موجود يشكل MDT افتراضي.
   
   
4. شكلت ال VRF على القارن إثرنيت0/x.
   
   
5. قم بتمكين توجيه البث المتعدد على VRF.
   
   
6. تكوين الوضع الافتراضي لبروتوكول PIM SSM في جميع العقد داخل المركز.
   
   
7. تكوين BGP Address Family MVPN.
   
   
8. تكوين BSR RP في عقدة CE.
   
   
9. مهيأ مسبقا:

            VRF SSM-BGP
            mBGP: Address family VPNv4
            VRF Routing Protocol
 

التحقق من الصحة

المهمة 1: التحقق من الاتصال الفعلي.

تحقق من تشغيل جميع الواجهة المتصلة.

المهمة 2: التحقق من البث الأحادي لعائلة عنوان BGP VPNv4.

• تحقق من تمكين BGP في جميع موجهات جهات البث الأحادي ل AF VPNv4 وجيران BGP قيد التشغيل.
  
  
• تحقق من إحتواء جدول البث الأحادي BGP VPNv4 على جميع بادئات العميل.

المهمة 3: التحقق من البث الأحادي لعائلة عنوان BGP MVPN.

• تحقق من تمكين BGP في جميع موجهات جهات جهات جهات AF IPv4 MVPN و BGP المجاورة قيد التشغيل.
  
  
• تحقق من أن جميع عمليات اكتشاف PE بعضها البعض، باستخدام المسار من النوع 1.

المهمة 4: التحقق من نهاية حركة مرور البث المتعدد.

           

• فحص جوار PIM.
  
  
• دققت أن خلقت multicast دولة في ال VRF.
  
  
• تحقق من إدخال mRIB على PE1 و PE2 و PE3.
  
  
• تحقق من زيادة إدخال (S، G) mFIB والحزمة في إعادة توجيه البرامج.
  
  
• تحقق من وصول حزم ICMP من CE إلى CE.

كيف يتم إنشاء واجهات النفق؟

إنشاء نفق MDT

ما إن يشكل أنت mdt تقصير 239.232.0.0

النفق 0 جاء وعين له عنوان الاسترجاع 0 كمصدر.

٪Lineproto-5-updown: بروتوكول الخط في نفق الواجهة0، تم تغيير الحالة إلى أعلى

PIM(1): Check DR after interface: Tunnel0 came up!
PIM(1): Changing DR for Tunnel0, from 0.0.0.0 to 1.1.1.1 (this system)
%PIM-5-DRCHG: VRF SSM-BGP: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel0

تعرض هذه الصورة إنشاء نفق MDT.

PE1#sh int tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Interface is unnumbered. Using address of Loopback0 (1.1.1.1)
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 1.1.1.1 (Loopback0)
   Tunnel Subblocks:
      src-track:
         Tunnel0 source tracking subblock associated with Loopback0
          Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport multi-GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
 

بمجرد ظهور شبكة BGP MVPN، تكتشف جميع شبكات PE بعضها البعض عبر المسار من النوع 1. تم تكوين نفق البث المتعدد. يحمل BGP كل عنوان Group و Source PE في سمة PMSI.

تعرض هذه الصورة تبادل المسار من النوع 1.

تعرض هذه الصورة PCAP-1.

PE1#sh ip mroute 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
      
 (3.3.3.3, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ
  Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2
  Outgoing interface list:
    MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18
 
(2.2.2.2, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ
  Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2
  Outgoing interface list:
    MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18
 
“Z” Multicast Tunnel formed after BGP mVPN comes up, as it advertises the Source PE and Group Address in PMSI attribute.

منطقة جوار PIM

PE1#sh ip pim vrf SSM-BGP neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.1.0.2          Ethernet0/2           00:58:18/00:01:31 v2  1 / DR S P G
3.3.3.3           Tunnel0                00:27:44/00:01:32 v2    1 / S P G
2.2.2.2           Tunnel0                 00:27:44/00:01:34 v2    1 / S P G
 

بمجرد تكوين معلومات RP:

٪Lineproto-5-updown: بروتوكول الخط في نفق الواجهة 1، تم تغيير الحالة إلى أعلى

تبادل رسائل بروتوكول نظام تمهيد تشغيل الكمبيوتر (BOOTSTRP) عبر نفق MDT

PIM(1): Received v2 Bootstrap on Tunnel0 from 2.2.2.2
PIM(1): pim_add_prm:: 224.0.0.0/240.0.0.0, rp=22.22.22.22, repl = 0, ver =2, is_neg =0, bidir = 0, crp = 0
PIM(1): Update
prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:22.22.22.22), PIMv2
*May 18 10:28:42.764: PIM(1): Received RP-Reachable on Tunnel0 from 22.22.22.22
 

تعرض هذه الصورة تبادل رسائل بروتوكول تمهيد تشغيل الكمبيوتر (BOOTSTRAP) عبر نفق MDT.

PE2#sh int tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Description: Pim Register Tunnel (Encap) for RP 22.22.22.22 on VRF SSM-BGP
  Interface is unnumbered. Using address of Ethernet0/2 (10.2.0.1)
  MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 10.2.0.1 (Ethernet0/2), destination 22.22.22.22
   Tunnel Subblocks:
      src-track:
         Tunnel1 source tracking subblock associated with Ethernet0/2
          Set of tunnels with source Ethernet0/2, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport PIM/IPv4
  Tunnel TOS/Traffic Class 0xC0,  Tunnel TTL 255
  Tunnel transport MTU 1472 bytes
  Tunnel is transmit only

تم تكوين نفق تسجيل PIM ونفق MDT.

• يتم إستخدام النفق 0 لإرسال انضمام PIM وحركة مرور البث المتعدد ذات النطاق الترددي المنخفض.
• يتم إستخدام النفق 1 لإرسال رسالة سجل تضمين PIM.

أمر للتحقق :

**MDT BGP:

PE1#sh ip pim vrf m-SSM MDT BGP 

   

** إرسال البيانات من أجل:

PE1#sh ip pim vrf m-SSM MDT

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

• https://tools.ietf.org/html/rfc4760
  
  
• https://tools.ietf.org/html/rfc5110
  
  
• https://tools.ietf.org/html/rfc6513
  
  
• الدعم التقني والمستندات - Cisco Systems