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

المقدمة

يصف هذا المستند توجيه البث المتعدد على جهاز الأمان القابل للتكيف (ASA)، والمشاكل الشائعة.

معلومات الميزة

• الوضع المتناثر ل PIM (البث المتعدد المستقل عن البروتوكول: RFC 4601)
• وضع بروتوكول إدارة مجموعات الإنترنت (IGMP Stub-mode) (بروتوكول إدارة مجموعات الإنترنت: RFC 2236)

الوضع المتناثر ل PIM هو الاختيار المفضل لأن ASA يتصل بالجيران عبر بروتوكول توجيه حقيقي للبث المتعدد (PIM). كان وضع IGMP Stub هو خيار تكوين البث المتعدد الوحيد قبل إصدار ASA الإصدار 7.0، ويتم تشغيله ببساطة عن طريق إعادة توجيه تقارير IGMP التي يتم استقبالها من العملاء تجاه موجهات البث الأولي.

مكونات البث المتعدد

 بشكل عام، تتكون البنية الأساسية للبث المتعدد من هذه المكونات:

المرسل => المضيف أو جهاز الشبكة الذي يقوم بإنشاء دفق البث المتعدد. الأمثلة هي الخادم الذي يرسل بث الفيديو و/أو الصوت وأجهزة الشبكة التي تشغل بروتوكول توجيه مثل EIGRP أو OSPF. 

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

الموجهات / ASA => أجهزة الشبكة المسؤولة عن معالجة تدفق/حركة مرور البث المتعدد وإعادة توجيهه إلى أجزاء أخرى من الشبكة عند الحاجة من المصدر إلى العميل (العملاء).

بروتوكول توجيه البث المتعدد => البروتوكول المسؤول عن إعادة توجيه حزم البث المتعدد. الأكثر شيوعا هو PIM (البث المتعدد المستقل عن البروتوكول)، ولكن هناك آخرون مثل MOSPF على سبيل المثال.

بروتوكول إدارة مجموعات الإنترنت (IGMP) => العملية التي يستخدمها العملاء لتلقي تدفق بث متعدد من مجموعة معينة.

عملية وضع تناثر PIM

• يدعم ASA وضع PIM المتناثر ووضع PIM ثنائي الإتجاه.
• يجب عدم تكوين أوامر وضع PIM المتناثر و IGMP stub في نفس الوقت.

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

توضح هذه الصورة عملية نشر شائعة حيث يحتوي ASA على عملاء بث متعدد على واجهة واحدة وجيران PIM على واجهة أخرى:

تكوين عينة وضع النثر ل PIM

1. قم بتمكين التوجيه متعدد البث (وضع التكوين العام).

ASA(config)# multicast-routing

 2. تحديد عنوان نقطة التقاء PIM.

ASA(config)# pim rp-address 172.18.123.3

 3. اسمح بحزم البث المتعدد في الواجهة المناسبة (ضروري فقط إذا قام سياسة الأمان الخاصة ب ASA بحظر حزم البث المتعدد الواردة).

access-list 105 extended permit ip any host 224.1.2.3
access-group 105 in interface outside

 مثال وضع PIM المتناثر:

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

خطوات تسجيل العميل (الخطوات الحمراء):

1. يرسل العميل تقرير IGMP للمجموعة 239.1.1.77

2. يرسل الموجه رسالة ربط PIM إلى RP الثابت المكون (10.1.1.1) للمجموعة 239.1.1.77.

3. يرسل ASA إلى RP رسالة PIM Join للمجموعة 239.1.1.77.

يعرض ASA إدخال PIM *،G على إخراج الأمر show mroute:

ciscoasa# show mroute 239.1.1.77

Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT 
Timers: Uptime/Expires
Interface state: Interface, State

(*, 239.1.1.77), 00:03:43/00:02:41, RP 10.1.1.1, flags: S
  Incoming interface: outside
  RPF nbr: 10.38.111.240
  Immediate Outgoing interface list:
    inside, Forward, 00:03:43/00:02:41

ولكن بما أن الخادم المصدر لم يبدأ أي تدفق، فإن إخراج "show mfib" على ASA لا يعرض أي حزم مستلمة:

ciscoasa# show mfib 239.1.1.77  
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling 
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count

