إعادة التوجيه بين البنى لواجهة التحكم في الوصول (ACI) وإصلاحها - إعادة التوجيه متعدد المنافذ

المقدمة

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

معلومات أساسية

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

نظرة عامة على إعادة التوجيه متعدد الوجهات

سيغطي هذا الفصل كيفية أستكشاف السيناريوهات التي لا يعمل فيها الاتصال بشكل صحيح عبر أجهزة Pod في بيئة متعددة الأجهزة وإصلاحها

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

مكونات Multi-Pod

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

وضمن كل Pod فردي، تعمل قائمة التحكم في الوصول (ACI) على الاستفادة من البروتوكولات نفسها في التغشية مثل البنية التقليدية. ويتضمن ذلك بروتوكول نظام وسيط إلى نظام وسيط (IS-IS) لتبادل معلومات بروتوكول الشجرة المتفرعة (TEP) بالإضافة إلى تحديد الواجهة الصادرة للبث المتعدد (OIF) وبروتوكول COOP لمستودع نقطة نهاية عمومي و BGP VPNv4 لتوزيع الموجهات الخارجية من خلال البنية.

يتم إنشاء أجهزة متعددة Pod على هذه المكونات حيث يجب عليها ربط كل Pod معا.

• لتبادل معلومات التوجيه المتعلقة ب TEPs في Pod البعيد، يتم إستخدام OSPF للإعلان عن تجمع TEP للملخص من خلال IP.
• لتبادل المسارات الخارجية التي تم التعرف عليها من Pod إلى آخر، يتم توسيع عائلة عنوان VPNv4 لبروتوكول BGP بين عقد العمود الفقري. يصبح كل Pod مجموعة منفصلة لعكس المسار.
• لمزامنة نقاط النهاية وكذلك المعلومات الأخرى المخزنة في COOP عبر نقاط الوصول، يتم تمديد عائلة عنوان BGP EVPN بين عقد العمود الرئيسي.
• أخيرا، من أجل معالجة فيضان حركة مرور البث والبث الأحادي غير المعروف والبث المتعدد (BUM) عبر نقاط الوصول، تعمل عقد العمود الفقري في كل Pod كمضيفات IGMP وتتبادل موجهات IPN معلومات توجيه البث المتعدد من خلال PIM ثنائي الإتجاه.

يشبه جزء كبير من سيناريوهات أستكشاف المشكلات وحلها باستخدام أجهزة Multi-Pod وتدفقات العمل بنى ACI أحادية باستخدام Pod. سيركز هذا القسم الذي يحتوي على العديد من الوصلات على الاختلافات بين إعادة توجيه كل من Pod الفردي و Multi-Pod.

طبولوجيا الأمثلة متعددة البروتوكولات

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

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

على مستوى عال، عند تصحيح مشكلة إعادة توجيه متعدد الوجهات، يمكن تقييم الخطوات التالية:

1. هل التدفق Unicast أو متعدد الوجهة؟ تذكر، حتى إذا كان من المتوقع أن يكون التدفق unicast في حالة العمل، إذا لم يتم حل ARP فهو تدفق متعدد الوجهة.
2. هل تم توجيه التدفق أو توصيله؟ بشكل تقليدي، سيكون التدفق الموجه من منظور قائمة التحكم في الوصول (ACI) أي تدفق حيث يكون عنوان MAC للوجهة عنوان MAC للموجه الذي يكون مملوكا بواسطة بوابة تم تكوينها على واجهة التحكم في الوصول (ACI). وبالإضافة إلى ذلك، إذا تم تعطيل تفيض ARP، فسيتم توجيه ورقة الدخول استنادا إلى عنوان IP الهدف. إذا لم يكن عنوان MAC للوجهة مملوك من قبل ACI، فسيقوم المحول إما بإعادة التوجيه بناء على عنوان MAC أو اتبع السلوك "مجهول unicast" الذي تم تكوينه على مجال الجسر.
3. هل ورقة الدخول تسقط التدفق؟ إن FTriage و ELAM هما أفضل الأدوات لتأكيد ذلك.

إذا كان التدفق هو البث الأحادي للطبقة 3:

1. هل تحتوي ورقة المدخل على نقطة نهاية تتعرف على IP للوجهة في نفس VRF الخاص بالمصدر EPG؟ إذا كان الأمر كذلك، سيكون لهذا دائما الأولوية على أي مسارات متعلمة. سيتم إعادة توجيه الورقة مباشرة إلى عنوان النفق أو واجهة الخروج حيث يتم التعرف على نقطة النهاية.
2. إذا لم يتم التعرف على نقطة نهاية، هل تحتوي ورقة المدخل على مسار للوجهة التي تم تعيين العلامة "المنتشرة" عليها؟ وهذا يشير إلى تكوين الشبكة الفرعية للوجهة كشبكة فرعية لمجال الجسر وأنه يجب أن تكون الخطوة التالية هي وكيل العمود الرئيسي في Pod المحلي.
3. إذا لم يكن هناك طريق منتشر، فإن الملاذ الأخير سيكون أي طرق يتم تعلمها من خلال L3Out. هذا الجزء مطابق لإعادة توجيه خرج L3Pod أحادي.

إذا كان التدفق هو البث الأحادي للطبقة 2:

1. هل تحتوي ورقة المدخل على نقطة نهاية تتعرف على عنوان MAC للوجهة في نفس مجال الجسر مثل EPG المصدر؟ إذا كان الأمر كذلك، فستقوم الورقة بإعادة التوجيه إلى IP للنفق البعيد أو خارج الواجهة المحلية حيث يتم تعلم نقطة النهاية.
2. إذا لم يتم التعرف على عنوان MAC للوجهة في مجال الجسر المصدر، عندئذ ستقوم الورقة بإعادة التوجيه بناءا على سلوك "مجهول-unicast" الذي تم تعيين BD عليه. إذا تم تعيينها إلى "تدفق"، فسيتم تدفق الورقة إلى مجموعة البث المتعدد ل GIPo المخصصة لمجال Bridge. يجب أن تحصل أجهزة الكمبيوتر المحمولة المحلية والبعيدة على نسخة ملحقة. إذا تم ضبطه على "وكيل الأجهزة"، فسيتم إرسال الإطار إلى العمود الرئيسي للبحث عن وكيل وإعادة توجيهه استنادا إلى إدخال COOP الخاص بالعمود الرئيسي.

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

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

