أستكشاف أخطاء IP للبث المتعدد وإصلاحها

أدخل بعض أوامر تصحيح الأخطاء الإضافية:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

تأتي الحزم في E3/1، وهذا صحيح. ومع ذلك، يتم إسقاطها لأنها ليست الواجهة التي يستخدمها جدول توجيه البث الأحادي للتحقق من إعادة توجيه المسار العكسي (RPF).

ملاحظة: تصحيح أخطاء الحزم أمر خطير. مشغلات تصحيح الحزم تقوم بعملية تحويل حزم البث المتعدد، والتي تكون مكثفة لوحدة المعالجة المركزية. كما يمكن أن ينتج عن تصحيح الحزم إخراج ضخم يمكن أن يعلق الموجه بالكامل نظرا لبطء الإخراج إلى منفذ وحدة التحكم. قبل تصحيح أخطاء الحزم، يجب توخي عناية خاصة لتعطيل إخراج التسجيل إلى وحدة التحكم، وتمكين التسجيل إلى المخزن المؤقت للذاكرة. لتحقيق ذلك، قم بتكوين no logging console وlogging buffered debuing. يمكن رؤية نتائج تصحيح الأخطاء باستخدام الأمر show logging.

الإصلاحات الممكنة

يمكنك إما تغيير جدول توجيه البث الأحادي لتلبية هذا المتطلب أو يمكنك إضافة مسار ثابت لإجبار البث المتعدد إلى RPF من واجهة معينة، بغض النظر عن ما يقوله جدول توجيه البث الأحادي. إضافة مسار ثابت:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

يوضح هذا المسار الثابت أنه للوصول إلى العنوان 10.1.1.1 لإعادة توجيه المسار العكسي (RPF)، أستخدم 10.2.1.1 كالخطوة التالية التي تخرج الواجهة E3/1.

ip22-72a#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

