أستكشاف أخطاء وحدة المعالجة المركزية (CPU) العالية وإصلاحها بسبب عملية ماسح BGP الضوئي أو الموجه

ملاحظة: يمكن أن تكون وحدة المعالجة المركزية (CPU) عالية على الجهاز بسبب عدم إستقرار جدول BGP. يحدث ذلك إذا كان الموجه يستقبل نسختين من جدول التوجيه، واحدة من eBGP peering مع ISP والأخرى من iBGP peering في الشبكة. والسبب الجذري لذلك هو مقدار الذاكرة الموجودة على الجهاز. توصي Cisco بذاكرة وصول عشوائي (RAM) واحدة كحد أدنى لنسخة واحدة من جدول توجيه الإنترنت. للالتفاف على عدم الاستقرار هذا، قم بزيادة ذاكرة الوصول العشوائي (RAM) على الجهاز أو تصفية البادئات حتى يتم إعفاء جدول BGP والذاكرة المشغولة به.

تحسينات الأداء

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

• تم قبول كافة المسارات.

• تم تثبيت جميع المسارات في جدول التوجيه.

• يساوي إصدار الجدول لجميع النظراء إصدار الجدول لجدول BGP.

• InQ و OutQ لجميع الأقران صفر.

يصف هذا القسم بعض تحسينات أداء Cisco IOS لتقليل وقت تقارب BGP، مما ينتج عنه تقليل حالة وحدة المعالجة المركزية (CPU) المرتفعة بسبب عملية BGP.

قائمة الانتظار لاتصالات نظير TCP

يقوم BGP الآن بوضع البيانات في قائمة انتظار قوية من BGP OutQ إلى مأخذ توصيل TCP لكل نظير حتى يتم إستنزاف OutQs بالكامل. ونظرا لأن بروتوكول BGP يرسل الآن بمعدل أسرع، فإن عمليات التقارب BGP تتم بسرعة أكبر.

مجموعات نظير BGP

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

مسار وحدة الحد الأقصى للنقل (MTU) وأمر ip tcp path-mtu-discovery

يتم تقييد جميع جلسات عمل TCP بحد على عدد وحدات البايت التي يمكن نقلها في حزمة واحدة. هذا الحد، المعروف باسم الحد الأقصى لحجم المقطع (MSS)، هو 536 بايت بشكل افتراضي. بمعنى آخر، يقوم TCP بتقسيم الحزم في قائمة انتظار الإرسال إلى 536 مجموعة بايت قبل أن يقوم بتمرير الحزم إلى طبقة IP. إستخدام جيران show ip bgp | تضمين أمر الحد الأقصى للبيانات لعرض MSS الخاص بنظراء BGP:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

تتمثل ميزة MSS التي تبلغ سرعتها 536 بايت في أنه من غير المحتمل تجزئة الحزم عند جهاز IP على المسار إلى الوجهة نظرا لأن معظم الارتباطات تستخدم وحدة الحد الأقصى للنقل (MTU) بسعة لا تقل عن 1500 بايت. غير المؤثر هو أن الحزم الصغيرة تزيد من مقدار عرض النطاق الترددي المستخدم لنقل النفقات العامة. ونظرا لأن بروتوكول BGP يقوم بإنشاء اتصال TCP لجميع الأجهزة النظيرة، فإن بروتوكول MSS سعة 536 بايت يؤثر على أوقات تقارب BGP.

الحل هو تمكين ميزة وحدة الحد الأقصى للنقل (MTU) الخاصة بالمسار (PMTU) باستخدام الأمر ip tcp path-mtu-discovery. يمكنك إستخدام هذه الميزة لتحديد مدى كبر قيمة MSS بشكل ديناميكي، وفي الوقت نفسه، لا يمكنك إنشاء الحزم التي يلزم تجزئتها. تسمح PMTU ل TCP بتحديد أصغر حجم MTU بين جميع الارتباطات في جلسة عمل TCP. بعد ذلك يستخدم TCP قيمة MTU هذه، مع خصم مساحة رؤوس IP و TCP، كخوادم MSS لجلسة العمل. إذا كانت جلسة TCP تجتاز مقاطع الإيثرنت فقط، فإن MSS يكون 1460 بايت. إذا كان يجتاز الحزمة عبر مقاطع SONET (POS) فقط، فعندئذ يكون MSS هو 4430 بايت. تعمل الزيادة في عدد وحدات التخزين متعددة الطبقات (MSS) من 536 إلى 1460 أو 4430 بايت على تقليل المصروفات الإضافية لبروتوكول TCP/IP، مما يساعد على تقارب BGP بشكل أسرع.

بعد تمكين PMTU، أستخدم مرة أخرى جيران show ip bgp | تضمين أمر الحد الأقصى للبيانات للاطلاع على قيمة MSS لكل نظير:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

زيادة قوائم انتظار إدخال الواجهة