بعد الطوبولوجيا، امشي في التدفق من 10.0.2.100 على ورقة 205 إلى 10.0.1.100 على ورقة 101.

ملاحظة، قبل المتابعة هنا، من المهم تأكيد ما إذا كان المصدر قد تم حل ARP للعبارة (للتدفق الموجه) أو عنوان MAC للوجهة (للتدفق عبر الجسر)

1. تأكد من أن المدخل ورقة يستلم الربط. أستخدم أداة واجهة سطر الأوامر (CLI) ل ELAM الموضحة في قسم "الأدوات" بالإضافة إلى مخرجات التقرير المتوفرة في 4.2. يستخدم تطبيق مساعد ELAM أيضا.

module-1# debug platform internal tah elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 6 out-select 1
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 10.0.2.100 dst_ip 10.0.1.100
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# status
ELAM STATUS
===========
Asic 0 Slice 0 Status Armed
Asic 0 Slice 1 Status Triggered

لاحظ أن ELAM التي تم تشغيلها تؤكد أن الحزمة تم تلقيها على مفتاح الدخول. الآن أنظر إلى حقلين في التقرير بما أن المخرجات شاملة.

===========================================================================================================
                                                           Captured Packet

===========================================================================================================

-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes
-----------------------------------------------------------------------------------------------------------
Outer Packet Attributes       : l2uc ipv4 ip ipuc ipv4uc
Opcode                        : OPCODE_UC

-----------------------------------------------------------------------------------------------------------
Outer L2 Header
-----------------------------------------------------------------------------------------------------------
Destination MAC               : 0022.BDF8.19FF
Source MAC                    : 0000.2222.2222
802.1Q tag is valid           : yes( 0x1 )
CoS                           : 0( 0x0 )
Access Encap VLAN             : 1021( 0x3FD )

------------------------------------------------------------------------------------------------------------
Outer L3 Header
------------------------------------------------------------------------------------------------------------
L3 Type                       : IPv4
IP Version                    : 4
DSCP                          : 0
IP Packet Length              : 84 ( = IP header(28 bytes) + IP payload )
Don't Fragment Bit            : not set
TTL                           : 255
IP Protocol Number            : ICMP
IP CheckSum                   : 10988( 0x2AEC )
Destination IP                : 10.0.1.100
Source IP                     : 10.0.2.100

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

2. هل المدخل صفحة يعلم الغاية كنقطة نهاية في المدخل VRF؟ إن لم يكن الأمر كذلك، فهل هناك طريق؟

a-leaf205# show endpoint ip 10.0.1.100 detail
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+-----------------------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface     Endpoint Group
     Domain                          VLAN            IP Address        IP Info                       Info
+-----------------------------------+---------------+-----------------+--------------+-------------+-----------------------------+

ما من إخراج في الأمر أعلاه يعني أنه لم يتم تعلم عنوان IP للوجهة. تحقق بعد ذلك من جدول التوجيه.

a-leaf205# show ip route 10.0.1.100 vrf Prod:Vrf1
IP Route Table for VRF "Prod:Vrf1"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.0.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
   *via 10.0.120.34%overlay-1, [1/0], 01:55:37, static, tag 4294967294
        recursive next hop: 10.0.120.34/32%overlay-1

في الإخراج المذكور أعلاه، يتم رؤية العلامة المنتشرة التي تشير إلى أن هذا هو مسار الشبكة الفرعية لمجال Bridge. يجب أن تكون الخطوة التالية عنوان وكيل AnyCast على العمود الفقري.

a-leaf205# show isis dtep vrf overlay-1 | grep 10.0.120.34
10.0.120.34        SPINE   N/A             PHYSICAL,PROXY-ACAST-V4

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

أستخدم مساعد ELAM لتأكيد قرارات إعادة التوجيه التي تمت رؤيتها في المخرجات المذكورة أعلاه.

تكوين مساعد ELAM

التحقق من قرارات إعادة التوجيه

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

3. تأكد على العمود الرئيسي من أن IP الوجهة موجود في COOP حتى يعمل طلب الوكيل.

هناك عدة طرق للحصول على مخرجات COOP على العامود الرئيسي، على سبيل المثال، نظرت إليها باستخدام أمر "show coop internal info ip-db":

a-spine4# show coop internal info ip-db | grep -B 2 -A 15 "10.0.1.100"

------------------------------
IP address : 10.0.1.100
Vrf : 2392068                          <-- This vnid should correspond to vrf where the IP is learned. Check operational tab of the tenant vrfs
Flags : 0x2
EP bd vnid : 15728642
EP mac :  00:00:11:11:11:11
Publisher Id : 192.168.1.254
Record timestamp : 12 31 1969 19:00:00 0
Publish timestamp : 12 31 1969 19:00:00 0
Seq No: 0
Remote publish timestamp: 09 30 2019 20:29:07 9900483
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.0.34       <-- When learned from a remote pod this will be an External Proxy TEP. We'll cover this more
       Tunnel ref count : 1

------------------------------

أوامر أخرى لتشغيلها على العامود الرئيسي:

استعلام COOP لإدخال L2:

moquery -c coopEpRec -f 'coop.EpRec.mac=="00:00:11:11:22:22"

استعلام COOP لإدخال L3 والحصول على إدخال L2 أصلي:

moquery -c coopEpRec -x rsp-subtree=children 'rsp-subtree-filter=eq(coopIpv4Rec.addr,"192.168.1.1")' rsp-subtree-include=required

استعلام COOP لإدخال L3 فقط:

moquery -c coopIpv4Rec -f 'coop.Ipv4Rec.addr=="192.168.1.1"'