الإنتاج من show ip mroute debug ip mpacket ويبدو جيد، الرقم من يرسل ربط في show ip mroute count الزيادات، و HostA يستلم ربط.

ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (10.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

لا يقوم الموجه بإعادة توجيه حزم البث المتعدد إلى المضيف بسبب إعداد TTL للمصدر

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

تطبيقات البث المتعدد المصممة بشكل رئيسي لمثال إستخدام شبكة LAN

تشخيص المشكلة

في الشكل السابق، لا يقوم الموجه A بإعادة توجيه الحزم من المصدر (المصادر) إلى الموجه B الذي يكون المستقبل المتصل مباشرة. نظرت في إخراج الأمر   show ip mroute  على الموجه A لترى حالة توجيه البث المتعدد:

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

يمكنك تجاهل 224.0.1.40 في الإخراج نظرا لأن جميع الموجهات تنضم إلى مجموعة اكتشاف Auto-RP هذه. غير أنه لا يوجد مصدر مدرج ل 224.1.1.1. بالإضافة إلى "*، 224.1.1.1" لا يمكنك مشاهدة "10.1.1.1، 224.1.1.1".

دخلت العرض ip rpf أمر in order to رأيت إن هو يكون RPF إصدار:

ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables 

من الإخراج، لا تعد مشكلة إعادة توجيه المسار العكسي (RPF). يشير التحقق من إعادة توجيه المسار العكسي (RPF) بشكل صحيح إلى E0/0 للوصول إلى عنوان IP للمصدر.

تحقق ما إذا تم تكوين PIM على الواجهات باستخدام show ip pim interface الأمر:

ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2 10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2 

الواقع أن الناتج يبدو جيدا، لذا فإن هذه ليست المشكلة. تحقق ما إذا كان الموجه يتعرف على أي حركة مرور نشطة باستخدام show ip mroute active الأمر:

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps 

استنادا إلى الإخراج، لا يتعرف الموجه على أي حركة مرور نشطة.

ROUTERA#debug ip mpacket IP multicast packets debugging is on 

ربما لا يرسل المستقبل أي تقارير (وصلات) لبروتوكول إدارة مجموعات الإنترنت (IGMP) للمجموعة 224.1.1.1. يمكنك فحصه باستخدام show ip igmp group  الأمر:

ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.1.1 تم الانضمام إليه في E1/2، وهو أمر جيد.

وضع PIM المكثف هو بروتوكول للطوفان والنتوء، لذلك لا توجد وصلات، ولكن هناك ترقيع. نظرا لأن الموجه B لم يتلق فيضا من الموجه A، فإنه لا يعرف أين يرسل الكسب غير المشروع.

أنت يستطيع فحصت أن يرى إن يكون هو إصدار TTL مع ال sniffer التقاط وأيضا رأيت مع show ip traffic  أمر:

ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options 

يبدي الإنتاج 63744 سيئ جنجل يعدد. كل مرة تكتب فيها هذا الأمر، يزداد عدد الخطوات السيئة. هذه إشارة قوية إلى أن المرسل يرسل الحزم ذات TTL=1، والتي يقوم الموجه A بإرسال المراتب إلى صفر. يؤدي هذا إلى زيادة في حقل عدد الخطوات غير الصحيحة.

الإصلاحات الممكنة

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

بمجرد القيام بذلك، سيبدو الموجه A كما يلي:

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

هذا هو نوع المخرجات الذي تريد رؤيته.

في الموجه B يمكنك مشاهدة:

ROUTERB#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (10.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

لا يقوم الموجه بإعادة توجيه حزم البث المتعدد بسبب حد TTL للموجه

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

حد TTL منخفض جدا لذلك لا تصل حركة مرور IP للبث المتعدد إلى المستقبل

تشخيص المشكلة

في الشكل السابق، لا يستقبل المستقبل حزم البث المتعدد من المصدر. يمكن أن يكون هناك عدة مسحاج تخديد بين المصدر والموجه 75a. نظرة أولى على الموجه 75a، نظرا لأنه متصل مباشرة بالمستقبل.

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

يعرض الإخراج الموجه 75a يعيد توجيه الحزم خارج Ethernet0/1. للتأكد بشكل مطلق من أن الموجه 75a يعيد توجيه الحزم، قم بتشغيل debug فقط لهذا المصدر ومجموعة البث المتعدد:

ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

تشير debug الرسائل إلى أن الموجه 75a لا يرسل حزم البث المتعدد لأنه تم الوصول إلى حد TTL. نظرت في تكوين الموجه لمعرفة ما إذا كان يمكنك العثور على السبب. يوضح هذا الإخراج المسؤول:

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 

يحتوي الموجه على حد TTL بقيمة 15، ولكن هذا لا يعني أنه لا يتم إرسال أي شيء أكبر من TTL بقيمة 15. بل إن العكس هو الصحيح. يتم إرسال التطبيق بعدد TTL يبلغ 15. بحلول وقت الوصول إلى الموجه 75a، يكون لحزم البث المتعدد مدة البقاء (TTL) أقل من 15.

ip multicast ttl-threshold <value> يعني الأمر أن أي حزم ذات مدة البقاء (TTL) أقل من الحد المحدد، في هذه الحالة، 15، لا يتم إعادة توجيهها. يتم إستخدام هذا الأمر عادة لتوفير حد لمنع حركة مرور البث المتعدد الداخلية من الانجراف خارج إنترانت.

الإصلاحات الممكنة

قم بإزالة ip multicast ttl-threshold <value> الأمر باستخدام هذا الأمر no form، والذي يرجع إلى قيمة حد TTL الافتراضية التي تبلغ 0، أو أقل من حد TTL حتى يمكن حركة المرور المرور.

ينتج عن مسارات متساوية التكلفة المتعددة سلوك إعادة توجيه المسار العكسي (RPF) غير المرغوب فيه

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

تؤدي مسارات التكلفة المتكافئة إلى مصدر البث المتعدد إلى سلوك إعادة توجيه المسار العكسي (RPF) غير المرغوب فيه

تشخيص المشكلة

في الشكل، يشتمل الموجه 75b على ثلاثة مسارات تكلفة متساوية للعودة إلى المصدر (10.1.1.1)، ويختار رابطا لا تريد أن يكون إختياره الأول كاتصال إعادة توجيه المسار العكسي (RPF).

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

الإصلاحات الممكنة

لتغيير الواجهة IP Multicast التي تختارها كواجهة واردة، يمكنك تنفيذ أحد الإجراءات التالية:

• قم فقط بتكوين PIM على الواجهات التي تريد أن يجتازها البث المتعدد، مما يعني أنك تفقد تكرار البث المتعدد.

• قم بتغيير الشبكات الفرعية حتى يكون عنوان IP الأعلى على الارتباط الذي تريده أن يكون إرتباط البث المتعدد الأساسي.

• قم بإنشاء مسار ساكن إستاتيكي للبث المتعدد (mroute) يشير إلى واجهة البث المتعدد المفضلة، مما يعني أنك تفقد تكرار البث المتعدد.

كمثال، خلقت ممر ساكن إستاتيكي.

قبل تثبيت مسار ثابت، ترى في هذا الإخراج أن جدول التوجيه به ثلاثة مسارات متساوية التكلفة لعنوان المصدر 10.1.1.1. تشير معلومات إعادة توجيه المسار العكسي (RPF) إلى أن واجهة إعادة توجيه المسار العكسي (RPF) هي E1/3:

ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (10.4.1.1) RPF route/mask: 10.1.1.1/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (10.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

بعد أن يشكل أنت المسار ساكن إستاتيكي، أنت ترى في هذا إنتاج غيرت ال RPF قارن إلى E1/1:

ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (10.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

لماذا لا يتم تحميل بث IP المتعدد عبر جميع مسارات التكلفة المتساوية المتاحة؟

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

ملاحظة: قبل تحميل حركة مرور IP متعددة البث المقسمة عبر مسارات متساوية التكلفة عبر نفق، قم بتكوين موازنة حمل CEF لكل حزمة أو وإلا لا يمكن أن تكون حزم GRE متوازنة للتحميل لكل حزمة. للاطلاع على الأساليب الأخرى لتحميل المشاركة في بيئات البث المتعدد، راجع تحميل حركة مرور بث IP المتعدد المنقسم عبر ECMP.

تكوين بث IP المتعدد لتوازن التحميل عبر جميع مسارات متساوية التكلفة المتاحة

في الشكل، للموجه 75b ثلاثة مسارات متساوية التكلفة تعود إلى المصدر (10.1.1.1). أنت تريد أن يتوازن الحمل المتعدد حركة مرور عبر كل ثلاثة روابط.

الإصلاحات الممكنة

كما رأيت في مسارات متساوية التكلفة المتعددة ينتج عنها قسم سلوك إعادة توجيه المسار العكسي (RPF) غير المرغوب فيه، يختار البث المتعدد المستقل عن البروتوكول (PIM) واجهة واحدة فقط للتحقق من إعادة توجيه المسار العكسي (RPF) ويختبر الواجهات الأخرى. وهذا يعني عدم حدوث موازنة الأحمال. من أجل موازنة الأحمال، يلزمك إزالة PIM من الارتباطات المتكررة وإنشاء نفق بين الموجه 75a والموجه 75b. يمكنك بعد ذلك موازنة التحميل على مستوى الارتباط، ويجري IP عبر النفق.

هذه هي تكوينات النفق.

interface Tunnel0 
 ip address 10.6.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 10.5.1.1 
! 
interface Ethernet0/0 
 ip address 10.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 10.3.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 10.4.1.1 255.255.255.0

interface Tunnel0 
 ip address 10.6.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 10.1.1.2 
! 
interface Ethernet1/1 
 ip address 10.2.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 10.3.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 10.4.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 10.5.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

بعد تكوين النفق، أدخل show ip mroute الأمر لعرض مسار البث المتعدد (المسار) للمجموعة:

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (10.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (10.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

للتحقق من أن بيانات البث المتعدد متوازنة الحمل بشكل متساو عبر الارتباطات الثلاثة، انظر إلى بيانات الواجهة للموجه 75a.

الواجهة الواردة هي 9000 بت/ثانية:

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec 

تظهر الواجهات الثلاث الصادرة لكل منها 3000 بت/ثانية:

ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec

عند تلقي رسائل الخطأ "invalid_rp_JOIN" للبث المتعدد ل IP على الموجه

يوفر هذا القسم حلولا للمشكلة الشائعة لرسالة خطأ "INVALID_RP_JOIN" للبث المتعدد ل IP.

تشخيص المشكلة - الجزء 1

يتم تلقي رسائل الخطأ هذه على نقطة الالتقاء (RP):

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 

يشرح مستند رسائل خطأ نظام برنامج Cisco IOS سبب هذا الخطأ: أرسل موجه PIM لتدفق البيانات (PIM) من الخادم رسالة انضمام للشجرة المشتركة، والتي لا يريد هذا الموجه قبولها. يشير هذا السلوك إلى أن هذا الموجه يسمح فقط لموجهات تدفق البيانات من الخادم بالانضمام إلى RP محدد.

ويشتبه في أنه ييصفي. تحتاج إلى إلقاء نظرة على تكوين الموجه:

interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255 

ما هو accept-rp  البيان في التكوين الذي من المفترض إنجازه؟ في أوامر التوجيه متعدد البث ل IP، تنص على إستخدام أمر التكوين العام لتكوين موجه لقبولip pim accept-rp الارتباطات أو الوحدات المعينة ل RP المحدد ولقائمة مجموعات محددة. لإزالة هذا التحقق، أستخدم نموذج no من هذا الأمر.

عند إزالة ip pim accept-rp الأمر، تختفي الرسائل. تم العثور على الأمر الذي يسبب المشكلة، ولكن ماذا إذا كنت تريد الاحتفاظ بهذا الأمر في التكوين؟ يمكنك السماح بعنوان RP الخطأ. دخلت show ip pim rp mapping  الأمر in order to رأيت ال يصح عنوان:

ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 10.1.5.4 (?), v2v1 Info source: 10.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07

استنادا إلى الإخراج، فإن 10.1.5.4 هو بروتوكول RP الوحيد الذي يتم تعلمه عبر بروتوكول Auto-RP أو غير ذلك. ومع ذلك، فإن هذا الموجه هو RP فقط للمجموعات 224.0.0.0/4. لذلك، فإن pim accept-rp العبارة في التكوين خاطئة.

الإصلاحات الممكنة

يكمن الحل في تصحيح عنوان IP في ip pim accept-rp البيان على النحو التالي:

تغيير هذه العبارة:

ip pim accept-rp 10.2.2.2 8

إلى هذا:

ip pim accept-rp 10.1.5.4 8

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

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

تشخيص المشكلة - الجزء 2

تظهر رسالة الخطأ هذه على الموجه2.

router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 10.2.1.1

تحقق لمعرفة ما إذا كان الموجه 2 هو RP للمجموعة 224.1.1.1:

router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#

قيمة rp ل 224.1.1.1 هي 10.1.1.1.

تحقق ما إذا كانت هذه إحدى واجهات الموجه2:

router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#

بما أن الموجه2 ليس RP، فيجب ألا يكون قد استلم حزمة RP-Join هذه. تحقق من سبب إرسال موجه تدفق البيانات من الخادم للانضمام إلى الموجه 2، بينما يجب ألا:

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 10.2.1.1 (?) router3#

كما ترى، يحتوي الموجه 3 على معلومات RP التي تم تكوينها بشكل ثابت ويشير إلى الموجه 2، وهو غير صحيح. هذا يفسر لماذا يرسل الموجه 3 RP-Join إلى الموجه 2.

الإصلاحات الممكنة

قم إما بجعل الموجه 2 هو RP للمجموعة 224.1.1.1 أو قم بتغيير التكوين على الموجه 3 حتى يشير إلى عنوان RP الصحيح.

router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#

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

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#

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

السبب 1

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

يمكن إصلاح 1

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

السبب 2

يمكن أن يقع هذا إصدار في cisco مادة حفازة 6500 مفتاح، أي يكون شكلت لمخرج multicast جواب أسلوب ويستطيع كنت أطلقت ب إزالة وإعادة إدخال أي linecards [OIR]. بعد OIR، القماش ميناء من مخرج [FPOE] يستطيع كنت misبرمجت، أي يستطيع سببت ربط أن يكون وجهت إلى القناة خطأ بناء مخرج وأرسلت إلى أسطر خاطئة. والنتيجة هي أن يتم تكرارها مرة أخرى إلى النسيج ويتم نسخها مرات عديدة عند خروجها على خط الكتابة الصحيح.

C6509#show mls ip multicast capability Current mode of replication is Egress Auto replication mode detection is ON Slot Multicast replication capability 1 Egress 2 Egress 3 Egress 4 Egress 5 Egress 6 Egress 7 Egress

الإصلاح المحتمل 2

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

mls ip multicast replication-mode ingress 

قم بترقية برنامج Cisco IOS software إلى إصدار لا يتأثر بمعرف تصحيح الأخطاء من Cisco CSCeg28814 من أجل حل المشكلة بشكل دائم.

ملاحظة: يمكن لمستخدمي Cisco المسجلين فقط الوصول إلى أدوات Cisco الداخلية ومعلومات الخطأ.

السبب 3

يمكن أن تحدث هذه المشكلة أيضا إذا تم تعطيل إعداد مقياس جانب التلقي (RSS)، على المضيفين النهائيين أو الخوادم.

يمكن إصلاح 3

يسهل إعداد RSS الإرسال السريع للبيانات عبر وحدات معالجة مركزية متعددة. قم بتمكين إعداد RSS على المضيف النهائي أو الخادم.

لماذا يتم إسقاط حزم البث المتعدد؟

السبب 1

من الممكن أن ترى التوهجات الزائدة وحالات إسقاط حزمة الإدخال على الواجهة (الواجهات) عند تدفق حركة مرور البث المتعدد. يمكنك التحقق من التوهجات باستخدام show interface الأمر.

Switch#show interface gigabitethernet 1/0 !--- Output suppressed MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 195000 bits/sec, 85 packets/sec 30 second output rate 1000 bits/sec, 1 packets/sec L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
 438000092206 bytes mcast L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes 1326976857 packets input, 506833655045 bytes, 0 no buffer Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 31643944 packets output, 3124494549 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

يمكن إصلاح 1

يمكنك ضبط قيمة SPT على أنها ما لا نهاية للواجهة حيث يتم رؤية التوهجات الزائدة.

تكوين هذا:

Switch(config-if)#ip pim spt-threshold infinity 

السبب 2

عند إستخدام الأمرip igmp join-group <group-name> على أي واجهة (واجهات)، فإنه يعالج التحويل. إذا تم تبديل حزم البث المتعدد على أي واجهة (واجهات)، فإنها تستهلك المزيد من وحدة المعالجة المركزية (CPU) لأنها تفوض تحويل العمليات لجميع الحزم إلى تلك المجموعة. يمكنك تشغيل show buffers input-interface الأمر والتحقق من الحجم غير الطبيعي.

Switch#show buffers input-interface gigabitethernet 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed 

الإصلاح المحتمل 2

يمكنك إستخدام الأمرip igmp static-group <group-name> بدلا من ip igmp join-group <group-name> الأمر.

ملاحظة: نظرا للمشكلات السابقة، من الممكن أن تشهد إرتفاعا في إستخدام وحدة المعالجة المركزية (CPU) بنسبة 90 بالمائة. وتصبح وحدة المعالجة المركزية (CPU) طبيعية عند حلها باستخدام هذه الإصلاحات المحتملة.

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

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

• تمكين تقسيم الحمل متعدد البث ل ECMP 

• دعم تقنية بث IP المتعدد
• دعم بروتوكولات توجيه IP
• الدعم التقني وأحمال العمل من Cisco