أستكشاف أخطاء Auto-RP للبث المتعدد وإصلاحها على Nexus 9000 باستخدام NX-OS

المقدمة

يصف هذا وثيقة كيف يعمل Auto-RP على Cisco Nexus 9000 مع NX-OS وكيفية التحقق من صحة عملية البث المتعدد واستكشاف أخطائها وإصلاحها.

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

المتطلبات

• معرفة أساسية ببث IP المتعدد
• معرفة أساسية بوضع IGMP و PIM المتناثر
• تجربة مع واجهة سطر الأوامر Cisco Nexus 9000 و NX-OS
• فهم مفاهيم توجيه البث الأحادي وإعادة توجيه المسار العكسي (RPF)

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

• سلسلة مبدلات Cisco Nexus 9000
• برنامج NX-OS من Cisco
• الوضع المتناثر ل PIM
• RP الثابت و Auto-RP

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

نظرة عامة على البث المتعدد

البث المتعدد هو نموذج اتصال من واحد إلى كثير حيث يرسل المصدر تدفق حركة مرور واحد إلى العديد من أجهزة الاستقبال المهتمة. وبدلا من إنشاء نسخة منفصلة لكل وجهة، تقوم الشبكة بنسخ حركة مرور البيانات فقط حيث يتم إنشاء فروع مسار إعادة التوجيه. وهذا يجعل البث المتعدد أكثر فعالية من البث أو الإرسال الأحادي المتكرر. في 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

عملية RP التلقائية في وضع ندرة PIM (سير عمل مستوى التحكم)

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 (سير عمل مستوى التحكم)

قيود بروتوكول RP التلقائي وقيود التشغيل

• يعمل بروتوكول Auto-RP فقط مع البث المتعدد عبر بروتوكول IPv4 وهو غير مدعوم للإصدار السادس من بروتوكول الإنترنت (PIM6)، لذلك تتطلب عمليات نشر بروتوكول IPv6 آلية اكتشاف RP مختلفة.
• لا يمكن أن يتواجد Auto-RP مع BSR داخل مجال PIM نفسه، لأنه يمكن تكوين آلية اكتشاف RP واحدة فقط لتجنب تعارضات مستوى التحكم.
• لا تتم معالجة رسائل RP التلقائية أو إعادة توجيهها بشكل افتراضي على أجهزة NX-OS، لذلك يلزم توفر تكوين صريح للتشغيل السليم.
• يعتمد نشر رسائل التحكم في RP التلقائي على تمكين منصت RP التلقائي؛ وإلا، لا تصل معلومات تعيين RP إلى جميع الموجهات.
• يحتوي الفاصل الزمني لإعلان RP على حد أدنى مقداره 15 ثانية، مما يحد من سرعة الإعلان عن تحديثات RP ويؤثر على وقت التقارب.
• يمكن أن تؤثر تصفية رسائل RP التلقائية من خلال خرائط المسار على العملية، لأن السياسات غير الصحيحة يمكن أن تمنع تعيينات RP إلى المجموعة.
• يتم تعطيل بروتوكول Auto-RP بشكل افتراضي في سياقات VRF، لذلك يجب تمكينه بشكل صريح في عمليات نشر بروتوكول VRF المتعدد.

• يتم تمكين إعادة التوجيه متعدد المسارات المستندة إلى بروتوكول ECMP بشكل افتراضي، مما يسمح لحركة مرور البث المتعدد باستخدام مسارات متساوية التكلفة لموازنة الحمل.

• يتم دعم مصادقة جار PIM باستخدام IPsec AH-MD5.

• التطفل على بروتوكول PIM غير متوفر.

فوائد إستخدام Auto-RP

يوفر بروتوكول Auto-RP اكتشاف RP ديناميكي وتوزيع تخطيط RP المركزي لبيئات البث المتعدد في الوضع المتناثر ل PIM. إنه يقلل الحاجة إلى تهيئة RP الثابتة على كل موجه للبث المتعدد ويقلل من تعقيد التشغيل ويحسن إمكانية التوسع للبث المتعدد. كما يدعم بروتوكول Auto-RP العديد من برامج RP، مما يتيح إمكانية التغلب على أعطال RP تلقائيا وتكرارها. تساعد هذه الآلية على الحفاظ على سلوك إعادة توجيه البث المتعدد المتسق، وتبسط توسيع الشبكة، وتسمح لموجهات البث المتعدد بتعلم معلومات RP تلقائيا عبر المجال.

عامل تعيين RP التلقائي وعملية تحديد RP

عملية التحديد في Auto-RP هي قطعية وتعتمد بشكل أساسي على عناوين IP. على عكس البروتوكولات الأخرى (مثل PIMv2 BSR)، لا يستخدم بروتوكول Auto-RP قيمة "أولوية" قابلة للتكوين؛ بدلا من ذلك، فإنه يعتمد على التدرج الهرمي لعنوان IP لحل التعارضات.