(*,239.1.1.77) Flags: C K
   Forwarding: 0/0/0/0, Other: 0/0/0
   outside Flags: A
   inside Flags: F NS
     Pkts: 0/0

قبل أن يبدأ الخادم في إرسال أي حركة مرور إلى مجموعة البث المتعدد، يعرض RP فقط إدخال "*.G" بدون واجهة واردة في القائمة، على سبيل المثال:

CRSv#show ip mroute 239.1.1.77
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, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.77), 00:00:02/00:03:27, RP 10.1.1.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse-Dense, 00:00:02/00:03:27

بمجرد بدء الخادم في الدفق إلى مجموعة البث المتعدد، يقوم RP بإنشاء إدخال "S،G" ويضع الواجهة التي تواجه المرسل في قائمة الواجهة الواردة ويبدأ في إرسال حركة مرور البيانات إلى الخادم إلى ASA:

CRSv#show ip mroute 239.1.1.77

...

(*, 239.1.1.77), 00:03:29/stopped, RP 10.1.1.1, flags: SF
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse-Dense, 00:03:29/00:02:58

(10.38.118.10, 239.1.1.77), 00:00:07/00:02:52, flags: FT
  Incoming interface: GigabitEthernet1, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse-Dense, 00:00:07/00:03:22

أستخدم هذه الأوامر للتحقق:

- عرض الأمر mroute يعرض إدخال "S،G"

يعرض الأمر -show mfib عدادات الحزم الأمامية

- يعرض الأمر show conn الاتصال المتعلق بمجموعة البث المتعدد ip

ciscoasa# show mroute 239.1.1.77

Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT 
Timers: Uptime/Expires
Interface state: Interface, State

(*, 239.1.1.77), 00:06:22/00:02:50, RP 10.1.1.1, flags: S
  Incoming interface: outside
  RPF nbr: 10.38.111.240
  Immediate Outgoing interface list:
    inside, Forward, 00:06:22/00:02:50

(10.38.118.10, 239.1.1.77), 00:03:00/00:03:28, flags: ST
  Incoming interface: outside
  RPF nbr: 10.38.111.240
  Immediate Outgoing interface list:
    inside, Forward, 00:03:00/00:03:26

ciscoasa# show mfib 239.1.1.77  
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling 
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count

(*,239.1.1.77) Flags: C K
   Forwarding: 15/0/1271/0, Other: 0/0/0
   outside Flags: A
   inside Flags: F NS
     Pkts: 0/15
(10.38.118.10,239.1.1.77) Flags: K
   Forwarding: 7159/34/1349/360, Other: 0/0/0
   outside Flags: A
   inside Flags: F NS
     Pkts: 7159/5

ciscoasa# show conn all | i 239.1.1.77
UDP outside  10.38.118.10:58944 inside  239.1.1.77:5004, idle 0:00:00, bytes 10732896, flags - 
UDP outside  10.38.118.10:58945 inside  239.1.1.77:5005, idle 0:00:01, bytes 2752, flags - 
UDP outside  10.38.118.10:58944 NP Identity Ifc  239.1.1.77:5004, idle 0:00:00, bytes 0, flags - 
UDP outside  10.38.118.10:58945 NP Identity Ifc  239.1.1.77:5005, idle 0:00:01, bytes 0, flags - 

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

في حالة ما إذا كان هذا هو المضيف الوحيد المعروف بواسطة الموجه كعميل يريد إستقبال الدفق، يرسل الموجه رسالة قناة IGMP إلى RP.

تشغيل وضع IGMP الأولي

