فهم آلية تأكيد PIM

المقدمة

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

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بآلية تأكيد PIM.

المكونات المستخدمة 

تستند المعلومات الواردة في هذا المستند إلى Cisco CSR1000V، الإصدار 16.4.1

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

ما هي آلية تأكيد PIM؟

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

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

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

يستغل PIM رسائل تأكيد PIM التي يتم تشغيلها عند تلقي حزمة بث متعدد على قائمة الواجهة الصادرة (OIL). تحتوي رسائل التأكيد هذه على مقاييس يتم إستخدامها بعد ذلك لحساب من سيصبح الفائز المؤكد. كما تتلقى موجهات تدفق البيانات من الخادم على شبكة LAN رسائل تأكيد PIM. ثم يتم إستخدام هذه الرسائل من قبل أجهزة تدفق البيانات من الخادم لإرسال رسائل الانضمام/النسخ المناسبة إلى موجه تدفق البيانات من الخادم الذي فاز بعملية تأكيد الرسالة.

السيناريو 1. الأساس المنطقي ل LHR

شكل 1.

في الرسم التخطيطي للشبكة، R3 هو موجه الخطوة الأخيرة (LHR)، يتصل R3 بكل من R2 و R1 عبر مقطع مشترك.

عندما تستلم تقريرا عن بروتوكول إدارة مجموعة الإنترنت (IGMP) من المستقبل، يتحقق R3 من هو جار إعادة توجيه المسار العكسي (RPF) تجاه RP. في الطبولوجيا، R1 هو جارة إعادة توجيه المسار العكسي (RPF) نحو RP، ومن ثم يرسل R3 (*،G) توسطا نحو R1. بمجرد سحب R1 أسفل الدفق (افترض أن المجموعة نشطة) يرسل R3 وصلة (S،G) باتجاه المصدر ويسحب شجرة المصدر إلى أسفل. R2 هو جار إعادة توجيه المسار العكسي (RPF) نحو شجرة المصدر مما يعني أن R3 سيرسل (S،G) الانضمام إلى R2. يحتوي R3 على واجهة إعادة توجيه المسار العكسي (RPF) نفسها تجاه كل من RP والمصدر. هنا يمكنك رؤية جدول مسار R3 للمجموعة 239.1.1.1.

R3#show ip mroute
IP Multicast Routing Table
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.1), 00:00:55/stopped, RP 192.168.0.100, flags: SJC
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:00:55/00:02:04

(10.0.0.2, 239.1.1.1), 00:00:52/00:02:07, flags: JT
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.2, Mroute
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:00:52/00:02:07

(*, 224.0.1.40), 00:01:22/00:02:09, RP 192.168.0.100, flags: SJPCL
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1

كما ترى في R3، فإن جار إعادة توجيه المسار العكسي (R3) هو 192.168.3.1 وجاره (S،G) هو 192.168.3.2. الآن، هذا يجب أن ينتج R1 و R2 على حد سواء أن يكون هناك نفط صالح تجاه R3. دعونا نلقي نظرة على هذه المدخلات:

R1#show ip mroute
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.1), 00:15:02/00:02:33, RP 192.168.0.100, flags: S
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:15:02/00:02:33

(10.0.0.2, 239.1.1.1), 00:13:24/00:02:33, flags: PR
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list: Null

(*, 224.0.1.40), 00:29:17/00:02:51, RP 192.168.0.100, flags: SJCL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:16:06/00:02:51
  Outgoing interface list: Null

R2#show ip mroute
IP Multicast Routing Table
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.1), 00:08:00/stopped, RP 192.168.0.100, flags: SP
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list: Null

(10.0.0.2, 239.1.1.1), 00:00:03/00:02:56, flags: T
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:00:03/00:03:26

(*, 224.0.1.40), 01:37:30/00:02:22, RP 192.168.0.100, flags: SJPL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1

وكما ذكرنا، يمكن تشغيل التأكيد عندما يكون هناك موجهان للتحميل يحتويان على زيت صالح يتم ملؤه على مقطع مشترك. بما أن R1 و R2 كليهما لهما زيت صالح، تحقق مما إذا كانت هناك آلية تأكيد في التقاط الحزمة.

تم التقاط الحزمة هذه على واجهة R3 Gi1 باتجاه SW1.

في التقاط الحزمة هذا، لا ترى أي حزم تأكيد على الرغم من وجود جميع المتطلبات الأساسية لإنشاء التكرار على المقطع المشترك بين R1 و R2 و R3. لماذا لا ترى أي حزم تأكيد PIM عند تنشيط تدفق (S،G)؟

