PIM-SM عبر VPN: تحقق من BSR وتعيين RP ومسارات RPF

النفق قائم، ورسائل ping الأحادية العنوان تعبره، ومع ذلك تظل الشاشة سوداء عند المستقبل. في نشر PIM-SM يعني هذا العَرَض تقريبًا دائمًا أن أحد مسارات التحكم الأربعة معطوب، وأن مسار البيانات نفسه لم يكن المشكلة قط. اتبع القائمة أدناه بالترتيب وتوقف عند أول خطوة تفشل، لأن كل خطوة لاحقة تعتمد على التي قبلها. أحتفظ بهذه الفحوص الخمسة في ملف مسودة وألصقها في طرفية عندما تصل شكوى بث جماعي، وهذا يمنع التشخيص من أن يتحول إلى تخمين.

ابدأ بالمستقبل، لا بالنفق

المستقبل الذي لم يطلب المجموعة قط لا يُنتج أي حالة على أي موجه، لذا تأكد من وجود الانضمام على المقطع المواجه للمستقبل قبل أن تفحص أي شيء آخر. على المنصات الشبيهة بـ Cisco، يطبع show ip igmp groups على موجه القفزة الأخيرة المجموعات المنضم إليها بجانب الواجهة التي سمعتها. وعندما تغيب المجموعة من ذلك الناتج، يكون النفق مجرد تشتيت: لقد مات الطلب عند مبدل الوصول، أو عند مقبس المضيف، أو في VLAN بلا مستجوِب.

سببان عاديان يفسران معظم حالات الانضمام المفقودة التي رأيتها: عدم تطابق إصدار IGMP بين المضيف والموجه، وانتخاب مستجوِب وقع على مبدل لا يقوم بالتوجيه. والسبب الثالث أدق: المجموعة منضم إليها لكن على VLAN خاطئة لأن المضيف لديه بطاقتا شبكة والتطبيق ارتبط بالخطأ منهما. لدى مستقبلات IPv6 المشكلة المكافئة مع MLD، حيث يجيب show ipv6 mld groups على السؤال نفسه. لا يُصلَح أي من هذه بالمساس بالنفق، وهذا بالضبط سبب أهمية الترتيب.

بمجرد أن يصبح الانضمام مرئيًا، تأكد من أن PIM مفعّل على كل من الواجهة المواجهة للمستقبل والواجهة المؤدية إلى نقطة الالتقاء. فموجه لديه عضوية IGMP لكن بلا PIM على واجهته العلوية سيحتفظ بالمجموعة في جدول محلي ولن يرسل شيئًا إلى أي مكان.

هل تصل مجموعة BSR إلى الجانب الآخر؟

تنتقل رسائل موجه التمهيد قفزة بقفزة داخل نطاق PIM واحد، وهذا هو الاتجاه الذي ينكسر عبر النفق. ترسل نقاط RP المرشحة إعلاناتها إلى BSR المنتخب بالإرسال الأحادي، لذا عادةً تبقى الوصلة بين RP وBSR عبر النفق العامل سليمة دون تغيير. يعتمد فيضان رسائل التمهيد في الاتجاه الآخر على تفعيل PIM على كل واجهة وسيطة، وعلى ألا يوقف شيء الرسائل عند حدّ ما. ويحدد RFC 5059 ذلك التوزيع وحدود النطاق الإداري المسموح لها بقطعه.

إن عبارة ip pim bsr-border، أو قائمة ACL تصفي البروتوكول 103، أو نفق IPsec قائم على السياسات لا يستطيع حمل البث الجماعي، كلها ستقطع الفيضان مع إبقاء الإرسال الأحادي سليمًا. هذا المزيج هو ما يجعل العطل يبدو كمشكلة RP بينما هو في الحقيقة مشكلة وصول، وهو سبب قراءتي لحالة BSR قبل قراءة إعداد RP.

على الموجه في الجانب البعيد، يذكر show ip pim bsr-router الـ BSR المنتخب ومجموعة RP التي تعلمها؛ وإذا كان الناتج فارغًا فإن الجانب البعيد يجلس في نطاقه الخاص ولن يوفّق أي قدر من إعداد RP بين الاثنين. قارن نطاقات المجموعات وعناوين RP في show ip pim rp mapping على جانبي النفق. التعيين الموجود محليًا فقط ينتج شجرة مشتركة تنتهي في المكان الخطأ، وينتظر المستقبل إلى الأبد.