• في وضع كعب بروتوكول إدارة مجموعات الإنترنت (IGMP)، يعمل بروتوكول ASA كعميل للبث المتعدد، ويقوم بإنشاء تقارير IGMP (المعروفة أيضا باسم "الوصلات" لبروتوكول إدارة مجموعات الإنترنت (IGMP) أو إعادة توجيهها نحو الموجهات المجاورة، لتشغيل إستقبال حركة مرور البث المتعدد
• ترسل الموجهات بشكل دوري استعلامات إلى الأجهزة المضيفة لمعرفة ما إذا كانت أي عقدة على الشبكة تريد الاستمرار في إستقبال حركة مرور البث المتعدد.
• لا يوصى بوضع IGMP Stub-mode لأن وضع PIM النادر يوفر العديد من الفوائد عبر وضع Stub (مع تدفقات حركة مرور البث المتعدد الأكثر فعالية، والقدرة على المشاركة في PIM، وما إلى ذلك).

تكوين وضع IGMP Stub

1. تمكين التوجيه متعدد البث (وضع التكوين العام).

ASA(config)# multicast-routing

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

!
interface Ethernet0
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0
 no pim
!
interface Ethernet1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.255.255.0
 no pim
 igmp forward interface outside
!

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

ASA(config)# access-list 105 extended permit ip any host 224.1.2.3
ASA(config)# access-group 105 in interface outside

غالبا ما يكون هناك تشويش حول أوامر الوضع الفرعي لواجهة بروتوكول إدارة مجموعات الإنترنت (IGMP) المختلفة، ويصف هذا المخطط الوقت الذي يتم فيه إستخدام كل:

بيدير بيم

في PIM ثنائي الإتجاه، لا توجد شجرة مشتركة (SPT). وهذا يعني ثلاثة أمور:

1. لا يقوم موجه الخطوة الأولى (المتصل بالمرسل) بإرسال حزم سجل PIM إلى RP.

2. لا يرسل RP رسائل PIM Join للانضمام إلى شجرة المصدر.

3. تقوم الموجهات الموجودة في المسار إلى المستقبل بإرسال رسائل PIM Join باتجاه RP للانضمام إلى RPT.

وهذا يعني أن ASA لا يقوم بإنشاء (S،G) لأن الأجهزة لا تنضم إلى SPT. كل حركة مرور البث المتعدد تمر عبر RP. يرسل ال ASA كل multicast حركة مرور طالما هناك (*،G). إذا لم يكن هناك (*،G)، فهذا يعني أن ASA لم يتلق أبدا حزمة PIM Join. إذا كان هذا هو الحالة، فيجب أن لا يرسل ASA حزم البث المتعدد.

تكوين Bidir PIM

1. قم بتمكين التوجيه متعدد البث (وضع التكوين العام).

ASA(config)# multicast-routing

 2. تحديد عنوان نقطة التقاء PIM.

ASA(config)# pim rp-address 172.18.123.3 bidir

 3. اسمح بحزم البث المتعدد في الواجهة المناسبة (ضروري فقط إذا قام سياسة الأمان الخاصة ب ASA بحظر حزم البث المتعدد الواردة).

access-list 105 extended permit ip any host 224.1.2.3
access-group 105 in interface outside

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

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

من أجل فهم مشكلة إعادة توجيه للبث المتعدد وتشخيصها بشكل كامل على ASA، يلزم بعض هذه المعلومات أو كلها:

show mroute
show mfib
show pim neighbor
show route
show tech-support

capture cap1 interface outside match ip any host 239.1.1.77  >>> This captures the multicast traffic itself
capture cappim1 interface inside match pim any any           >>> This captures PIM Join/Prune messages
capture capigmp interface inside match igmp any any          >>> This captures IGMP Report/Query messages

إخراج أمر إظهار مفيد

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

ciscoasa# show mfib
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling 
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count
(*,224.1.2.3) Flags: S K
   Forwarding: 0/0/0/0, Other: 0/0/0
   inside Flags: F
     Pkts: 0/0
(192.168.1.100,224.1.2.3) Flags: K
   Forwarding: 6749/18/1300/182, Other: 690/0/690
   outside Flags: A
   inside Flags: F
     Pkts: 6619/8
(*,232.0.0.0/8) Flags: K
   Forwarding: 0/0/0/0, Other: 0/0/0
ciscoasa# 

يمكن إستخدام الأمر clear mfib counters لمسح العدادات، وهو أمر مفيد للغاية أثناء الاختبار:

ciscoasa# clear mfib counters

التقاط الحزم

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

ciscoasa# capture dmzcap interface dmz 
ciscoasa# capture dmzcap match ip any host 239.17.17.17
ciscoasa# show cap dmzcap

324 packets captured

   1: 17:13:30.976618       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:  udp 172 
   2: 17:13:30.976679       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:  udp 172 
   3: 17:13:30.996606       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:  udp 172 
   4: 17:13:30.996652       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:  udp 172 
   5: 17:13:31.016676       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:  udp 172 
   6: 17:13:31.016722       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:  udp 172 
....

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

ASA# show cap capout detail
453 packets captured
...
   1: 14:40:39.427147 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
      802.1Q vlan#1007 P0 10.4.2.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0)

كما أن التقاط الحزم مفيد لالتقاط حركة مرور PIM و IGMP. يوضح هذا الالتقاط أن الواجهة الداخلية تلقت حزمة IGMP (بروتوكول IP 2) مصدرها 10.0.0.2:

ciscoasa# capture capin interface inside
ciscoasa# capture capin match igmp any any
ciscoasa# show cap capin
1 packets captured
1: 10:47:53.540346 802.1Q vlan#15 P0 10.0.0.2 > 224.1.2.3:  ip-proto-2, length 8
ciscoasa#

لاحظ أنه يمكن رؤية TTL للحزم باستخدام الأمر 'show capture x detail'.

هنا يمكننا رؤية التقاط إسقاط ASP المتخذ الذي يظهر حزم البث المتعدد المسقطة وسبب عمليات الإسقاط (معدل الإنقطاع-الحد):

ASA#  show cap capasp det
 12: 14:37:26.538332 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
      802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded
  13: 14:37:26.538439 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
      802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded

نشر البث المتعدد في الوضع المتناثر ASA PIM

توضح هذه المخططات كيفية تفاعل ASA مع الأجهزة المجاورة في وضع PIM المتفرق.

فهم مخطط الشبكة

تحديد موقع المرسلين والمستلمين لتدفق البث المتعدد المحدد بدقة. أيضا، حدد عنوان IP لمجموعة البث المتعدد، بالإضافة إلى موقع نقطة الالتقاء.

 في هذه الحالة، يمكن تلقي البيانات على الواجهة الخارجية ل ASA، وإعادة توجيهها إلى مستقبل البث المتعدد على الواجهة الداخلية. نظرا لأن جهاز الاستقبال موجود في شبكة IP الفرعية نفسها الخاصة بالواجهة الداخلية ل ASA، فعليك توقع رؤية تقرير IGMP يتم إستقباله على الواجهة الداخلية عندما يطلب العميل تلقي الدفق. عنوان IP الخاص بالمرسل هو 192.168.1.50.

التحقق من تلقي ASA تقرير IGMP من المستقبل

في هذا المثال، يتم إنشاء تقرير IGMP بواسطة المستلم ويتم معالجته بواسطة ASA.

يمكن إستخدام التقاط الحزم ومخرجات تصحيح أخطاء بروتوكول العبارة الداخلية للتحقق من تلقي ASA، ومعالجة رسالة IGMP بنجاح.

التحقق من أن ASA يرسل رسالة PIM Join إلى نقطة الالتقاء

يفسر ASA تقرير IGMP ويولد رسالة انضمام PIM، ثم يرسلها خارج الواجهة نحو RP.

هذا الإخراج من مجموعة تصحيح الأخطاء PIM 224.1.2.3 ويظهر أن ASA يرسل رسالة انضمام PIM بنجاح. مرسل دفق البث المتعدد هو 192.168.1.50.

IPv4 PIM: (*,224.1.2.3) J/P processing
IPv4 PIM: (*,224.1.2.3) Periodic J/P scheduled in 50 secs
IPv4 PIM: (*,224.1.2.3) J/P adding Join on outside
IPv4 PIM: (*,224.1.2.3) inside Processing timers
IPv4 PIM: Sending J/P message for neighbor 10.2.3.2 on outside for 1 groups
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) MRIB update (a=0,f=0,t=1)
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) outside MRIB update (f=20,c=20)
IPv4 PIM: [0] (192.168.1.50,224.1.2.3) Signal present on outside
IPv4 PIM: (192.168.1.50,224.1.2.3) Create entry
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) outside MRIB modify NS
IPv4 PIM: Adding monitor for 192.168.1.50

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

