أستكشاف أخطاء بروتوكول التوجيه المتقطع وإصلاحها مع EEM و EPC

المقدمة

يصف هذا المستند كيفية أستكشاف أخطاء بروتوكول التوجيه المتقطع ورفقات BFD وإصلاحها في Cisco IOS® XE باستخدام IM و EPC.

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

المتطلبات

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

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

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

نظرة عامة على المشكلة

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

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

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

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

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

نظرة عامة على التكوين

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

قالب تكوين قائمة التحكم في الوصول ACL

في معظم الحالات، تكون حركة المرور الوحيدة التي يتم الحصول عليها من عنوان IP للواجهة على كلا طرفي توجيه التجاور هي حركة مرور التحكم في التوجيه نفسها. وعلى هذا النحو، تغطي قائمة التحكم في الوصول (ACL) التي تسمح بحركة المرور من كل من عنوان IP للواجهة المحلية وعنوان IP المجاور إلى أي وجهة متطلبات أي بروتوكول توجيه، بالإضافة إلى BFD. إذا كانت هناك حاجة إلى عامل تصفية إضافي، فيمكن تحديد عنوان IP للوجهة ذات الصلة استنادا إلى بروتوكول التوجيه أو وضع BFD كذلك. تحديد معلمات قائمة التحكم في الوصول (ACL) في وضع التكوين:

config t

ip access-list extended 
    
    
      permit ip host 
     
       any permit ip host 
      
        any end 
       
      
    

قالب معلمات EPC

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

• قارن <interface> التقاط جهاز العرض <EPC Name>
• مراقبة التقاط <EPC Name> قائمة الوصول <ACL Name>
• جهاز عرض التقاط <EPC Name> مخزن مؤقت حجم 5 دائري

• مستوى التحكم لالتقاط الشاشة <EPC Name>
• مراقبة التقاط <EPC Name> قائمة الوصول <ACL Name>
• جهاز عرض التقاط <EPC Name> مخزن مؤقت حجم 5 دائري

عند تكوينها، ابدأ تشغيل EPC:

• بدء التقاط الشاشة <EPC Name>

يتم تعيين IM لإيقاف الالتقاط عند حدوث الرفرفة.

لضمان التقاط الحزم في كلا الاتجاهين، تحقق من مخزن الالتقاط المؤقت:

show monitor capture 
    
    
      buffer brief 
    

قالب تكوين IM

الغرض الرئيسي من أداة الإدخال/الإخراج (IM) هو إيقاف التقاط الحزمة وحفظها مع المخزن المؤقت syslog. يمكن تضمين أوامر إضافية للتحقق من عوامل أخرى مثل وحدة المعالجة المركزية أو عمليات إسقاط الواجهة أو إستخدام الموارد الخاصة بالنظام الأساسي عدادات الإسقاط. قم بإنشاء التطبيق الصغير EEM في وضع التكوين:

config t
event manager applet 
    
    
      authorization bypass event syslog pattern " 
     
       " maxrun 120 ratelimit 100000 action 000 cli command "enable" action 005 cli command "show clock | append bootflash: 
      
        .txt" action 010 cli command "show logging | append bootflash: 
       
         .txt" action 015 cli command "show process cpu sorted | append bootflash: 
        
          .txt" action 020 cli command "show process cpu history | append bootflash: 
         
           .txt" action 025 cli command "show interfaces | append bootflash: 
          
            .txt" action 030 cli command "monitor capture 
           
             stop" action 035 cli command "monitor capture 
            
              export bootflash: 
             
               .pcap" action 040 syslog msg "Saved logs to bootflash: 
              
                .txt and saved packet capture to bootflash: 
               
                 .pcap" action 045 cli command "end" end 
                
               
              
             
            
           
          
         
        
       
      
    

action 035 cli command "monitor capture 
    
    
      export location bootflash: 
     
       .pcap" 
      
    

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

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

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