يبدو أن RFC 7761 قد يجيب على هذه الأسئلة.

ملخص من RFC 7761 القسم 4.2.2.

4.2.2.  Setting and Clearing the (S,G) SPTbit

   Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the
   appropriate (S,G) join state, and if the packet arrived on the
   correct upstream interface for S, and if one or more of the following
   conditions apply:

   1.  The source is directly connected, in which case the switch to the
       SPT is a no-op.

   2.  The RPF interface to S is different from the RPF interface to the
       RP.  The packet arrived on RPF_interface(S), and so the SPT must
       have been completed.

   3.  No one wants the packet on the RP tree.

   4.  RPF'(S,G) == RPF'(*,G).  In this case, the router will never be
       able to tell if the SPT has been completed, so it should just
       switch immediately.  The RPF'(S,G) != NULL check ensures that the
       SPTbit is set only if the RPF neighbor towards S is valid.
 
 In the case where the RPF interface is the same for the RP and for S,
 but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which
 indicates that the upstream router with (S,G) state believes the SPT
 has been completed. 

يتم إستخدام SPTbit (S،G) لتمييز ما إذا كان سيتم إعادة التوجيه على حالة (*،G) أو على (S،G). عند التبديل من شجرة RP إلى شجرة المصدر، هناك فترة انتقالية عندما تصل البيانات بسبب حالة تدفق (*،G) بينما يتم إنشاء حالة تدفق (S،G)، وفي ذلك الوقت، يجب أن يستمر الموجه في إعادة التوجيه فقط على حالة (*،G). وهذا يؤدي إلى منع الثقوب السوداء المؤقتة التي قد تحدث بسبب إرسال حالة خوخ (s،g،rpt) قبل انتهاء إنشاء حالة المنبع (S،G).

وعلى الرغم من أنه يبدو أن السيناريو يمكن أن يرتبط بالنقطة الأخيرة المذكورة أعلاه. في الحالة التي تكون فيها واجهة إعادة توجيه المسار العكسي (RPF) هي نفسها ل RP و S،
ولكن يختلف RPF'(s،G) و RPF'(*،G)، وننتظر تأكيد (S،G)، مما يشير إلى أن موجه المنبع بحالة (S،G) يعتقد أن SPT قد تم إتمامه. 

لكي يتم تشغيل التأكيد، يجب أن يتلقى الموجه حزمة مكررة على نفطه المأهول بالفعل لنفس مجموعة المصدر IP/الوجهة على المقطع. R3 هو أيضا LHR، مما يعني أنه تم تعيينه للتحويل من (*،G) إلى SPT (S،G) عند تلقي حزمة من (*،G).

في التقاط الحزمة نلاحظ أنه لا يتم إطلاق أي تأكيدات. وعلى الرغم من أننا نرى بالفعل عملية نسخ إحتياطي يتم إرسالها مباشرة بعد تلقي أول صدى لبروتوكول ICMP. 

كما يمكنك أن ترى، بمجرد إستلام أول حزمة طلب لبروتوكول رسائل التحكم بالإنترنت (ICMP) على واجهة R3 G1، يتم إرسال (*،G) شظية SR-bit باتجاه جار الخادم 192.168.3.1. يقوم هذا التجزيء (*،g) للمصدر المحدد.

أنت يستطيع رأيت هذا علم أيضا يثبت: (SR):

The S flag: indicates that the multicast group is a sparse mode group.
The R flag: The R flag is the RP-bit flag and indicates that the information in the (S, G) entry is applicable to the shared tree.  

في حزمة PIM الثانية رقم 14، يمكنك أن ترى أن R3 يحاول الانضمام إلى شجرة (S،G).

يلاحظ أنه بمجرد إستلام مستوى البيانات الأول، تقوم الحزمة R3 بتقليم (*،G) وإنشاء (S،G). هذا هو السبب وراء عدم رؤية حزم تأكيد PIM. يسري هذا السيناريو المعين عندما يكون لديك LHR لديه نفس واجهة إعادة توجيه المسار العكسي (S،G) و(*،G). وعلى الرغم من أن هذا السلوك قد يختلف قليلا عن RFC 7761، إلا أنه لا ينبغي أن يتسبب في أي مشاكل.

الآن لنتابع مع السيناريو 2. يمكن رؤية الرسم التخطيطي لهذا السيناريو هنا:

السيناريو 2. تأكيد تحديد المسار

شكل 2.

في هذا المخطط، هناك موجه آخر متصل على R3 وهو LHR. تتصل LHR مباشرة بالمستقبل. المصدر و RP كلاهما فوق R2 و R1. وجارة إعادة توجيه المسار العكسي (RPF) في R3 تجاه نقطة الوصول (RP) هي R1 وجارة إعادة توجيه المسار العكسي (RPF) نحو المصدر هي R2.

دعنا التحقق من جار إعادة توجيه المسار العكسي (RPF) لكل من المصدر و RP.

ترون هنا جارة إعادة توجيه المسار العكسي (RPF) نحو نقطة: 192.168.0.100 هي 192.168.3.1.

R3#show ip rpf 192.168.0.100
RPF information for ? (192.168.0.100)
  RPF interface: GigabitEthernet1
  RPF neighbor: ? (192.168.3.1)
  RPF route/mask: 192.168.0.100/32
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

ترون هنا جارة إعادة توجيه المسار العكسي (RPF) نحو المصدر: 10.0.0.2 هو 192.168.3.2.

R3#show ip rpf 10.0.0.2
RPF information for ? (10.0.0.2)
  RPF interface: GigabitEthernet1
  RPF neighbor: ? (192.168.3.2)
  RPF route/mask: 10.0.0.0/24
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

قبل تنشيط المصدر، دعونا نلقي نظرة على جدول المسار على R3، كما يمكنك أن ترى هناك بالفعل (*،G) للمجموعة 239.1.1.1. وذلك لأن المستلم المتصل ب LHR قد طلب مسبقا للمجموعة المحددة.

R3#show ip mroute
IP Multicast Routing Table
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.1), 00:00:57/00:02:32, RP 192.168.0.100, flags: S
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:00:57/00:02:32

(*, 224.0.1.40), 00:11:24/00:02:41, RP 192.168.0.100, flags: SJCL
  Incoming interface: GigabitEthernet1, RPF nbr 192.168.3.1
  Outgoing interface list:
    GigabitEthernet2, Forward/Sparse, 00:02:02/00:02:41

الآن، قم بتنشيط المصدر والتقاط الحزم على واجهة R3 gi1.

كما ترى في التقاط الحزمة هذا، يؤكد PIM على أن الحزم موجودة بالفعل.

الإطار 11:

الإطار 12:

عندما تنظر إلى هذه الحزم، يجب أن تكون قادرا على تحديد من هو الفائز المؤكد. الآن دعونا نلقي نظرة على تأكيد PIM للانتقاء مرة أخرى.

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

هناك أيضا سمات أخرى تستخدم لتحديد من هو الفائز المؤكد. يمكنك مشاهدة هذه التفاصيل في RFC 7761.

ملخص من RFC 7761 القسم 4.6.3.

4.6.3.  Assert Metrics

   Assert metrics are defined as:

     struct assert_metric {
       rpt_bit_flag;
       metric_preference;
       route_metric;
       ip_address;
     };
   When comparing assert_metrics, the rpt_bit_flag, metric_preference,
   and route_metric fields are compared in order, where the first lower
   value wins.  If all fields are equal, the primary IP address of the
   router that sourced the Assert message is used as a tie-breaker, with
   the highest IP address winning.

باستخدام هذه الحقول المحددة وتحديد المسار، يمكنك تحديد من سيكون الفائز المؤكدة في هذا السيناريو. إذا ألقيت نظرة على حزم التأكيد مرة أخرى، يمكنك أن ترى أن التفضيل المتري لا يتم مقارنته منذ إتخاذ القرار على معايير التحديد الأولى وهي RPT_BIT_FLAG.

في هذا السيناريو، تتم مقارنة مقارنة R1 و R2. يرسل كلا الموجهين رسائل تأكيد تم رؤيتها سابقا وبمجرد أن يرى كلا الجهازين رسائل تأكيد الآخر، فيمكنهما مقارنة المقاييس فيما بينهما لتحديد من هو الفائز.

وبما أن R2 يرسل رسالة تأكيد مع شجرة RP: خطأ بقيمة 0، فهو في الواقع أقل مما أرسله R1 مع شجرة RP: صحيح الذي له قيمة 1. تم تعيين بت شجرة RP على 0 أو 1.

يعني بت شجرة RP عند تعيينه على 1 أنك موجود حاليا على الشجرة المشتركة؛ يشير بت RPT الذي تم مسحه إلى أن مرسل تأكيد لديه حالة إعادة توجيه (S،G) على واجهة.