تحديد عامل التعيين (MA)

في Auto-RP، يمكن أن يتواجد العديد من وكلاء التعيين ضمن نفس الشبكة للتكرار. فلا توجد عملية انتخابية رسمية حيث ينطفئ أحدهما ويبدأ الآخر في العمل؛ وجميعهم نشطون من الناحية الفنية. ومع ذلك، يجب أن تحدد المحولات في الشبكة المعلومات التي يجب أن تثق بها.

• معيار التحديد: أعلى عنوان IP.
• العملية:
  1. يرسل جميع وكلاء التعيين رسائل اكتشاف RP الخاصة بهم إلى مجموعة البث المتعدد 224.0.1.40.
  2. تتلقى محولات العميل هذه الرسائل.
  3. إذا كان المحول يتلقى رسائل اكتشاف من إثنين مختلفين من عملاء التعيين تحتوي على معلومات متعارضة، فإن المحول يقبل المعلومات من وكيل التعيين مع أعلى عنوان IP للمصدر.
  4. سلوك Nexus: يدخل عامل التعيين الذي له عنوان IP أقل بشكل نموذجي حالة "الخاملة" أو "القمع" عند اكتشاف عنوان IP أعلى آخر مع منع تكرار حركة مرور التحكم في الشبكة.

تحديد نقطة الالتقاء (RP)

يتم إجراء هذه العملية بواسطة "عامل التعيين" بعد الاستماع إلى كافة رسائل RP-Announce (المرسلة إلى المجموعة 224.0.1.39) من المرشحين.

عندما يستقبل "عامل التعيين" مرشحين متعددين لمجموعة البث المتعدد نفسها، فإنه يطبق القواعد التالية بالترتيب التالي:

القاعدة أ: أطول تطابق للبادئة (القناع الأكثر تحديدا)

إذا قام المرشحون بالإعلان عن نطاقات متداخلة، فإن MA يعين المجموعة إلى RP الذي أعلن عن أقل نطاق (أطول قناع شبكة فرعية).

• مثال:
  • المرشح A يعلن عن نطاق البث المتعدد بالكامل 224.0.0.0/4 (the).
  • المرشح B يعلن 224.10.20.0/24.
  • النتيجة: وبالنسبة للفئة 224.10.20.5، يفوز المرشح باء لأن نطاقها أكثر تحديدا.

القاعدة ب: أعلى عنوان IP (قاطع الربط)

إذا قام مرشحان أو أكثر بالإعلان عن نفس نطاق المجموعة بالضبط، يجب أن يختار عامل التعيين واحدا فقط.

• المعيار: يفوز المرشح صاحب أعلى عنوان IP.
• مثال:
  • المرشح الأول: 10.2.0.1 للمدى 224.10.20.0/24.
  • المرشح الثاني: 10.2.0.4 للمدى 224.10.20.0/24.
  • النتيجة: يحدد "عامل التعيين" 10.2.0.4 ك RP الرسمي لذلك النطاق ويتم الإعلان عن ذلك في رسائل الاكتشاف الخاصة به.

اعتبارات الطبقة 2: MAC الخاص بالبث المتعدد والتطفل

على الرغم من أن تركيز هذه المقالة هو البث المتعدد من الطبقة 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 التلقائي

يقدم هذا القسم شرحا مفصلا لتكوين RP التلقائي، باستخدام تطبيق بسيط كمرجع. في هذا الإعداد، يتم توصيل مصدر بث متعدد بمحولين من Nexus عبر vPC لتسليم حركة مرور البيانات إلى جهاز إستقبال. في هذا التصميم، تعمل كل من N9K-1 و N9K-2 في نفس الوقت كمرشحي RP ووكلاء للخرائط.

تدفق حركة مرور البث المتعدد

موجه الخطوة الأولى

يحتوي التكوين نفسه على 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.

وكيل التعيين ومرشح RP

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، مما يمنع طوفان الشبكة غير الضروري.

تكوين التوجيه لإمكانية الوصول إلى IPv4