يبدأ ال ASA بتلقي حركة مرور multicast على القارن خارجي (يبدي ذلك السهم أخضر)، ويعيد توجيهها إلى المتلقي على الداخل.

يمكن إستخدام أوامر show mroute وshow mfib، بالإضافة إلى التقاط الحزم، للتحقق من تلقي ASA لحزم البث المتعدد وإعادة توجيهها.

يتم إنشاء اتصال في جدول الاتصال لتمثيل تدفق البث المتعدد:

ciscoasa# show conn
59 in use, 29089 most used
...
UDP outside:192.168.1.50/52075 inside:224.1.2.3/1234 flags -
...

تحليل البيانات

مشاكل مشتركة

يوفر هذا القسم سلسلة من المشاكل ذات الصلة بالبث المتعدد ASA في العالم الحقيقي

فشل ASA في إرسال رسائل PIM نحو موجهات الخادم بسبب HSRP

عند مواجهة هذه المشكلة، يفشل ASA في إرسال أي رسائل PIM من واجهة. يوضح هذا المخطط أن ASA لا يمكنه إرسال رسائل PIM إلى المرسل، ولكن يمكن رؤية نفس المشكلة عندما يحتاج ASA إلى إرسال رسالة PIM إلى RP.

يوضح إخراج الأمر debug pim أن ASA لا يمكنه إرسال رسالة PIM إلى موجه الخطوة التالية للتدفق:

IPv4 PIM: Sending J/P to an invalid neighbor: outside 10.0.0.1

 لا تقتصر هذه المشكلة على ASA، وتؤثر أيضا على الموجهات. يتم تشغيل المشكلة من خلال الجمع بين تكوين جدول التوجيه وتكوين HSRP المستخدم من قبل جيران PIM.

يشير جدول التوجيه إلى HSRP IP 10.0.0.1 كجهاز الخطوة التالية:

ciscoasa# show run route
route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

 ومع ذلك، يتم تكوين علاقة جوار PIM بين عناوين IP للواجهة المادية للموجهات، وليس عنوان IP HSRP:

ciscoasa# show pim neighbor
Neighbor Address  Interface          Uptime    Expires DR pri Bidir
10.0.0.2          outside            01:18:27  00:01:25 1 
10.0.0.3          outside            01:18:03  00:01:29 1 (DR)

راجع "لماذا لا يعمل وضع PIM النادر مع مسار ثابت إلى عنوان HSRP؟" للحصول على مزيد من المعلومات.

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

لماذا لا يقوم الموجه بإرسال رسالة الانضمام/التقليم؟ يشير RFC 2362 إلى أن الموجه يرسل رسالة انضمام/تنقيح دورية إلى كل مجاور مميز لإعادة توجيه المسار العكسي (RPF) مرتبط بكل إدخال (S،G) و(*،G) و(*،*،RP). يتم إرسال رسائل الانضمام/النسخ فقط إذا كان جار إعادة توجيه المسار العكسي (RPF) جار PIM.

لتقليل المشكلة، أضف إدخال مسار ثابت على ASA لحركة المرور المعنية. تأكد من أنها تشير إلى أحد عنواني IP لواجهة الموجه (10.0.0.2 أو 10.0.0.3). في هذه الحالة، يسمح هذا الأمر ل ASA بإرسال رسائل PIM الموجهة إلى مرسل البث المتعدد على 172.16.1.2:

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3

 وبمجرد القيام بذلك، يتجاوز جدول توجيه البث المتعدد جدول توجيه البث الأحادي الخاص ب ASA، ويرسل ASA رسائل PIM مباشرة إلى جهاز 10.0.0.3 المجاور.

يتجاهل ASA تقارير IGMP لأنه ليس الموجه المعين على مقطع الشبكة المحلية (LAN)

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

بالنسبة لهذه المشكلة، يتجاهل ASA الحزمة لأنه ليس الموجه المعين الذي تم انتخابه ل PIM على مقطع الشبكة المحلية (LAN) حيث يتواجد العملاء.

يوضح إخراج واجهة سطر الأوامر (CLI) هذا ASA أن جهازا آخر هو الموجه المعين (المشار إليه بواسطة "DR") على شبكة الواجهة الداخلية:

ciscoasa#show pim neighbor

 Neighbor Address  Interface          Uptime    Expires DR pri Bidir
 192.168.1.2       outside      	   01:18:27  00:01:25 N/A> 
 10.0.0.2          inside              01:18:03  00:01:29 1 (DR)