الشيء المفيد حول الاستعلام المتعدد هو أنه يمكن أيضا تشغيله مباشرة على APIC ويمكن للمستخدم أن يرى كل عامود أساسي له السجل في كوب.

4. قرار إعادة توجيه وكيل العمود الفقري متعدد الأرجل

إذا كان إدخال COOP الخاص بالعمود الرئيسي يشير إلى نفق في Pod المحلي، فإن إعادة التوجيه تستند إلى سلوك ACI التقليدي.

لاحظ أنه يمكن التحقق من مالك TEP في البنية عن طريق التشغيل من APIC: moquery -c ipv4addr -f 'ipV4.addr.addr="<tunnel address>"

في سيناريو الوكيل، النفق التالي هو 10.0.0.34. من هو مالك عنوان IP هذا؟:

a-apic1# moquery -c ipv4Addr -f 'ipv4.Addr.addr=="10.0.0.34"' | grep dn
dn               : topology/pod-1/node-1002/sys/ipv4/inst/dom-overlay-1/if-[lo9]/addr-[10.0.0.34/32]
dn               : topology/pod-1/node-1001/sys/ipv4/inst/dom-overlay-1/if-[lo2]/addr-[10.0.0.34/32]

هذا IP مملوك لكل من عقدتي العمود الفقري في Pod 1. هذا عنوان IP محدد يسمى عنوان وكيل خارجي. بنفس الطريقة التي تحتوي فيها واجهة التحكم في الوصول (ACI) على عناوين وكيل مملوكة لعقد العمود الرئيسي داخل Pod (راجع الخطوة 2 من هذا القسم)، هناك أيضا عناوين وكيل تم تعيينها إلى Pod نفسه. يمكن التحقق من نوع الواجهة هذا من خلال التشغيل:

a-apic1# moquery -c ipv4If -x rsp-subtree=children 'rsp-subtree-filter=eq(ipv4Addr.addr,"10.0.0.34")' rsp-subtree-include=required
   
...
# ipv4.If
mode         : anycast-v4,external

# ipv4.Addr
 addr             : 10.0.0.34/32
 dn               : topology/pod-1/node-1002/sys/ipv4/inst/dom-overlay-1/if-[lo9]/addr-[10.0.0.34/32]

تشير العلامة "الخارجية" إلى أن هذه عبارة عن TEP للوكيل الخارجي.

5. التحقق من BGP EVPN على العمود الفقري

يجب إستيراد سجل نقطة نهاية البروتوكول من BGP EVPN على العمود الرئيسي. يمكن إستخدام الأمر التالي للتحقق من أنه موجود في EVPN (على الرغم من أنه إذا كان بالفعل في COOP مع الخطوة التالية من TEP الوكيل الخارجي ل Pod البعيد، يمكن افتراض أنه جاء من EVPN):