• في هذا المخطط، تشارك جميع محولات Nexus في عملية OSPF واحدة باسم Underlay، حيث تعمل داخل المنطقة 0 (0.0.0.0) لتوفير إمكانية الوصول إلى التوجيه الكامل عبر الشبكة.
• على LHR، يتم تمكين OSPF على شبكة VLAN رقم 2، والتي تعمل كبوابة لمستقبل البث المتعدد، وعلى واجهات الوصلة Ethernet1/49 و Ethernet1/50، ويتم تكوين كليهما كنقطة إلى نقطة. وهذا يضمن تكوين عمليات تجاور فعالة تجاه محولات N9K التي تعمل بالجزء العلوي من الخادم دون الحاجة إلى انتخابات عن طريق عمليات الاسترداد من بعد الكوارث (DR)/عمليات إعادة التوجيه من بعد (BDR).
• تتشارك طبقة FHR (FHR-1 و FHR-2) في تكوين مطابق. يتم تمكين OSPF على شبكة VLAN رقم 1، والتي تعمل كبوابة لمصدر البث المتعدد، وعلى الوصلات الموجهة (Ethernet1/1 و Ethernet1/3) نحو طبقة التجميع. ويتم تكوين هذه الارتباطات أيضا كنقطة إلى نقطة، مما يعمل على تحسين سلوك التقارب والتجاور.
• وبالمثل، فإن N9K-1 و N9K-2 لهما تكوينات OSPF متطابقة، مع إضافة إعلان Loopback0 و Loopback1 إلى OSPF.
  • تعد عمليات الاسترجاع هذه أمرا بالغ الأهمية، حيث يتم إستخدامها لاحقا لأدوار مرشح PIM RP ووكيل التعيين.

جيران 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

التحقق من حالة التشغيل واستكشاف أخطاء RP التلقائي وإصلاحها

الخطوة 1: التحقق من إمكانية الوصول إلى IP الأساسي (التحقق من صحة Unicast الأساسي)

قبل تحليل سلوك البث المتعدد، من المهم التحقق من أن أساس البث الأحادي (منطقة 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 بشكل غير صحيح

الخطوة 2: تحديد أدوار البث المتعدد والهيكل الشامل

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

وعلى أقل تقدير، يجب تحديد هذه العناصر:

• مصدر (مصادر) البث المتعدد: 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

  • تخطيط عناوين الاسترجاع التعطيلية

الخطوة 3: التحقق من تكوين 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).

الخطوة 4: التحقق من صحة عملية جميع مرشحي RP وجميع وكلاء التعيين

الخطوة 4.1 تحقق من تجاور جوار PIM

تتمثل خطوة التحقق الأولى في التأكد من أن جميع جيران 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

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

• تحقق من ظهور كافة الجيران المتوقعين على كل واجهة موجهة.
• تحقق من إستقرار وقت عمل الجوار وازدياده باستمرار.
• تحقق من تحديث مؤقت انتهاء الصلاحية بشكل دوري.
• تحقق من عدم حدوث أي حركات تدفق غير متوقعة للتجاور.
• تحقق من إختيار الموجه المعين (DR) الصحيح.
• تحقق من أن واجهات البث المتعدد تشكل عمليات تجاور PIM بنجاح.

في هذه الطوبولوجيا:

• تقوم N9K-1 بإنشاء ثلاثة جيران PIM.
• كما تؤسس N9K-2 ثلاثة من جيران PIM.
• تبقى جميع عمليات التجاور مستقرة لأكثر من 23 ساعة، مما يشير إلى تشغيل مستوى التحكم في البث المتعدد بشكل ثابت.

---

الخطوة 4.2 التحقق من الواجهات التي تم تمكين PIM عليها

تتمثل الخطوة التالية في تأكيد تمكين جميع الواجهات المشاركة في بروتوكول Auto-RP ل PIM.

يعتبر هذا التحقق من الصحة مهما بشكل خاص ل:

• إعادة توجيه مرشح RP
• إستعراضات وكيل التعيين

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

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

• تحقق من ظهور جميع واجهات البث المتعدد الموجهة في الإخراج.
• تحقق من تمكين عمليات إعادة توجيه مرشح RP ل PIM.
• تحقق من تمكين PIM لعملاء التعيين.
• تحقق من صحة عمليات العد المجاورة على واجهات النقل.
• تحقق من إظهار واجهات الاسترجاع بشكل صحيح عدد الجيران = 0.

تعيين دور الاسترجاع:

في المثال التالي	الوظيفة	إسترجاع
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. هذا السلوك متوقع لأن واجهات الاسترجاع لا تنشئ تجاور البث المتعدد مباشرة.

إن وجود هذه الاستردادات يؤكد أن:

• يمكن أن يصدر PIM رسائل التحكم في RP التلقائي بشكل صحيح.
• يمكن إنشاء إعلانات RP بنجاح.
• يمكن أن تعمل وظائف "عامل التعيين" بشكل صحيح.

---

الخطوة 4.3 تحليل عرض ip pim rp

يتحقق هذا الأمر من الصحة:

• اكتشاف RP
• إعلانات Auto-RP
• عملية عامل التعيين
• تعيينات مجموعة إلى RP

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

وهذا يؤكد ما يلي:

• لم يتم إستخدام موجه بروتوكول نظام تمهيد تشغيل الكمبيوتر (BSR).
• يعتمد مجال البث المتعدد بشكل حصري على Auto-RP.