وكما تؤكد (S،G) أن لها الأولوية على (*،G)، ينبغي أن يكون R2 هو الفائز المؤكد. الانتقال إلى حالة "أنا أثبت الفائز". وكما ذكر في البيان السابق في RFC 7761، فإن القيمة الأقل هي الأكثر تفضيلا.

دعونا نلقي نظرة على كل من R1 و R2 لمعرفة من هو الفائز المؤكد.

R2#show ip mroute
IP Multicast Routing Table
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.1), 00:42:52/stopped, RP 192.168.0.100, flags: SP
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list: Null

(10.0.0.2, 239.1.1.1), 00:42:52/00:01:40, flags: T
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:42:52/00:03:07, A

(*, 224.0.1.40), 00:43:23/00:02:25, RP 192.168.0.100, flags: SJPL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.4.1
  Outgoing interface list: Null

في هذا المخرج، يمكنك أن ترى أن علامة (S،G) الموجودة على R2 وضعت على النفط مما يشير إلى أنه الفائز المؤكد. هنا في R1، ليس لديك نفط على (S،G) ورقم العلم P مضبوط مما يعني أن المحدد (S،G) قد تم تشذيبه في هذه الحالة، وهو ليس الفائز المؤكد.

ملاحظة: عندما يكون التأكيد موجودا على مقطع مشترك، يرسل الجيران من الخادم رسائل دورية "انضمام"(*،g) و"انضمام(s،g)" إلى الجار المناسب لإعادة توجيه المسار العكسي (RPF)، أي الجار الذي له صلة إعادة توجيه المسار العكسي (RPF) وفقا لما تم تعديله بواسطة عملية التأكيد. ولا ترسل دائما إلى البلد المجاور للجبهة الوطنية الرواندية على النحو الذي تشير إليه وزارة الخارجية.

R1#show ip mroute
IP Multicast Routing Table
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.1), 00:44:32/00:03:09, RP 192.168.0.100, flags: S
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:44:32/00:03:09, A

(10.0.0.2, 239.1.1.1), 00:44:19/00:03:09, flags: PR
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list: Null

(*, 224.0.1.40), 00:44:50/00:02:53, RP 192.168.0.100, flags: SJCL
  Incoming interface: GigabitEthernet2, RPF nbr 192.168.5.2
  Outgoing interface list:
    GigabitEthernet1, Forward/Sparse, 00:43:56/00:02:53

إذا كان هو الحال أن كل من R1 و R2 تم تعيين بت شجرة RP عليه 1. يمكنك بعد ذلك إعتبار الموجه بأدنى AD، إذا كان متساويا، فانظر إلى المقياس. إذا كانت وحدة بت شجرة RP صحيحة على كلا الموجهين، تتم مقارنة القياس بعنوان IP ل RP. إذا كانت وحدة بت شجرة RP هي 0، تتم مقارنة القياس باتجاه مصدر تدفق البث المتعدد.

إذا كانت جميع هذه القيم واحدة، فإن رسالة تأكيد مصدر عنوان IP الأعلى هي الفائز.

ملخص 

في السيناريو الأول، لم تلاحظ حزم التأكيد، ومع ذلك، لكل RFC يجب أن يتم تشغيلها. وكما ذكرنا، كان السبب في ذلك هو أن R3 كان يشذب (*،G) قبل إنشاء مستوى التحكم ل(S،G).

بينما في السيناريو الثاني، ترى تأكيد الحزم. عند تلقي الحزمة الأولى على LHR، فإنها سترسل (S،G) انضمام/تشذيب باتجاه R3 لسحب المصدر/المجموعة. سيقوم R3 بعد ذلك بإرسال حزمة ربط/تقسيم إلى R2 لنفس المصدر/المجموعة. سيؤدي ذلك إلى تعبئة كل من R1 و R2 للنفط بشكل صحيح. الآن R3 فقط يقضب (S،G) مع ضبط RP-bit عندما يتم ملء علامة T على حالة R3s (S،G). لكي يحدث ذلك، تحتاج إلى إستلام حزمة مستوى بيانات أخرى من المقطع المشترك. نظرا لأنه قد تم بالفعل إنشاء مستوى تحكم ل (S،G)، يؤدي ذلك إلى حدوث إزدواجية في المقطع المشترك الذي يقوم بتشغيل رسائل التأكيد.