مثال - EIGRP

يتم تعيين جميع وحدات التوقيت على الإعداد الافتراضي في هذا المثال (عدد مرات الانتظار 5 ثوان، ومدة الانتظار 15 ثانية).

المخطط

تشير السجلات الموجودة على R1 إلى وجود نقاط EIGRP متقطعة حدثت عدة ساعات منفصلة عن بعضها البعض:

R1#show logging | i EIGRP
*Jul 16 20:45:08.019: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: Interface PEER-TERMINATION received
*Jul 16 20:45:12.919: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency
*Jul 17 10:25:42.970: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: holding time expired
*Jul 17 10:25:59.488: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency
*Jul 17 14:39:02.970: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: holding time expired
*Jul 17 14:39:16.488: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency

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

التكوين

1. قم بتكوين قائمة التحكم في الوصول (ACL) باستخدام عناوين IP لواجهة النفق، بما أن هذه هي عناوين IP المصدر للهيكل:

R1#conf t
R1(config)#ip access-list extended FLAP_CAPTURE
R1(config-ext-nacl)#permit ip host 192.168.10.1 any
R1(config-ext-nacl)#permit ip host 192.168.10.2 any
R1(config-ext-nacl)#end 

2. قم بإنشاء EPC وربطه مع الواجهة وقائمة التحكم في الوصول (ACL):

R1#monitor capture CAP interface Tunnel10 both
R1#monitor capture CAP access-list FLAP_CAPTURE
R1#monitor capture CAP buffer size 5 circular

3. بدء تشغيل EPC والتأكيد من التقاط الحزم في كلا الاتجاهين:

R1#monitor capture CAP start
R1#show monitor capture CAP buffer brief 
 ----------------------------------------------------------------------------
 #   size   timestamp     source             destination      dscp    protocol
 ----------------------------------------------------------------------------
   0   74    0.000000   192.168.10.1     ->  224.0.0.10       48 CS6  EIGRP
   1   74    0.228000   192.168.10.2     ->  224.0.0.10       48 CS6  EIGRP
   2   74    4.480978   192.168.10.2     ->  224.0.0.10       48 CS6  EIGRP
   3   74    4.706024   192.168.10.1     ->  224.0.0.10       48 CS6  EIGRP

4. قم بتكوين IM:

R1#conf t
R1(config)#event manager applet R1_EIGRP_FLAP authorization bypass
R1(config-applet)#event syslog pattern "%DUAL-5-NBRCHANGE" maxrun 120 ratelimit 100000
R1(config-applet)#action 000 cli command "enable"
R1(config-applet)#action 005 cli command "show clock | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 010 cli command "show logging | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 015 cli command "show process cpu sorted | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 020 cli command "show process cpu history | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 025 cli command "show interfaces | append bootflash:R1_EIGRP_FLAP.txt"
R1(config-applet)#action 030 cli command "monitor capture CAP stop"
R1(config-applet)#action 035 cli command "monitor capture CAP export bootflash:R1_EIGRP_CAP.pcap"
R1(config-applet)#action 040 syslog msg "Saved logs to bootflash:R1_EIGRP_FLAP.txt and saved packet capture to bootflash:R1_EIGRP_CAP.pcap"
R1(config-applet)#action 045 cli command "end"
R1(config-applet)#end

5. انتظر حدوث الرفرفة التالية، وانسخ الملفات من bootflash عبر طريقة النقل المفضلة لديك للتحليل:

R1#show logging

    
    
      *Jul 17 16:51:47.154: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is down: Interface PEER-TERMINATION received *Jul 17 16:51:48.015: %BUFCAP-6-DISABLE: Capture Point CAP disabled. *Jul 17 16:51:48.283: %HA_EM-6-LOG: EIGRP_FLAP: Saved logs to bootflash:EIGRP_FLAP.txt and saved packet capture to bootflash:EIGRP_FLAP.pcap *Jul 17 16:51:51.767: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.2 (Tunnel10) is up: new adjacency R1# R1#dir bootflash: | i EIGRP 23 -rw- 147804 Jul 17 2024 16:51:48 +00:00 EIGRP_CAP.pcap 22 -rw- 74450 Jul 17 2024 16:51:47 +00:00 EIGRP_FLAP.txt 
    

