كيف يعمل بروتوكول PIM

بروتوكول PIM عبارة عن مجموعة من البروتوكولات لنقل البث المتعدد في الشبكة بين أجهزة التوجيه. يتم إنشاء علاقات الجوار بنفس الطريقة كما في حالة بروتوكولات التوجيه الديناميكي. يرسل PIMv2 رسائل الترحيب كل 30 ثانية إلى عنوان البث المتعدد المحجوز 224.0.0.13 (جميع أجهزة توجيه PIM). تحتوي الرسالة على مؤقتات الانتظار - عادةً ما تساوي 3.5*Hello Timer، أي 105 ثانية بشكل افتراضي.

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

سوف يتعرف R3 على مصدر البث المتعدد (Source IP) من رسالة البث المتعدد ويتحقق من التدفقين من R1 وR2 باستخدام جدول البث الأحادي الخاص به. سيتم إرسال الدفق من الواجهة المشار إليها بالجدول (R1 إلى R3) بشكل أكبر، وسيتم إسقاط الدفق من R2، لأنه من أجل الوصول إلى مصدر البث المتعدد، تحتاج إلى إرسال الحزم عبر S0/1.
السؤال هو، ماذا يحدث إذا كان لديك مساران متكافئان لهما نفس المقياس؟ في هذه الحالة، سيحدد جهاز التوجيه الخطوة التالية من هذه المسارات. من لديه عنوان IP الأعلى يفوز. إذا كنت بحاجة إلى تغيير هذا السلوك، فيمكنك استخدام ECMP. المزيد من التفاصيل هنا.
بعد التحقق من قاعدة RPF، يرسل جهاز التوجيه حزمة بث متعدد إلى جميع جيرانه من PIM، باستثناء الشخص الذي تم استلام الحزمة منه. تكرر أجهزة توجيه PIM الأخرى هذه العملية. يشكل المسار الذي اتخذته حزمة البث المتعدد من المصدر إلى المستلمين النهائيين شجرة تسمى شجرة التوزيع المستندة إلى المصدر، شجرة المسار الأقصر (SPT)، شجرة المصدر. ثلاثة أسماء مختلفة، اختر أي واحد.
كيفية حل مشكلة أن بعض أجهزة التوجيه لم تتخلى عن بعض البث المتعدد ولا يوجد من يرسلها إليه، ولكن جهاز التوجيه الأعلى يرسلها إليه. تم اختراع آلية البرقوق لهذا الغرض.
رسالة تقليم.
على سبيل المثال، سيستمر R2 في إرسال بث متعدد إلى R3، على الرغم من أن R3، وفقًا لقاعدة RPF، سيسقطه. لماذا تحميل القناة؟ يرسل R3 رسالة PIM Prune وسيقوم R2، عند استلام هذه الرسالة، بإزالة الواجهة S0/1 من قائمة الواجهة الصادرة لهذا التدفق، وهي قائمة الواجهات التي يجب إرسال حركة المرور هذه منها.

فيما يلي تعريف أكثر رسمية لرسالة PIM Prune:
يتم إرسال رسالة PIM Prune بواسطة جهاز توجيه واحد إلى جهاز توجيه آخر لجعل جهاز التوجيه الثاني يزيل الارتباط الذي يتم من خلاله استلام Prune من SPT معين (S,G).

بعد تلقي رسالة Prune، يقوم R2 بتعيين مؤقت Prune على 3 دقائق. وبعد ثلاث دقائق، سيبدأ في إرسال حركة المرور مرة أخرى حتى يتلقى رسالة Prune أخرى. هذا في PIMv1.
وفي PIMv2 تمت إضافة مؤقت تحديث الحالة (60 ثانية افتراضيًا). بمجرد إرسال رسالة Prune من R3، يبدأ هذا المؤقت في R3. عند انتهاء هذا المؤقت، سيرسل R3 رسالة تحديث الحالة، والتي ستعيد ضبط مؤقت التقليم لمدة 3 دقائق على R2 لهذه المجموعة.
أسباب إرسال رسالة Prune:

• عندما تفشل حزمة البث المتعدد في فحص RPF.
• في حالة عدم وجود عملاء متصلين محليًا طلبوا مجموعة بث متعدد (انضمام IGMP) ولا يوجد جيران PIM يمكن إرسال حركة مرور البث المتعدد إليهم (واجهة غير قابلة للتقليم).

