أستكشاف أخطاء توجيه BGP وإصلاحها (فشل التوجيه المتكرر)

المقدمة

يصف هذا المستند كيفية استكشاف أخطاء مسارات بروتوكول العبّارة الحدودية (BGP) المتذبذبة الناتجة عن فشل التوجيه المتكرر وإصلاحها. 

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

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

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

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

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

يصف هذا المستند كيفية استكشاف أخطاء مسارات بروتوكول العبّارة الحدودية (BGP) المتذبذبة الناتجة عن فشل التوجيه المتكرر وإصلاحها.

الأعراض الشائعة لفشل التوجيه المتكرر في BGP هي:

• حذف مسارات BGP وإعادة إدماجها بشكل مستمر في جدول التوجيه.

• فقدان الاتصال بوجهات تم التعرف عليها من خلال بروتوكول بوابة الحدود (BGP).

أحلت هذا شبكة رسم بياني بما أن أنت تستعمل هذا وثيقة:

الرسم التخطيطي للشبكة

ارجع إلى هذه التكوينات وأنت تستخدم هذا المستند:

hostname RTR-A
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
interface Serial8/0
 ip address 192.168.16.1 255.255.255.252
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.20.20.20 remote-as 2
 neighbor 10.20.20.20 ebgp-multihop 2
 neighbor 10.20.20.20 update-source Loopback0
!
ip route 10.20.20.0 255.255.255.0 192.168.16.2

hostname RTR-B

!
interface Loopback0
 ip address 10.20.20.20 255.255.255.255
!
interface Ethernet0/0
 ip address 172.16.1.1 255.255.255.0
!

interface Serial8/0
 ip address 192.168.16.2 255.255.255.252
!
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 network 10.20.20.20 mask 255.255.255.255
 network 172.16.1.0 mask 255.255.255.0
 neighbor 10.10.10.10 remote-as 1
 neighbor 10.10.10.10 ebgp-multihop 2
 neighbor 10.10.10.10 update-source Loopback0
 no auto-summary
!
ip route 10.10.10.0 255.255.255.0 192.168.16.1
!

الاصطلاحات

راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.

المشكلة

الأعراض

يتم ملاحظة هذين العرضين مع فشل التوجيه المتكرر:

• الرفرفة المستمرة للمسارات التي تعلمها BGP في جدول توجيه IP.

  راقب جدول التوجيه بشكل متواصل لبضع دقائق لمشاهدة الرفرفة.

RTR-A#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2, ia - ISIS inter are
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B       10.20.20.20/32 [20/0] via 10.20.20.20, 00:00:35
S       10.20.20.0/24 [1/0] via 192.168.16.2
     172.16.0.0/24 is subnetted, 1 subnets
B       172.16.1.0 [20/0] via 10.20.20.20, 00:00:35
     10.0.0.0/32 is subnetted, 1 subnets
C       10.10.10.10 is directly connected, Loopback0
     192.168.16.0/30 is subnetted, 1 subnets
C       192.168.16.0 is directly connected, Serial8/0

ملاحظة: من المفيد إستخدام show ip route | قم بتضمين ، الأمر 00:00 لمراقبة مسارات رفرفة عند التعامل مع جداول التوجيه الكبيرة.

بعد الانتظار لمدة دقيقة تقريبا، تتغير نتائج الأمر show ip route إلى هذا:

RTR-A#show ip route
[..]

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
S       10.20.20.0 [1/0] via 192.168.16.2
     10.0.0.0/32 is subnetted, 1 subnets
C       10.10.10.10 is directly connected, Loopback0
     192.168.16.0/30 is subnetted, 1 subnets
C       192.168.16.0 is directly connected, Serial8/0

ملاحظة: مسارات BGP مفقودة في جدول التوجيه السابق.