هذا السلوك متوقع في هذه الطوبولوجيا.

Auto-RP RPA: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 يتوافق مع الاسترجاع 1 على N9K-1.
• يشير * إلى أن المحول المحلي نفسه هو عامل التعيين النشط.

وهذا يعني:

• تقوم N9K-1 بإنشاء رسائل RP-Discovery.
• تجمع N9K-1 إعلانات RP من مرشحي RP.
• تقوم N9K-1 بتوزيع معلومات تعيين RP إلى مجال البث المتعدد.

رسالة الاكتشاف التالية في

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 الأول

RP: 10.2.0.1*, (0),

• عنوان RP = 10.2.0.1
• يشير * إلى أن RP هذا محلي ل N9K-1.
• 10.2.0.1 يماثل loopback0 على N9K-1.

وهذا يؤكد تكوين N9K-1 كمرشح RP.

وقت التشغيل والأولوية

uptime: 22:18:44   priority: 255,

• وقت تشغيل ثابت يشير إلى تشغيل إعلانات RP بشكل ثابت.
• الأولوية 255 هي الأولوية القصوى الافتراضية.

مصدر RP

RP-source: 10.2.0.1 (A),

• تم إنشاء إعلان RP مباشرة من RP نفسه.
• (أ) يشير إلى معلومات RP التي تم التعرف عليها تلقائيا.

نطاق المجموعة

224.10.20.0/24

• تحقق من الإعلان عن نطاق البث المتعدد الصحيح.
• تحقق من تطابق نطاق المجموعة مع التكوين.

إدخال RP الثاني

RP: 10.2.0.4, (0),

• يوجد RP آخر في المخطط.
• 10.2.0.4 يماثل loopback0 على N9K-2.
• لا يظهر * لأن RP هذا بعيد من N9K-1.

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

• لا يظهر * لأن N9K-2 ليس وكيل التعيين.
• N9K-2 يتعلم معلومات وكيل رسم الخرائط عن بعد من N9K-1.

فرق RP الهام

RP-source: 10.2.1.5 (A),

• يتعلم N9K-2 معلومات RP من وكيل التعيين.
• عامل التعيين هو 10.2.1.5.

وهذا يؤكد ما يلي:

• رسائل اكتشاف RP التلقائي تعمل بشكل صحيح.
• يتم نشر إعلانات "عامل التعيين" بنجاح من خلال مجال البث المتعدد.

الخطوة 4.4 التحقق من صحة عملية إختيار Auto-RP وتحديد RP

يستخدم بروتوكول Auto-RP دالتين مختلفتين للتحكم في البث المتعدد:

• مرشح RP
• عامل رسم الخرائط

يعتبر فهم كيفية تفاعل هذه الوظائف أمرا بالغ الأهمية عند التحقق من صحة عملية البث المتعدد في بيئة وضع ندرة PIM.

في هذه الطوبولوجيا:

• تعمل N9K-1 و N9K-2 كمرشحين لبروتوكول RP.
• يعمل N9K-1 كعامل تعيين نشط.

عملية مرشح RP

يعلن مرشح RP عن نفسه كنقطة تجميع صالحة لنطاق مجموعة واحدة أو أكثر من نطاقات مجموعات البث المتعدد.

يقوم كل مرشح RP بإرسال رسائل إعلان RP التلقائي بشكل دوري إلى:

• 224.0.1.39 — مجموعة إعلان Auto-RP
  
  

تحتوي هذه الإعلانات على:

• عنوان RP
• نطاق المجموعة
• أولوية
• هولداتايم

في هذه الطوبولوجيا:

• 10.2.0.1 على N9K-1 يعلن نفسه ك RP.
• 10.2.0.4 على N9K-2 تعلن عن نفسها على أنها 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)

يعلن كلا الجهازين عن نطاق مجموعة البث المتعدد نفسه:

• 224.10.20.0/24

يستخدم كل من المرشحين لمنصب rp أيضا:

• الأولوية 255

هذا مهم لأن Auto-RP يستخدم الأولوية وعنوان RP أثناء تحديد RP.

تعريف عامل التعيين النشط

يحدد "عامل التعيين" RP النشط لمجموعة البث المتعدد بدءا من هذا المنطق:

1. تفوز أعلى أولوية ل RP.
2. إذا كانت الأولويات متساوية، يربح أعلى عنوان IP ل RP.

في هذه الطوبولوجيا:

• N9K-1 عنوان RP = 10.2.0.1
• N9K-2 عنوان RP = 10.2.0.4
• يستخدم كلا مرشحي rp الأولوية 255

لأن كلا مرشحي rp لهما الأولوية نفسها:

• يصبح أعلى عنوان RP IP هو RP المحدد.

لذلك:

• 10.2.0.4 يصبح RP النشط ل 224.10.20.0/24.

التحقق من صحة 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),

هذا السلوك متوقع بسبب:

• يعمل N9K-1 كعميل تعيين.
• يحافظ وكيل التخطيط على إمكانية رؤية جميع مرشحي RP.
• يعرض الإخراج جميع إعلانات RP التي تم تعلمها قبل توزيع التحديد النهائي ل RP.

الخطوة 5: التحقق من إمكانية الوصول إلى مرشحي RP وعملاء التعيين

يجب أن تحافظ جميع موجهات البث المتعدد المشاركة في مجال وضع ندرة PIM على إمكانية وصول IP بشكل ثابت إلى:

• جميع مرشحي RP
• جميع عوامل التعيين

يعد هذا التحقق من الصحة أمرا بالغ الأهمية لأن وضع ندرة PIM يعتمد على توجيه البث الأحادي إلى:

• الوصول إلى نقطة الالتقاء (RP)
• إنشاء شجرة البث المتعدد المشتركة (RPT)
• تسليم رسائل تسجيل PIM من موجه الخطوة الأولى (FHR)
• إستلام إعلانات اكتشاف Auto-RP
• تنفيذ التحقق من صحة إعادة توجيه المسار العكسي (RPF)

إذا فشلت إمكانية الوصول إلى RP أو وكيل التعيين:

• يمكن أن تفشل مصادر البث المتعدد في التسجيل بنجاح.
• يمكن أن تفشل أجهزة الاستقبال في الانضمام إلى مجموعات البث المتعدد.
• تعذر نشر إعلانات Auto-RP بشكل صحيح.
• قد تحدث حالات فشل RPF.
• يمكن أن تصبح إعادة توجيه حركة مرور البث المتعدد غير مستقرة أو متقطعة.

---

التحقق من إدخالات التوجيه الثابتة

يجب أن يحتوي جدول التوجيه على مسارات ثابتة للبث الأحادي تجاه:

• جميع عمليات إعادة توجيه 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

---

التحقق من إمكانية الوصول إلى إختبار الاتصال من واجهات PIM

بعد التحقق من صحة جدول التوجيه، تحقق من إمكانية الوصول إلى IP الشاملة تجاه:

• جميع مرشحي RP
• جميع عوامل التعيين

يجب الحصول على إختبار الاتصال من:

• الواجهات التي تم تمكين PIM عليها
• واجهات الاسترجاع المشاركة في التوجيه متعدد البث

هذا التحقق من الصحة مهم لأن موجهات البث المتعدد تستخدم عناوين المصدر التالية أثناء:

• مؤسسة PIM المجاورة
• حسابات RPF
• تضمين سجل PIM
• اتصال Auto-RP

ملخص التحقق من إختبار الاتصال

في المثال التالي	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	عامل رسم الخرائط	نجحت العملية

التحقق من إعادة توجيه حركة مرور بيانات حالة التشغيل والبث المتعدد على FHR و LHR

تتمثل خطوة التحقق التالية في التحقق من:

• لقد تعلم كل من الممثل الخاص للأمين العام الممثل السامي الممثل المقيم المتوقع بنجاح.
• يحتوي جدول توجيه البث المتعدد على حالات البث المتعدد المتوقعة.
• يعمل مستوى التحكم في البث المتعدد بشكل صحيح قبل بدء إرسال حركة مرور البث المتعدد.
• يقوم وضع PIM المتناثر بإنشاء حالة الشجرة المشتركة المتوقعة.

---

الخطوة 1 تأكد من تعلم RP على FHR و LHR

قبل التحقق من صحة حالة إعادة توجيه البث المتعدد، تحقق من أن جميع موجهات البث المتعدد علمت RP المتوقع لمجموعة البث المتعدد قيد التحقق.

هذه الخطوة مهمة لأن:

• يجب أن يعرف FHR مكان إرسال رسائل سجل PIM.
• يجب أن تعرف LHR أي بروتوكول RP يجب إستخدامه عند إنشاء الشجرة المشتركة.
• يجب أن يحتفظ مجال البث المتعدد بتعيين RP متناسق.

في هذه الطوبولوجيا:

• RP المحدد هو 10.2.0.4.
• عامل التعيين هو 10.2.1.5.
• نطاق مجموعة البث المتعدد هو 224.10.20.0/24.

---

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 بشكل ثابت.
• RP المحدد هو 10.2.0.4.
• تم التعرف على تخطيط RP من خلال Auto-RP.
• عامل التعيين الذي يوزع معلومات RP هو 10.2.1.5.
• يبقى رسم خرائط ال‍ RP مستقرا لأكثر من يوم واحد.
• يتم تحديث مؤقتات انتهاء صلاحية الاكتشاف بشكل صحيح.

