المحتويات

المقدمة

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

المتطلبات

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

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

الاصطلاحات

المشكلة

الأعراض

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

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

الحل

تثبيط المسار

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

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء توجيه بروتوكول العبارة الحدودية (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

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

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

- ماذا تعني رسالة الخطأ "#٪BGP-3-INSUFCHUNKS: تجمعات قطع كبيرة غير كافية ل aspath"؟

- لماذا تقوم جارات BGP بالتبديل بين الحالات الخاملة والمتصلة والنشطة؟

- دعم توجيه IP/BGP

- الدعم التقني والتنزيلات من Cisco