إذا أعلن BGP عن آلاف الموجهات إلى العديد من النظراء، فيجب على TCP إرسال آلاف الحزم في فترة قصيرة. يتلقى نظراء BGP هذه الحزم ويرسل إقرارات TCP إلى مكبر صوت BGP الذي يعلن، والذي يتسبب في تلقي مكبر صوت BGP طوفان من حزم TCP ACKs في فترة زمنية قصيرة. إذا وصلت وحدات التحكم في الوصول إلى معدل مرتفع جدا بالنسبة لمعالج التوجيه، فستتم إعادة الحزم إلى قوائم انتظار الواجهة الواردة. بشكل افتراضي، تستخدم واجهات الموجهات حجم قائمة انتظار الإدخال من 75 حزمة. بالإضافة إلى ذلك، تستخدم حزم التحكم الخاصة مثل تحديثات BGP قائمة انتظار خاصة مع تجاهل الحزمة الانتقائي (SPD). تحمل قائمة الانتظار الخاصة هذه 100 حزمة. عند تقارب BGP، يمكن أن تملأ حزم TCP السريعة نقاط التخزين المؤقت للإدخال البالغ عددها 175 نقطة ويجب إسقاط الحزم الجديدة التي تصل. في الموجهات ذات أقران BGP 15 أو أكثر وتبادل جدول توجيه الإنترنت الكامل، يمكن رؤية أكثر من 10000 عملية إسقاط لكل واجهة في الدقيقة. هنا مثال إخراج من موجه بعد 15 دقيقة من إعادة التمهيد:

Router#show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

إذا قمت بزيادة عمق قائمة انتظار إدخال الواجهة (باستخدام الأمر hold-queue في ) فإنها تساعد على تقليل عدد رسائل TCP ACK التي تم إسقاطها، والتي تقلل مقدار ما يجب أن يقوم به بروتوكول BGP للعمل للتجميع. عادة، تقوم القيمة 1000 بحل المشاكل التي تتسبب فيها حالات إسقاط قائمة انتظار الإدخال.

ملاحظة: يمكن أن يؤدي إستخدام هذا بشكل واعي كتزايد في قائمة انتظار الإدخال إلى إضافة بعض التأخير.

تحسينات إضافية في برنامج Cisco IOS

يتضمن Cisco IOS العديد من عمليات التحسين لكود مجموعة نظير BGP لتحسين تعبئة التحديث والنسخ المتماثل. قبل مراجعة هذه التحسينات، راجع تعبئة التحديث والنسخ المتماثل بمزيد من التفاصيل.

يتكون تحديث BGP من مجموعة من السمات (مثل MED = 50 و LOCAL_pref = 120) وقائمة من بادئات معلومات إمكانية الوصول إلى طبقة الشبكة (NLRI) التي تتشارك في هذه المجموعة من السمات. وكلما زاد عدد بادئات NLRI التي يمكن أن يسرد BGP في تحديث واحد، زادت سرعة تقارب BGP منذ تقليل المصروفات العامة (مثل رؤوس IP و TCP و BGP). يشير تحديث التعبئة إلى تعبئة NLRI في تحديثات BGP. على سبيل المثال، إذا كان جدول BGP يحتوي على 100000 مسار مع 15000 مجموعة سمات فريدة، يحتاج BGP إلى إرسال 15000 تحديث فقط إذا تم تعبئة NLRI بفعالية 100 بالمائة.

ملاحظة: تعني فعالية التعبئة بنسبة صفر في المائة أن بروتوكول BGP سيحتاج إلى إرسال 100000 تحديث في هذه البيئة.

أستخدم الأمر show ip bgp peer-group لعرض كفاءة تحديثات BGP.

إذا كان عضو مجموعة نظير في حالة مزامنة، فإن موجه BGP يأخذ رسالة تحديث منسقة لزعيم مجموعة النظير ويقوم بنسخها للعضو. يعد تكرار تحديث عضو مجموعة نظير أكثر فعالية من إعادة تنسيق التحديث. على سبيل المثال، افترض أن مجموعة نظيرة تحتوي على 20 عضوا وأن جميع الأعضاء يحتاجون إلى تلقي 100 رسالة BGP. ويعني النسخ المتماثل بنسبة 100 في المائة أن موجه BGP يقوم بتنسيق 100 رسالة لقائد مجموعة النظير وينسخ هذه الرسائل إلى أعضاء مجموعة النظير ال 19 الآخرين. لتأكيد تحسينات النسخ المتماثل، قارن عدد الرسائل المنسوخة نسخا متماثلا بعدد الرسائل المنسقة، كما هو موضح بواسطة الأمر show ip bgp peer-group. تحدث هذه التحسينات فارقا كبيرا في أوقات التقارب وتسمح لبروتوكول بوابة الحدود (BGP) بدعم المزيد من الأقران.

على سبيل المثال، أستخدم الأمر show ip bgp peer-group للتحقق من كفاءة تحديث التعبئة والتكرار. والمخرج التالي هو من إختبار تقارب مع 6 مجموعات نظيرة و 20 نظير في كل من مجموعات الأقران الخمس الأولى (نظراء eBGP) و 100 نظير في مجموعة الأقران السادسة (نظراء BGP (iBGP) الداخليين). كما أن جدول BGP المستخدم كان يحتوي على 36250 مجموعة سمات.