هذا السلوك متوقع بسبب:

• تم تحديد 10.2.0.4 ك RP النشط أثناء عملية إختيار RP التلقائي.
• 10-2-1-5 يعمل بوصفه وكيل التعيين.
• تتلقى جميع موجهات البث المتعدد بنجاح إعلانات اكتشاف Auto-RP.

في هذه المرحلة، يعمل مستوى التحكم في البث المتعدد بشكل صحيح، كما أن جميع الموجهات لديها تخطيط RP متناسق ل 224.10.20.0/24

---

الخطوة 2 تحقق من حالة توجيه البث المتعدد قبل حركة مرور البث المتعدد النشطة

تتمثل الخطوة التالية في التحقق من صحة جدول توجيه البث المتعدد قبل بدء نقل حركة مرور البث المتعدد.

في هذا السيناريو:

• انضم المستقبل متعدد البث بالفعل إلى مجموعة البث المتعدد.
• لا توجد حركة مرور نشطة لمصدر البث المتعدد تتدفق بعد.

هذه الحالة مهمة لأنها تتحقق:

• عملية عضوية IGMP
• إنشاء شجرة مشتركة ل PIM
• حالة البث المتعدد الأولية (*،g)
• نشر فائدة المستقبل

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

لا تحتوي هذه اللوائح بعد على:

• (* ، (ز) الدولة ل 224.10.20.10
• (s،g) حالة مصدر البث المتعدد

هذا السلوك متوقع بسبب:

• لا توجد حركة مرور مصدر البث المتعدد نشطة بعد.
• لم يتم إنشاء أي رسائل لسجل PIM.
• لم يبدأ FHR إعادة توجيه البث المتعدد.

الإدخال الوحيد للبث المتعدد الموجود هو:

• 232.0.0.0/8

وهذا يتوافق مع نطاق SSM الافتراضي ويتم تثبيته تلقائيا بواسطة النظام.

هذه القيم متوقعة:

• الواجهة الواردة: فارغ (null)
• جار RPF: 0.0.0.0
• عدد الواجهات الصادرة: 0

لا يشير هذا الإدخال إلى إعادة توجيه البث المتعدد النشطة.

---

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) نشط ل:

• 224.10.20.10

هذا السلوك متوقع بسبب:

• انضم المستقبل متعدد البث بالفعل إلى المجموعة.
• تم التعرف على معلومات عضوية IGMP على شبكة VLAN2.
• قامت LHR بإنشاء إرتباط الشجرة المشتركة باتجاه RP.

يؤكد جدول توجيه البث المتعدد:

• الواجهة الواردة (IIF) هي Ethernet1/50.
• يبلغ جار إعادة توجيه المسار العكسي (RPF) 10.4.0.26.
• تحتوي قائمة الواجهة الصادرة (OIL) على شبكة VLAN2.

وهذا يشير إلى ما يلي:

• قامت LHR بشكل صحيح بإنشاء الشجرة المشتركة باتجاه RP.
• تم نشر اهتمام متلقي البث المتعدد بنجاح في الخادم.
• تم إرسال رسائل PIM Join بشكل صحيح.

في هذه المرحلة:

• لا توجد حركة مرور مصدر البث المتعدد نشطة بعد.
• لا توجد حالة (S،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 نشط من أجل:

• 224.10.20.0/24

لذلك، يحتوي RP على حالة الشجرة المشتركة (*،G) ل 224.10.20.10

هذه القيم متوقعة:

• الواجهة الواردة = loopback0
• جار إعادة توجيه المسار العكسي (RPF) = 10.2.0.4
• الواجهة الصادرة = Ethernet1/49

وهذا يشير إلى ما يلي:

• قام RP بتثبيت حالة الشجرة المشتركة بنجاح.
• تلقى RP رسائل انضمام PIM من موجهات تدفق البيانات من الخادم.
• تم إنشاء الشجرة المشتركة للبث المتعدد تجاه أجهزة الاستقبال بشكل صحيح.

في هذه المرحلة:

• يحتوي RP على حالة الشجرة المشتركة فقط.
• لا توجد حركة مرور مصدر البث المتعدد نشطة بعد.
• لا توجد إدخالات (S،G) بعد.

---

الخطوة 3 تحقق من حالة توجيه البث المتعدد مع حركة مرور البث المتعدد النشطة

بمجرد بدء إرسال حركة مرور البث المتعدد، يتم نقل جدول توجيه البث المتعدد من حالة الشجرة المشتركة إلى حالة إعادة التوجيه النشطة الخاصة بالمصدر.

في هذا السيناريو:

• مصدر البث المتعدد هو 10.150.1.37.
• مجموعة البث المتعدد هي 224.10.20.10.
• RP النشط هو 10.2.0.4 على N9K-2.
• يتصل مصدر البث المتعدد من خلال vPC port-channel 78.

---

اعتبارات هامة للبث المتعدد للكمبيوتر الشخصي vPC

يتصل مصدر البث المتعدد من خلال مجال vPC مكون من قبل FHR-1 و FHR-2.

لأن المصدر يتصل من خلال vPC عضو ميناء-channel:

• يمكن أن يقوم تجزئة حركة المرور بإعادة توجيه حزم البث المتعدد نحو محول Nexus.
• تتطلب كلتا شبكتي الموارد البشرية تكوين بث متعدد متماثل.
• تتطلب كلتا شبكتي الموارد البشرية معلومات توجيه متسقة للبث الأحادي.
• يجب أن يحتفظ كل من FHRs بتعيينات RP متطابقة.
• يجب أن تحافظ كل من الخادمين على تجاور PIM مستقر.

في هذا سيناريو محدد:

• يتعطل تدفق البث المتعدد تجاه FHR-2.
• يصبح FHR-2 هو إعادة التوجيه النشطة لمصدر البث المتعدد.

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) ل:

• المصدر = 10.150.1.37
• المجموعة = 224.10.20.10

يؤكد إدخال توجيه البث المتعدد:

• علمت المصدر على VLAN1.
• يكون جار إعادة توجيه المسار العكسي (RPF) مصدر البث المتعدد المتصل مباشرة.
• لا توجد واجهات صادرة في النفط.

من المتوقع أن يكون هذا السلوك لأن تدفق البث المتعدد لم يتم تجزئة إتجاه FHR-1 لإعادة التوجيه الصادرة.

ونتيجة لذلك:

• يقوم FHR-1 بتثبيت دولة المصدر المحلية فقط.
• لا يقوم FHR-1 بإعادة توجيه حركة مرور بيانات البث المتعدد عبر PIM.

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 على:

• قائمة الواجهة الصادرة النشطة
• مسار إعادة توجيه PIM نشط

وهذا يشير إلى ما يلي:

• أصبحت FHR-2 هي إعادة التوجيه التشغيلية لتدفق البث المتعدد.
• تتم تجزئة حزم البث المتعدد باتجاه FHR-2 من خلال قناة منفذ عضو vPC.
• يغلف FHR-2 حركة مرور البث المتعدد في رسائل سجل PIM.
• تدفق حركة مرور البث المتعدد المعاد توجيهها وفقا لمعيار FHR-2 نحو بروتوكول RP.

سلوك إعادة توجيه 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 على مسارين متساويين التكلفة تجاه الشبكة الفرعية لإستقبال البث المتعدد:

• 10.4.0.13 عبر الإيثرنت 1/3
• 10.4.0.18 عبر الإيثرنت 1/4

وهذا يؤكد ما يلي:

• يكون توجيه ECMP نشطا في مخطط نقل البث المتعدد.
• توجد العديد من مسارات إعادة توجيه البث الأحادي الصالحة لشبكة المستقبل.
• يمكن أن يستخدم PIM مسار إعادة توجيه المسار العكسي (RPF) المحدد من قبل MRIB لقرارات إعادة توجيه البث المتعدد.
• لا يحدث تكرار الحزمة عبر مسارات ECMP المتوازية.

على الرغم من وجود مسارين متساويين التكلفة، فإن إعادة توجيه البث المتعدد تستخدم مسار إعادة توجيه المسار العكسي (RPF) واحدا لكل تدفق للبث المتعدد.

في هذا المخطط، يستخدم تدفق البث المتعدد:

• Ethernet1/3 باتجاه 10.4.0.13

يتطابق هذا السلوك مع جدول توجيه البث المتعدد الذي تمت ملاحظته سابقا:

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

سلوك التشغيل الأساسي والثانوي

تؤثر الأدوار التشغيلية للكمبيوتر الشخصي vPC على سلوك إعادة توجيه البث المتعدد بشكل مختلف من أجل:

• حركة مرور PIM
• معالجة IGMP

في هذه الطوبولوجيا:

• FHR-1 هو الأساسي للتشغيل vPC.
• إن FHR-2 هو المعالج الثانوي للتشغيل vPC.

يمكن لكل من محولي Nexus:

• معالجة حركة مرور مستوى التحكم في PIM
• إنشاء حالة توجيه البث المتعدد
• إعادة توجيه حركة مرور البث المتعدد من خلال PIM

ومع ذلك:

• تتم فقط العمليات الأساسية للعمليات التشغيلية لبروتوكول vPC لحركة مرور مستقبل IGMP نحو طبقة الوصول.

هذا التمييز مهم لأن:

• تظل إعادة توجيه PIM نحو الشبكة الموجهة نشطة على كلا النظرين.
• تبقى إعادة توجيه IGMP نحو شرائح جهاز الاستقبال من الطبقة 2 مركزية على الأساسي للتشغيل.