• يشير المخزن المؤقت للسجل على الموجه إلى وجود رفرفة EIGRP، وتم حفظ الملفات بواسطة IM.

تحليل

عند هذه النقطة، أربط وقت الرفرفة التي وجدت في السجل مصد مع الربط الذي تم تجميعه لتحديد ما إذا كانت حزم الترحيب تم إرسالها واستقبالها على كلا النهايتين عند حدوث الرفرفة. بما أن "إنهاء نظير الواجهة" الذي تم تلقيه في R1، فهذا يعني أنه يجب أن يكون R2 قد اكتشف ضياع الاتصال وبالتالي انتهاء صلاحية فترة الانتظار، وهو ما يظهر في ملف السجل:

*Jul 17 16:51:47.156: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.1 (Tunnel10) is down: holding time expired
*Jul 17 16:51:51.870: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.10.1 (Tunnel10) is up: new adjacency

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

• يظهر الالتقاط إرتباط من كل من 192.168.10.1 (R1) و 192.168.10.2 (R2) في 15 ثانية قبل الحزمة Peer-Termination Hello التي يرسلها R2 في 16:51:47 (الحزمة 513).
• وعلى وجه التحديد، كانت الحزم 503 و 505 و 508 و 511 (المشار إليها بواسطة الأسهم الخضراء) جميعها مرسلة من R1 في هذه الفترة الزمنية.

تتمثل الخطوة التالية في تأكيد ما إذا كان R2 قد تم إستلام جميع الخوذ المرسلة بواسطة R1 في ذلك الوقت، لذا يجب التحقق من عملية الالتقاط التي تم تجميعها من R2:

• يظهر الالتقاط أن آخر ترحيب تم تلقيه من 192.168.10.1 (R1) كان في 16:51:32 (يشار إليه بالسهم الأخضر). بعد ذلك، تظهر ال 15 ثانية التالية هويات مرسلة بواسطة R2 (يشار إليها بواسطة المربع الأحمر). لا تظهر الحزم 505 و 508 و 511 في الالتقاط من R1 في الالتقاط على R2. وهذا يتسبب في اكتشاف انتهاء صلاحية مؤقت الاحتجاز وإرسال الحزمة Peer-Termination Hello في 16:51:47 (الحزمة 502).

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

بروتوكول أقصر مسار أولاً (OSPF)

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

• المؤقتات الافتراضية هي 10 ثواني وساعة وفاة 40 ثانية. تأكيد وحدات التوقيت المستخدمة في شبكتك دائما عند أستكشاف أخطاء وحدات التوقيت المنتهية صلاحيتها وإصلاحها.
• يتم الحصول على حزم الترحيب من عناوين IP للواجهة. إذا كانت هناك حاجة إلى تحديد قائمة التحكم في الوصول (ACL) إضافية، فإن عنوان وجهة البث المتعدد لخط اتصال OSPF هو 224.0.0.5.
• تختلف رسائل السجل الموجودة على الأجهزة قليلا. على النقيض من EIGRP، لا يوجد مفهوم لرسالة إنهاء النظير مع OSPF. بدلا من ذلك، يقوم الجهاز الذي يكشف المؤقت المميت منته الصلاحية بتسجيل هذا كسبب الرفرفة وبعد ذلك يقوم الجهاز بإرسال رسالة لم يعد يحتوي على معرف الموجه الخاص بالنظير، والذي يتسبب في نقل النظير إلى حالة INIT. عندما يتم الكشف عن حالة التجاور مرة أخرى، يتم الانتقال عبر التجاور حتى تصل إلى الحالة الكاملة. على سبيل المثال:

يكتشف R1 وقت منتهي الصلاحية:

R1#show logging | i OSPF
*Jul 30 15:29:14.027: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jul 30 15:32:30.278: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from LOADING to FULL, Loading Done
*Jul 30 16:33:19.841: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from FULL to DOWN, Neighbor Down: Dead timer expired
*Jul 30 16:48:10.504: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.2 on Tunnel20 from LOADING to FULL, Loading Done

ومع ذلك، يعرض R2 رسائل السجل فقط عندما ينتقل OSPF مرة أخرى إلى الكامل. لا يظهر رسالة سجل عندما تتغير الحالة إلى INIT:

R2#show logging | i OSPF    
*Jul 30 16:32:30.279: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.1 on Tunnel20 from LOADING to FULL, Loading Done
*Jul 30 16:48:10.506: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.30.1 on Tunnel20 from LOADING to FULL, Loading Done

لتشغيل IM على كلا الجهازين، أستخدم "٪OSPF-5-ADJCHG" كنمط syslog. وهذا يضمن أن أداة التحكم في الوصول للبنية الأساسية (IM) تعمل على كلا الجهازين طالما أنها تنزل ثم تعود مرة أخرى للاعلى. تضمن قيمة الحد من الدقة التي تم تكوينها عدم تشغيلها مرتين خلال فترة قصيرة عند رؤية سجلات متعددة بهذه السلسلة. المفتاح أن يؤكد ما إذا كان يتم إرسال واستقبال هويات في الربط يلتقط على كلا جانب.

BGP

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

• المؤقتات الافتراضية هي حزم keepalives من 60 ثانية ووقت الانتظار من 180 ثانية. قم دوما بتأكيد وحدات التوقيت المستخدمة في شبكتك عند أستكشاف أخطاء وقت الانتظار منتهية الصلاحية وإصلاحها.
• يتم إرسال حزم Keepalive للبث الأحادي بين عناوين IP المجاورة إلى منفذ وجهة TCP 179. إذا كانت هناك حاجة إلى تحديد قائمة تحكم في الوصول (ACL) إضافية، فعليك السماح بحركة مرور TCP من عناوين IP للمصدر إلى وجهة منفذ TCP 179.
• تبدو رسائل السجل لبروتوكول BGP متشابهة على كلا الجهازين، ولكن الجهاز الذي يكتشف وقت الانتظار ينتهي يظهر أنه أرسل الإعلام إلى المجاور، بينما يشير الآخر إلى أنه استلم رسالة الإعلام. على سبيل المثال:

يكتشف R1 وقت الانتظار الذي انتهت صلاحيته ويرسل الإخطار إلى R2:

R1#show logging | i BGP
*Jul 30 17:49:23.730: %BGP-3-NOTIFICATION: sent to neighbor 192.168.30.2 4/0 (hold time expired) 0 bytes 
*Jul 30 17:49:23.731: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BGP Notification sent)
*Jul 30 17:49:23.732: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BGP Notification sent
*Jul 30 17:49:23.732: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BGP Notification sent

يستلم R2 الإعلام من R1 لأن وقت الانتظار الذي تم اكتشافه انتهى:

R2#show logging | i BGP
*Jul 30 17:49:23.741: %BGP-3-NOTIFICATION: received from neighbor 192.168.30.1 4/0 (hold time expired) 0 bytes 
*Jul 30 17:49:23.741: %BGP-5-NBR_RESET: Neighbor 192.168.30.1 reset (BGP Notification received)
*Jul 30 17:49:23.749: %BGP-5-ADJCHANGE: neighbor 192.168.30.1 Down BGP Notification received
*Jul 30 17:49:23.749: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.1 IPv4 Unicast topology base removed from session  BGP Notification received