a-spine4# show bgp l2vpn evpn 10.0.1.100 vrf overlay-1
Route Distinguisher: 1:16777199
BGP routing table entry for [2]:[0]:[15728642]:[48]:[0000.1111.1111]:[32]:[10.0.1.100]/272, version 689242 dest ptr 0xaf42a4ca
Paths: (2 available, best #2)
Flags: (0x000202 00000000) on xmit-list, is not in rib/evpn, is not in HW, is locked
Multipath: eBGP iBGP

 Path type: internal 0x40000018 0x2040 ref 0 adv path ref 0, path is valid, not best reason: Router Id, remote nh not installed
 AS-Path: NONE, path sourced internal to AS
   192.168.1.254 (metric 7) from 192.168.1.102 (192.168.1.102)
     Origin IGP, MED not set, localpref 100, weight 0
     Received label 15728642 2392068
     Received path-id 1
     Extcommunity:
         RT:5:16
         SOO:1:1
         ENCAP:8
         Router MAC:0200.0000.0000            
         
           Advertised path-id 1
 Path type: internal 0x40000018 0x2040 ref 1 adv path ref 1, path is valid, is best path, remote nh not installed
 AS-Path: NONE, path sourced internal to AS
   192.168.1.254 (metric 7) from 192.168.1.101 (192.168.1.101)
     Origin IGP, MED not set, localpref 100, weight 0
     Received label 15728642 2392068
     Received path-id 1
     Extcommunity:
         RT:5:16
         SOO:1:1
         ENCAP:8
         Router MAC:0200.0000.0000            
         
           Path-id 1 not advertised to any peer

لاحظ أن الأمر أعلاه يمكن أن يتم تشغيله لعنوان MAC أيضا.

-192.168.1.254 هو TEP لمستوى البيانات الذي يتم تكوينه أثناء إعداد Multi-Pod. لاحظ مع ذلك أنه على الرغم من الإعلان عنها في BGP على أنها NH، إلا أن الخطوة التالية الفعلية ستكون TEP للوكيل الخارجي.

-192.168.1.101 و.102 هي عقد Pod 1 الرئيسية التي تعلن هذا المسار.

6. التحقق من COOP على العمود الفقري في Pod الوجهة.

يمكن إستخدام الأمر نفسه السابق:

a-spine2# show coop internal info ip-db | grep -B 2 -A 15 "10.0.1.100"

------------------------------
IP address : 10.0.1.100
Vrf : 2392068
Flags : 0
EP bd vnid : 15728642
EP mac :  00:50:56:81:3E:E6
Publisher Id : 10.0.72.67
Record timestamp : 10 01 2019 15:46:24 502206158
Publish timestamp : 10 01 2019 15:46:24 524378376
Seq No: 0
Remote publish timestamp: 12 31 1969 19:00:00 0
URIB Tunnel Info
Num tunnels : 1
       Tunnel address : 10.0.72.67
       Tunnel ref count : 1

------------------------------

دققت من يملك النفق عنوان ب يركض الأمر التالي على APIC:

a-apic1# moquery -c ipv4Addr -f 'ipv4.Addr.addr=="10.0.72.67"'
Total Objects shown: 1

# ipv4.Addr
addr             : 10.0.72.67/32
childAction      :
ctrl             :
dn               : topology/pod-1/node-101/sys/ipv4/inst/dom-overlay-1/if-[lo0]/addr-[10.0.72.67/32]
ipv4CfgFailedBmp :
ipv4CfgFailedTs  : 00:00:00:00.000
ipv4CfgState     : 0
lcOwn            : local
modTs            : 2019-09-30T18:42:43.262-04:00
monPolDn         : uni/fabric/monfab-default
operSt           : up
operStQual       : up
pref             : 0
rn               : addr-[10.0.72.67/32]
status           :
tag              : 0
type             : primary
vpcPeer          : 0.0.0.0

يظهر الامر المذكور اعلاه ان النفق من نقاط كوب إلى ليف 101. هذا يعني أن Leaf101 ينبغي أن يتلقى التعلم المحلي لنقطة النهاية الوجهة.

7. تأكد من أن ورقة الخروج لها التعلم المحلي.

يمكن القيام بذلك من خلال الأمر 'show endpoint':

a-leaf101# show endpoint ip 10.0.1.100 detail
Legend:
s - arp              H - vtep             V - vpc-attached     p - peer-aged
R - peer-attached-rl B - bounce           S - static           M - span
D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr
L - local            E - shared-service
+-----------------------------------+---------------+-----------------+--------------+-------------+-----------------------------+
     VLAN/                           Encap           MAC Address       MAC Info/       Interface     Endpoint Group
     Domain                          VLAN            IP Address        IP Info                       Info
+-----------------------------------+---------------+-----------------+--------------+-------------+-----------------------------+
341                                       vlan-1075    0000.1111.1111 LV                        po5                  Prod:ap1:epg1
Prod:Vrf1                                 vlan-1075        10.0.1.100 LV                        po5

لاحظ أنه يتم التعرف على نقطة النهاية. يجب إعادة توجيه الحزمة استنادا إلى خارج القناة 5 مع مجموعة علامة VLAN 1075.

إستخدام fTriage للتحقق من التدفق من نهاية إلى نهاية

كما تمت مناقشته في قسم "الأدوات" في هذا الفصل، يمكن إستخدام fTriage لتعيين تدفق موجود من نهاية إلى نهاية وفهم ما يقوم به كل محول في المسار مع الحزمة. ويعد هذا مفيدا بشكل خاص في عمليات النشر الأكبر والأكثر تعقيدا مثل Multi-Pod.

لاحظ أن الفرز سيستغرق بعض الوقت للتشغيل الكامل (ربما 15 دقيقة).

عند تشغيل fTriage على المثال flow:

a-apic1# ftriage route -ii LEAF:205 -dip 10.0.1.100 -sip 10.0.2.100
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "InProgress", "pid": "7297", "apicId": "1", "id": "0"}}}
Starting ftriage
Log file name for the current run is: ftlog_2019-10-01-16-04-15-438.txt
2019-10-01 16:04:15,442 INFO     /controller/bin/ftriage route -ii LEAF:205 -dip 10.0.1.100 -sip 10.0.2.100
2019-10-01 16:04:38,883 INFO     ftriage:     main:1165 Invoking ftriage with default password and default username: apic#fallback\\admin
2019-10-01 16:04:54,678 INFO     ftriage:     main:839  L3 packet Seen on a-leaf205 Ingress: Eth1/31  Egress: Eth1/53 Vnid: 2392068
2019-10-01 16:04:54,896 INFO     ftriage:     main:242  ingress encap string vlan-1021
2019-10-01 16:04:54,899 INFO     ftriage:     main:271  Building ingress BD(s), Ctx
2019-10-01 16:04:56,778 INFO     ftriage:     main:294  Ingress BD(s) Prod:Bd2
2019-10-01 16:04:56,778 INFO     ftriage:     main:301  Ingress Ctx: Prod:Vrf1
2019-10-01 16:04:56,887 INFO     ftriage:   pktrec:490  a-leaf205: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:05:22,458 INFO     ftriage:     main:933  SIP 10.0.2.100 DIP 10.0.1.100
2019-10-01 16:05:22,459 INFO     ftriage:  unicast:973  a-leaf205: <- is ingress node
2019-10-01 16:05:25,206 INFO     ftriage:  unicast:1215 a-leaf205: Dst EP is remote
2019-10-01 16:05:26,758 INFO     ftriage:     misc:657  a-leaf205: DMAC(00:22:BD:F8:19:FF) same as RMAC(00:22:BD:F8:19:FF)
2019-10-01 16:05:26,758 INFO     ftriage:     misc:659  a-leaf205: L3 packet getting routed/bounced in SUG
2019-10-01 16:05:27,030 INFO     ftriage:     misc:657  a-leaf205: Dst IP is present in SUG L3 tbl
2019-10-01 16:05:27,473 INFO     ftriage:     misc:657  a-leaf205: RwDMAC DIPo(10.0.72.67) is one of dst TEPs ['10.0.72.67']
2019-10-01 16:06:25,200 INFO     ftriage:     main:622  Found peer-node a-spine3 and IF: Eth1/31 in candidate list
2019-10-01 16:06:30,802 INFO     ftriage:     node:643  a-spine3: Extracted Internal-port GPD Info for lc: 1
2019-10-01 16:06:30,803 INFO     ftriage:     fcls:4414 a-spine3: LC trigger ELAM with IFS: Eth1/31 Asic :3 Slice: 1 Srcid: 24
2019-10-01 16:07:05,717 INFO     ftriage:     main:839  L3 packet Seen on a-spine3 Ingress: Eth1/31 Egress: LC-1/3 FC-24/0 Port-1 Vnid: 2392068
2019-10-01 16:07:05,718 INFO     ftriage:   pktrec:490  a-spine3: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:07:28,043 INFO     ftriage:      fib:332  a-spine3: Transit in spine
2019-10-01 16:07:35,902 INFO     ftriage:  unicast:1252 a-spine3: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.72.67
2019-10-01 16:07:36,018 INFO     ftriage:  unicast:1417 a-spine3: EP is known in COOP (DIPo = 10.0.72.67)
2019-10-01 16:07:40,422 INFO     ftriage:  unicast:1458 a-spine3: Infra route 10.0.72.67 present in RIB
2019-10-01 16:07:40,423 INFO     ftriage:     node:1331 a-spine3: Mapped LC interface: LC-1/3 FC-24/0 Port-1 to FC interface: FC-24/0 LC-1/3 Port-1
2019-10-01 16:07:46,059 INFO     ftriage:     node:460  a-spine3: Extracted GPD Info for fc: 24
2019-10-01 16:07:46,060 INFO     ftriage:     fcls:5748 a-spine3: FC trigger ELAM with IFS: FC-24/0 LC-1/3 Port-1 Asic :0 Slice: 1 Srcid: 40
2019-10-01 16:08:06,735 INFO     ftriage:  unicast:1774 L3 packet Seen on FC of node: a-spine3  with Ingress: FC-24/0 LC-1/3 Port-1  Egress: FC-24/0 LC-1/3 Port-1 Vnid: 2392068
2019-10-01 16:08:06,735 INFO     ftriage:   pktrec:487  a-spine3: Collecting transient losses snapshot for FC module: 24
2019-10-01 16:08:09,123 INFO     ftriage:     node:1339 a-spine3: Mapped FC interface: FC-24/0 LC-1/3 Port-1 to LC interface: LC-1/3 FC-24/0 Port-1
2019-10-01 16:08:09,124 INFO     ftriage:  unicast:1474 a-spine3: Capturing Spine  Transit pkt-type L3 packet on egress LC on Node: a-spine3 IFS: LC-1/3 FC-24/0 Port-1
2019-10-01 16:08:09,594 INFO     ftriage:     fcls:4414 a-spine3: LC trigger ELAM with IFS: LC-1/3 FC-24/0 Port-1 Asic :3 Slice: 1 Srcid: 48
2019-10-01 16:08:44,447 INFO     ftriage:  unicast:1510 a-spine3: L3 packet Spine egress  Transit pkt Seen on a-spine3 Ingress: LC-1/3 FC-24/0 Port-1 Egress: Eth1/29 Vnid: 2392068
2019-10-01 16:08:44,448 INFO     ftriage:   pktrec:490  a-spine3: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:08:46,691 INFO     ftriage:  unicast:1681 a-spine3: Packet is exiting the fabric through {a-spine3: ['Eth1/29']} Dipo 10.0.72.67 and filter SIP 10.0.2.100 DIP 10.0.1.100
2019-10-01 16:10:19,947 INFO     ftriage:     main:716  Capturing L3 packet Fex: False on node: a-spine1 IF: Eth2/25
2019-10-01 16:10:25,752 INFO     ftriage:     node:643  a-spine1: Extracted Internal-port GPD Info for lc: 2
2019-10-01 16:10:25,754 INFO     ftriage:     fcls:4414 a-spine1: LC trigger ELAM with IFS: Eth2/25 Asic :3 Slice: 0 Srcid: 24
2019-10-01 16:10:51,164 INFO     ftriage:     main:716  Capturing L3 packet Fex: False on node: a-spine2 IF: Eth1/31
2019-10-01 16:11:09,690 INFO     ftriage:     main:839  L3 packet Seen on a-spine2 Ingress: Eth1/31 Egress: Eth1/25 Vnid: 2392068
2019-10-01 16:11:09,690 INFO     ftriage:   pktrec:490  a-spine2: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:11:24,882 INFO     ftriage:      fib:332  a-spine2: Transit in spine
2019-10-01 16:11:32,598 INFO     ftriage:  unicast:1252 a-spine2: Enter dbg_sub_nexthop with Transit inst: ig infra: False glbs.dipo: 10.0.72.67
2019-10-01 16:11:32,714 INFO     ftriage:  unicast:1417 a-spine2: EP is known in COOP (DIPo = 10.0.72.67)
2019-10-01 16:11:36,901 INFO     ftriage:  unicast:1458 a-spine2: Infra route 10.0.72.67 present in RIB
2019-10-01 16:11:47,106 INFO     ftriage:     main:622  Found peer-node a-leaf101 and IF: Eth1/54 in candidate list
2019-10-01 16:12:09,836 INFO     ftriage:     main:839  L3 packet Seen on a-leaf101 Ingress: Eth1/54 Egress: Eth1/30 (Po5) Vnid: 11470
2019-10-01 16:12:09,952 INFO     ftriage:   pktrec:490  a-leaf101: Collecting transient losses snapshot for LC module: 1
2019-10-01 16:12:30,991 INFO     ftriage:     nxos:1404 a-leaf101: nxos matching rule id:4659 scope:84 filter:65534
2019-10-01 16:12:32,327 INFO     ftriage:     main:522  Computed egress encap string vlan-1075
2019-10-01 16:12:32,333 INFO     ftriage:     main:313  Building egress BD(s), Ctx
2019-10-01 16:12:34,559 INFO     ftriage:     main:331  Egress Ctx Prod:Vrf1
2019-10-01 16:12:34,560 INFO     ftriage:     main:332  Egress BD(s): Prod:Bd1
2019-10-01 16:12:37,704 INFO     ftriage:  unicast:1252 a-leaf101: Enter dbg_sub_nexthop with Local inst: eg infra: False glbs.dipo: 10.0.72.67
2019-10-01 16:12:37,705 INFO     ftriage:  unicast:1257 a-leaf101: dbg_sub_nexthop invokes dbg_sub_eg for ptep
2019-10-01 16:12:37,705 INFO     ftriage:  unicast:1784 a-leaf101: <- is egress node
2019-10-01 16:12:37,911 INFO     ftriage:  unicast:1833 a-leaf101: Dst EP is local
2019-10-01 16:12:37,912 INFO     ftriage:     misc:657  a-leaf101: EP if(Po5) same as egr if(Po5)
2019-10-01 16:12:38,172 INFO     ftriage:     misc:657  a-leaf101: Dst IP is present in SUG L3 tbl
2019-10-01 16:12:38,564 INFO     ftriage:     misc:657  a-leaf101: RW seg_id:11470 in SUG same as EP segid:11470
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "Idle", "pid": "0", "apicId": "0", "id": "0"}}}
fTriage Status: {"dbgFtriage": {"attributes": {"operState": "Idle", "pid": "0", "apicId": "0", "id": "0"}}}