بشكل افتراضي، يتم تمكين PIM على جميع واجهات ASA عند إضافة الأمر multicast-routing إلى التكوين. إذا كان هناك جيران آخرون ل PIM (موجهات أخرى أو ASA) على الواجهة الداخلية ل ASA (حيث يقيم العملاء) وتم إختيار أحد هؤلاء الجيران لأن DR لذلك الجزء، عندئذ تقوم موجهات أخرى غير DR بإسقاط تقارير IGMP. الحل هو تعطيل PIM على الواجهة (باستخدام الأمر no pim على الواجهة المعنية)، أو جعل ASA هو DR للمقطع عبر أمر الواجهة PIM dr-priority.

يتم رفض تقارير IGMP بواسطة جدار الحماية عند تجاوز حد واجهة IGMP

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

لتأكيد ما إذا كان هذا هو سبب فشل البث المتعدد، قم بإصدار الأمر show igmp interface interface interface' وابحث عن معلومات "حد IGMP" للواجهة.

ASA# show igmp interface inside
Hosting-DMZ is up, line protocol is up
  Internet address is 10.11.27.13/24
  IGMP is enabled on interface
  Current IGMP version is 2
  IGMP query interval is 125 seconds
  IGMP querier timeout is 255 seconds
  IGMP max query response time is 10 seconds
  Last member query response interval is 1 seconds
  Inbound IGMP access group is:
  IGMP limit is 500, currently active joins: 500
  Cumulative IGMP activity: 7018 joins, 6219 leaves
  IGMP querying router is 10.11.27.13 (this system)

DEBUG - IGMP: Group x.x.x.x limit denied on outside

يفشل ال ASA أن يرسل multicast حركة مرور في ال 232.x.x/8 مدى

نطاق العناوين هذا مخصص للاستخدام مع البث المتعدد محدد المصدر (SSM) الذي لا يدعمه ASA حاليا.

يعرض إخراج الأمر debug igmp هذا الخطأ:

IGMP: Exclude report on inside ignored for SSM group 232.179.89.253

يسقط ASA حزم البث المتعدد بسبب التحقق من إعادة توجيه المسار العكسي

في هذه الحالة، يستلم ال ASA حركة مرور multicast على قارن، غير أن هو لا يرسل على المتلقي. يتم إسقاط الحزم بواسطة ASA لأنها تفشل في التحقق من أمان إعادة توجيه المسار العكسي (RPF). يتم تمكين إعادة توجيه المسار العكسي (RPF) على جميع الواجهات لحركة مرور البث المتعدد ولا يمكن تعطيلها (بالنسبة لحزم البث الأحادي، لا يتم التحقق بشكل افتراضي، ويتم تمكينه باستخدام أمر ip verify reverse-path interface).

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

ciscoasa(config)# show asp drop

Frame drop:
  Invalid UDP Length                                          2
  No valid adjacency                                         36
  No route to host                                         4469
  Reverse-path verify failed                      121012

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside

لا يقوم ASA بإنشاء PIM Join على تبديل PIM إلى شجرة المصدر

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

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

 NO RPF Neighbor to send J/P

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

تسقط ASA حزم البث المتعدد بسبب تجاوز مدة البقاء (TTL)

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

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

يختبر ASA إستخدام وحدة المعالجة المركزية (CPU) العالي وإسقاط الحزم بسبب طبولوجيا البث المتعدد المحددة

يمكن أن يواجه ASA وحدة معالجة مركزية (CPU) عالية ويمكن أن يواجه تدفق البث المتعدد حالات إسقاط الحزم إذا كانت جميع هذه الحالات صحيحة حول مخطط البث المتعدد:

1. ويعمل ال‍ ASA بصفته ال‍ RP.
2. ال ASA هو أول خطوة إستقبال من ال multicast تيار. هذا يعني أن مرسل البث المتعدد موجود في شبكة IP الفرعية نفسها وواجهة ASA.
3. ASA هو موجه الخطوة الأخيرة من تدفق البث المتعدد. هذا يعني أن مستقبل البث المتعدد موجود في شبكة IP الفرعية نفسها الخاصة بواجهة ASA.

إذا ظهرت الأعراض المذكورة واجب عمل تصميم تحديد ال ASA يكون مجبر أن يعالج المفتاح ال multicast حركة مرور. وهذا يؤدي إلى تدفقات البث المتعدد ذات معدل نقل بيانات مرتفع لتجربة عمليات إسقاط الحزم. يكون عداد إسقاط show asp الذي يزيد عند إسقاط هذه الحزم هو punt-rate-limit.

