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

المقدمة

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

تمت المساهمة من قبل ويليام شو، مهندس TAC من Cisco.

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

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• BGP
• TCP
• LPTS ل IOS XR

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

تستند المعلومات الواردة في هذا المستند إلى أنظمة ASR9000 (موجه خدمات التجميع) الأساسية.

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

المشكلة

عندما يشكل أنت eBGP، الجلسة يستطيع كنت ب التصق في نشط إلى أجل غير مسمى إن:

• لا يوجد أمر update-source تم تكوينه
• هناك تغيير في الطبولوجيا يتسبب في أن تأخذ حركة المرور مسار مختلف

تظهر هذه الأعراض عند حدوث هذه المشكلة:

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

Feb 18 09:32:15.393 tcp/error 0/RSP0/CPU0 t9  Lpts set the drop flag for 179 -> 5368, drop packet (pak 0xb1cf80f3) and send a RST

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

هناك بعض التحسينات التي تم إجراؤها لبروتوكول BGP. ويغطي هذان السيناريوهان المزيد من التفاصيل حول هذه المسألة.

ملاحظة: عادة ما لا يبلغ iBGP (بروتوكول العبارة الحدودية الداخلية) هذه المشكلة نظرا لأنه يتم إستخدام update-source دائما.

السيناريو 1 - EBGP متعدد الخطوات مع تغيير المخطط

يمكنك إنشاء جلسات عمل eBGP متعددة الخطوات بين ASR9K-1 و ASR9K-3. عنوان IP للنظير هو 172.123.1.1 و 172.123.2.2 في الواجهات المادية. لا يوجد أمر update-source تم تكوينه. مع الطبولوجيا الحالية، يبقى الجلسة في الحالة نشط. هذا متوقع لأن كلا الموجهين سيستخدم الواجهة في الشبكة الفرعية 172.123.3.0/24 كواجهة مخرج.

يمكنك إيقاف تشغيل الارتباط المباشر بين ASR9K-1 و ASR9K-3. بعد ذلك، يمكن الوصول إلى عناوين النظير عبر ASR9K-2 وهو الارتباط متعدد الخطوات، وبالتالي يكون إختبار الاتصال ناجحا. تطابق عناوين IP للمصدر في كلا النهايتين، ولكن جلسة BGP لا تزال في حالة نشطة.

عند تكوين جيران BGP، يتم إنشاء إدخالات LPTS وفقا لجدول (إعادة التوجيه السريع من Cisco) CEF. بالنسبة ل ASR9K-1، يمكن الوصول إلى عنوان IP 172.123.2.2 عبر الشبكة الفرعية 172.123.3.0/24. ولذلك، فإن القيودات ذات الصلة في LPTS متاحة. وهو يسمح لجارة BGP بتوصيل المنفذ 179 بعنوان IP المحلي 172.123.3.1. بما أنه يحاول بدء جلسة TCP من المنفذ المحلي 26036، فيمكنك رؤية إدخال آخر له.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.2.2
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,26036 172.123.2.2,179

هذا المخرج هو نفسه في ASR9K-3.

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,11126 172.123.1.1,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.1.1

عندما ينقطع الارتباط بين ASR9K-1 و ASR9K-3، يمكن الوصول إلى الأقران عبر مسار ASR9K-2 باستخدام عنوان IP لمصدر محلي جديد. ولكن تغيير الطبولوجيا لا يؤدي إلى تحديث LPTS. يبقى الإدخال الأصلي مع المنفذ 179 مع عنوان IP المحلي الأصلي. وهذا يمنع الموجه من السماح بإدخال طلبات TCP إلى عنوان IP المحلي الجديد. وبالتالي، تظل جلسة BGP في كلا النهايتين عالقة في حالة نشطة.

السيناريو 2 - eBGP مع تغيير عنوان المصدر للتحديث

يمكنك نشر جلسة عمل eBGP بين ASR9K-1 و ASR9K-3. عناوين IP هي 172.123.3.1 و 172.123.3.2. وفقا للخطة الجديدة، قمت بتغيير عناوين IP إلى 172.123.3.111 و 172.123.3.222. إن يشكل أنت eBGP أولا وبعد ذلك يحدث العنوان في القارن، ال eBGP جلسة ب التصق في حالة نشط.

السبب هو نفسه السيناريو 1. بمجرد تكوين جلسة عمل eBGP، يتم إنشاء إدخالات LPTS وفقا لواجهة مخرج محلي عند تلك النقطة.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.3.222
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,24067 172.123.3.222,179

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,45091 172.123.3.111,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.3.111

على الرغم من تغيير عناوين IP المحلية لاحقا، إلا أنه لا يتم تحديث إدخالات LPTS. تم حظر طلب TCP وتظل الجلسة عالقة في حالة نشطة إلى الأبد.

الحل

لحل هذه المشكلة، تحتاج إلى تشغيل تحديث ل LPTS. أنت يستطيع استعملت هذا خيار أن يحل الإصدار:

• إغلاق/عدم إغلاق جيران BGP
• إعادة تكوين جيران BGP
• إعادة تشغيل بروتوكول بوابة الحدود (BGP) للعملية
• قم بتكوين مصدر التحديث في كلا النهايتين مما يمكن أن يمنع هذه المشكلة.

تحسين في إصدار XR

هناك بعض التحسينات في إصدارات IOS XR الأخيرة.

CSCuz51103 - علقت جلسة BGP في الوضع النشط

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

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

وهناك تحسين آخر لهذا الوضع من الإصدار XR 6.2.1.

CSCvb15128-BGP جلسة ب نشط بينما المسحاج تخديد يتلقى خامل BGP أسلوب يشكل

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

• ASR9000/XR: خدمات نقل الحزم المحلية (LPTS) CoPP(تنظيم مستوى التحكم)
• دليل التكوين: تنفيذ LPTS
• دليل التكوين: تنفيذ بروتوكول بوابة الحدود (BGP)

---