إخراج النموذج التالي لمجموعة نظيرة show ip bgp | يتضمن أمر منسوخ نسخا متماثلا على موجه يعمل بنظام التشغيل Cisco IOS 12.0(18)S يعرض هذه المعلومات:

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

لحساب معدل النسخ المتماثل لكل مجموعة نظير، قم بقسمة عدد التحديثات التي تم نسخها نسخا متماثلا على عدد التحديثات المنسقة:

1668500/836500 = 1.99 145000/105000 = 1.38 184500/660500 = 2.79 184900/656000 = 2.81 2003750/501250 = 3.99121111111111111111111111111111111111111114111111444445/2476715 = 4.89

• إذا تم نسخ BGP بشكل مثالي، فسيكون لكل مجموعة نظير من مجموعات eBGP معدل نسخ يبلغ 19 نظرا لوجود 20 نظير في مجموعة النظير. تم تنسيق التحديث لمؤشر مجموعة الأقران ثم تم نسخه نسخا متماثلا إلى النظراء ال 19 الآخرين. وهذا يوفر معدل نسخ مثالي يبلغ 19. سيكون معدل النسخ المثالي لمجموعة نظراء iBGP هو 99 نظرا لوجود 100 نظير.
• إذا قام BGP بحزم التحديثات بشكل مثالي، فسيكون هناك 36،250 تحديث مهيأة فقط. تحتاج فقط إلى إنشاء 36250 تحديث لكل مجموعة نظير لأن هذا هو عدد مجموعات السمات في جدول BGP. تقوم مجموعة نظير iBGP وحدها بتنسيق ما يقرب من 2،500،000 تحديث بينما تقوم كل مجموعة نظيرة eBGP بإنشاء أي مكان من 500،000 إلى 1،000،000 تحديث.

على موجه يعمل بنظام التشغيل Cisco IOS 12.0(19)S، يتم إستخدام مجموعة نظيرة ip bgp | يتضمن الأمر copyEded يوفر هذه المعلومات:

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

ملاحظة: تحديث التعبئة هو الأمثل. تم تنسيق 36250 تحديث لكل مجموعة نظيرة بالضبط. 688750/36250 = 19 68750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 358750/36250 = 99

ملاحظة: النسخ المتماثل للتحديث مثالي أيضا.

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

أستخدم هذه الإجراءات لاستكشاف أخطاء وحدة المعالجة المركزية (CPU) العالية وإصلاحها بسبب ماسح BGP الضوئي أو موجه BGP:

• تجميع معلومات حول مخطط BGP الخاص بك. حدد عدد نظراء BGP وعدد الموجهات التي يتم الإعلان عنها بواسطة كل نظير. هل مدة حالة وحدة المعالجة المركزية (CPU) المرتفعة معقولة استنادا إلى بيئتك؟

• حدد وقت حدوث إرتفاع في وحدة المعالجة المركزية (CPU). هل يتزامن مع المشي المنتظم لجدول بوابة الحدود؟

• هل اتبعت وحدة المعالجة المركزية (CPU) العالية رفرفة واجهة؟ أنت يستطيع استعملت أمر show ip bgp دامغ flap-statistics أمر إن مكنت دامزة يكون.

• يتم الآن إختبار الاتصال من خلال الموجه ثم إختبار الاتصال من الموجه. يتم التعامل مع أصداء بروتوكول ICMP كعملية ذات أولوية منخفضة. يشرح DocumentUnderstanding الأمر ping و traceroute هذا بمزيد من التفاصيل. تأكد من عدم تأثر إعادة التوجيه المنتظمة.

• ستحتاج إلى التأكد من أنه يمكن للحزم اتباع مسار إعادة توجيه سريع عند التحقق من تمكين التحويل السريع و/أو إعادة التوجيه السريع على الواجهات الواردة والصادرة. تأكد من أنك لا ترى الأمر no ip route-cache cef على الواجهة أو الأمر no ip cef على التكوين العام. لتمكين CEF في وضع التكوين العام، أستخدم الأمر ip cef.

• تحقق من مقياس النظام الأساسي لأنه، في معظم الحالات، يرجع ذلك إلى وجود جهاز محمل بشكل زائد يؤدي إلى مثل هذه المواقف. تأكد أيضا من وجود مساحة ذاكرة قابلة للتوجيه (TCAM) مناسبة للمحتوى الثالث متوفرة على الموجه.

• تحقق من وجود ذاكرة كافية على الموجه. طبقا للتوصية، قم بتعيين 1 غيغابايت كحد أدنى من DRAM إلى مساحة Cisco IOS لكل نظير BGP الذي يرسل جدول توجيه الإنترنت الكامل. مساحة DRAM المذكورة هنا هي الذاكرة المطلوبة فقط لبروتوكول BGP. يمكن أن تتطلب الميزات الأخرى التي يتم تشغيلها على الموجه مساحة إضافية.

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

• صفحة دعم توجيه IP
• الدعم الفني - Cisco Systems