أستكشاف أخطاء IP للبث المتعدد وإصلاحها
المحتويات
المقدمة
يصف هذا المستند المشكلات والحلول الشائعة الخاصة بالبث المتعدد لبروتوكول IP.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات خاصة لهذا المستند.
المكونات المستخدمة
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
عندما تقوم باستكشاف أخطاء توجيه البث المتعدد وإصلاحها، فإن المخاوف الأساسية هي عنوان المصدر. يتضمن البث المتعدد مفهوما لإعادة توجيه المسار العكسي (RPF). عندما تصل حزمة بث متعدد إلى واجهة، تتحقق عملية إعادة توجيه المسار العكسي (RPF) من أن هذه الواجهة الواردة هي الواجهة الصادرة المستخدمة بواسطة توجيه البث الأحادي للوصول إلى مصدر حزمة البث المتعدد. تمنع عملية فحص إعادة توجيه المسار العكسي (RPF) هذه حلقات التكرار. لا يقوم توجيه البث المتعدد بإعادة توجيه حزمة ما لم يقوم مصدر الحزمة بتمرير التحقق من إعادة توجيه المسار العكسي (RPF). ما إن يمرر ربط هذا RPF تدقيق، multicast يرسل تحشد الربط يؤسس فقط على الغاية عنوان.
مثل توجيه البث الأحادي، يحتوي توجيه البث المتعدد على العديد من البروتوكولات المتاحة، مثل وضع البث المتعدد المستقل عن البروتوكول (PIM-DM)، ووضع البث المتناثر ل PIM (PIM-SM)، وبروتوكول توجيه البث المتعدد متجه المسافات (DVMRP)، وبروتوكول العبارة الحدودية للبث المتعدد (MBGP)، وبروتوكول اكتشاف مصدر البث المتعدد (MSDP). تساعدك دراسات الحالة الواردة في هذا المستند على أستكشاف أخطاء المشكلة وإصلاحها. أنت يستطيع رأيت أي أمر يكون استعملت in order to حددت المشكلة بسرعة وتعلمت كيف أن يحل هو. دراسات الحالة المدرجة هنا عامة عبر البروتوكولات، باستثناء الحالات التي تمت الإشارة إليها.
لا يقوم الموجه بإعادة توجيه حزم البث المتعدد إلى المضيف بسبب فشل RPF
يوفر هذا القسم حلا للمشكلة الشائعة لفشل إعادة توجيه المسار العكسي (RPF) للبث المتعدد ل IP. يتم إستخدام الرسم التخطيطي للشبكة هذا كمثال.
مثال الرسم التخطيطي للشبكة لفشل إعادة توجيه المسار العكسي (RPF) للبث المتعدد
في هذا الشكل، تأتي حزم البث المتعدد إلى E0/0 من الموجه 75a من خادم يكون عنوان IP الخاص به 10.1.1.1 ويرسل إلى المجموعة 10.224.1.1. وهذا يعرف باسم (S،G) أو (10.1.1.1 و 10.224.1.1).
تشخيص المشكلة
تتلقى الأجهزة المضيفة المتصلة مباشرة بالموجه 75a موجز ويب البث المتعدد، ولكن الأجهزة المضيفة المتصلة مباشرة بالموجه 72a لا تتلقى ذلك. أولا، أدخل show ip mroute 224.1.1.1 أمر in order to فحصت نشاط على مسحاج تخديد 75a. يفحص هذا الأمر مسار البث المتعدد (mroute) لعنوان المجموعة 10.224.1.1:
75a#show ip mroute 10.224.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
(*, 10.224.1.1), 00:01:23/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:01:23/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:23/00:03:00, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
بما أن الموجه يشغل وضع PIM المكثف (أنت تعرف أنه وضع الكثافة بسبب علامة D)، فتجاهل إدخال *،G وركز على إدخال S،G. يخبرك هذا الإدخال بأن حزم البث المتعدد يتم الحصول عليها من خادم عنوانه 10.1.1.1، والذي يرسل إلى مجموعة بث متعدد 10.224.1.1. تأتي الحزم إلى واجهة Ethernet0/0 ويتم إعادة توجيهها خارج واجهة Ethernet0/1. وهذا سيناريو مثالي.
أدخل show ip pim neighbor الأمر لمعرفة ما إذا كان الموجه 72a يعرض الموجه (75a) من الخادم كموجه PIM المجاور:
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet3/1 2d00h 00:01:15 v2
من موقع show ip pim neighbor من حيث مخرجات القيادة، تبدو منطقة جوار "عملية السلام في الشرق الأوسط" جيدة.
أدخل show ip mroute الأمر لمعرفة ما إذا كان الموجه 72a يحتوي على مسار جيد:
ip22-72a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 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 - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:10/00:02:48, flags:
Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
ip22-72a#
يمكنك ان ترى من show ip mroute 10.224.1.1 أمر بأن الواجهة الواردة هي Ethernet2/0، بينما من المتوقع أن يكون EtherT3/1.
أدخل show ip mroute 10.224.1.1 count أمر in order to رأيت ما إذا أي multicast حركة مرور ل هذا مجموعة يصل إلى المسحاج تخديد 72a وما يحدث بعد ذلك:
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2032 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: 10.224.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471
Source: 10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#
يمكنك أن ترى من العدادات الأخرى أن حركة المرور يتم إسقاطها بسبب فشل إعادة توجيه المسار العكسي (RPF): إجمالي حالات السقوط التي يبلغ 471، بسبب فشل إعادة توجيه المسار العكسي (RPF) - 471...
أدخل show ip rpf أمر in order to رأيت إن هناك يكون RPF خطأ:
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 10.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
يقوم Cisco IOS® بحساب واجهة إعادة توجيه المسار العكسي (RPF) بهذه الطريقة. مصادر معلومات إعادة توجيه المسار العكسي (RPF) المحتملة هي جدول توجيه البث الأحادي وجدول توجيه MBGP وجدول توجيه DVMRP وجدول المسار الثابت. عند حساب واجهة إعادة توجيه المسار العكسي (RPF)، يتم إستخدام المسافة الإدارية في المقام الأول لتحديد مصدر المعلومات الذي يستند إليه حساب إعادة توجيه المسار العكسي (RPF) بدقة. القواعد المحددة هي:
-
يتم البحث عن تطابق في عنوان IP المصدر في جميع المصادر السابقة لبيانات إعادة توجيه المسار العكسي (RPF). عندما يستعمل أنت شجرة مشترك، ال RP عنوان استعملت بدلا من المصدر عنوان.
-
وفي حالة العثور على أكثر من مسار مطابق واحد، يتم إستخدام المسار ذي المسافة الإدارية الدنيا.
-
إذا كانت المسافات الإدارية متساوية، فإن هذا الترتيب من التفضيل يتم إستخدامه:
-
المسارات الثابتة
-
مسارات بروتوكول DVMRP
-
مسارات بروتوكول MBGP
-
مسارات البث الأحادي
-
-
إذا حدثت إدخالات متعددة لمسحاج تخديد ضمن نفس جدول المسار، يتم إستخدام أطول مسار مطابقة.
يعرض الأمر show ip mroute 224.1.1.1 تعرض مخرجات الأمر واجهة إعادة توجيه المسار العكسي (RPF) هي E2/0، ولكن الواجهة الواردة يجب أن تكون E3/1.
أدخل show ip mroute 224.1.1.1 أمر in order to رأيت لما ال RPF قارن مختلف من كان يتوقع.
ip22-72a#show ip route 10.1.1.1 Routing entry for 10.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1
يمكنك أن ترى من إخراج الأمر show ip route 10.1.1.1 هذا أن هناك مسار ثابت/32، والذي يجعل الواجهة الخطأ التي سيتم إختيارها كواجهة إعادة توجيه المسار العكسي (RPF).
أدخل بعض أوامر تصحيح الأخطاء الإضافية:
ip22-72a#debug ip mpacket 10.224.1.1 *Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface
تأتي الحزم في E3/1، وهذا صحيح. ومع ذلك، يتم إسقاطها لأنها ليست الواجهة التي يستخدمها جدول توجيه البث الأحادي للتحقق من إعادة توجيه المسار العكسي (RPF).
الإصلاحات الممكنة
يمكنك إما تغيير جدول توجيه البث الأحادي لتلبية هذا المتطلب أو يمكنك إضافة مسار ثابت لإجبار البث المتعدد إلى 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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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: 10.224.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 10.224.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: 10.224.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 10.224.1.1
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.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
(*, 10.224.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
يمكنك تجاهل 10.224.0.40 في الإخراج نظرا لأن جميع الموجهات تنضم إلى مجموعة اكتشاف Auto-RP هذه. ولكن لا يوجد مصدر مدرج ل 10.224.1.1. بالإضافة إلى "*، 10.224.1.1" يمكنك مشاهدة "10.1.1.1، 10.224.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) للمجموعة 10.224.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 10.224.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2
تم الانضمام إلى الإصدار 10.224.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
(*, 10.224.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, 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.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
الأمر يعني أن أي حزم ذات مدة البقاء (TTL) أقل من الحد المحدد، في هذه الحالة، 15، لا يتم إعادة توجيهها. يتم إستخدام هذا الأمر عادة لتوفير حد لمنع حركة مرور البث المتعدد الداخلية من الانجراف خارج إنترانت.
الإصلاحات الممكنة
قم بإزالة إما ip multicast ttl-threshold
أمر مع الصيغة no من هذا الأمر، والذي يرتد إلى قيمة حد 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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 المتعدد لتوازن التحميل عبر جميع مسارات متساوية التكلفة المتاحة
في الشكل، للموجه 75b ثلاثة مسارات متساوية التكلفة تعود إلى المصدر (10.1.1.1). أنت تريد أن يتوازن الحمل المتعدد حركة مرور عبر كل ثلاثة روابط.
الإصلاحات الممكنة
كما رأيت في مسارات متساوية التكلفة المتعددة ينتج عنها قسم سلوك إعادة توجيه المسار العكسي (RPF) غير المرغوب فيه، يختار البث المتعدد المستقل عن البروتوكول (PIM) واجهة واحدة فقط للتحقق من إعادة توجيه المسار العكسي (RPF) ويختبر الواجهات الأخرى. وهذا يعني عدم حدوث موازنة الأحمال. من أجل موازنة الأحمال، يلزمك إزالة PIM من الارتباطات المتكررة وإنشاء نفق بين الموجه 75a والموجه 75b. يمكنك بعد ذلك موازنة التحميل على مستوى الارتباط، ويجري IP عبر النفق.
هذه هي تكوينات النفق.
| الموجه 75a |
|---|
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 |
| الموجه 75b |
|---|
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 أمر in order to رأيت ال multicast طريق (مسار) للمجموعة:
ip22-75a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.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، تنص على إستخدام ما يلي: لتكوين موجه لقبول الصلات أو الوحدات الموجهة ل RP محدد ولقائمة مجموعات محددة، ip pim accept-rp أمر التكوين العام. لإزالة هذا التحقق، أستخدم نموذج no من هذا الأمر.
عند إزالة ip pim accept-rp أمر، الرسائل تختفي. تم العثور على الأمر الذي يسبب المشكلة، ولكن ماذا إذا كنت تريد الاحتفاظ بهذا الأمر في التكوين؟ يمكنك السماح بعنوان RP الخطأ. أدخل show ip pim rp mapping أمر in order to رأيت الصحيح RP عنوان:
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 للمجموعة 10.224.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 ل 10.224.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 للمجموعة 10.224.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#
لا يمنع CGMP تدفق حزم البث المتعدد
يشرح هذا القسم كيف يمكن أن يحدث فيض غير مرغوب فيه لحزم البث المتعدد عند عدم تمكين بروتوكول إدارة مجموعة Cisco (CGMP) على جميع الموجهات على شبكة فرعية معينة، وكيف يمكن تجنب هذه المشكلة. يتم إستخدام الرسم التخطيطي للشبكة هذا كمثال.
بروتوكول إدارة مجموعة Cisco (CGMP) غير ممكن
تشخيص المشكلة
في الشكل، ال ساكن إستاتيكي حدبة طاولة في المادة حفازة 5000 مفتاح A لا يبدي أي من ال يصح ميناء أن يكون زودت. لا يرسل الموجه الذي تم تكوينه من CGMP حزم CGMP.
تم تكوين CGMP بشكل صحيح باستخدام set cgmp enable الأمر على المحول A و ip cgmp أمر على ال E0/2 قارن من مسحاج تخديد 75a. ومع ذلك، لا يتم عرض أي مجموعات بث متعدد على المحول (أ) عند show multicast group الأمر صادر:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
يجب أن يعرض إخراج هذا الأمر كل منفذ يحتوي على موجه تم تكوينه من CGMP عليه (المنفذ 2/3) وكل منفذ يحتوي على جهاز إستقبال مهتم (المنفذ 2/6). بما أن 0 مدرج، يمكنك أن تفترض أن كل المنافذ تفيض دون داع بحركة مرور البث المتعدد سواء أرادت ذلك أم لا.
ملاحظات
تحقق لمعرفة ما إذا كان هناك أي جيران للبث المتعدد المستقل عن البروتوكول (PIM) على الموجه 75a:
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet0/2 00:07:41 00:01:34 v2
يوضح الإخراج أن الموجه 75a قادر على رؤية الموجه 75b على أنه جار PIM صالح من خلال المحول (أ).
تحقق الآن ما إذا كنت تتلقى معلومات المسار الصحيح للبث المتعدد (المسار) على الموجهات:
ip22-75a#show ip mroute 10.224.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
(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
يعرض الإخراج الموجه 75a يعيد توجيه حزم البث المتعدد من E0/2 نحو المحول (أ). يوضح هذا الإخراج الموجه 75b يحصل على حزم البث المتعدد ويعيد توجيهها بشكل صحيح:
ip22-75b#show ip mroute 10.224.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
(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
من المحول وجهة نظر، أنت ترى أن هو يرى المسحاج تخديد 75a خارج الميناء 2/3.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
كل شيء شوهد حتى الآن يبدو على ما يرام. أدخل بعض debug أمر على مسحاج تخديد 75a in order to رأيت ما أنت يستطيع اكتشفت:
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
في الإخراج، يكون 0000.000.0000 هو عنوان جميع المجموعات ويتم إستخدامه عندما تقوم الموجهات بإرسال رسائل الانضمام/المغادرة إلى CGMP حتى يمكن للمحولات تعبئة منافذ الموجه. ويرمز GDA لعنوان وجهة المجموعة في تنسيق التحكم في الوصول إلى الوسائط (MAC) ويرمز USA لعنوان مصدر البث الأحادي. هذا هو عنوان المضيف الذي أنشأ تقرير IGMP الذي تم إنشاء رسالة CGMP هذه من أجله. في هذه الحالة، هو عنوان MAC للموجه 75a قارن E0/2. يمكن رؤية عنوان MAC للموجه E0/2 من الموجه 75a مع show interface الأمر كما يظهر هنا:
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
بالإضافة إلى ذلك، يمكنك أن ترى هذا بشكل دوري عندما debug ip igmp الأمر قيد التشغيل:
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1
مهما، لا يرى أنت بعد ذلك يماثل CGMP ربط من مسحاج تخديد 75a. هذا يعني أن الموجه 75a يستقبل تقارير IGMP، ولكنه لا ينشئ حزم CGMP الضرورية للمساعدة في تحويل A إلى معرفة المنافذ التي يجب حظرها. هذا شيء متوقع من الموجه 75a إذا كان مستعلم IGMP. يخبرنا هذا الإخراج من الموجه 75a لماذا لا يحدث السلوك المتوقع:
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 10.2.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.2.1.2 (this system) IGMP querying router is 10.2.1.1 No multicast groups joined
إن يتلقى أنت إثنان مسحاج تخديد على ال نفسه subnet، وأنت تشكل كلا ل CGMP، واحد فقط يستطيع أرسلت CGMP ربط. الموجه الذي يرسل حزم CGMP هو بروتوكول IGMP الذي يستعلم عن الموجه. وهذا يعني الموجه صاحب عنوان IP للبث الأحادي الأدنى لموجهات IGMP التي تم تمكين IGMP بها.
في هذه الحالة، يتلقى كلا الموجهين 75a و 75b تمكين IGMP (الموجه 75b أصبح الموجه IGMP الذي يستعلم الموجه)، ولكن الموجه 75a فقط هو الذي تم تمكين CGMP. بما أن الموجه 75a ليس موجه استعلامات IGMP، فلا يتم إرسال حزم CGMP.
الإصلاحات الممكنة
لحل المشكلة، يلزمك تكوين CGMP على موجه استعلامات IGMP. في هذه الحالة، الموجه 75b. أولا، شغل debug أوامر على الموجه 75b:
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 10.2.1.3 for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
يستلم الموجه 75b تقرير IGMP من 10.2.1.3 للمجموعة 10.224.1.1. وهو يرسل فيما بعد انضمام CGMP إلى المحول A لمعادل MAC 10.224.1.1 مع عنوان MAC (الولايات المتحدة الأمريكية) من المضيف 10.2.1.3 المهتم. يعرف المفتاح A أي ميناء أن مضيف يكون على، لذلك وضع علامة هو كفتح ويحظر الآخر.
يجب أن تعمل الأشياء الآن على المحول A:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
هذا أفضل بكثير. لا يتم إرسال الحزم 10.224.1.1 (01-00-5e-01-01-01) إلا من المنافذ 2/3 و 2/4 و 2/6 على المحول (أ)، كما يجب. لقد توقف تدفق البيانات إلى جميع المنافذ الأخرى. يتم الآن إدراج العدد الإجمالي للإدخالات بشكل صحيح ك 2. يتم تعيين عنوان MAC 01-00-5e-00-01-28 من عنوان البث المتعدد 224.0.1.40، والذي يتم إستخدامه للروابط الذاتية ل CGMP.
لا يمنع CGMP تدفق حزم البث المتعدد، بسبب وضع المصدر/المستقبل
يزود هذا قسم حل إلى المشكلة المشتركة من مادة حفازة مفتاح أن يفيض حركة مرور إلى كل ميناء، instead to فقط المضيف صحيح. يتم إستخدام الرسم التخطيطي للشبكة هذا كمثال.
مادة حفازة مفتاح أن يفيض حركة مرور إلى كل ميناء
تشخيص المشكلة
في الشكل، تم تكوين الموجهات 75a و 75b و Catalyst 5000 (المحول (أ) بشكل صحيح للبث المتعدد وبروتوكول إدارة مجموعة Cisco (CGMP). يحصل المضيف على حركة مرور البث المتعدد. ومع ذلك، كذلك هو كل مضيف آخر من المفتاح A. مفتاح a يفيض الحركة مرور خارج كل ميناء، لذلك هو يعني أن CGMP لا يعمل.
الناتج من show multicast group يبدو الأمر على المحول A:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
يمكنك أن ترى من الإخراج أن المجموعة الوحيدة هي 224.0.1.40، والتي يتم إستخدامها من قبل الموجه عندما يرسل روابط CGMP الذاتية لمجموعة RP التلقائية. لماذا لا توجد مجموعات أخرى؟
الإصلاحات الممكنة
لفهم الحل، يلزمك فهم كيفية تصرف CGMP في ظل ظروف معينة. يرسل الموجه الذي يدعم CGMP روابط CGMP إلى محول لإعلام المحول بالمضيفين المهتمين بمجموعة بث متعدد معينة. يقوم المحول بالبحث عن عناوين MAC لهذه الأجهزة المضيفة في جدول CAM الخاص به، ثم إعادة توجيه حزم البث المتعدد خارج المنافذ مع الأجهزة المضيفة المهتمة ويحظر جميع المنافذ الأخرى من إعادة توجيه حزم البث المتعدد.
يرسل الموجه الروابط الذاتية ل CGMP من واجهة تم تمكين CGMP إذا كان يستلم حزم البث المتعدد من مصدر موجود على الواجهة نفسها التي يحتوي عليها (الموجه) على CGMP الممكنة.
على سبيل المثال، إذا كان المصدر على الشبكة الفرعية (VLAN) نفسها، 10.2.1.0/24، كموجهات 75a و 75b، فإن CGMP يعمل بشكل كامل. يرسل الموجه، عندما يحدد الحزم من المصدر، انضمام CGMP ذاتي إلى المحول، والذي سيتعرف بعد ذلك بشكل ديناميكي على المنافذ التي يتم تشغيل الموجه عليها ويحظر جميع المنافذ الأخرى من إعادة توجيه حزم البث المتعدد.
يرسل الموجه CGMP وينضم إلى واجهة تم تمكين CGMP إذا كان يستلم تقارير IGMP من مضيف على الواجهة نفسها التي تحتوي (الموجه) على CGMP الممكنة.
مثال آخر إن يتلقى أنت مهتم مضيف على هذا VLAN نفسه. في هذه الحالة، عندما يستلم موجه تم تمكين CGMP عليه تقرير بروتوكول إدارة مجموعة الإنترنت (IGMP) من مضيف مهتم بمجموعة بث متعدد معينة، يقوم الموجه بإرسال انضمام CGMP. يشير الربط إلى عنوان التحكم بالوصول إلى الوسائط (MAC) للمضيف الذي يريد الانضمام والمجموعة التي يريد الانضمام إليها. المادة حفازة 5000 بعد ذلك فحصت ه حدبة طاولة للمضيف {upper}mac address، وضعت الميناء موحد على ال multicast مجموعة قائمة، ويحظر كل آخر ميناء غير مهتم.
نفس الشيء غير صحيح عندما يكون المصدر والمضيف (المضيف) المهتمة على شبكة فرعية غير الشبكة الفرعية التي تم تمكين CGMP عليها (VLAN). لا تقوم حزم البث المتعدد، التي تأتي من المصدر، بتشغيل الموجه لإرسال وصلات CGMP الذاتية إلى المحول. لذلك ربطت الربط المفتاح وفضت في كل مكان ضمن ال VLAN. يستمر هذا سيناريو إلى أن يرسل مضيف في ال VLAN، أن يأتي من ميناء على المفتاح، IGMP ربط. لا يرسل الموجه حزمة CGMP إلا مع إستلام تقرير IGMP، مما يتسبب في قيام المحول بإضافة منفذ المضيف المناسب لإعادة التوجيه وحظر جميع المنافذ الأخرى (باستثناء منافذ الموجه).
ل CGMP أن يعمل في هذا عابر نوع طبولوجيا، أنت يستطيع إما أضفت مضيف إلى ال نفسه VLAN بما أن مسحاج تخديد 75a و 75b، بما أن في هذا شبكة رسم بياني.
أضفت مضيف إلى ال نفسه VLAN كمسحاج تخديد 75a و 75b
أو قم بنقل المصدر على الشبكة الفرعية نفسها الخاصة بالموجهين 75a و 75b، كما هو الحال في هذا المثال.
نقل المصدر على الشبكة الفرعية نفسها الخاصة بالموجهين 75a و 75b
قم بنقل المصدر إلى الشبكة الفرعية نفسها ثم تحقق من الإخراج من المحول (أ):
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
لا يمنع CGMP غمر حزم البث المتعدد لعناوين مجموعة معينة
يشرح هذا القسم لماذا تتسبب بعض عناوين IP للبث المتعدد في أن يتسبب بروتوكول إدارة مجموعة Cisco (CGMP) في تدفق حركة مرور البث المتعدد خارج جميع المنافذ على شبكة المنطقة المحلية (LAN). عندما تستخدم عنوان مجموعة البث المتعدد 10.225.0.1، لا يعمل CGMP. يفيض تيار البث المتعدد عن جميع منافذ المحولات والمخلفات عرض النطاق الترددي. ومع ذلك، إذا قمت بتغيير العنوان إلى 10.225.1.1 يعمل CGMP بشكل جيد. هل يمكنك إستخدام 10.225.0.1 لأنه ليس عنوانا مسجلا لبروتوكول توجيه؟
الإصلاحات الممكنة
أولا، من المهم فهم كيفية تعيين عناوين البث المتعدد للطبقة 3 على عناوين البث المتعدد للطبقة 2. تستخدم جميع إطارات بث IP المتعدد عناوين طبقة IEEE MAC التي تبدأ ببادئة 24 بت من 0x0100.5e. عندما تقوم بترجمة عناوين الطبقة 3 إلى الطبقة 2، يتم ترجمة 23 بت منخفضة الترتيب لعنوان البث المتعدد للطبقة 3 إلى 23 بت منخفضة الترتيب من عنوان IEEE MAC.
هناك حقيقة مهمة أخرى يجب فهمها هي وجود 28 وحدة بت من مساحة العنوان الفريدة لعنوان IP للبث المتعدد (32 وحدة بت ناقص وحدات البت الأربع الأولى التي تحتوي على البادئة 1110 من الفئة D). ونظرا لوجود 23 وحدة بت فقط موصلة في عنوان IEEE MAC، فلا تزال هناك 5 وحدات بت من التداخل. هذا يعني أنه يمكن تعيين عناوين البث المتعدد للطبقة 3 المتعددة إلى نفس عنوان البث المتعدد للطبقة 2.
على سبيل المثال:
10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
لاحظ في المثال كلا من خريطة 10.244.0.1 و 10.244.128.0 إلى عنوان البث المتعدد للطبقة 2 نفسها.
الآن بعد أن أصبحت تعرف كيفية تعيين عناوين البث المتعدد من الطبقة 3 إلى الطبقة 2، انتقل إلى الحل المحدد لهذه المشكلة.
قم بالتبديل لحزم البث المتعدد إلى 224.0.0.x لأن هذه العناوين هي link-local وأنت تريد التأكد من وصول عناوين الارتباط المحلية إلى جميع الأجهزة الموجودة على شبكة المنطقة المحلية (LAN). كما تقوم محولات Catalyst بتموين حزم البث المتعدد إلى عناوين البث المتعدد الأخرى التي تكون غامضة على مستوى MAC باستخدام 224.0.0.x (على سبيل المثال، يتم تعيين كل من 10.244.0.1 و 10.225.0.1 إلى 0100.5e0001). يفيض المحول حزم البث المتعدد الموجهة لعناوين الارتباط المحلية هذه سواء تم تمكين CGMP أم لا.
لذلك، يجب أن يتجنب تطبيق البث المتعدد إستخدام عناوين الفئة D التي تترجم إلى عنوان بث متعدد للطبقة 2 من 0100.5e00.00xx، حيث يمكن أن يكون xx 00 من خلال FF في قاعدة سداسية عشرية. يتكون هذا من عناوين الفئة D التالية:
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
يتم تلقي تدفقات حزم البث المتعدد المكررة
السبب 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 erasecat4000_flash:.
Switch#show interface gi 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
أمر على أي قارن (واجهات)، هو يعالج تحويل. إذا تم تبديل حزم البث المتعدد على أي واجهة (واجهات)، فإنها تستهلك المزيد من وحدة المعالجة المركزية (CPU) لأنها تفوض تحويل العمليات لجميع الحزم إلى تلك المجموعة. يمكنك تشغيل show buffers input-interface وأمر وفحص الحجم غير الطبيعي.
Switch#show buffers input-interface gi 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
بدلا من ip igmp join-group
erasecat4000_flash:.
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
2.0 |
26-May-2023 |
تقويم |
1.0 |
02-Dec-2013 |
الإصدار الأولي |
التعليقات