لذلك:

• يمكن لحركة مرور البث المتعدد من المصدر نحو مجال البث المتعدد الموجه الخروج من خلال أي من نظراء vPC.
• تعتمد حركة مرور البث المتعدد تجاه مستقبلات IGMP على السلوك الأساسي للتشغيل.

---

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

تحتوي LHR الآن على كليهما:

• (*، G) حالة الشجرة المشتركة
• (s،g) حالة شجرة المصدر

وهذا يؤكد:

• تم الانضمام إلى مستقبل البث المتعدد بنجاح.
• أصبح مصدر البث المتعدد نشطا.
• تم نقل LHR من إعادة توجيه الشجرة المشتركة إلى إعادة توجيه شجرة المصدر.

يؤكد إدخال (S،G):

• تم التعرف على مسار مصدر البث المتعدد بنجاح.
• يبلغ جار إعادة توجيه المسار العكسي (RPF) 10.4.0.22.
• تصل حركة مرور البث المتعدد من خلال Ethernet1/49.
• تقوم حركة مرور البث المتعدد بإعادة توجيه حركة مرور البيانات نحو أجهزة إستقبال VLAN2.

ويؤكد هذا السلوك النجاح:

• إعادة توجيه PIM
• التحقق من صحة RPF
• بناء شجرة المصدر
• تسليم حركة مرور البث المتعدد

---

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 كموجه متعدد البث العابرة للتدفق النشط للبث المتعدد.

يؤكد إدخال توجيه البث المتعدد:

• تصل حركة مرور البث المتعدد من Ethernet1/4.
• يتم توجيه حركة مرور البث المتعدد نحو Ethernet1/49.
• مسار إعادة توجيه البث المتعدد نحو LHR قيد التشغيل.

وهذا يؤكد النجاح:

• عملية PIM المجاورة
• التحقق من صحة RPF
• إعادة توجيه البث المتعدد عبر شبكة النقل

---

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)

تحليل حالة بث RP المتعدد

يعمل N9K-2 كبروتوكول RP نشط لمجموعة البث المتعدد.

يحتوي RP على كل من:

• (*، G) حالة الشجرة المشتركة
• (s،g) حالة شجرة المصدر

من المتوقع غياب الواجهات الصادرة في الإدخال (S،G) بسبب:

• قام RP بالفعل بتحويل أجهزة الاستقبال إلى أقصر شجرة مسار.
• لم يعد مسار إعادة توجيه الشجرة المشتركة مطلوبا لإعادة توجيه البث المتعدد النشط.

الحد الأدنى من معلومات البث المتعدد المطلوبة ل RCA وتشخيصات الصحة

توفر قائمة الأوامر الحد الأدنى من مجموعة بيانات البث المتعدد الموصى بها والمطلوبة لإجراء تحليل سبب جذر (RCA) مناسب أو تشخيص صحة البث المتعدد على محولات Cisco Nexus 9000 Series التي تشغل NX-OS. تتضمن هذه المخرجات تفاصيل حالة لوحة التحكم في البث المتعدد، وبرمجة MRIB، ومعلومات إعادة التوجيه، وحالة تشغيل vPC، وإعادة توجيه الأجهزة. ومع ذلك، لا يزال من الممكن طلب معلومات إضافية بناء على سيناريو الفشل. على سبيل المثال، غالبا ما يتطلب فقد حزم البث المتعدد أو حالات إسقاط حركة مرور متقطعة أو مشاكل نسخ الحزم المتماثل أو عدم تناسق إعادة توجيه الأجهزة أو إعادة توجيه البث المتعدد خارج الترتيب التقاط الحزم المباشر على المحول Nexus باستخدام Ethanalyzer أو الفسحة بين دعامتين أو التقاط مستوى الأجهزة. وبالمثل، يمكن أن تحدث حالات عدم تناسق إعادة توجيه المسار العكسي (RPF) العابرة أو تغييرات إعادة توجيه بروتوكول إدارة مجموعات الإنترنت (ECMP) أو حالات فشل برمجة ASIC أو أحداث قمع بروتوكول إدارة مجموعات الإنترنت (IGMP) دون إنشاء سجل دائم.

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

الحد الأدنى لأوامر تجميع بيانات البث المتعدد

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

إنشاء أرشيف TAR للتصدير

بعد إنشاء ملفات 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 واحد يبسط:

• تحميلات حالة TAC
• عمليات سير عمل RCA
• تحليل السجلات المركزية
• إرتباط إعادة توجيه البث المتعدد
• حفظ الفشل التاريخي

محفوظات المراجعة

المراجعة	تاريخ النشر	التعليقات
1.0	13-May-2026	الإصدار الأولي