هناك كمية كبيرة من البيانات في هذا النظام. يتم إبراز بعض من أهم الحقول. لاحظ أن مسار الحزمة كان 'leaf205 (pod 2) > spine3 (pod 2) > spine2 (pod 1) > leaf101 (pod 1)'. كما تكون جميع قرارات إعادة التوجيه وعمليات بحث العقود التي تتم على طول الطريق مرئية.

لاحظ أنه إذا كان هذا تدفق من الطبقة 2، فستحتاج صياغة الفئة إلى تعيينها على شيء مثل:

ftriage bridge -ii LEAF:205 -dmac 00:00:11:11:22:22

طلبات الوكيل حيث لا يكون EP في COOP

قبل النظر في سيناريوهات فشل محددة، هناك قطعة أخرى لمناقشتها تتعلق بإعادة توجيه البث الأحادي عبر Multi-Pod. ماذا يحدث إذا كانت نقطة النهاية الوجهة غير معروفة، تم تمثيل الطلب، والنقطة النهائية غير موجودة في COOP؟

في هذا السيناريو، يتم إرسال الحزمة/الإطار إلى العامود الرئيسي ويتم إنشاء طلب glean.

عندما يقوم العامود الرئيسي بإنشاء طلب glean، فإن الحزمة الأصلية لا تزال محفوظة في الطلب على أي حال، فإن الحزمة تستلم etherType 0xfff2 أي يكون EtherType مخصص محجوز للglean. ولهذا السبب، لن يكون من السهل تفسير هذه الرسائل في أدوات التقاط الحزم مثل Wireshark.