رسالة الكسب غير المشروع.
لنتخيل أن R3 لم يكن يريد حركة مرور من R2، وأرسل Prune واستقبل بثًا متعددًا من R1. ولكن فجأة، سقطت القناة بين R1-R3 وبقي R3 بدون بث متعدد. يمكنك الانتظار لمدة 3 دقائق حتى تنتهي صلاحية مؤقت التقليم على R2. 3 دقائق هي فترة انتظار طويلة، وحتى لا تنتظر، تحتاج إلى إرسال رسالة ستخرج واجهة S0/1 هذه على الفور إلى R2 من الحالة المحفوفة بالمخاطر. ستكون هذه الرسالة بمثابة رسالة Graft. بعد تلقي رسالة Graft، سوف يستجيب R2 بـ Graft-ACK.
تجاوز التقليم.

دعونا ننظر إلى هذا الرسم البياني. يبث R1 البث المتعدد إلى مقطع به جهازي توجيه. يتلقى R3 حركة المرور ويبثها، ويستقبل R2، ولكن ليس لديه من يبث حركة المرور إليه. يرسل رسالة Prune إلى R1 في هذا المقطع. يجب على R1 إزالة Fa0/0 من القائمة وإيقاف البث في هذا المقطع، ولكن ماذا سيحدث لـ R3؟ و R3 في نفس المقطع، تلقى أيضًا هذه الرسالة من Prune وفهم مأساة الوضع. قبل أن يتوقف R1 عن البث، فإنه يضبط مؤقتًا مدته 3 ثوانٍ وسيتوقف عن البث بعد 3 ثوانٍ. 3 ثوانٍ - هذا هو بالضبط مقدار الوقت المتاح لـ R3 حتى لا يفقد البث المتعدد الخاص به. لذلك، يرسل R3 رسالة Pim Join لهذه المجموعة في أقرب وقت ممكن، ولم يعد R1 يفكر في إيقاف البث. حول الانضمام إلى الرسائل أدناه.
تأكيد الرسالة.

لنتخيل هذا الموقف: يقوم جهازا توجيه بالبث إلى شبكة واحدة في وقت واحد. إنهم يتلقون نفس الدفق من المصدر، وكلاهما يبثه إلى نفس الشبكة خلف الواجهة e0. ولذلك، يتعين عليهم تحديد من سيكون المذيع الوحيد لهذه الشبكة. يتم استخدام رسائل التأكيد لهذا الغرض. عندما يكتشف R2 وR3 تكرار حركة مرور البث المتعدد، أي أن R2 وR3 يستقبلان بثًا متعددًا يبثانه بأنفسهم، تفهم أجهزة التوجيه أن هناك خطأ ما هنا. في هذه الحالة، ترسل أجهزة التوجيه رسائل تأكيد، والتي تتضمن المسافة الإدارية وقياس المسار الذي يتم من خلاله الوصول إلى مصدر البث المتعدد - 10.1.1.10. يتم تحديد الفائز على النحو التالي:

1. واحد مع انخفاض م.
2. إذا كان AD متساويين، فمن صاحب المقياس الأقل.
3. إذا كانت هناك مساواة هنا، فمن لديه IP أعلى في الشبكة التي يبثون عليها هذا البث المتعدد.

الفائز بهذا التصويت يصبح جهاز التوجيه المعين. يتم استخدام Pim Hello أيضًا لتحديد DRs. في بداية المقال، تم عرض رسالة PIM Hello، ويمكنك رؤية حقل DR هناك. يفوز الشخص الذي لديه أعلى عنوان IP على هذا الرابط.
علامة مفيدة:

جدول مروت.
بعد إلقاء نظرة أولية على كيفية عمل بروتوكول PIM، نحتاج إلى فهم كيفية العمل مع جدول توجيه البث المتعدد. يقوم جدول mroute بتخزين معلومات حول التدفقات المطلوبة من العملاء وأي التدفقات تتدفق من خوادم البث المتعدد.
على سبيل المثال، عند تلقي تقرير عضوية IGMP أو انضمام PIM على بعض الواجهات، تتم إضافة سجل من النوع ( *، G ) إلى جدول التوجيه:

يعني هذا الإدخال أنه تم استلام طلب مرور بالعنوان 238.38.38.38. تعني علامة DC أن البث المتعدد سيعمل في الوضع الكثيف وتعني C أن المستلم متصل مباشرة بجهاز التوجيه، أي أن جهاز التوجيه تلقى تقرير عضوية IGMP وانضمام PIM.
إذا كان هناك سجل من النوع (S,G) فهذا يعني أن لدينا تدفق متعدد البث:

في الحقل S - 192.168.1.11، قمنا بتسجيل عنوان IP لمصدر البث المتعدد، وهو ما سيتم التحقق منه بواسطة قاعدة RPF. إذا كانت هناك مشكلات، فإن أول ما عليك فعله هو التحقق من جدول البث الأحادي لمعرفة المسار إلى المصدر. في حقل الواجهة الواردة، يشير إلى الواجهة التي يتم استقبال البث المتعدد عليها. في جدول توجيه البث الأحادي، يجب أن يشير المسار إلى المصدر إلى الواجهة المحددة هنا. تحدد الواجهة الصادرة المكان الذي سيتم إعادة توجيه البث المتعدد فيه. إذا كان فارغًا، فهذا يعني أن جهاز التوجيه لم يتلق أي طلبات لحركة المرور هذه. يمكن العثور على مزيد من المعلومات حول جميع الأعلام هنا.
PIM وضع متفرق.
استراتيجية الوضع المتناثر هي عكس الوضع الكثيف. عندما يتلقى الوضع المتفرق حركة مرور البث المتعدد، فإنه سيرسل فقط حركة المرور من خلال تلك الواجهات التي كانت هناك طلبات لهذا التدفق، على سبيل المثال Pim Join أو رسائل تقرير IGMP التي تطلب حركة المرور هذه.
عناصر مماثلة لـ SM وDM:

• يتم بناء علاقات الجوار بنفس الطريقة كما في PIM DM.
• تعمل قاعدة RPF.
• اختيار DR مشابه.
• آلية تجاوزات Prune ورسائل التأكيد متشابهة.

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

دعونا نتخيل طوبولوجيا حيث RP هو R3. بمجرد أن يستقبل R1 حركة المرور من S1، فإنه يقوم بتغليف حزمة البث المتعدد هذه في رسالة تسجيل PIM أحادية البث ويرسلها إلى RP. كيف يعرف من هو RP؟ في هذه الحالة، تم تكوينه بشكل ثابت، وسنتحدث عن تكوين RP الديناميكي لاحقًا.

عنوان IP PIM RP 3.3.3.3

سوف ينظر RP - هل كانت هناك معلومات من شخص يرغب في تلقي هذه الحركة؟ لنفترض أنه لم يكن كذلك. ثم سيرسل RP إلى R1 رسالة PIM Register-Stop، مما يعني أنه لا أحد يحتاج إلى هذا البث المتعدد، وتم رفض التسجيل. لن يرسل R1 البث المتعدد. لكن مضيف مصدر البث المتعدد سيرسله، بحيث يبدأ R1، بعد تلقي Register-Stop، مؤقتًا لقمع التسجيل يساوي 60 ثانية. قبل 5 ثوانٍ من انتهاء صلاحية هذا المؤقت، سيرسل R1 رسالة تسجيل فارغة مع بت Null-Register (أي بدون حزمة بث متعدد مغلفة) نحو RP. سوف يتصرف RP بدوره على النحو التالي:

• إذا لم يكن هناك مستلمين، فسوف يستجيب برسالة إيقاف التسجيل.
• إذا ظهر المستلمون، فلن يستجيب لهم بأي شكل من الأشكال. سيكون R1، الذي لم يتلق رفضًا للتسجيل خلال 5 ثوانٍ، سعيدًا ويرسل رسالة تسجيل مع بث متعدد مغلف إلى RP.

يبدو أننا اكتشفنا كيفية وصول البث المتعدد إلى RP، والآن دعونا نحاول الإجابة على سؤال حول كيفية توصيل RP لحركة المرور إلى المستلمين. من الضروري هنا تقديم مفهوم جديد - شجرة مسار الجذر (RPT). RPT عبارة عن شجرة متجذرة في RP، وتنمو باتجاه المستلمين، وتتفرع على كل جهاز توجيه PIM-SM. يقوم RP بإنشائه عن طريق تلقي رسائل PIM Join وإضافة فرع جديد إلى الشجرة. وهكذا، فإن كل جهاز توجيه يتجه نحو المصب يفعل ذلك. القاعدة العامة تبدو كالتالي:

• عندما يتلقى جهاز توجيه PIM-SM رسالة انضمام PIM على أي واجهة بخلاف الواجهة التي يتم إخفاء RP خلفها، فإنه يضيف فرعًا جديدًا إلى الشجرة.
• تتم إضافة فرع أيضًا عندما يتلقى جهاز التوجيه PIM-SM تقرير عضوية IGMP من مضيف متصل مباشرة.

لنتخيل أن لدينا عميل بث متعدد على جهاز التوجيه R5 للمجموعة 228.8.8.8. بمجرد أن يتلقى R5 تقرير عضوية IGMP من المضيف، يرسل R5 PIM Join في اتجاه RP، ويضيف بنفسه واجهة إلى الشجرة التي تنظر إلى المضيف. بعد ذلك، يتلقى R4 PIM Join من R5، ويضيف الواجهة Gi0/1 إلى الشجرة ويرسل PIM Join في اتجاه RP. أخيرًا، يتلقى RP (R3) PIM Join ويضيف Gi0/0 إلى الشجرة. وبالتالي، يتم تسجيل مستلم البث المتعدد. نحن نبني شجرة بالجذر R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
بعد ذلك، سيتم إرسال PIM Join إلى R1 وسيبدأ R1 في إرسال حركة مرور البث المتعدد. من المهم ملاحظة أنه إذا طلب المضيف حركة المرور قبل بدء البث المتعدد، فلن يرسل RP PIM Join ولن يرسل أي شيء إلى R1 على الإطلاق.
إذا توقف المضيف فجأة أثناء إرسال البث المتعدد عن الرغبة في استقباله، بمجرد أن يتلقى RP PIM Prune على واجهة Gi0/0، فسوف يرسل على الفور PIM Register-Stop مباشرة إلى R1، ثم PIM Prune الرسالة عبر واجهة Gi0/1. يتم إرسال PIM Register-stop عبر البث الأحادي إلى العنوان الذي جاء منه سجل PIM.
كما قلنا سابقًا، بمجرد أن يرسل جهاز التوجيه PIM Join إلى جهاز آخر، على سبيل المثال R5 إلى R4، تتم إضافة سجل إلى R4:

ويتم تشغيل مؤقت حيث يجب على R5 إعادة تعيين هذا المؤقت PIM للانضمام إلى الرسائل باستمرار، وإلا سيتم استبعاد R4 من القائمة الصادرة. سيرسل R5 كل 60 رسالة انضمام إلى PIM.
تحويل شجرة المسار الأقصر.
سنضيف واجهة بين R1 وR5 ونرى كيف تتدفق حركة المرور مع هذه الهيكلية.

لنفترض أن حركة المرور تم إرسالها واستلامها وفقًا للمخطط القديم R1-R2-R3-R4-R5، وهنا قمنا بتوصيل وتكوين الواجهة بين R1 وR5.
أولاً، يتعين علينا إعادة بناء جدول توجيه البث الأحادي على R5 والآن يتم الوصول إلى الشبكة 192.168.1.0/24 من خلال واجهة R5 Gi0/2. الآن، يفهم R5، الذي يتلقى البث المتعدد على الواجهة Gi0/1، أن قاعدة RPF غير مستوفاة وسيكون من المنطقي أكثر تلقي البث المتعدد على Gi0/2. يجب أن يتم قطع اتصاله بـ RPT وإنشاء شجرة أقصر تسمى شجرة المسار الأقصر (SPT). للقيام بذلك، يرسل PIM Join إلى R0 من خلال Gi2/1 ويبدأ R1 في إرسال بث متعدد أيضًا من خلال Gi0/2. يحتاج R5 الآن إلى إلغاء الاشتراك في RPT حتى لا يتلقى نسختين. للقيام بذلك، يرسل رسالة إلى Prune تشير إلى عنوان IP المصدر وإدراج بت خاص - بت RPT. هذا يعني أنك لست بحاجة إلى أن ترسل لي حركة المرور، فلدي شجرة أفضل هنا. يرسل RP أيضًا رسائل PIM Prune إلى R1، لكنه لا يرسل رسالة إيقاف التسجيل. ميزة أخرى: سيرسل R5 الآن بشكل مستمر PIM Prune إلى RP، حيث يستمر R1 في إرسال PIM Register إلى RP كل دقيقة. وإلى أن لا يكون هناك أشخاص جدد يريدون هذه الحركة، فإن RP سوف يرفضها. يقوم R5 بإعلام RP بأنه يستمر في تلقي البث المتعدد عبر SPT.
بحث RP الديناميكي.
لصناعة السيارات في RP.
هذه التقنية مملوكة لشركة Cisco ولا تحظى بشعبية خاصة، ولكنها لا تزال حية. تتكون عملية RP التلقائي من مرحلتين رئيسيتين:
1) يرسل RP رسائل RP-Announce إلى العنوان المحجوز - 224.0.1.39، معلنًا نفسه RP إما للجميع أو لمجموعات محددة. يتم إرسال هذه الرسالة كل دقيقة.
2) مطلوب وكيل رسم خرائط RP، والذي سيرسل رسائل RP-Discovery للإشارة إلى المجموعات التي يجب الاستماع إلى RP. من هذه الرسالة ستحدد أجهزة توجيه PIM العادية RP لأنفسها. يمكن أن يكون وكيل التعيين إما جهاز توجيه RP نفسه أو جهاز توجيه PIM منفصلاً. يتم إرسال RP-Discovery إلى العنوان 224.0.1.40 مع مؤقت مدته دقيقة واحدة.
دعونا نلقي نظرة على العملية بمزيد من التفصيل:
لنقم بتكوين R3 كـ RP:

IP pim إرسال-RP-إعلان الاسترجاع 0 النطاق 10

R2 كعامل رسم الخرائط:

IP pim إرسال-RP-اكتشاف الاسترجاع 0 النطاق 10

وعلى جميع الآخرين نتوقع RP عبر Auto-RP:

IP PIM مستمع Autorp

بمجرد تكوين R3، سيبدأ في إرسال RP-Announce:

وسيبدأ R2، بعد إعداد وكيل التعيين، في انتظار رسالة RP-Announce. فقط عندما يعثر على RP واحد على الأقل، سيبدأ في إرسال RP-Discovery:

بهذه الطريقة، بمجرد أن تتلقى أجهزة التوجيه العادية (PIM RP Lister) هذه الرسالة، فإنها ستعرف مكان البحث عن RP.
إحدى المشكلات الرئيسية في Auto-RP هي أنه لتلقي رسائل RP-Announce وRP-Discovery، تحتاج إلى إرسال PIM Join إلى العناوين 224.0.1.39-40، ومن أجل الإرسال، عليك معرفة مكان يقع RP. مشكلة الدجاج والبيض الكلاسيكية. لحل هذه المشكلة، تم اختراع وضع PIM Sparse-Dense-Mode. إذا كان جهاز التوجيه لا يعرف RP، فإنه يعمل في الوضع الكثيف، وإذا كان يعرف، ففي الوضع المتناثر. عند تكوين وضع PIM Sparse وأمر ip pim autorpwriter على واجهات أجهزة التوجيه العادية، سيعمل جهاز التوجيه في الوضع الكثيف فقط للبث المتعدد مباشرة من بروتوكول Auto-RP (224.0.1.39-40).
جهاز توجيه BootStrap (BSR).
تعمل هذه الوظيفة بشكل مشابه لوظيفة Auto-RP. يرسل كل RP رسالة إلى وكيل التعيين، الذي يجمع معلومات التعيين ثم يخبر جميع أجهزة التوجيه الأخرى. دعنا نصف العملية بشكل مشابه لـ Auto-RP:
1) بمجرد تكوين R3 كمرشح ليكون RP، باستخدام الأمر:

استرجاع IP pim Rp-candidate 0

ثم لن يفعل R3 أي شيء، ولكي يبدأ في إرسال رسائل خاصة، عليه أولاً العثور على وكيل رسم الخرائط. وهكذا ننتقل إلى الخطوة الثانية.
2) قم بتكوين R2 كوكيل رسم الخرائط:

الاسترجاع IP PIM BSR-المرشح 0

يبدأ R2 بإرسال رسائل PIM Bootstrap، حيث يشير إلى نفسه كوكيل رسم الخرائط:

يتم إرسال هذه الرسالة إلى العنوان 224.0.013، والذي يستخدمه بروتوكول PIM أيضًا لرسائله الأخرى. إنه يرسلهم في كل الاتجاهات وبالتالي لا توجد مشكلة الدجاج والبيض كما كان الحال في Auto-RP.
3) بمجرد أن يتلقى RP رسالة من جهاز توجيه BSR، فإنه سيرسل على الفور رسالة أحادية البث إلى عنوان جهاز توجيه BSR:

بعد ذلك، سيقوم BSR، بعد تلقي معلومات حول RPs، بإرسالها عن طريق البث المتعدد إلى العنوان 224.0.0.13، والذي تستمع إليه جميع أجهزة توجيه PIM. لذلك، التناظرية للأمر IP PIM مستمع Autorp لأجهزة التوجيه العادية وليس في BSR.
Anycast RP مع بروتوكول اكتشاف مصدر البث المتعدد (MSDP).
يسمح لنا Auto-RP وBSR بتوزيع الحمل على RP على النحو التالي: تحتوي كل مجموعة بث متعدد على RP نشط واحد فقط. لن يكون من الممكن توزيع الحمل لمجموعة بث متعدد واحدة على عدة RPs. يقوم MSDP بذلك عن طريق إصدار نفس عنوان IP لأجهزة توجيه RP بقناع 255.255.255.255. يتعلم MSDP المعلومات باستخدام إحدى الطرق: ثابتة أو Auto-RP أو BSR.

في الصورة لدينا تكوين Auto-RP باستخدام MSDP. تم تكوين كلا RPs بعنوان IP 172.16.1.1/32 على واجهة Loopback 1 ويتم استخدامه لجميع المجموعات. باستخدام RP-Announce، يعلن كلا الموجهين عن أنفسهم من خلال الإشارة إلى هذا العنوان. يقوم وكيل تعيين Auto-RP، بعد تلقي المعلومات، بإرسال RP-Discovery حول RP بالعنوان 172.16.1.1/32. نخبر أجهزة التوجيه عن الشبكة 172.16.1.1/32 باستخدام IGP، وبالتالي. ومن ثم، تطلب أجهزة توجيه PIM أو تسجل التدفقات من RP المحدد كخطوة تالية على المسار إلى الشبكة 172.16.1.1/32. تم تصميم بروتوكول MSDP نفسه لـ RPs أنفسهم لتبادل الرسائل حول معلومات البث المتعدد.
النظر في هذه الطوبولوجيا:

يبث Switch6 حركة المرور إلى العنوان 238.38.38.38 وحتى الآن لا يعرف عنها سوى RP-R1. طلب Switch7 وSwitch8 هذه المجموعة. سيقوم جهازا التوجيه R5 وR4 بإرسال PIM Join إلى R1 وR3، على التوالي. لماذا؟ سيشير المسار إلى 13.13.13.13 لـ R5 إلى R1 باستخدام مقياس IGP، تمامًا كما هو الحال مع R4.
يعرف RP-R1 عن الدفق وسيبدأ في بثه نحو R5، لكن R4 لا يعرف شيئًا عنه، نظرًا لأن R1 لن يرسله ببساطة. ولذلك فإن MSDP ضروري. نقوم بتكوينه على R1 وR5:

IP msdp Peer 3.3.3.3 Loopback1 لمصدر الاتصال على R1

IP msdp Peer 1.1.1.1 Loopback3 لمصدر الاتصال على R3

سوف يقومون برفع جلسة بين بعضهم البعض وعند تلقي أي تدفق سوف يقومون بإبلاغ جارهم RP عنه.
بمجرد أن يتلقى RP-R1 دفقًا من Switch6، فإنه سيرسل على الفور رسالة MSDP Source-Active أحادية البث، والتي ستحتوي على معلومات مثل (S، G) - معلومات حول مصدر ووجهة البث المتعدد. الآن بعد أن عرف RP-R3 أن مصدرًا مثل Switch6، عند تلقي طلب من R4 لهذا التدفق، سيرسل PIM Join نحو Switch6، مسترشدًا بجدول التوجيه. وبالتالي، بعد أن تلقى R1 مثل PIM Join، سيبدأ في إرسال حركة المرور نحو RP-R3.
يعمل MSDP عبر TCP، وترسل RPs رسائل استمرارية لبعضها البعض للتحقق من الحيوية. الموقت هو 60 ثانية.
لا تزال وظيفة تقسيم أقران MSDP إلى نطاقات مختلفة غير واضحة، نظرًا لأن رسائل Keepalive وSA لا تشير إلى العضوية في أي مجال. وفي هذا الهيكل أيضًا، قمنا باختبار تكوين يشير إلى مجالات مختلفة - ولم يكن هناك اختلاف في الأداء.
إذا كان بإمكان أي شخص التوضيح، سأكون سعيدًا بقراءته في التعليقات.

المصدر: www.habr.com