يصف هذا وثيقة كيف يعمل Auto-RP على Cisco Nexus 9000 مع NX-OS وكيفية التحقق من صحة عملية البث المتعدد واستكشاف أخطائها وإصلاحها.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
البث المتعدد هو نموذج اتصال من واحد إلى كثير حيث يرسل المصدر تدفق حركة مرور واحد إلى العديد من أجهزة الاستقبال المهتمة. وبدلا من إنشاء نسخة منفصلة لكل وجهة، تقوم الشبكة بنسخ حركة مرور البيانات فقط حيث يتم إنشاء فروع مسار إعادة التوجيه. وهذا يجعل البث المتعدد أكثر فعالية من البث أو الإرسال الأحادي المتكرر. في IPv4، تستخدم حركة مرور البث المتعدد عناوين الوجهة من نطاق 224.0.0.0/4.
PIM Sparse Mode هو نموذج توجيه البث المتعدد المدعوم على محولات Cisco Nexus التي تعمل بنظام تشغيل NX-OS. إنه يعيد توجيه حركة المرور فقط عندما يتم التعرف بشكل صريح على فائدة المستلم. في تصميم البث المتعدد بأي مصدر، ينضم المتلقيون في البداية إلى شجرة مشتركة باتجاه نقطة الالتقاء، وتسجل المصادر مع RP تلك. بعد أن تبدأ حركة المرور في التدفق، يمكن أن ينتقل موجه الخطوة الأخيرة من الشجرة المشتركة إلى أقصر شجرة مسار نحو المصدر.
من المهم تحديد المصطلحات المستخدمة في البث المتعدد لأن أستكشاف الأخطاء وإصلاحها بشكل دقيق يعتمد على فهم كيفية تمثيل أحداث مستوى التحكم وإدخالات التوجيه وقرارات إعادة التوجيه. يساعد مسح المصطلحات في ترجمة إخراج الأمر بشكل صحيح، والتمييز بين سلوك الشجرة المشتركة وشجرة المصدر، والتعرف على دور كل مكون بث متعدد في عملية إعادة التوجيه من نهاية إلى نهاية.
| مدة | التعريف |
|---|---|
| عنوان مجموعة البث المتعدد | عنوان وجهة IPv4 في النطاق 224.0.0.0/4 المستخدم لتعريف مجموعة بث متعدد. |
| عنوان المصدر | عنوان IP للبث الأحادي الخاص بالمرسل الذي يرسل حركة مرور البيانات إلى مجموعة البث المتعدد. |
| مسالك | إدخال توجيه البث المتعدد الذي يحدد كيفية معالجة حركة مرور البث المتعدد لمجموعة أو مجموعة مصدر. |
| IIF | الواجهة الواردة. الواجهة التي من المتوقع أن تصل عليها حركة مرور البث المتعدد. |
| OIF | الواجهة الصادرة. واجهة تستخدم لإعادة توجيه حركة مرور البث المتعدد نحو أجهزة الاستقبال أو جيران تدفق البيانات من الخادم. |
| زيت | قائمة واجهة الصادر. مجموعة الواجهات الصادرة المرتبطة بإدخال توجيه البث المتعدد. |
| إعادة توجيه المسار العكسي | إعادة توجيه المسار العكسي. تحقق مما إذا كانت حركة مرور البث المتعدد قد وصلت على الواجهة الصحيحة استنادا إلى مسار البث الأحادي نحو المصدر أو RP. |
| MDT | شجرة توزيع البث المتعدد. الشجرة المنطقية التي تحمل حركة مرور البث المتعدد من المصدر إلى جميع المتلقيات. |
| RPT | شجرة RP، تسمى أيضا الشجرة المشتركة. ويربط المتلقين ببرنامج الاستجابة السريعة ويمثلهم (*،G). |
| SPT | أقصر شجرة مسار، تسمى أيضا شجرة المصدر. ويربط المستقبل مباشرة بالمصدر ويمثله (S،G). |
| إف اتش آر | موجه الخطوة الأولى. يتصل موجه البث المتعدد مباشرة بالمصدر ويكون مسؤولا عن تسجيل المصدر مع RP. |
| ل.ر | موجه الخطوة الأخيرة. موجه البث المتعدد المتصل مباشرة بالمتلقين والمسؤول عن إنشاء حالة البث المتعدد بعد تعلم اهتمام المتلقي من خلال IGMP. |
| آر بي | نقطة الالتقاء. نقطة الاجتماع المنطقية المستخدمة في وضع ASM و PIM المتناثر لتوصيل المصادر والمستقبلين في البداية. |
| ASM | البث المتعدد لأي مصدر. نموذج البث المتعدد حيث ينضم المتلقيون إلى مجموعة دون تحديد المصدر مسبقا. |
من المهم فهم عناوين البث المتعدد المحجوزة المعروفة لأن أستكشاف أخطاء البث المتعدد وإصلاحها يعتمد على التحديد السريع لبروتوكول التحكم الذي يستخدم مجموعة وجهة محددة والوظائف التي تخدم حركة مرور البيانات في الشبكة. تساعد هذه العناوين في التمييز بين عملية البروتوكول العادية والسلوك غير الطبيعي وتجعل من السهل التحقق من تبادلات IGMP و PIM و Auto-RP. بالنسبة ل Auto-RP على وجه التحديد، فإن المجموعات الأكثر أهمية التي يجب التعرف عليها هي 224.0.1.39 ل RP-Announce و 224.0.1.40 ل RP-Discovery، لأنها تحمل المعلومات التي تسمح للموجات بتعلم تعيينات RP الديناميكية.
| عنوان البث المتعدد | الغرض |
|---|---|
| 224.0.0.1 | جميع البيئات المضيفة على الشبكة الفرعية المحلية |
| 224.0.0.2 | جميع الموجهات على الشبكة الفرعية المحلية |
| 224.0.0.13 | جميع موجهات PIM |
| 224.0.0.22 | رسائل IGMPv3 |
| 224.0.1.39 | رسائل RP-Announce من Cisco المستخدمة من قبل Auto-RP |
| 224.0.1.40 | رسائل اكتشاف RP من Cisco المستخدمة بواسطة Auto-RP |
Auto-RP هو آلية Cisco تستخدم في الوضع المتناثر للبث المتعدد المستقل عن البروتوكول لاكتشاف معلومات نقطة الالتقاء (RP) وتوزيعها بشكل ديناميكي عبر مجال البث المتعدد. وهو يزيل الحاجة إلى تكوين RP الثابت باستخدام رسائل مستوى التحكم المستندة إلى البث المتعدد للإعلان عن تعيينات RP إلى مجموعة واختيارها وتعلمها. ومكوناته الرئيسية هي وحدات التخطيط الإقليمي المرشحة، التي تقدم خدمات التخطيط عن بعد لنطاقات محددة من المجموعات، ووكلاء التخطيط، الذين يجمعون المرشحين ويقررون برنامج التخطيط عن بعد لكل مجموعة.
تبدأ العملية عندما يرسل كل مرشح RP دوريا رسائل RP-Announce إلى 224.0.1.39، بما في ذلك عنوان IP الخاص به، والأولوية، ونطاقات مجموعة البث المتعدد المدعومة. يتم تدفق هذه الرسائل عبر الشبكة باستخدام وحدة إصغاء Auto-RP في NX-OS، مما يضمن تلقي جميع وكلاء التعيين لهذه الرسائل حتى قبل تشغيل الشبكة بالكامل في وضع الندرة.
يستمع وكلاء التخطيط إلى هذه الإعلانات، وينشئون قاعدة بيانات RP مرشحة، ويقومون بعملية تحديد محددة لكل مجموعة (عادة ما تكون الأولوية القصوى، ثم عنوان IP الأعلى). بمجرد إختيار أفضل RP، يقوم وكيل التعيين بإنشاء رسائل اكتشاف RP وإرسالها إلى 224.0.1.40، والإعلان عن تعيينات RP-to-group النهائية لجميع الموجهات في المجال.
تتلقى جميع موجهات PIM رسائل RP-Discovery وتثبيت التعيينات في جداول RP المحلية الخاصة بها. مع هذه المعلومات، تقوم موجهات الخطوة الأخيرة (المتصلة بالمتلقي) بإرسال رسائل وصل PIM إلى RP المحدد لإنشاء الشجرة المشتركة (RPT)، بينما تقوم موجهات الخطوة الأولى (المتصلة بالمصادر) بتضمين حركة مرور البث المتعدد في رسائل سجل PIM لإعلام RP بالمصادر النشطة.
مع تدفق حركة المرور عبر RP، يمكن للموجهات التبديل إختياريا من الشجرة المشتركة (RPT) إلى شجرة أقصر مسار (SPT) باستخدام إشارات ربط/تقسيم PIM الإضافية مباشرة نحو المصدر. وخلال هذه العملية، يقوم بروتوكول Auto-RP بتحديث التعيينات بشكل مستمر من خلال رسائل التحكم الدورية، مما يضمن المرونة والتكيف التلقائي مع تغييرات المخطط أو بروتوكول حل العناوين (RP).
عملية RP التلقائية في وضع ندرة PIM (سير عمل مستوى التحكم)
يتم تمكين إعادة التوجيه متعدد المسارات المستندة إلى بروتوكول ECMP بشكل افتراضي، مما يسمح لحركة مرور البث المتعدد باستخدام مسارات متساوية التكلفة لموازنة الحمل.
يتم دعم مصادقة جار PIM باستخدام IPsec AH-MD5.
التطفل على بروتوكول PIM غير متوفر.
يوفر بروتوكول Auto-RP اكتشاف RP ديناميكي وتوزيع تخطيط RP المركزي لبيئات البث المتعدد في الوضع المتناثر ل PIM. إنه يقلل الحاجة إلى تهيئة RP الثابتة على كل موجه للبث المتعدد ويقلل من تعقيد التشغيل ويحسن إمكانية التوسع للبث المتعدد. كما يدعم بروتوكول Auto-RP العديد من برامج RP، مما يتيح إمكانية التغلب على أعطال RP تلقائيا وتكرارها. تساعد هذه الآلية على الحفاظ على سلوك إعادة توجيه البث المتعدد المتسق، وتبسط توسيع الشبكة، وتسمح لموجهات البث المتعدد بتعلم معلومات RP تلقائيا عبر المجال.
عملية التحديد في Auto-RP هي قطعية وتعتمد بشكل أساسي على عناوين IP. على عكس البروتوكولات الأخرى (مثل PIMv2 BSR)، لا يستخدم بروتوكول Auto-RP قيمة "أولوية" قابلة للتكوين؛ بدلا من ذلك، فإنه يعتمد على التدرج الهرمي لعنوان IP لحل التعارضات.
في Auto-RP، يمكن أن يتواجد العديد من وكلاء التعيين ضمن نفس الشبكة للتكرار. فلا توجد عملية انتخابية رسمية حيث ينطفئ أحدهما ويبدأ الآخر في العمل؛ وجميعهم نشطون من الناحية الفنية. ومع ذلك، يجب أن تحدد المحولات في الشبكة المعلومات التي يجب أن تثق بها.
يتم إجراء هذه العملية بواسطة "عامل التعيين" بعد الاستماع إلى كافة رسائل RP-Announce (المرسلة إلى المجموعة 224.0.1.39) من المرشحين.
عندما يستقبل "عامل التعيين" مرشحين متعددين لمجموعة البث المتعدد نفسها، فإنه يطبق القواعد التالية بالترتيب التالي:
القاعدة أ: أطول تطابق للبادئة (القناع الأكثر تحديدا)
إذا قام المرشحون بالإعلان عن نطاقات متداخلة، فإن MA يعين المجموعة إلى RP الذي أعلن عن أقل نطاق (أطول قناع شبكة فرعية).
القاعدة ب: أعلى عنوان IP (قاطع الربط)
إذا قام مرشحان أو أكثر بالإعلان عن نفس نطاق المجموعة بالضبط، يجب أن يختار عامل التعيين واحدا فقط.
على الرغم من أن تركيز هذه المقالة هو البث المتعدد من الطبقة 3 باستخدام PIM، إلا أن سلوك الطبقة 2 يلعب دورا حاسما في أستكشاف الأخطاء وإصلاحها والتصميم الكلي. في الطبقة 2، تتصل الأجهزة باستخدام عناوين MAC، وهي معرفات 48-بت يتم تعيينها لواجهات الشبكة، وحركة مرور البث المتعدد تتطلب مخطط عنوان MAC محدد لتمييزه عن حركة مرور البث الأحادي والبث.
يتم اشتقاق عناوين MAC للبث المتعدد من الطبقة 3 لعناوين مجموعة البث المتعدد باستخدام البادئة المحجوزة '01:00:5E'. ومع ذلك، يتم تعيين 23 بت فقط من عنوان بث IP المتعدد في عنوان MAC، مما يؤدي إلى إنشاء تداخل 32:1، مما يعني أن ما يصل إلى 32 مجموعة IP مختلفة للبث المتعدد يمكن أن تخطط إلى عنوان MAC نفسه. ونتيجة لذلك، يمكن للمضيفين الذين يستمعون إلى عنوان MAC للبث المتعدد أن يستقبلوا حركة مرور البيانات لمجموعات البث المتعدد، حتى إذا كانوا مهتمين بواحد فقط. على سبيل المثال، 224.1.1.1 و 225.1.1.1 و 226.1.1.1 و 227.1.1.1 و 228.1.1.1 وأكثر.
ولهذا التداخل آثار مباشرة على كفاءة الشبكة واستكشاف الأخطاء وإصلاحها. بما أن قرارات إعادة توجيه الطبقة 2 التي تعتمد فقط على عناوين MAC لا يمكن أن تميز بين مجموعات البث المتعدد المتداخلة، فيمكن للمحولات توفير حركة مرور غير ضرورية إلى الأجهزة المضيفة. ويجب أن تعتمد هذه البيئات المضيفة بعد ذلك على تصفية الطبقة الأعلى (IP/IGMP) لتجاهل الحزم غير المرغوب فيها، والاستهلاك لموارد وحدة المعالجة المركزية (CPU) والمخزن المؤقت.
في نظام التشغيل Cisco Nexus NX-OS، يتم الحد من هذا الحد بواسطة سلوك التطفل على بروتوكول IGMP. وبشكل افتراضي، يقوم إستطلاع بروتوكول إدارة مجموعات الإنترنت (IGMP) بتنفيذ عمليات بحث قائمة على بروتوكول الإنترنت (IP) بدلا من إعادة التوجيه عبر بروتوكول التحكم في الوصول للوسائط (MAC) فقط، مما يسمح للمحولات باتخاذ قرارات إعادة توجيه أكثر دقة حتى عندما تتشارك مجموعات متعددة للبث المتعدد في عنوان MAC نفسه. وهذا يحسن بشكل كبير من كفاءة الطبقة الثانية ويقلل من تسليم حركة المرور غير الضرورية.
يقدم هذا القسم شرحا مفصلا لتكوين RP التلقائي، باستخدام تطبيق بسيط كمرجع. في هذا الإعداد، يتم توصيل مصدر بث متعدد بمحولين من Nexus عبر vPC لتسليم حركة مرور البيانات إلى جهاز إستقبال. في هذا التصميم، تعمل كل من N9K-1 و N9K-2 في نفس الوقت كمرشحي RP ووكلاء للخرائط.
تحذير: لا يتم دعم جيران PIM عبر قناة منفذ vPC.
تدفق حركة مرور البث المتعدد
يحتوي التكوين نفسه على FHR-2.
FHR-1# show running-config pim feature pim ip pim auto-rp forward listen interface Vlan1 ip pim sparse-mode interface Ethernet1/1 ip pim sparse-mode interface Ethernet1/3 ip pim sparse-mode
| الغرض / الوصف | |
|---|---|
| خاصية PIM | تمكين عملية PIM (البث المتعدد المستقل عن البروتوكول) على المحول. |
| ip pim auto-rp forward مع الاستماع | تمكين منصت RP التلقائي. وهذا يسمح للمحول بتلقي رسائل التحكم في RP التلقائي وإعادة توجيهها (224.0.1.39 و 224.0.1.40) حتى إذا لم يكن يعرف بعد هوية RP. |
| وضع النثر لبروتوكول IP PIM | تمكين الوضع المتناثر ل PIM على واجهة معينة. في هذا الوضع، تتم إعادة توجيه حركة مرور البث المتعدد فقط إلى المقاطع التي طلبتها بشكل صريح عبر رسائل انضمام PIM. |
N9K-1# show running-config pim feature pim ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15 ip pim auto-rp mapping-agent loopback1 interface loopback0 ip pim sparse-mode interface loopback1 ip pim sparse-mode interface Ethernet1/3 ip pim sparse-mode interface Ethernet1/4 ip pim sparse-mode interface Ethernet1/49 ip pim sparse-mode
يوفر هذا الجدول تفصيلا فنيا لتكوين PIM ل N9K-1. تم نسخ هذا التكوين نسخا متماثلا على N9K-2. تم تكوين كلا المحولين بدور مزدوج، حيث يعمل كمرشح RP ووكيل تعيين لمجال البث المتعدد على حد سواء.
| الشرح الفني التفصيلي | |
|---|---|
| خاصية PIM | تنشيط الميزات: تمكين محرك البث المتعدد المستقل للبروتوكول (PIM) بشكل عام على المحول Nexus. |
| ip pim auto-rp-candidate loopback0 group-list 224.10.20.0/24 interval 15 | دور مرشح RP: تكوين هذا المحول إلى "تطوع" كنقطة الالتقاء (RP). المصدر: يستخدم عنوان IP الخاص ب loopback0 النطاق: وهو يعرض معالجة نطاق مجموعة البث المتعدد 224.10.20.0/24. الفاصل الزمني: إرسال رسائل "إعلان" إلى "وكيل التعيين" كل 15 ثانية. وحدة توقيت الاحتجاز هي ثلاثة أضعاف هذه القيمة. |
| وكيل تعيين IP PIM auto-RP loopback1 | دور وكيل التعيين: تكوين المحول ك "مسؤول" عملية RP التلقائية. الوظيفة: فإنه يستمع إلى جميع مرشحي RP، ويحل التعارضات (باستخدام أعلى عنوان IP كقاطع توصيل)، ويبث رسائل "الاكتشاف" إلى باقي الشبكة لإعلامهم بهوية RP النشط. |
| interface loopback0 / loopback1 | الواجهات المنطقية: يتم تمكين PIM على هذه الواجهات لأنها تعمل كعناوين IP المصدر لأدوار مرشح RP ووكيل التعيين. يجب أن تكون قابلة للوصول إليها عبر جدول توجيه البث الأحادي من جميع موجهات PIM. |
| واجهة إيثرنت 1/3 و 1/4 و 1/49 | إعادة التوجيه المادي: تمكين الوضع المتناثر ل PIM على المنافذ الفعلية. وهذا يسمح للمحول بتكوين تجاور PIM المجاور مع الموجهات الأخرى وإعادة توجيه حركة مرور البث المتعدد عبر هذه الارتباطات المحددة. |
| وضع النثر لبروتوكول IP PIM | وضع التشغيل: مطبق على جميع الواجهات أعلاه. وهو يضمن إرسال حركة مرور البث المتعدد فقط إلى أجهزة الاستقبال التي طلبتها بشكل صريح عبر رسائل PIM Join، مما يمنع طوفان الشبكة غير الضروري. |
جيران PIM والمنطقة 0 من OSPF
N9K-1 — تكوين OSPF
N9K-1(config)# show running-config ospf feature ospf router ospf UNDERLAY router-id 10.2.0.1 interface loopback0 ip router ospf UNDERLAY area 0.0.0.0 interface loopback1 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/3 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/4 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/49 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0
FHR-1 — تكوين OSPF
FHR-1(config)# show running-config ospf feature ospf router ospf UNDERLAY interface Vlan1 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/1 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/3 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0
LHR — تكوين OSPF
LHR(config)# show running-config ospf feature ospf router ospf UNDERLAY interface Vlan2 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/49 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/50 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0
قبل تحليل سلوك البث المتعدد، من المهم التحقق من أن أساس البث الأحادي (منطقة OSPF 0) قيد التشغيل بالكامل. تعتمد بروتوكولات مستوى التحكم للبث المتعدد مثل PIM و Auto-RP على إمكانية الوصول للبث الأحادي للعمل بشكل صحيح.
تتمثل خطوة التحقق الأولى في التأكد من أن المصدر والمستقبل (أو أقرب بوابات الطبقة 3 لهما: FHR و LHR) يمكن الوصول إليها.
من المخطط:
FHR-1 / FHR-2 → الأقرب إلى مصدر البث المتعدد (10.150.1.37 - VLAN 1)
LHR → أقرب جهاز إستقبال للبث المتعدد (192.168.2.37 - VLAN 2)
1. إجراء إختبارات إمكانية الوصول إلى ICMP بين:
FHR ↔ LHR
الشبكة الفرعية لجهاز الاستقبال ↔ FHR (بوابة VLAN 2)
الشبكة الفرعية لمصدر ↔ LHR (بوابة VLAN 1)
2. التحقق من إمكانية الوصول إلى المصدر والمستلم في جدول التوجيه. بالنسبة لعمليات نشر تقنية vPC، تأكد من التناسق عبر كل من نظامي Nexus. لاحظ أن المستقبل به مسار ECMP، حيث أن المصدر يمكن الوصول إليه عبر الطبقة 2.
FHR-1 — المسار إلى المصدر
FHR-1# show ip route 10.150.1.37
10.150.1.37/32, ubest/mbest: 1/0, attached
*via 10.150.1.37, Vlan1, [250/0], 06:57:19, am
FHR-1 — المسار إلى المستقبل
FHR-1# show ip route 192.168.2.37
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
*via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra
FHR-2 — المسار إلى المصدر
FHR-2# show ip route 10.150.1.37
10.150.1.37/32, ubest/mbest: 1/0, attached
*via 10.150.1.37, Vlan1, [250/0], 07:03:45, am
FHR-2 — المسار إلى المستقبل
FHR-2# show ip route 192.168.2.37
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
*via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra
LHR — المسار إلى المصدر
LHR(config)# show ip route 10.150.1.37
10.150.1.0/24, ubest/mbest: 2/0
*via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
*via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra
LHR — المسار إلى المستقبل
LHR(config)# show ip route 192.168.2.37
192.168.2.37/32, ubest/mbest: 1/0, attached
*via 192.168.2.37, Vlan2, [250/0], 06:47:21, am
يشير فشل هذا الاختبار بقوة إلى مشكلة أساسية.
لا يمكن للبث المتعدد العمل بشكل صحيح بدون إمكانية الوصول للبث الأحادي، نظرا لما يلي:
يعتمد جيران PIM على توجيه البث الأحادي
يجب أن تكون عناوين RP (الاسترجاع) قابلة للوصول
تعتمد إختبارات إعادة توجيه المسار العكسي (RPF) على جدول التوجيه
لا يضمن إختبار الاتصال الناجح إمكانية عمل البث المتعدد، لأنه:
يمكن السماح ب ICMP أثناء حظر البث المتعدد
لا يزال من الممكن تكوين PIM أو Auto-RP بشكل غير صحيح
تلميح: قبل تحليل ميزة Auto-RP، أو تجاور PIM، أو تحديد RP، تأكد دائما أن مجال التوجيه الأساسي مستقر ومتسق ويمكن الوصول إليه من نهاية إلى نهاية.
تتمثل الخطوة التالية في تحديد دور كل جهاز مشترك في إعادة توجيه حركة مرور البث المتعدد بشكل واضح. هذه خطوة إجبارية، بما أن أستكشاف أخطاء البث المتعدد وإصلاحها يعتمد تماما على فهم تدفق حركة المرور والسلوك المتوقع عبر المخطط.
وعلى أقل تقدير، يجب تحديد هذه العناصر:
مصدر (مصادر) البث المتعدد: 10.150.1.37 (VLAN 1)
مجموعة البث المتعدد (G): 224.10.20.10
المستقبل: 192.168.2.37 (VLAN 2)
موجه الخطوة الأولى (FHR): FHR-1 / FHR-2 (الأقرب إلى المصدر)
موجه الخطوة الأخيرة (LHR): LHR (الأقرب إلى المستقبل)
وبالإضافة إلى ذلك، يلزم تحديد أدوار مستوى التحكم:
مرشحو برنامج إعادة التوجيه: N9K-1 و N9K-2 (Loopback0)
وكلاء التعيين: N9K-1 و N9K-2 (Loopback1)
مخطط الشبكة التفصيلي إلزامي لمتابعة أي أستكشاف أخطاء البث المتعدد وإصلاحها. ويشمل ذلك ما يلي:
الاتصال المادي (الواجهات المستخدمة بين الأجهزة)
المخطط المنطقي (شبكات VLAN والروابط الموجهة وعلاقات vPC)
بروتوكول التوجيه قيد الاستخدام (منطقة OSPF 0 في هذا التصميم)
حدود مجال التوجيه (بروتوكول العبارة الداخلية الواحد مقابل البروتوكولات المختلطة مثل OSPF أو EIGRP أو BGP)
واجهات الاسترجاع المستخدمة لأدوار RP ووكيل التعيين
الواجهات التي تم تمكين PIM عليها والعلاقات المجاورة
المسار الدقيق من المصدر → FHR → RP → LHR → المستقبل
الأجهزة المسؤولة عن:
إرسال سجل PIM (FHR)
أشجار البناء (*،g) أو (s،g) (lhr)
إعلان معلومات RP (وكيل التعيين)
كيف يضمن التوجيه (OSPF) إمكانية الوصول إلى:
الشبكة الفرعية المصدر
الشبكة الفرعية لجهاز الاستقبال
عناوين إسترجاع RP
تحذير: أستكشاف أخطاء البث المتعدد وإصلاحها دون وجود مخطط واضح يعادل تصحيح الأخطاء دون إمكانية الرؤية - يؤدي ذلك إلى افتراضات غير صحيحة وتشخيص خاطئ.
تتمثل الخطوة التالية في التحقق من تكوين بروتوكول Auto-RP بشكل صحيح على كل جهاز وفقا لدوره في مخطط البث المتعدد. وهذا يشمل تأكيد ما يلي:
يتم تكوين مرشحي RP (N9K-1 / N9K-2) بشكل صحيح للإعلان عن Loopback0 الخاص بهم كنطاق مجموعة البث المتعدد.
يتم تكوين وكلاء التعيين (N9K-1 / N9K-2) لجمع رسائل RP-Announce وإنشاء رسائل اكتشاف RP باستخدام Loopback1.
تحتوي FHR و LHR على وضع ندرة PIM ممكن على جميع الواجهات ذات الصلة للمشاركة في تعيين RP التلقائي واستقبال تعيينات RP.
من الضروري التأكد من تمكين جميع الواجهات المطلوبة (بما في ذلك الاسترجاع والارتباطات الموجهة) لوضع PIM المتناثر، ومن عدم وجود تكوينات مفقودة من شأنها منع تبادل رسائل RP-Announce (224.0.1.39) و RP-Discovery (224.0.1.40).
ملاحظة: يتم تكوين N9K-1 و N9K-2 كموجهات RP وعملاء تعيين داخل مجال البث المتعدد.
تحذير: يمكن أن يمنع أي تكوين RP التلقائي مفقود أو غير متناسق الموجهات من معرفة RP، مما ينتج عنه عدم إعادة توجيه حركة مرور البث المتعدد بشكل صحيح.
تتمثل خطوة التحقق الأولى في التأكد من أن جميع جيران PIM المتوقعين تم تحديدهم بشكل صحيح عبر مخطط البث المتعدد.
N9K-1 — التحقق من جيران PIM
N9K-1# show ip pim neighbor
PIM Neighbor Status for VRF "default"
Neighbor Interface Uptime Expires DR Bidir- BFD ECMP Redirect
Priority Capable State Capable
10.4.0.5 Ethernet1/3 23:19:45 00:01:20 1 yes n/a no
10.4.0.14 Ethernet1/4 23:19:45 00:01:38 1 yes n/a no
10.4.0.21 Ethernet1/49 23:19:45 00:01:38 1 yes n/a no
N9K-2 — التحقق من جيران PIM
N9K-2# show ip pim neighbor
PIM Neighbor Status for VRF "default"
Neighbor Interface Uptime Expires DR Bidir- BFD ECMP Redirect
Priority Capable State Capable
10.4.0.9 Ethernet1/3 23:21:18 00:01:29 1 yes n/a no
10.4.0.17 Ethernet1/4 23:21:18 00:01:23 1 yes n/a no
10.4.0.25 Ethernet1/49 23:21:18 00:01:44 1 yes n/a no
نقاط التحقق من الصحة
في هذه الطوبولوجيا:
تتمثل الخطوة التالية في تأكيد تمكين جميع الواجهات المشاركة في بروتوكول Auto-RP ل PIM.
يعتبر هذا التحقق من الصحة مهما بشكل خاص ل:
N9K-1 — التحقق من واجهات PIM
N9K-1# show ip pim interface brief
PIM Interface Status for VRF "default"
Interface IP Address PIM DR Address Neighbor Border
Count Interface
Ethernet1/3 10.4.0.6 10.4.0.6 1 no
Ethernet1/4 10.4.0.13 10.4.0.14 1 no
Ethernet1/49 10.4.0.22 10.4.0.22 1 no
loopback0 10.2.0.1 10.2.0.1 0 no
loopback1 10.2.1.5 10.2.1.5 0 no
N9K-2 — التحقق من واجهات PIM
N9K-2# show ip pim interface brief
PIM Interface Status for VRF "default"
Interface IP Address PIM DR Address Neighbor Border
Count Interface
Ethernet1/3 10.4.0.10 10.4.0.10 1 no
Ethernet1/4 10.4.0.18 10.4.0.18 1 no
Ethernet1/49 10.4.0.26 10.4.0.26 1 no
loopback0 10.2.0.4 10.2.0.4 0 no
loopback1 10.2.1.4 10.2.1.4 0 no
نقاط التحقق من الصحة:
تعيين دور الاسترجاع:
| في المثال التالي | الوظيفة | إسترجاع |
|---|---|---|
| N9K-1 | مرشح RP | 10.2.0.1 |
| N9K-1 | عامل رسم الخرائط | 10.2.1.5 |
| N9K-2 | مرشح RP | 10.2.0.4 |
| N9K-2 | عامل رسم الخرائط | 10.2.1.4 |
تظهر عمليات الاسترجاع بشكل صحيح كواجهات PIM نشطة على الرغم من أنها لا تشكل جيران PIM. هذا السلوك متوقع لأن واجهات الاسترجاع لا تنشئ تجاور البث المتعدد مباشرة.
إن وجود هذه الاستردادات يؤكد أن:
يتحقق هذا الأمر من الصحة:
N9K-1 — معلومات RP
N9K-1# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.1*, (0), uptime: 22:18:44 priority: 255, RP-source: 10.2.0.1 (A), group ranges: 224.10.20.0/24 , expires: 00:00:37 (A) RP: 10.2.0.4, (0), uptime: 23:00:32 priority: 255, RP-source: 10.2.0.4 (A), group ranges: 224.10.20.0/24 , expires: 00:00:44 (A)
شرح خط بسطر
BSR معطل
BSR disabled
وهذا يؤكد ما يلي:
هذا السلوك متوقع في هذه الطوبولوجيا.
Auto-RP RPA: 10.2.1.5*
Auto-RP RPA: 10.2.1.5*
وهذا يعني:
رسالة الاكتشاف التالية في
next Discovery message in: 00:00:39
إذا قام المؤقت بتجميد أو انتهاء صلاحيته بشكل غير متوقع، لا يمكن نشر إعلانات Auto-RP بشكل صحيح.
حقول النهج
BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None
إدخال RP الأول
RP: 10.2.0.1*, (0),
وهذا يؤكد تكوين N9K-1 كمرشح RP.
وقت التشغيل والأولوية
uptime: 22:18:44 priority: 255,
مصدر RP
RP-source: 10.2.0.1 (A),
نطاق المجموعة
224.10.20.0/24
إدخال RP الثاني
RP: 10.2.0.4, (0),
N9K-2 — معلومات RP
N9K-2# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28 RP: 10.2.0.4*, (0), uptime: 23:14:14 priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:28 (A)
الاختلافات الأساسية على N9K-2
Auto-RP RPA: 10.2.1.5
فرق RP الهام
RP-source: 10.2.1.5 (A),
وهذا يؤكد ما يلي:
يستخدم بروتوكول Auto-RP دالتين مختلفتين للتحكم في البث المتعدد:
يعتبر فهم كيفية تفاعل هذه الوظائف أمرا بالغ الأهمية عند التحقق من صحة عملية البث المتعدد في بيئة وضع ندرة PIM.
في هذه الطوبولوجيا:
عملية مرشح RP
يعلن مرشح RP عن نفسه كنقطة تجميع صالحة لنطاق مجموعة واحدة أو أكثر من نطاقات مجموعات البث المتعدد.
يقوم كل مرشح RP بإرسال رسائل إعلان RP التلقائي بشكل دوري إلى:
تحتوي هذه الإعلانات على:
في هذه الطوبولوجيا:
N9K-1 — معلومات مرشح RP
N9K-1# show ip pim rp <snip>
RP: 10.2.0.1*, (0),
uptime: 23:11:22 priority: 255,
RP-source: 10.2.0.1 (A),
group ranges:
224.10.20.0/24 , expires: 00:00:38 (A)
RP: 10.2.0.4, (0),
uptime: 23:53:09 priority: 255,
RP-source: 10.2.0.4 (A),
group ranges:
224.10.20.0/24 , expires: 00:00:43 (A)
N9K-2 — معلومات مرشح RP
N9K-2# show ip pim rp <snip>
RP: 10.2.0.4*, (0),
uptime: 1d00h priority: 255,
RP-source: 10.2.1.5 (A),
group ranges:
224.10.20.0/24 , expires: 00:02:52 (A)
يعلن كلا الجهازين عن نطاق مجموعة البث المتعدد نفسه:
يستخدم كل من المرشحين لمنصب rp أيضا:
هذا مهم لأن Auto-RP يستخدم الأولوية وعنوان RP أثناء تحديد RP.
تعريف عامل التعيين النشط
يحدد "عامل التعيين" RP النشط لمجموعة البث المتعدد بدءا من هذا المنطق:
في هذه الطوبولوجيا:
لأن كلا مرشحي rp لهما الأولوية نفسها:
لذلك:
التحقق من صحة RP المحدد
N9K-2 — RP المحدد
N9K-2# show ip pim rp <snip> RP: 10.2.0.4*, (0), uptime: 23:14:14 priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24
لماذا لا يزال N9K-1 يعرض كلا إدخالات RP
على N9K-1:
N9K-1# show ip pim rp <snip> RP: 10.2.0.1*, (0), RP: 10.2.0.4, (0),
هذا السلوك متوقع بسبب:
تحذير: في عامل التعيين، يجب أن تظهر جميع مرشحي RP داخل مجال البث المتعدد نفسه. إذا كان أي RP-Candidate مفقودا، فتحقق من إمكانية الوصول عن طريق إرسال إختبار اتصال إلى عنوان IP لمرشح RP الذي تم الحصول عليه من عنوان IP لعامل التعيين، وعادة ما تكون واجهة إسترجاع.
يجب أن تحافظ جميع موجهات البث المتعدد المشاركة في مجال وضع ندرة PIM على إمكانية وصول IP بشكل ثابت إلى:
يعد هذا التحقق من الصحة أمرا بالغ الأهمية لأن وضع ندرة PIM يعتمد على توجيه البث الأحادي إلى:
إذا فشلت إمكانية الوصول إلى RP أو وكيل التعيين:
يجب أن يحتوي جدول التوجيه على مسارات ثابتة للبث الأحادي تجاه:
يجب أن تظل المسارات مثبتة بشكل مستمر دون إرباك المسار أو حدوث أحداث إعادة تقارب مفرطة.
التحقق من الصحة:
FHR-1 — المسار إلى مرشح RP 10.2.0.1
FHR-1# show ip route 10.2.0.1
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.1/32, ubest/mbest: 1/0
*via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — المسار إلى مرشح RP 10.2.0.4
FHR-1# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — مسار إلى وكيل رسم الخرائط 10.2.1.5
FHR-1# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — مسار إلى وكيل رسم الخرائط 10.2.1.4
FHR-1# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — المسار إلى مرشح RP 10.2.0.1
FHR-2# show ip route 10.2.0.1
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.1/32, ubest/mbest: 1/0
*via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — المسار إلى مرشح RP 10.2.0.4
FHR-2# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — مسار إلى وكيل رسم الخرائط 10.2.1.5
FHR-2# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — مسار إلى وكيل رسم الخرائط 10.2.1.4
FHR-2# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra
LHR — المسار إلى مرشح RP 10.2.0.1
LHR# show ip route 10.2.0.1
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.1/32, ubest/mbest: 1/0
*via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — المسار إلى مرشح RP 10.2.0.4
LHR# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — مسار إلى وكيل التعيين 10.2.1.5
LHR# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — مسار إلى وكيل التعيين 10.2.1.4
LHR# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra
بعد التحقق من صحة جدول التوجيه، تحقق من إمكانية الوصول إلى IP الشاملة تجاه:
يجب الحصول على إختبار الاتصال من:
هذا التحقق من الصحة مهم لأن موجهات البث المتعدد تستخدم عناوين المصدر التالية أثناء:
تلميح: إذا تم إستخدام واجهات غير مرقمة، حيث تتشارك واجهات متعددة من الطبقة 3 في عنوان IP نفسه من واجهة الاسترجاع، يصبح التحقق من إمكانية الوصول أكثر بساطة لأنه يمكن إستخدام عنوان IP أحادي المصدر باستمرار.
| في المثال التالي | IP المصدر | الوجهة | الوظيفة | نتيجة |
|---|---|---|---|---|
| إف إتش إتش-1 | 10.4.0.5 | 10.2.0.1 | مرشح RP | نجحت العملية |
| إف إتش إتش-1 | 10.4.0.5 | 10.2.0.4 | مرشح RP | نجحت العملية |
| إف إتش إتش-1 | 10.4.0.5 | 10.2.1.5 | عامل رسم الخرائط | نجحت العملية |
| إف إتش إتش-1 | 10.4.0.5 | 10.2.1.4 | عامل رسم الخرائط | نجحت العملية |
| إف إتش إتش-2 | 10.4.0.9 | 10.2.0.1 | مرشح RP | نجحت العملية |
| إف إتش إتش-2 | 10.4.0.9 | 10.2.0.4 | مرشح RP | نجحت العملية |
| إف إتش إتش-2 | 10.4.0.9 | 10.2.1.5 | عامل رسم الخرائط | نجحت العملية |
| إف إتش إتش-2 | 10.4.0.9 | 10.2.1.4 | عامل رسم الخرائط | نجحت العملية |
| ل.ر | 10.4.0.5 | 10.2.0.1 | مرشح RP | نجحت العملية |
| ل.ر | 10.4.0.5 | 10.2.0.4 | مرشح RP | نجحت العملية |
| ل.ر | 10.4.0.5 | 10.2.1.5 | عامل رسم الخرائط | نجحت العملية |
| ل.ر | 10.4.0.5 | 10.2.1.4 | عامل رسم الخرائط | نجحت العملية |
تتمثل خطوة التحقق التالية في التحقق من:
قبل التحقق من صحة حالة إعادة توجيه البث المتعدد، تحقق من أن جميع موجهات البث المتعدد علمت RP المتوقع لمجموعة البث المتعدد قيد التحقق.
هذه الخطوة مهمة لأن:
في هذه الطوبولوجيا:
FHR-1 — التحقق من RP الذي تم التعرف عليه
FHR-1# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.4, (0), uptime: 1d03h priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:30 (A)
FHR-2 — التحقق من RP الذي تم التعرف عليه
FHR-2# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.4, (0), uptime: 1d03h priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:15 (A)
LHR — التحقق من RP الذي تم التعرف عليه
LHR# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.4, (0), uptime: 1d03h priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:07 (A)
تحليل تعلم RP
وتؤكد النواتج ما يلي:
هذا السلوك متوقع بسبب:
في هذه المرحلة، يعمل مستوى التحكم في البث المتعدد بشكل صحيح، كما أن جميع الموجهات لديها تخطيط RP متناسق ل 224.10.20.0/24
تتمثل الخطوة التالية في التحقق من صحة جدول توجيه البث المتعدد قبل بدء نقل حركة مرور البث المتعدد.
في هذا السيناريو:
هذه الحالة مهمة لأنها تتحقق:
FHR-1 — جدول توجيه البث المتعدد
FHR-1# show ip mroute IP Multicast Routing Table for VRF "default" (*, 232.0.0.0/8), uptime: 23:07:34, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
FHR-2 — جدول توجيه البث المتعدد
FHR-2# show ip mroute IP Multicast Routing Table for VRF "default" (*, 232.0.0.0/8), uptime: 23:07:37, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
تحليل حالة البث المتعدد ل FHR
لا تحتوي هذه اللوائح بعد على:
هذا السلوك متوقع بسبب:
الإدخال الوحيد للبث المتعدد الموجود هو:
وهذا يتوافق مع نطاق SSM الافتراضي ويتم تثبيته تلقائيا بواسطة النظام.
هذه القيم متوقعة:
لا يشير هذا الإدخال إلى إعادة توجيه البث المتعدد النشطة.
LHR — جدول توجيه البث المتعدد
LHR# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
Outgoing interface list: (count: 1)
Vlan2, uptime: 23:07:39, igmp
(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
تحليل حالة البث المتعدد ل LHR
بخلاف FHRs، تحتوي LHR على إدخال (*،G) نشط ل:
هذا السلوك متوقع بسبب:
يؤكد جدول توجيه البث المتعدد:
وهذا يشير إلى ما يلي:
في هذه المرحلة:
N9K-1 — جدول توجيه البث المتعدد لوكيل التعيين
N9K-1# show ip mroute IP Multicast Routing Table for VRF "default" (*, 232.0.0.0/8), uptime: 1d03h, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
تحليل حالة البث المتعدد لوكيل التعيين
يعمل N9K-1 كعميل تعيين فقط ولا يشارك في إعادة توجيه البث المتعدد ل 224.10.20.10
وبالتالي، من المتوقع عدم وجود إدخالات (*، g) و(s،g).
يقوم "عامل التعيين" فقط بتوزيع معلومات تعيين RP ولا يشارك بالضرورة في إعادة توجيه بيانات البث المتعدد ما لم تجتاز حركة مرور البث المتعدد الجهاز مباشرة.
N9K-2 — جدول توجيه البث المتعدد ل RP
N9K-2# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 1d01h, pim ip
Incoming interface: loopback0, RPF nbr: 10.2.0.4
Outgoing interface list: (count: 1)
Ethernet1/49, uptime: 1d01h, pim
(*, 232.0.0.0/8), uptime: 1d03h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
تحليل حالة بث RP المتعدد
تعمل N9K-2 كبروتوكول RP نشط من أجل:
لذلك، يحتوي RP على حالة الشجرة المشتركة (*،G) ل 224.10.20.10
هذه القيم متوقعة:
وهذا يشير إلى ما يلي:
في هذه المرحلة:
بمجرد بدء إرسال حركة مرور البث المتعدد، يتم نقل جدول توجيه البث المتعدد من حالة الشجرة المشتركة إلى حالة إعادة التوجيه النشطة الخاصة بالمصدر.
في هذا السيناريو:
اعتبارات هامة للبث المتعدد للكمبيوتر الشخصي vPC
يتصل مصدر البث المتعدد من خلال مجال vPC مكون من قبل FHR-1 و FHR-2.
لأن المصدر يتصل من خلال vPC عضو ميناء-channel:
في هذا سيناريو محدد:
FHR-1 — جدول توجيه البث المتعدد
FHR-1# show ip mroute IP Multicast Routing Table for VRF "default" (10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim Incoming interface: Vlan1, RPF nbr: 10.150.1.37 Outgoing interface list: (count: 0) (*, 232.0.0.0/8), uptime: 1d00h, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
دور FHR-1 — vPC
FHR-1# show vpc role vPC Role status ---------------------------------------------------- vPC role : primary <<< Dual Active Detection Status : 0 vPC system-mac : 00:23:04:ee:be:01 vPC system-priority : 32667 vPC local system-mac : 00:6b:f1:84:02:97 vPC local role-priority : 32667 vPC local config role-priority : 32667 vPC peer system-mac : 6c:b2:ae:ee:5a:97 vPC peer role-priority : 32667 vPC peer config role-priority : 32667
تحليل حالة البث المتعدد وفقا لمعيار FHR-1
يحتوي FHR-1 على إدخال نشط (S،G) ل:
يؤكد إدخال توجيه البث المتعدد:
من المتوقع أن يكون هذا السلوك لأن تدفق البث المتعدد لم يتم تجزئة إتجاه FHR-1 لإعادة التوجيه الصادرة.
ونتيجة لذلك:
FHR-2 — جدول توجيه البث المتعدد
FHR-2# show ip mroute
IP Multicast Routing Table for VRF "default"
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
Incoming interface: Vlan1, RPF nbr: 10.150.1.37
Outgoing interface list: (count: 1)
Ethernet1/3, uptime: 00:16:35, pim
(*, 232.0.0.0/8), uptime: 1d00h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
دور FHR-2 — vPC
FHR-2# show vpc role vPC Role status ---------------------------------------------------- vPC role : secondary <<< Dual Active Detection Status : 0 vPC system-mac : 00:23:04:ee:be:01 vPC system-priority : 32667 vPC local system-mac : 6c:b2:ae:ee:5a:97 vPC local role-priority : 32667 vPC local config role-priority : 32667 vPC peer system-mac : 00:6b:f1:84:02:97 vPC peer role-priority : 32667 vPC peer config role-priority : 32667
تحليل حالة البث المتعدد FHR-2
على عكس FHR-1، يحتوي FHR-2 على:
وهذا يشير إلى ما يلي:
سلوك إعادة توجيه ECMP والبث المتعدد
تطابق الواجهة الصادرة Ethernet1/3 جدول توجيه البث الأحادي تجاه المستقبل 192.168.2.37
FHR-2 — توجيه إلى مستقبل البث المتعدد
FHR-2# show ip route 192.168.2.37
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
*via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra
يحتوي FHR-2 على مسارين متساويين التكلفة تجاه الشبكة الفرعية لإستقبال البث المتعدد:
وهذا يؤكد ما يلي:
على الرغم من وجود مسارين متساويين التكلفة، فإن إعادة توجيه البث المتعدد تستخدم مسار إعادة توجيه المسار العكسي (RPF) واحدا لكل تدفق للبث المتعدد.
في هذا المخطط، يستخدم تدفق البث المتعدد:
يتطابق هذا السلوك مع جدول توجيه البث المتعدد الذي تمت ملاحظته سابقا:
(10.150.1.37/32, 224.10.20.10/32)
Outgoing interface list:
Ethernet1/3
تؤثر الأدوار التشغيلية للكمبيوتر الشخصي vPC على سلوك إعادة توجيه البث المتعدد بشكل مختلف من أجل:
في هذه الطوبولوجيا:
يمكن لكل من محولي Nexus:
ومع ذلك:
هذا التمييز مهم لأن:
لذلك:
LHR — جدول توجيه البث المتعدد
LHR# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
Outgoing interface list: (count: 1)
Vlan2, uptime: 1d00h, igmp
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
Outgoing interface list: (count: 1)
Vlan2, uptime: 00:06:31, mrib
(*, 232.0.0.0/8), uptime: 1d00h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
تحتوي LHR الآن على كليهما:
وهذا يؤكد:
يؤكد إدخال (S،G):
ويؤكد هذا السلوك النجاح:
N9K-1 — جدول توجيه البث المتعدد العابرة
N9K-1# show ip mroute
IP Multicast Routing Table for VRF "default"
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
Outgoing interface list: (count: 1)
Ethernet1/49, uptime: 00:06:42, pim
(*, 232.0.0.0/8), uptime: 1d04h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
تحليل حالة النقل N9K-1
يعمل N9K-1 كموجه متعدد البث العابرة للتدفق النشط للبث المتعدد.
يؤكد إدخال توجيه البث المتعدد:
وهذا يؤكد النجاح:
N9K-2 — جدول توجيه البث المتعدد ل RP
N9K-2# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 1d02h, pim ip
Incoming interface: loopback0, RPF nbr: 10.2.0.4
Outgoing interface list: (count: 1)
Ethernet1/49, uptime: 1d02h, pim
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
Outgoing interface list: (count: 0)
(*, 232.0.0.0/8), uptime: 1d04h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
يعمل N9K-2 كبروتوكول RP نشط لمجموعة البث المتعدد.
يحتوي RP على كل من:
من المتوقع غياب الواجهات الصادرة في الإدخال (S،G) بسبب:
توفر قائمة الأوامر الحد الأدنى من مجموعة بيانات البث المتعدد الموصى بها والمطلوبة لإجراء تحليل سبب جذر (RCA) مناسب أو تشخيص صحة البث المتعدد على محولات Cisco Nexus 9000 Series التي تشغل NX-OS. تتضمن هذه المخرجات تفاصيل حالة لوحة التحكم في البث المتعدد، وبرمجة MRIB، ومعلومات إعادة التوجيه، وحالة تشغيل vPC، وإعادة توجيه الأجهزة. ومع ذلك، لا يزال من الممكن طلب معلومات إضافية بناء على سيناريو الفشل. على سبيل المثال، غالبا ما يتطلب فقد حزم البث المتعدد أو حالات إسقاط حركة مرور متقطعة أو مشاكل نسخ الحزم المتماثل أو عدم تناسق إعادة توجيه الأجهزة أو إعادة توجيه البث المتعدد خارج الترتيب التقاط الحزم المباشر على المحول Nexus باستخدام Ethanalyzer أو الفسحة بين دعامتين أو التقاط مستوى الأجهزة. وبالمثل، يمكن أن تحدث حالات عدم تناسق إعادة توجيه المسار العكسي (RPF) العابرة أو تغييرات إعادة توجيه بروتوكول إدارة مجموعات الإنترنت (ECMP) أو حالات فشل برمجة ASIC أو أحداث قمع بروتوكول إدارة مجموعات الإنترنت (IGMP) دون إنشاء سجل دائم.
ونتيجة لذلك، فإن الجمع بين إخراج show tech مع التقاط الحزم والتحقق من إعادة التوجيه يعمل على تحسين الدقة التشخيصية وجودة RCA بشكل كبير. على الرغم من أن هذه المعلومات توفر خط أساس تشغيلي قوي لاستكشاف أخطاء البث المتعدد وإصلاحها، إلا أنها لا تضمن إمكانية تحديد ترخيص المواد المسترجعة دائما بشكل حصري من هذه المخرجات. تتطلب بعض حالات فشل البث المتعدد أستكشاف أخطاء إضافية وإصلاحها أو تحليل حركة مرور بيانات مباشرة أو التحقق من مستوى الأجهزة أو إرتباط المخطط أو التقاط الحزم الموسعة لعزل السبب الجذري الدقيق.
تلميح: إن جمع هذه المعلومات أثناء العمل وغير العمل يوفر لقطة واضحة لكيفية ظهور المشكلة من منظور Nexus ويحسن بشكل كبير من القدرة على تحديد السبب الجذري.
N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt
N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt
بعد إنشاء ملفات show tech، قم بدمجها في أرشيف TAR واحد للتصدير والتحليل. الأمر عبارة عن سطر واحد.
N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt
تصدير أرشيف TAR واحد يبسط:
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
13-May-2026
|
الإصدار الأولي |