كما يتم تعيين وجهة الطبقة الخارجية 3 على 239.255.255.240 وهي مجموعة بث متعدد محجوزة خصيصا لرسائل الشبكة. هذا ينبغي كنت فضت عبر البناء وأي مخرج ورقة مفتاح أن يتلقى الغاية subnet من ال glean طلب ينشر سيولد ARP طلب أن يحل الغاية. يتم إرسال ARPs هذه من عنوان IP لشبكة BD الفرعية التي تم تكوينها (وبالتالي لا يمكن لطلبات الوكيل حل موقع نقاط النهاية الصامتة/غير المعروفة إذا تم تعطيل توجيه البث الأحادي على مجال جسر).

يمكن التحقق من إستقبال الرسالة الدبقية على ورقة الخروج و ARP الذي تم إنشاؤه بعد ذلك واستقبال إستجابة ARP من خلال الأمر التالي:

التحقق من ARP ل Glean

a-leaf205# show ip arp internal event-history event | grep -F -B 1 192.168.21.11 
...
73) Event:E_DEBUG_DSF, length:127, at 316928 usecs after Wed May  1 08:31:53 2019
Updating epm ifidx: 1a01e000 vlan: 105 ip: 192.168.21.11, ifMode: 128 mac: 8c60.4f02.88fc   <<< Endpoint is learned
75) Event:E_DEBUG_DSF, length:152, at 316420 usecs after Wed May  1 08:31:53 2019
log_collect_arp_pkt; sip = 192.168.21.11; dip = 192.168.21.254; interface = Vlan104;info = Garp Check adj:(nil)  <<< Response received
77) Event:E_DEBUG_DSF, length:142, at 131918 usecs after Wed May  1 08:28:36 2019
log_collect_arp_pkt; dip = 192.168.21.11; interface = Vlan104;iod = 138; Info = Internal Request Done   <<< ARP request is generated by leaf
78) Event:E_DEBUG_DSF, length:136, at 131757 usecs after Wed May  1 08:28:36 2019   <<< Glean received, Dst IP is in BD subnet
log_collect_arp_glean;dip = 192.168.21.11;interface = Vlan104;info = Received pkt Fabric-Glean: 1
79) Event:E_DEBUG_DSF, length:174, at 131748 usecs after Wed May  1 08:28:36 2019
log_collect_arp_glean; dip = 192.168.21.11; interface = Vlan104; vrf = CiscoLive2019:vrf1; info = Address in PSVI subnet or special VIP   <<< Glean Received, Dst IP is in BD subnet

بالنسبة للمرجع، فإن رسائل glean التي يتم إرسالها إلى 239.255.255.240 هي السبب في ضرورة تضمين هذه المجموعة في نطاق مجموعة PIM ثنائي الإتجاه على IPN.

السيناريو رقم 1 لاستكشاف الأخطاء وإصلاحها باستخدام نظام Multi-Pod (البث الأحادي)

وفي الطوبولوجيا التالية، لا يمكن ل EP B الاتصال ب EP A.

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

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

أثناء متابعة سير عمل أستكشاف أخطاء البث الأحادي وإصلاحها الموضح مسبقا، لاحظ أن الطلب تم توكيله ولكن لا تحتوي عقد العمود الرئيسي في Pod 2 على عنوان IP للوجهة في COOP.

السبب: نقطة النهاية مفقودة في COOP

وكما تمت مناقشته سابقا، يتم ملء إدخالات COOP لنقاط النهاية ل Pod البعيدة من معلومات BGP EVPN. ونتيجة لهذا فمن الأهمية بمكان أن نحدد:

أ) هل يحتوي العمود الفقري للمصدر POD (Pod 2) على EVPN؟

a-spine4# show bgp l2vpn evpn 10.0.1.100 vrf overlay-1
<no output>

ب) هل يحتوي العمود الفقري البعيد Pod (Pod 1) على هذا في EVPN؟