أتمت in order to حددت إن ASA يتلقى هذا مشكلة، هذا steps:

الخطوة 1: تحقق مما إذا كان ASA هو RP:

show run pim
show pim tunnel

الخطوة 2: تحقق مما إذا كان ASA هو موجه الخطوة الأخيرة:

show igmp group <mcast_group_IP>

الخطوة 3: تحقق مما إذا كان ASA هو موجه الخطوة الأولى:

show mroute <mcast_group_IP>

يمكن إتخاذ الخطوات التالية للتخفيف من هذه المشكلة:

- تعديل المخطط بحيث لا يكون ASA هو RP. أو، جعل المرسل أو المستلم غير متصل مباشرة مع ASA

- بدلا من PIM، أستخدم وضع IGMP stub لإعادة توجيه البث المتعدد.

يقوم ASA بإسقاط الحزم القليلة الأولى عند بدء تدفق البث المتعدد أولا

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

يكون للحزم التي تم إسقاطها لهذا السبب سبب إسقاط ASP ل "(Punt-rate-limit) Punt-rate-limit) Limit". هذا هو مخرج 'show capture asp' (حيث يكون ASP التقاط إسقاط ASP تم تكوينه على ASA لالتقاط الحزم التي تم إسقاطها) ويمكنك رؤية حزم البث المتعدد التي تم إسقاطها لهذا السبب:

ASA # show capture asp
2 packets captured
   1: 16:14:49.419091 10.23.2.2.810 > 239.255.123.123.890:  udp 32 Drop-reason: (punt-rate-limit) Punt rate limit exceeded
   2: 16:14:49.919172 10.23.2.2.810 > 239.255.123.123.890:  udp 32 Drop-reason: (punt-rate-limit) Punt rate limit exceeded
2 packets shown

يقوم جهاز إستقبال متعدد البث غير المتصل بمقاطعة إستقبال مجموعة البث المتعدد على الواجهات الأخرى

فقط ASAs التي تعمل في وضع IGMP Stub تعاني من هذه المشكلة. لا تتأثر وحدات ASA التي تشارك في توجيه البث المتعدد ل PIM.

عينت الإصدار ب ال cisco بق id CSCeg48235 IGMP إجازة على واحد قارن يقاطع حركة مرور البث المتعدد على آخر قارن.

هذه هي ملاحظة الإصدار من الخطأ، والتي تشرح المشكلة:

Symptom:
When a PIX or ASA firewall is configured for IGMP stub mode multicast reception and traffic from a multicast group is forwarded to more than one interface, if a host behind a the interface sends an IGMP Leave message for the group, it could temporarily interrupt the reception for that group on other interfaces of the firewall.

The problem is triggered when the firewall forwards the IGMP leave for the group towards the upstream device; that device then sends a IGMP query to determine if any other receivers exist out that interface towards the firewall, but the firewall does not report that it still has valid receivers.

Conditions:
The PIX or ASA must be configured for IGMP stub mode multicast. IGMP stub mode is a legacy multicast forwarding technique, whereby IGMP packets from receivers are forwarded through the firewall towards the source of the stream. It is recommended to use PIM multicast routing instead of stub igmp forwarding.

Workarounds:
1) Use PIM multicast routing instead of IGMP stub mode.
2) Decrease multicast IGMP query timers so that the receivers are queried more frequently, so their IGMP reports are forwarded towards the sender more frequently, thus restarting the stream quicker.

تسقط ASA حزم البث المتعدد بسبب سياسة الأمان لقائمة الوصول الصادرة

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

عندما يحدث ذلك، يتم إسقاط حزم البث المتعدد باستخدام عداد إسقاط ASP "FP no mcast output intrf (no-mcast-intrf)".

يقوم ASA بإسقاط بعض الحزم (ولكن ليس كلها) بشكل مستمر في تدفق البث المتعدد بسبب تحديد معدل نقطة التحكم

من المحتمل أن تكون حركة المرور مقيدة بمعدل محدد بواسطة نقطة التحكم بسبب الحد الأقصى لسرعة البدل. راجع إخراج إسقاط ASP والتقطيرات لتأكيد:

ASA# show asp drop

Frame drop:
  Punt rate limit exceeded (punt-rate-limit)                             1492520

ASA#  show cap capasp det
 12: 14:37:26.538332 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
      802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000:  [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded

يظهر إدخال MFIB أن كل حركة مرور يتم تحويلها:

ASA(config)# show mfib  239.255.2.1195
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling 
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count

(*,239.255.2.195) Flags: C K
   Forwarding: 4278/50/1341/521, Other: 0/0/0
   Outside-1007 Flags: A
   RDEQ-to-Corporate Flags: F NS
     Pkts: 0/4278                               <---- HERE

يظهر جدول توجيه البث المتعدد (*،G) ولكن لا (S،G).

ASA(config)# show mroute  239.255.2.1195
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, 239.255.2.195), 00:44:03/00:02:44, RP 10.1.135.10, flags: S
  Incoming interface: Outside-1007
  RPF nbr: 10.100.254.18
  Immediate Outgoing interface list:
    RDEQ-to-Corporate, Forward, 00:44:03/00:02:44

المشكلة هنا أن ال TTL من الربط multicast معطيات ربط أن يصل إلى ال ASA هو 1. يقوم ASA بإعادة توجيه هذه الحزم إلى جهاز تدفق البيانات إلى الخادم (لأنه لا يقلل TTL)، ولكن يقوم الموجه إلى الخادم بإسقاط الحزم. ونتيجة لذلك، لا يقوم موجه تدفق البيانات من الخادم بإرسال انضمام إلى PIM (S،G) (انضمام محدد المصدر) إلى ASA تجاه المرسل. لا يقوم ASA بإنشاء إدخال (S،G) حتى يستلم انضمام PIM هذا. لأن (S،G) لم يتم بناؤه، فإن كل حركة مرور البث المتعدد يتم تحويلها مما ينتج عنه حد المعدل.

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

تم إيقاف تدفق البث المتعدد بسبب رسالة تأكيد PIM

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

يمكن ملاحظة مزيد من المعلومات حول هذه الرسالة في قسم من RFC 4601 متعلق بعملية التأكيد.

تظهر الأخطاء أن ASA يستلم تقرير IGMP للمجموعة 239.1.1.227، ولكنه يتجاهل التقرير بسبب تأكيد الرسالة التي يتلقاها من موجه مجاور:

IPv4 PIM: (*,239.1.1.227) Periodic J/P scheduled in 50 secs
IPv4 PIM: (*,239.1.1.227) J/P adding Join on outside
IPv4 PIM: (10.99.41.205,239.1.1.227)RPT J/P adding Prune on outside
IPv4 PIM: (10.99.41.253,239.1.1.227)RPT J/P adding Prune on outside
IGMP: Received v2 Report on inside from 10.20.213.204 for 239.1.1.227
IGMP: Updating EXCLUDE group timer for 239.1.1.227
IPv4 PIM: (10.99.41.253,239.1.1.227) Received [15/110] Assert from 10.20.13.2 on inside
IPv4 PIM: (10.99.41.253,239.1.1.227) Assert processing message wins
IPv4 PIM: (10.99.41.253,239.1.1.227) inside Update assert timer (winner 10.20.13.2)

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

يرسل ASA PIM Join ولكن لا تتم معالجته بواسطة المجاور بسبب حجم الحزمة الأكبر من MTU

ولوحظ ذلك في عام 629575899. تم تكوين ASA لإطارات Jumbo ولم يتم تكوين الطراز 4900. عندما طلب العميل أكثر من 73 عملية دفق للبث المتعدد، لن تعمل بعض عمليات دفق البث المتعدد. 73 SGs سينشئ رسالة PIM Join بحجم 1494، والتي لا تزال داخل MTU. 74SGs سينشئ رسالة PIM Join أكبر من 1500، مما تسبب في قيام 4900M بإسقاط الحزمة الواردة.

كان الإصلاح الخاص بهذه المشكلة:

1. تأكد من تمكين الإطارات كبيرة الحجم بشكل عام على الطراز 4900m

2. قم بتكوين كل من الواجهة المادية و SVI باستخدام وحدة الحد الأقصى للنقل (MTU) تبلغ 9216