• عندما تكون مسارات بروتوكول BGP موجودة في جدول التوجيه، يفشل الاتصال بتلك الشبكات.

  ومن أجل ملاحظة ذلك، عندما يحتوي جدول التوجيه الخاص ب Rtr-A على المسار 172.16.1.0/24 الذي تم التعرف عليه من قبل BGP في جدول التوجيه الخاص به، يفشل إختبار الاتصال بالمضيف الصالح 172.16.1.1.

  RTR-A#show ip route 172.16.1.0
  Routing entry for 172.16.1.0/24
    Known via "bgp 1", distance 20, metric 0
    Tag 2, type external
    Last update from 10.20.20.20 00:00:16 ago
    Routing Descriptor Blocks:
    * 10.20.20.20, from 10.20.20.20, 00:00:16 ago
        Route metric is 0, traffic share count is 1
        AS Hops 1
  
  RTR-A#ping 172.16.1.1
  
  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
  .....
  Success rate is 0 percent (0/5)
  RTR-A#

فشل التوجيه المتكرر

في RTR-A، لاحظ المسار نحو نظير BGP 10.20.20.20. ويربط المسار بين النقطتين التاليتين بشكل ثابت كل دقيقة أو نحو ذلك.

RTR-A#show ip route 10.20.20.20
Routing entry for 10.20.20.20/32
  Known via "bgp 1", distance 20, metric 0
  Tag 2, type external
  Last update from 10.20.20.20 00:00:35 ago
  Routing Descriptor Blocks:
  * 10.20.20.20, from 10.20.20.20, 00:00:35 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

يتم التعرف على المسار نحو عنوان IP لنظير BGP من خلال BGP نفسه، وبالتالي فإنه يخلق فشل توجيه متكرر.

يتغير المسار بعد حوالي دقيقة إلى:

RTR-A#show ip route 10.20.20.20
Routing entry for 10.20.20.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.16.2
      Route metric is 0, traffic share count is 1

أسباب فشل التوجيه المتكرر

تصف هذه الخطوات سبب حالات فشل التوجيه المتكررة:

1. ارجع إلى تكوين RTR-A. في هذا التكوين، يتم تكوين مسار ساكن إستاتيكي 10.20.20.0/24 للإشارة إلى الخطوة التالية المتصلة مباشرة 192.168.16.2. مع هذا المسار الثابت، يتم إنشاء جلسة BGP مع RTR-B 10.20.20.20.

2. يعلن RTR-B عن مسارات BGP 172.16.1.0/24 و 10.20.20.20/32 إلى RTR-A مع عنوان IP الاحتياطي الخاص به 10.20.20.20 كالخطوة التالية.

3. يتلقى RTR-A مسارات BGP التي تم الإعلان عنها من قبل RTR-B ويحاول تثبيت 10.20.20.20/32. وهذا أكثر تحديدا من 10.20.20.0/24، والذي تم تكوينه بالفعل في Rtr-A كمسار ثابت. نظرا لأنه يفضل أطول مسار مطابقة، فيفضل 10.20.20.20/32 على 10.20.20.0/24. راجع تحديد المسار في موجهات Cisco للحصول على مزيد من المعلومات. يحتوي المسار المثبت 10.20.20.20/32 على الخطوة التالية من 10.20.20.20 (عنوان IP للتجميع من Rtr-B) في جدول التوجيه. يؤدي ذلك إلى فشل التوجيه المتكرر نظرا لأن المسار نحو 10.20.20.20/32 يحتوي على الخطوة التالية نفسها.

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

   في هذه الحالة الخاصة، يتعلم RTR-A مسار إلى الشبكة غير المتصلة مباشرة 10.20.20.20/32 مع خطوة تالية غير متصلة مباشرة من 10.20.20.20 (نفسه). يتم تشغيل خوارزمية التوجيه في فشل تكرار حلقة التوجيه لأنه غير قادر على العثور على أي واجهة متصلة مباشرة يتم إرسال الحزم الموجهة ل 10.20.20.20/32 إليها.

4. يكتشف الموجه أن هذا المسار غير المتصل مباشرة 10.20.20.20/32 لديه فشل توجيه متكرر ويسحب 10.20.20.20/32 من جدول التوجيه. وبالتالي، يتم سحب جميع المسارات التي تم التعرف عليها من قبل BGP مع عنوان IP للخطوة التالية 10.20.20.20 أيضا من جدول التوجيه.