a-spine1# show bgp l2vpn evpn 10.0.1.100 vrf overlay-1
Route Distinguisher: 1:16777199    (L2VNI 1)
BGP routing table entry for [2]:[0]:[15728642]:[48]:[0050.5681.3ee6]:[32]:[10.0.1.100]/272, version 11751 dest ptr 0xafbf8192
Paths: (1 available, best #1)
Flags: (0x00010a 00000000) on xmit-list, is not in rib/evpn
Multipath: eBGP iBGP

 Advertised path-id 1
 Path type: local 0x4000008c 0x0 ref 0 adv path ref 1, path is valid, is best path
 AS-Path: NONE, path locally originated
   0.0.0.0 (metric 0) from 0.0.0.0 (192.168.1.101)
     Origin IGP, MED not set, localpref 100, weight 32768
     Received label 15728642 2392068
     Extcommunity:
         RT:5:16
         
           Path-id 1 advertised to peers:

يحتوي العمود الفقري Pod 1 على ذلك، و Next-hop IP هو 0.0.0.0؛ هذا يعني أنه تم تصديره من COOP محليا. ومع ذلك، لاحظ أن قسم "المعلن للشركاء" لا يتضمن عقد العمود الفقري ل Pod 2.

ج) هل BGP EVPN بين Pods؟

a-spine4# show bgp l2vpn evpn summ vrf overlay-1

Neighbor            V      AS   MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.101   4 65000       57380    66362            0     0      0  00:00:21  Active
192.168.1.102   4 65000       57568    66357            0     0      0  00:00:22  Active

لاحظ في الإخراج أعلاه أن حالات BGP EVPN قد انخفضت بين Pods. يشير أي شيء غير القيمة الرقمية في عمود State/PfxRcd إلى أن التجاور غير مرتفع. لم يتم التعرف على POD 1 EPs من خلال EVPN ولا يتم إستيرادها إلى COOP.

إن يرى هذا إصدار يكون دققت التالي:

1. هل هناك OSPF بين عقد العمود الفقري وشبكات IPN المتصلة؟
2. هل تحتوي عقد العمود الفقري على مسارات تم التعرف عليها من خلال OSPF لبروتوكول IPs الخاص بالعمود الرئيسي البعيد؟
3. هل يدعم المسار الكامل عبر IPN وحدة الحد الأقصى للنقل (MTU) من Jumbo؟
4. هل جميع عمليات تجاور البروتوكولات مستقرة؟

الأسباب المحتملة الأخرى

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

• يجب تمكين توجيه البث الأحادي على BD.
• يجب أن تكون الوجهة في شبكة BD فرعية.
• يجب أن يوفر IPN خدمة توجيه البث المتعدد للمجموعة 239.255.255.240.

يتم تغطية جزء البث المتعدد بشكل أكبر في القسم التالي.

نظرة عامة على إعادة توجيه البث متعدد النبضات والبث الأحادي غير المعروف والبث المتعدد (BUM)

في قائمة التحكم في الوصول (ACI)، يتم تدفق حركة المرور عبر مجموعات البث المتعدد المضمنة في العديد من السيناريوهات المختلفة. على سبيل المثال، يحدث فيض ل:

• البث المتعدد وحركة مرور البث.
• مجهول unicast أن ينبغي كنت فضت.
• رسائل شبكة ARP الليفية.
• أعلن EP عن الرسائل.

تعتمد العديد من الميزات والوظائف على إعادة توجيه BUM.

ضمن قائمة التحكم في الوصول (ACI)، يتم تخصيص جميع مجالات الجسر لعنوان بث متعدد معروف باسم عنوان خارجي (أو GIPo) للمجموعة. فضت كل حركة مرور أن يكون داخل جسر مجال على هذا GIPo.

BD GIPo في واجهة المستخدم الرسومية

يمكن الاستعلام عن الكائن مباشرة على أحد APICs.

BD GIPo في Moquery

a-apic1# moquery -c fvBD -f 'fv.BD.name=="Bd1"'
Total Objects shown: 1

# fv.BD
name                     : Bd1
OptimizeWanBandwidth     : no
annotation               :
arpFlood                 : yes
bcastP                   : 225.1.53.64
childAction              :
configIssues             :
descr                    :
dn                       : uni/tn-Prod/BD-Bd1
epClear                  : no
epMoveDetectMode         :
extMngdBy                :
hostBasedRouting         : no
intersiteBumTrafficAllow : no
intersiteL2Stretch       : no
ipLearning               : yes
ipv6McastAllow           : no
lcOwn                    : local
limitIpLearnToSubnets    : yes
llAddr                   : ::
mac                      : 00:22:BD:F8:19:FF
mcastAllow               : no
modTs                    : 2019-09-30T20:12:01.339-04:00
monPolDn                 : uni/tn-common/monepg-default
mtu                      : inherit
multiDstPktAct           : bd-flood
nameAlias                :
ownerKey                 :
ownerTag                 :
pcTag                    : 16387
rn                       : BD-Bd1
scope                    : 2392068
seg                      : 15728642
status                   :
type                     : regular
uid                      : 16011
unicastRoute             : yes
unkMacUcastAct           : proxy
unkMcastAct              : flood
v6unkMcastAct            : flood
vmac                     : not-applicable

المعلومات الواردة أعلاه حول تفيض GIPo صحيحة بغض النظر عما إذا كان Multi-Pod مستخدما أم لا. الجزء الإضافي المتعلق ب Multi-Pod هو توجيه البث المتعدد على IPN.

يتضمن توجيه بث IPN المتعدد ما يلي:

• تعمل العقد الأساسية كمضيفات للبث المتعدد (IGMP فقط). لا يشغلون PIM.
• إذا تم نشر BD في POD، فإن عمودا رئيسيا واحدا من POD سيرسل وصلة IGMP على إحدى واجهات واجهة IP الخاصة به. ويتم تقسيم هذه الوظيفة إلى شرائط عبر جميع عقد العمود الفقري وواجهة واجهة واجهة IPN عبر العديد من المجموعات.
• تتلقى شبكات IPN هذه الوصلات وترسل واجهات PIM نحو PIM RP ثنائي الإتجاه.
• لا توجد أشجار (S،G) بسبب إستخدام PIM Bidir. لا تستخدم إلا أشجار (*،g) في بيدير PIM.
• تمر جميع حركة مرور مستوى البيانات التي يتم إرسالها إلى GIPo عبر RP.