لتشغيل IM لرفرفة BGP، أستخدم "٪BGP_SESSION-5-ADJCHANGE" كنمط syslog. أي من رسائل syslog الأخرى "٪BGP" التي تم تسجيلها أيضا بعد الرفرفة يمكن إستخدامها لتشغيل IM أيضا.

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

ويمكن تطبيق نفس المنهجية لاستكشاف أخطاء تفريغ BFD المتقطعة وإصلاحها، مع بعض الاختلافات الطفيفة لتطبيقها على التحليل. يغطي هذا القسم بعض وظائف BFD الأساسية ويقدم مثالا على كيفية إستخدام IM و EPC لاستكشاف الأخطاء وإصلاحها. للحصول على معلومات أكثر تفصيلا حول أستكشاف أخطاء BFD وإصلاحها، ارجع إلى اكتشاف إعادة التوجيه ثنائي الإتجاه وإصلاحها في Cisco IOS XE.

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

المخطط

مثال - وضع صدى BFD

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

تشير السجلات من R1 إلى أن تجاور BFD قد انخفض عدة مرات بسبب فشل ECHO، مما يعني أنه خلال هذه الفواصل، لم يستلم R1 أو يعالج 3 من حزم ECHO الخاصة به من R2.

R1#show logging | i BFD
*Jul 18 13:41:09.007: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4097 handle:1,is going Down Reason: ECHO FAILURE
*Jul 18 13:41:09.009: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BFD adjacency down)
*Jul 18 13:41:09.010: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BFD adjacency down
*Jul 18 13:41:09.010: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 13:41:09.010: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:BGP, handle:1 active
*Jul 18 13:41:13.335: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 13:41:18.576: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 192.168.30.2 proc:BGP, idb:Tunnel30 handle:1 act
*Jul 18 13:41:19.351: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 15:44:08.360: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4097 handle:1,is going Down Reason: ECHO FAILURE
*Jul 18 15:44:08.362: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BFD adjacency down)
*Jul 18 15:44:08.363: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BFD adjacency down
*Jul 18 15:44:08.363: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 15:44:08.363: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:BGP, handle:1 active
*Jul 18 15:44:14.416: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP
*Jul 18 15:44:14.418: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4097 neigh proc:CEF, handle:1 active
*Jul 18 15:44:18.315: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 192.168.30.2 proc:BGP, idb:Tunnel30 handle:2 act

التكوين

1. قم بتكوين قائمة التحكم في الوصول (ACL) باستخدام عناوين IP لواجهة النفق، بما أن هذه هي عناوين IP المصدر لحزم صدى BFD وحزم التحكم:

R1#conf t
R1(config)#ip access-list extended FLAP_CAPTURE
R1(config-ext-nacl)#permit ip host 192.168.30.1 any
R1(config-ext-nacl)#permit ip host 192.168.30.2 any

2. قم بإنشاء EPC وربطه مع الواجهة وقائمة التحكم في الوصول (ACL):

R1#monitor capture CAP interface Tunnel30 both
R1#monitor capture CAP access-list FLAP_CAPTURE
R1#monitor capture CAP buffer size 5 circular

3. بدء تشغيل EPC والتأكيد من التقاط الحزم في كلا الاتجاهين:

R1#monitor capture CAP start 
R1#show monitor capture CAP buff brief 
 ----------------------------------------------------------------------------
 #   size   timestamp     source             destination      dscp    protocol
 ----------------------------------------------------------------------------
   0   54    0.000000   192.168.30.2     ->  192.168.30.2     48 CS6  UDP
   1   54    0.000000   192.168.30.2     ->  192.168.30.2     48 CS6  UDP
   2   54    0.005005   192.168.30.1     ->  192.168.30.1     48 CS6  UDP
   3   54    0.005997   192.168.30.1     ->  192.168.30.1     48 CS6  UDP

4. قم بتكوين IM:

R1#conf t
R1(config)#event manager applet R1_BFD_FLAP authorization bypass
R1(config-applet)#event syslog pattern "%BFDFSM-6-BFD_SESS_DOWN" maxrun 120 ratelimit 100000
R1(config-applet)#action 000 cli command "enable"
R1(config-applet)#action 005 cli command "show clock | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 010 cli command "show logging | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 015 cli command "show process cpu sorted | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 020 cli command "show process cpu history | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 025 cli command "show interfaces | append bootflash:R1_BFD_FLAP.txt"
R1(config-applet)#action 030 cli command "monitor capture CAP stop"
R1(config-applet)#action 035 cli command "monitor capture CAP export bootflash:R1_BFD_CAP.pcap"
R1(config-applet)#action 040 syslog msg "Saved logs to bootflash:R1_BFD_FLAP.txt and saved packet capture to bootflash:R1_BFD_CAP.pcap"
R1(config-applet)#action 045 cli command "end"
R1(config-applet)#end

5. انتظر حدوث الرفرفة التالية، وانسخ الملفات من bootflash عبر طريقة النقل المفضلة لديك للتحليل:

R1#show logging

    
    
      *Jul 18 19:09:47.482: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4097 handle:1,is going Down Reason: ECHO FAILURE *Jul 18 19:09:47.483: %BGP-5-NBR_RESET: Neighbor 192.168.30.2 reset (BFD adjacency down) *Jul 18 19:09:47.487: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Down BFD adjacency down *Jul 18 19:09:47.487: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.2 IPv4 Unicast topology base removed from session BFD adjacency down *Jul 18 19:09:47.487: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed, ld:4097 neigh proc:BGP, handle:1 active *Jul 18 19:09:48.191: %BUFCAP-6-DISABLE: Capture Point CAP disabled. *Jul 18 19:09:48.668: %HA_EM-6-LOG: R1_BFD_FLAP: Saved logs to bootflash:R1_BFD_FLAP.txt and saved packet capture to bootflash:R1_BFD_CAP.pcap *Jul 18 19:09:50.165: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP *Jul 18 19:09:54.386: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 192.168.30.2 proc:BGP, idb:Tunnel30 handle:1 act *Jul 18 19:09:54.386: %BGP-5-ADJCHANGE: neighbor 192.168.30.2 Up *Jul 18 19:09:55.178: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:4097 handle:1 is going UP R1# R1#dir | i BFD 25 -rw- 1591803 Jul 18 2024 19:09:48 +00:00 R1_BFD_CAP.pcap 24 -rw- 84949 Jul 18 2024 19:09:48 +00:00 R1_BFD_FLAP.txt 
    

• يشير المخزن المؤقت للسجل إلى وجود رفرفة BFD في 19:09:47، وتم حفظ الملفات بواسطة IM.

تحليل

عند هذه النقطة، قم بربط وقت الرفرفة الموجودة في المخزن المؤقت للسجل مع التقاط الحزمة التي تم تجميعها لتحديد ما إذا كان قد تم إرسال صدى BFD واستقباله على كلا النهايتين عند حدوث المشكلة. بما أن سبب الرفرفة على R1 هو فشل ECHO، هذا يعني أنه كان قد أرسل أيضا حزمة تحكم إلى R2 لإنهاء جلسة BFD، وهذا ينعكس في ملف السجل الذي تم تجميعه من R2 حيث أن سبب انخفاض BFD RX يتم رؤيته:

*Jul 18 19:09:47.468: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:4098 handle:2,is going Down Reason: RX DOWN
*Jul 18 19:09:47.470: %BGP-5-NBR_RESET: Neighbor 192.168.30.1 reset (BFD adjacency down)
*Jul 18 19:09:47.471: %BGP-5-ADJCHANGE: neighbor 192.168.30.1 Down BFD adjacency down
*Jul 18 19:09:47.471: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.30.1 IPv4 Unicast topology base removed from session  BFD adjacency down
*Jul 18 19:09:47.471: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:4098 neigh proc:BGP, handle:2 active

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