5. يتم تكرار العملية بالكامل من الخطوة 1. يمكنك تأكيد ذلك إذا قمت بإصدار الأمر debug ip routing.

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

   RTR-A(config)#access-list 1 permit 10.20.20.20
   RTR-A(config)#access-list 1 permit 172.16.1.0 
   RTR-A(config)#end
   
   
   RTR-A#debug ip routing 1 
   IP routing debugging is on for access list 1
    
   00:29:50: RT: add 10.20.20.20/32 via 10.20.20.20, bgp metric [20/0]
   00:29:50: RT: add 172.16.1.0/24 via 10.20.20.20, bgp metric [20/0]
   00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:50: RT: del 10.20.20.20/32 via 10.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 10.20.20.20/32
   00:30:50: RT: del 172.16.1.0/24 via 10.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 172.16.1.0/24

6. إذا فشل تكرار المسار باستمرار، تظهر رسالة الخطأ هذه:

   %COMMON_FIB-SP-6-FIB_RECURSION: 10.71.124.25/32 has too many (8) levels of
   recursion during setting up switching info
   %COMMON_FIB-SP-STDBY-6-FIB_RECURSION: 10.71.124.25/32 has too many (8)
   levels of recursion during setting up switching info

   وهذا يرجع إلى عمليات إعادة إرسال TCP التي تحدث على الشبكة التي تم تمكين MPLS بها. إذا فشلت رسالة keepalive لبروتوكول BGP مرة واحدة وتم إرسالها إلى نظير BGP لأن إرتباط النقل معطل، فإن نظير BGP المجاور لا يقبل أي حزم keepalive أخرى حتى ولو أعاد بروتوكول TCP إرسال الرسالة الفاشلة من خلال مسار النسخ الاحتياطي، ويؤدي في نهاية المطاف إلى انخفاض نظير BGP مع انتهاء صلاحية وقت الانتظار. رأيت هذا إصدار فقط عندما MPLS يكون شكلت على مادة حفازة 6500 أو Cisco7600. تضمنت هذا معلومة في cisco بق id CSCsj89544 .

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

الحل

يتم شرح حل (حلول) هذه المشكلة في هذه التفاصيل.

قم بإضافة مسار ثابت محدد في Rtr-A لعنوان IP لنظير BGP (10.20.20.20 في هذه الحالة).

RTR-A#configure terminal        
Enter configuration commands, one per line.  End with CNTL/Z.
RTR-A(config)#ip route 10.20.20.20 255.255.255.255 192.168.16.2

يضمن تكوين مسار ثابت للبادئة 10.20.20.20/32 عدم تثبيت مسار BGP 10.20.20.20/32 الذي تم التعرف عليه ديناميكيا في جدول التوجيه وبالتالي تجنب حالة حلقة التوجيه المتكررة. راجع تحديد المسار في موجهات Cisco للحصول على مزيد من المعلومات.

ملاحظة: عند تكوين نظراء eBGP للوصول إلى بعضهم البعض باستخدام المسارات الافتراضية، لا تظهر جوار BGP. ويتم القيام بذلك لتجنب رفرفة المسار وحلقات تكرار التوجيه.

يؤكد إختبار الاتصال على 172.16.1.1 الحل.

RTR-A#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/40 ms

تثبيط المسار

تقوية المسار هي ميزة BGP مصممة لتقليل نشر مسارات الرفرفة عبر شبكة داخلية. القيم التي يوصى بها ISP هي القيم الافتراضية على Cisco IOS^®ولا تحتاج إلا إلى تكوين هذا الأمر لتمكينه.

router bgp <AS number>
 bgp dampening

يضبط الأمرBGP القيم الافتراضية لمعلمات التثبيط مثل HalfTime= 15 دقيقة، إعادة الاستخدام = 750، منع = 2000 و Max Suppress Time= 60. تكون هذه القيم قابلة للتكوين من قبل المستخدم، ولكن توصي Cisco بأن تظل دون تغيير.

معلومات ذات صلة

• ماذا تعني رسالة الخطأ "#٪BGP-3-INSUFCHUNKS: تجمعات قطع كبيرة غير كافية ل aspath"؟
• أستكشاف أخطاء اتصال منطقة جوار BGP وإصلاحها
• دعم توجيه IP/BGP
• الدعم الفني والتنزيلات من Cisco