مستوى التحكم في البث المتعدد ل IPN

مستوى بيانات بث IPN المتعدد

الوسيلة الوحيدة لتكرار بروتوكول RP مع PIM Bidir هي إستخدام الأداة الوهمية. تتم تغطية هذا الأمر بالتفصيل ضمن جزء "اكتشاف أجهزة الكمبيوتر متعددة الطبقات" من هذا الكتاب. كخلاصة سريعة، لاحظ أنه مع Phantom RP:

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

تكوين RP الوهمي

سير عمل أستكشاف أخطاء البث المتعدد Multi-Pod والبث الأحادي غير المعروف والبث المتعدد (BUM) وإصلاحها

1. تأكد أولا ما إذا كان يتم التعامل مع التدفق حقا على أنه متعدد الوجهة بواسطة البنية.

سيتم تدفق التدفق في BD في هذه الأمثلة الشائعة:

• الإطار هو بث ARP ويتم تمكين غمر ARP على BD.
• يتم توجيه الإطار إلى مجموعة بث متعدد. لاحظ أنه حتى إذا تم تمكين التطفل على بروتوكول IGMP، فإن حركة المرور لا تزال تفيض دائما داخل البنية على GIPo.
• يتم توجيه حركة المرور إلى مجموعة البث المتعدد التي تقوم واجهة التحكم في الوصول (ACI) بتوفير خدمات توجيه البث المتعدد لها.
• التدفق هو طبقة 2 (تدفق يجسر) والغاية {upper}mac address غير معروف ومجهول unicast تصرف على ال BD ثبتت إلى 'flood'.

أسهل طريقة لتحديد أي قرار تحويل سيتم إتخاذه هي مع ELAM.

2. التعرف على BD GIPo.

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

3. تحقق من جداول توجيه البث المتعدد على IPN لهذا GIPo.

وتختلف النواتج اللازمة للقيام بذلك تبعا لمنهاج عمل الشبكة الدولية للإنترنت المستخدم، ولكن على مستوى عال:

• يجب أن تتفق جميع موجهات IP على RP ويجب أن تشير إعادة توجيه المسار العكسي (RPF) لهذا GIPo إلى هذه الشجرة.
• يجب أن يحصل موجه IPn واحد متصل بكل Pod على انضمام IGMP للمجموعة.

السيناريو رقم 2 لاستكشاف الأخطاء وإصلاحها باستخدام بطاقات Multi-Pod (تدفق BUM)

يغطي هذا السيناريو أي سيناريو يتضمن عدم حل ARP عبر سيناريوهات Multi-Pod أو BUM (البث الأحادي غير المعروف، وما إلى ذلك).

وهناك العديد من الأسباب المحتملة الشائعة هنا.

السبب المحتمل 1: تمتلك الموجهات المتعددة عنوان PIM RP

مع هذا السيناريو، تغرق المدخل حركة المرور (تحقق مع ELAM)، مصدر Pod يستلم ويفيض الحركة، لكن Pod لا يحصل عليها. بالنسبة لبعض دي بي، فيضان يعمل، لكن بالنسبة لآخرين لا يعمل.

على IPn، قم بتشغيل "show ip route <gipO address>" ل GIPo للاطلاع على أن شجرة RPF تشير إلى موجهات متعددة ومختلفة.

إذا كان هذا هو الحال فتحقق مما يلي:

• تحقق من عدم تكوين عنوان PIM RP الفعلي في أي مكان. سيرى أي جهاز يمتلك عنوان RP الفعلي طريقا محليا /32 له.
• تحقق من أن موجهات IP المتعددة لا تعلن عن نفس طول البادئة ل RP في سيناريو RP الوهمي.

السبب المحتمل 2: موجهات IPN لا تتعلم المسارات لعنوان RP

وبنفس الطريقة كالسبب الاول الممكن، هنا تفشل حركة المرور المغمورة في مغادرة IPN. سيظهر إخراج 'show ip route <rp address>' على كل موجه IP طول البادئة التي تم تكوينها محليا فقط بدلا من ما تقوم الموجهات الأخرى بالإعلان عنه.

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

إذا كان هذا هو الحال. تحقق مما يلي:

• تحقق من وجود عمليات توجيه التجاور بين موجهات IP. تحقق من أن المسار موجود في قاعدة بيانات البروتوكول الفعلية (مثل قاعدة بيانات OSPF).
• تحقق من تكوين جميع عمليات الاسترجاع التي من المفترض أن تكون RP للمرشح كأنواع شبكات OSPF من نقطة إلى نقطة. إذا لم يتم تكوين نوع الشبكة هذا، فسيقوم كل موجه دائما بالإعلان عن طول بادئة /32 بغض النظر عن ما تم تكوينه بالفعل.

السبب المحتمل 3: لا تقوم موجهات IP بتثبيت مسار GIPo أو نقاط RPF إلى ACI

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

واجهة RPF نحو ACI

لحل هذه المشكلة:

• تأكد من تشغيل عمليات تجاور بروتوكول التوجيه بين موجهات IP.
• قم بزيادة مقاييس تكلفة OSPF الخاصة بالروابط المقابلة ل IPn على عقد العمود الفقري إلى قيمة تجعل هذا القياس أقل تفضيلا من إرتباطات IP إلى IPn.

مراجع أخرى

قبل برنامج ACI 4.0، كانت هناك بعض التحديات فيما يتعلق باستخدام CoS 6 بواسطة أجهزة خارجية. تمت معالجة معظم هذه المشاكل من خلال تحسينات 4.0 ولكن للحصول على مزيد من المعلومات، يرجى الرجوع إلى جلسة عمل CiscoLive "BRKACI-2934 - أستكشاف أخطاء البرامج المتعددة وإصلاحها" وقسم "جودة الخدمة".