• يظهر الالتقاط أن R1 أرسل بنشاط حزم صدى BFD حتى وقت الرفرفة، غير أن هم لم يرجع ب R2، لذلك R1 يرسل ربط تحكم أن ينهي الجلسة في 19:09:47.468. 
• وهذا واضح من حقيقة أن الحزم 137 و 138 و 140 (المشار إليها بواسطة الأسهم الخضراء) يتم رؤيتها فقط مرة واحدة في الالتقاط، والتي يمكن تحديدها من معرفات صدى BFD (في المربع الأحمر). إذا تم إرجاع الصدى، فسيكون هناك نسخة ثانية من كل من هذه الحزم بنفس معرف صدى BFD. يمكن إستخدام حقل تعريف IP في رأس IP (غير الموجود في الصورة هنا) للتحقق من ذلك أيضا.
• كما يوضح هذا الالتقاط أنه لم يتم تلقي أي أصداء لبروتوكول BFD من R2 بعد الحزمة 136، وهو ما يعد مؤشرا آخر على فقدان الحزمة في إتجاه R2 إلى R1.

تتمثل الخطوة التالية في تأكيد ما إذا كان قد تم إستلام جميع حزم صدى BFD التي تم إرسالها بواسطة R1 وإعادتها بواسطة R2، لذلك يجب التحقق من الالتقاط الذي تم تجميعه من R2:

•  ويبين هذا الالتقاط أن جميع أصداء داء داء داء البيرفد التي أرسلها R1 قد تم تلقيها وإعادتها من قبل R2 (يشار إليها بالسهام الخضراء)؛ الحزم 107 و 108 هي نفس صدى BFD، والحزم 111 و 112 هي نفس صدى BFD، والحزم 116 و 117 هي نفس صدى BFD.
• يوضح هذا الالتقاط أيضا أن R2 أرسل حزم صدى بشكل نشط (يشار إليها باستخدام المربعات الحمراء) والتي لا ترى في الالتقاط على R1، وهو ما يشير أيضا إلى فقدان الحزمة بين الأجهزة في الإتجاه من R2 إلى R1.

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

وضع BFD غير المتزامن

يمكن تطبيق نفس الطريقة عندما يكون وضع BFD غير المتزامن قيد الاستخدام (تم تعطيل وظيفة echo)، ويمكن الحفاظ على تكوين EEM و EPC بنفس الطريقة. يكمن الاختلاف في الوضع غير المتزامن في أن الأجهزة ترسل حزم التحكم في BFD للبث الأحادي لبعضها البعض مثل keepalives، المماثلة لتجاور بروتوكول توجيه نموذجي. هذا يعني أن فقط UDP ميناء 3784 ربط أرسلت. في هذا السيناريو، يبقى BFD في حالة up طالما تم تلقي حزمة BFD من المجاور ضمن الفاصل الزمني المطلوب. عند عدم حدوث ذلك، يكون سبب الفشل هو "اكتشاف انتهاء صلاحية المؤقت"، ويقوم الموجه بإرسال حزمة تحكم إلى النظير لإسقاط جلسة العمل.

لتحليل الالتقاط على الجهاز الذي كشف الفشل، ابحث عن حزم BFD للبث الأحادي التي تم استقبالها من النظير أثناء الوقت السابق إلى الرفرفة. على سبيل المثال، إذا تم تعيين فترة TX على 300 مللي ثانية بمضاعف 3، حينئذ إذا لم يكن هناك حزم BFD تم استقبالها في 900 مللي ثانية قبل الرفرفة، فإن هذا يشير إلى فقد الحزمة المحتمل. في عملية الإمساك التي تم تجميعها من الجار عبر التيار الآلي، تحقق من النافذة الزمنية نفسها؛ إذا تم إرسال الحزم أثناء ذلك الوقت، فإنه يؤكد أن هناك خسارة في مكان ما بين الأجهزة.