طابِق تعيين RP على جانبي النفق

RP الساكن وBSR وanycast-RP ثلاث طرق للإجابة على السؤال نفسه، وخلطها عبر نفق طريقة موثوقة لبناء نطاق لا يتقارب أبدًا. إذا استخدم الطرف الرئيسي BSR واستخدم الفرع ip pim rp-address ساكنًا يشير إلى عنوان مختلف، فسيبني الفرع شجرته المشتركة نحو RP لا يعرف أن المستقبل موجود. ويجب أن يتفق التعيين على نطاق المجموعة وعلى العنوان معًا، لأن النطاق الأكثر تحديدًا يفوز على الأوسع.

وُجد anycast-RP تحديدًا كي يتمكن موقعان من مشاركة عنوان RP واحد، ويستحق ذكره هنا لأنه يغيّر معنى «نفس RP». فاثنان من RP يعلنان عنوانًا واحدًا متسقان بالتصميم؛ أما اثنان يعلنان عنوانين مختلفين للنطاق نفسه فليسا كذلك، مهما بدا كل موقع سليمًا بمفرده.

بالنسبة للبث الجماعي الخاص بالمصدر داخل 232.0.0.0/8، لا يُستشار RP أبدًا، لذا لا يُعدّ تعيين RP الفارغ عطلًا تلقائيًا. قرّر أي نموذج خدمة يستخدمه التطبيق قبل مطاردة RP لم يكن مطلوبًا قط.

اقرأ بحث RPF نحو المصدر

يبني PIM الشجرة بعكس مسار الإرسال الأحادي، لذا الفحص المهم هو المسار العائد إلى المصدر، أو إلى RP في حالة الشجرة المشتركة. يُسقَط أي انضمام يصل على واجهة لا يعتبرها الموجه علوية، وتُسجَّل السبب كفشل RPF لا كفشل نفق. على موجه فرعي لديه مسار افتراضي عبر النفق ومسار أكثر تحديدًا عبر WAN، يمكن أن تكون واجهة RPF هي WAN بسهولة رغم أن المصدر لا يُوصل إليه إلا عبر النفق. وهذا هو السبب الأكثر شيوعًا على الإطلاق لإسقاط انضمام بصمت.

يطبع show ip rpf 192.0.2.10 الواجهة المختارة والقفزة التالية والمسار الذي أنتج القرار، وهذا عادةً كافٍ لرؤية عدم التطابق. ومسار بث جماعي ساكن مثل ip mroute 192.0.2.0 255.255.255.0 tunnel0 يتجاوز بحث الإرسال الأحادي لتلك البادئة، وهو إصلاح مشروع عندما تختلف طوبولوجيا البث الجماعي فعليًا عن طوبولوجيا الإرسال الأحادي. تعامل معه كإعداد يجب توثيقه، لا كرقعة تُطبَّق أثناء حادثة ثم تُنسى.

أكّد الانضمام بالأوامر، لا بأمر ping

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

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

إدخال (S,G) معمور بواجهة دخول حقيقية وقائمة خروج غير فارغة يعني أن مستوى التحكم أنهى عمله. أما إدخال تقرأ واجهته الداخلة Null، أو عدّاد مسمّى RPF failed يستمر في الارتفاع، فيشير رجوعًا إلى القسم السابق لا إلى النفق.

إذا بدت الأوامر الخمسة كلها صحيحة ومع ذلك لا يرى المستقبل شيئًا، فإن المشتبه المتبقي هو سياسة النفق نفسها: قائمة ACL تشفيرية أو قاعدة جدار حماية تسمح ببروتوكول التوجيه الأحادي ولا تسمح بـ PIM أو IGMP أو حركة المجموعة نفسها. على نفق IPsec قائم على السياسات لا يُنقل البث الجماعي إطلاقًا، لذا الحل هو تصميم GRE أو VTI لا استثناء آخر في المرشح. اكتب أي الفحوص الخمسة فشل قبل أن تغيّر شيئًا، ثم غيّر تلك الطبقة وحدها.