استكشاف المشكلات الأساسية لبروتوكول البوابة الحدودية وإصلاحها
المحتويات
المقدمة
يصف هذا المستند كيفية استكشاف المشكلات الأكثر شيوعًا في بروتوكول البوابة الحدودية (BGP) وإصلاحها ويوفر حلولاً وإرشادات أساسية.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات أساسية خاصة لهذا المستند. معرفة بروتوكول BGP الأساسية مفيدة، يمكنك الرجوع إلى دليل تكوين BGP للحصول على مزيد من المعلومات.
المكونات المستخدمة
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة، ولكن الأوامر قابلة للتطبيق على Cisco IOS® و Cisco IOS® XE.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يصف هذا وثيقة دليل أساسي أن يتحرى المشاكل الأكثر شيوعا في بروتوكول العبارة الحدودية (BGP)، يوفر إجراءات تصحيحية، أمر/تصحيح مفيد أن يكشف السبب الرئيسي للمشاكل، وأفضل ممارسات أن يتجنب المشاكل المحتملة. تذكر دائما كل المتغيرات والسيناريوهات الممكنة لا يمكن أخذها في الاعتبار ويمكن أن يتطلب Cisco TAC تحليلا أعمق.
المخطط
أستخدم مخطط المخطط هذا كمرجع للمخرجات الواردة في هذا المستند.
السيناريوهات والمشاكل
التجاور لأسفل
إذا كانت جلسة BGP غير متصلة، قم بتشغيل العرض ip bgp all summary command. هذا يقدم الحالة الحالية للجلسة:
- إذا لم تكن جلسة العمل في حالة عدم التشغيل، يمكن أن تختلف بين وضع السكون والنشاط (يعتمد ذلك على عملية جهاز حالة محدودة).
- إذا كانت جلسة العمل متصلة، فيمكنك رؤية عدد البادئات التي تم تلقيها.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
لا يوجد اتصال
المتطلب الأول هو الاتصال بين كلا الأقران، لذلك، تم إنشاء جلسة عمل TCP على المنفذ 179. إما أنها متصلة مباشرة أو لا) ويمكنك إستخدام إختبار الاتصال. إذا تم إنشاء نظير بين واجهات الاسترجاع، فيجب إكمال إعادة الاسترجاع إلى إختبار الاتصال. إذا تم إجراء إختبار اتصال دون إسترجاع محدد كواجهة المصدر، فسيتم إستخدام عنوان IP للواجهة المادية الصادرة كعنوان IP لمصدر الحزمة بدلا من عنوان IP للموجه المسترد الخاص بالموجه.
إذا لم ينجح إختبار الاتصال، فتأمل في هذه الأسباب:
- لا يوجد نظير مسار متصل أو لا يوجد مسار على الإطلاق؛ قم بتشغيل الأمر show ip route peer_ip_address.
- مسألة الطبقة 1: يجب مراعاة الواجهة المادية أو SFP (الموصل) أو الكابل أو المشكلة الخارجية (النقل والمزود إذا كان ذلك ينطبق).
- تحقق من أي جدار حماية أو قوائم وصول يمكن أن تمنع الاتصال.
إذا نجح إختبار الاتصال:
مشكلات التكوين
- عنوان IP غير صحيح أو تم تكوينه: بالنسبة لعنوان IP غير صحيح، لا توجد مثل هذه الرسالة المعروضة، ومع ذلك، تأكد من اكتمال التكوين المناسب. لخطأ AS، يجب أن ترى رسالة مماثلة للأمر show logging .
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
تحقق من تكوين BGP على كلا النهايتين لتصحيح أرقام AS أو عنوان IP للنظير.
- معرّف موجّه مكرر:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
تحقق من معرف BGP على كلا النهايتين من خلال تشغيل الأمر show ip bgp all summary وتصحيح المشكلة المكررة. يمكن تحقيق ذلك يدويا باستخدام الأمر العام bgp router-id X.X.X.X ضمن تكوين موجه BGP. كأفضل ممارسة، تأكد من تعيين معرف الموجه يدويا على رقم فريد.
- مصدر BGP و TTL:
يتم تكوين معظم جلسات عمل iBGP عبر واجهات الاسترجاع، والتي يمكن الوصول إليها عبر بروتوكول العبارة الداخلية. يجب تعريف واجهة الاسترجاع هذه بشكل صريح على أنها المصدر، ويمكنك إكمال هذا الأمر من خلال تشغيل الأمر neighbor ip-address update-source interface-id.
لواجهات نظير eBGP المتصلة مباشرة، يتم إستخدام معظم هذه الواجهات لتقشير البيانات. هناك تحقق من برنامج Cisco IOS/Cisco IOS XE لتحقيق هذا الغرض، أو لا يحاول إنشاء جلسة عمل. إذا تمت محاولة تنفيذ eBGP من الاسترجاع إلى الاسترجاع على الموجهات المتصلة مباشرة، يمكن تعطيل هذا التحقق لمجاورة معينة في كلا الطرفين عن طريق تشغيل الأمر neighbor ip-address disable-connected-check.
ومع ذلك، إذا كانت هناك نقلات متعددة بين أقران eBGP، يلزم عدد الخطوات المناسبة، فتأكد من تكوين عنوان ip المجاور عبر متعدد الخطوات [hop-count] باستخدام عدد الخطوات الصحيح بحيث يمكن إنشاء كل جلسة. إذا لم يتم تحديد عدد الخطوات، فإن قيمة TTL الافتراضية لجلسات عمل iBGP هي 255، بينما قيمة TTL الافتراضية لجلسات عمل eBGP هي 1.
مشاكل جلسة TCP
الإجراء المفيد لاختبار المنفذ 179 هو برنامج Telnet يدوي من نظير إلى آخر:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
يشير الاتصال/الفتح المغلق أو رفض الاتصال من قبل المضيف البعيد إلى وصول الحزم إلى الطرف البعيد. بعد ذلك، تأكد من عدم وجود مشاكل في مستوى التحكم في الطرف البعيد. وإلا، إذا كانت هناك رسالة وجهة يتعذر الوصول إليها، فتحقق من أي جدار حماية أو قوائم وصول يمكن أن تحظر منفذ TCP 179، حزم BGP، أو إذا كان هناك أي فقد للحزم على المسار.
إذا كانت المصادقة هي المشكلة، فالرسائل التي يمكنك رؤيتها هي:
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
تحقق من طرق المصادقة وكلمة المرور والتكوينات ذات الصلة، ولمزيد من أستكشاف الأخطاء وإصلاحها، ارجع إلى دليل مصادقة MD5 بين مثال تكوين أقران BGP.
إذا لم تكن جلسة TCP متصلة، فاستخدم الأوامر التالية للعزل:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
حدود التجاور
إذا كانت الجلسة متقطعة، ابحث عن عرض سجل ويمكنك العثور على بعض السيناريوهات.
رفرفة الواجهة
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
يرجع سبب هذا الفشل إلى "رفرفة أسفل الواجهة." ابحث عن أي مشاكل مادية على المنفذ/SFP أو الكبل أو الانقطاع.
انتهت صلاحية مؤقت الاحتجاز
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
هذا أمر شائع ولم يستقبل الموجه/يعالج رسالة keepalive أو يحدث الرسالة قبل انتهاء صلاحية مؤقت الاحتجاز. يرسل الجهاز رسالة إعلام ويغلق الجلسة. أكثر أسباب المشاع لهذه المسألة هي:
- مشاكل الواجهة: ابحث عن أخطاء الإدخال أو عمليات إسقاط قائمة انتظار الإدخال أو المشكلات الفعلية على كلا الواجهات المتصلة بالأقران؛ يمكن إستخدام أمر show interface لهذا الغرض.
- فقدان الحزمة أثناء النقل: في بعض الأحيان يمكن إسقاط حزم Hello أثناء النقل، لضمان أن هذا هو التقاط حزمة على مستوى الواجهة:
- أستخدم التقاط الحزمة المضمنة على أجهزة Cisco IOS وCisco IOS XE.
- إذا تم رؤية الحزم على مستوى الواجهة، فتأكد من أنها تصل إلى مستوى التحكم أو EPC على مستوى التحكم أو قم بتشغيل الأمر debug bgp [vrf name] ipV4 unicast keepalives.
- وحدة المعالجة المركزية (CPU) عالية: يمكن أن تتسبب حالة وحدة المعالجة المركزية (CPU) عالية في حالات السقوط على مستوى التحكم، ويمكن أن يساعد الأمر show process cpu [sorted|history] في تحديد هذه المشاكل. استنادا إلى النظام الأساسي، يمكنك العثور على الخطوات التالية لاستكشاف الأخطاء وإصلاحها من خلال الإشارة إلى الدليل المرجعي لوحدة المعالجة المركزية (CPU).
- قضايا سياسة CoPP: تختلف منهجية أستكشاف الأخطاء وإصلاحها لكل نظام أساسي وهي خارج نطاق هذا المستند.
- عدم تطابق MTU: إذا كانت هناك إختلافات في MTU في المسار، وإذا تم حظر رسائل ICMP في المسار من المصدر إلى الوجهة، فإن PMTUD لا يعمل بشكل صحيح ويمكن أن يؤدي إلى رفرفة جلسة العمل. يتم إرسال التحديثات مع قيمة MSS التي تم التفاوض عليها ومجموعة بت DF. إذا تعذر على جهاز في المسار أو الوجهة قبول الحزم ذات وحدة الحد الأقصى للنقل (MTU) أعلى، فإنه يرسل رسالة خطأ ICMP مرة أخرى إلى مكبر صوت BGP. ينتظر موجه الوجهة ل BGP keepalive أو BGP يقوم بتحديث الحزمة إلى مؤقت التعليق الخاص بها.
يمكنك التحقق من MSS الذي تم التفاوض عليه من خلال تشغيل الأمر show ip bgp neighbors ip_address.
يمكن أن يظهر إختبار إختبار إختبار الاتصال لجار محدد باستخدام مجموعة DF إذا كان MTU صحيح على المسار:
ping 198.51.100.2 size max_seg_size df
إذا تم العثور على مشكلات وحدة الحد الأقصى للنقل (MTU)، فيجب إكمال مراجعة دقيقة للتكوين لضمان اتساق قيم وحدة الحد الأقصى للنقل (MTU) عبر الشبكة.
قضايا AFI/SAFI
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
معرف فئة العنوان (AFI) هو امتداد قدرة تمت إضافته بواسطة BGP متعدد البروتوكولات (MP-BGP.) وهو يرتبط ببروتوكول شبكة محدد، مثل IPv4 و IPv6 وما إلى ذلك. تكرار إضافي من خلال "معرف عائلة عناوين" لاحق (SAFI)، مثل البث الأحادي والبث المتعدد. يحقق MBGP هذا الفصل باستخدام سمات مسار BGP (PAs) MP_REACH_NLRI و MP_UNREACH_NLRI. يتم نقل هذه السمات داخل رسائل تحديث BGP ويتم إستخدامها لحمل معلومات إمكانية الوصول إلى الشبكة لعائلات العناوين المختلفة.
توفر لك الرسالة أرقام AFI/SAFI المسجلة من قبل ANA:
- تحقق من تكوين BGP لعائلات العناوين المخصصة على كلا الجانبين لتصحيح أي عائلات عناوين غير مرغوب فيها.
- قم بتشغيل الأمر neighbor ip-address dont-capability-negotiate على كلا الطرفين. لمزيد من المعلومات، راجع دليل القدرات غير المدعومة لخطأ نظير BGP.
تثبيت المسار وتحديده
للحصول على معلومات إضافية حول BGP وتحديد أفضل مسار، راجع خوارزمية تحديد مسار BGP الأفضل.
الخطوة التالية
لكي يتم تثبيت مسار في جدول التوجيه، يجب أن تكون الخطوة التالية قابلة للوصول، وإلا، حتى إذا كانت البادئة على جدول Loc-RIB BGP، فإنها لا تنتقل إلى RIB. كقاعدة تجنب تكرار حلقي، على Cisco IOS/Cisco IOS XE، لا يقوم iBGP بتغيير سمة الخطوة التالية حيث أنها تترك AS_PATH وحده بينما يقوم eBGP بإعادة كتابة الخطوة التالية وتمهيد AS_PATH الخاص بها.
يمكنك مراجعة الخطوة التالية بتشغيل الأمر show ip bgp [prefix] لأنها توفر الخطوة التالية وكلمة يتعذر الوصول إليها. في هذا المثال، هذه بادئة يعلن عنها بواسطة R1 عبر eBGP إلى R2 ويتعلمها بواسطة R3 من خلال اتصال iBGP من R2:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
على الإخراج، تكون الخطوة التالية هي الواجهة الصادرة ل R1، والتي لا يعرفها R3. لإصلاح هذه الحالة، يمكنك الإعلان عن الخطوة التالية عبر بروتوكول العبارة الداخلية، أو المسار الثابت، أو تشغيل الأمر المجاور ip-address next-hop-self على نظير iBGP لتعديل عنوان IP للخطوة التالية (والذي يكون متصلا مباشرة). في مثال المخطط، يجب أن يكون هذا التكوين على R2؛ المجاور باتجاه R3 (المجاور 10.0.23.3 التالي-hop-self.)
ونتيجة لذلك، تتغير الخطوة التالية (بعد مسح ip bgp 10.0.23.2 soft) إلى الواجهة المتصلة مباشرة (reachable) ويتم تثبيت البادئة:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
عطل ضلعي
يحدث ذلك عندما لا يمكن تثبيت مسار في RIB العمومي، مما يؤدي إلى فشل RIB. الأسباب الشائعة هي عندما تكون البادئة نفسها موجودة بالفعل على RIB لبروتوكول توجيه آخر ذات مسافة إدارية أقل، ولكن السبب المحدد لفشل RIB يظهر مع الأمر show ip bgp rib-failure.
حالة السباق
والمسألة الأكثر شيوعا التي لوحظت هي عندما يفضل بروتوكول العبارة الداخلية على بروتوكول eBGP في سيناريو إعادة توزيع متبادل. عند إعادة توزيع مسار بروتوكول العبارة الداخلية إلى BGP، فإنه يعتبر قد تم إنشاؤه محليا بواسطة BGP ويستلم وزنا مقداره 32768 بشكل افتراضي. يتم تعيين وزن محلي لكل البادئات المستلمة من نظير BGP بمقدار 0 بشكل افتراضي. لذلك، إذا كان يجب مقارنة البادئة نفسها، فسيتم تثبيت البادئة ذات الوزن الأعلى في جدول التوجيه استنادا إلى عملية تحديد مسار BGP، وهذا هو السبب وراء تثبيت مسار IGP على RIB.
يكمن الحل لهذه المشكلة في تعيين وزن أعلى لجميع المسارات المستلمة من نظير BGP تحت تكوين BGP للموجه:
neighbor ip-address weight 40000
مسائل أخرى
نظير BGP بطيء
إنه النظير الذي لا يمكنه مواكبة معدل إنشاء المرسل لرسائل التحديث. وهناك العديد من الأسباب التي قد تدفع أي نظير إلى عرض هذه القضية؛ وحدة معالجة مركزية (CPU) عالية في أحد الأجهزة النظيرة، حركة مرور زائدة، فقدان حركة مرور البيانات على إرتباط، مورد عرض النطاق الترددي، من بين أمور أخرى.
مشكلات الذاكرة
يستخدم BGP الذاكرة التي يتم تعيينها لعملية Cisco IOS للحفاظ على بادئات الشبكة وأفضل المسارات والسياسات وجميع التكوينات ذات الصلة للعمل بشكل صحيح. يتم عرض العمليات الإجمالية من خلال تشغيل الأمر show process memory sortedcommand:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
تجمع المعالجات هو الذاكرة المستخدمة؛ حوالي 2. 1 غيغابايت في المثال. بعد ذلك، يجب أن تنظر إلى عمود "الانتظار" لتحديد العملية الفرعية التي تحتفظ بمعظمها. ثم، يجب عليك التحقق من جلسات عمل BGP التي لديك وعدد المسارات التي يتم استقبالها والتكوين المستخدم.
خطوات شائعة لتقليل إمكانات الاحتفاظ بالذاكرة بواسطة بروتوكول BGP:
- تصفية BGP: إذا لم يكن من الضروري تلقي جدول BGP كامل، أستخدم السياسات لتصفية المسارات وتثبيت البادئات التي تحتاجها فقط.
- إعادة تكوين ناعمة: ابحث عن neighbor ip_address soft-reconfiguration الوارد ضمن تكوين BGP؛ يتيح لك هذا الأمر الاطلاع على جميع البادئات المستلمة قبل أي نهج وارد (ADJ-RIB-in). ومع ذلك، يحتاج هذا الجدول إلى حوالي نصف جدول BGP المحلي الحالي لتخزين هذه المعلومات حتى يمكنك تجنب هذا التكوين ما لم يكن مطلوبا بشكل إلزامي، أو أن البادئات الحالية قليلة.
وحدة المعالجة المركزية (CPU) المرتفعة
تستخدم الموجهات عمليات مختلفة لبروتوكول BGP لتشغيلها. للتحقق من أن عملية BGP هي سبب إستخدام وحدة المعالجة المركزية (CPU) بشكل مرتفع، قم بتشغيل الأمر show process cpu التي تم فرزها.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
هذه هي العمليات والأسباب الشائعة والخطوات العامة للتغلب على الاستخدام المرتفع لوحدة المعالجة المركزية (CPU) بسبب بروتوكول BGP:
- موجه BGP: يعمل مرة واحدة في الثانية لحماية التقارب الأسرع (هذا مؤشر ترابط مهم). فهو يقرأ رسائل تحديث BGP ويتحقق من صحة البادئات/الشبكات والسمات ويحدث جدول والسمات لكل AFI/SAFI Network/PREFIX ويقوم بحساب أفضل المسارات، من بين مهام أخرى.
فتقاد الطريق الضخم هو سيناريو شائع جدا يؤدي إلى هذا الوضع. - ماسح BGP الضوئي: عملية ذات أولوية منخفضة يتم تشغيلها كل 60 ثانية بشكل افتراضي. تتحقق هذه العملية من جدول BGP بالكامل للتحقق من إمكانية الوصول إلى الخطوة التالية وتحديث جدول BGP وفقا لذلك. يتم تشغيله من خلال قاعدة معلومات التوجيه (RIB) لأغراض إعادة التوزيع. تحقق من مقياس النظام الأساسي، نظرا لأنه تم تثبيت المزيد من البادئات والمسارات واستخدام TCAM، يلزم مزيد من الموارد.
- إدخال/إخراج BGP: يتم تشغيله عند إستلام حزم التحكم في BGP ويدير قوائم الانتظار ومعالجة حزم BGP. إذا كانت هناك حزم مفرطة مستلمة في قائمة انتظار BGP لفترة طويلة، أو إذا كانت هناك مشكلة مع TCP، فإن الموجه يظهر أعراض وحدة المعالجة المركزية العالية بسبب عملية الإدخال/الإخراج لبروتوكول BGP. عادة، يكون موجه BGP أيضا مرتفعا في هذه الحالة. راجع عدد الرسائل للتعرف على حزم النظير والتقاط لتحديد مصدر هذه الرسائل.
- بروتوكول BGP Open: العملية المستخدمة في إنشاء الدورة؛ ليست مشكلة عامة ل CPU عالية ما لم يتم تعليق جلسة في حالة مفتوحة.
- حدث BGP: مسؤول عن معالجة الخطوة التالية. ابحث عن نقاط الاتصال التالية على البادئات التي تم تلقيها.
معلومات ذات صلة
- الدعم التقني والمستندات - Cisco Systems
- دليل تكوين BGP
- مصادقة MD5 بين مثال تكوين أقران BGP
- التقاط حزمة مضمنة
- BGP المجاور يرفرف مع أستكشاف أخطاء MTU وإصلاحها
- قدرات غير مدعومة تتسبب في تعطيل نظير BGP
- خوارزمية تحديد أفضل مسار في إطار بروتوكول العبّارة الحدودية (BGP)
- فهم BGP RIB-failure والأمر BGP suppress-inactive
- استيعاب أهمية سمة مسار وزن بروتوكول العبّارة الحدودية (BGP) في سيناريوهات تجاوز فشل الشبكة
- أستخدم ميزة "النظير البطيء" لبروتوكول BGP لحل مشاكل النظير البطيء
- قم بتكوين موجهات BGP للحصول على الأداء الأمثل وتقليل إستهلاك الذاكرة
- أستكشاف أخطاء وحدة المعالجة المركزية (CPU) العالية وإصلاحها بسبب عملية ماسح BGP الضوئي أو الموجه
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
5.0 |
02-Sep-2026
|
تم تحديث التدقيق الإملائي/النحوي، وأدرجت خطوط أفقية لفصل المقاطع من أجل إمكانية القراءة، وأخطاء CCW ثابتة. |
4.0 |
19-Feb-2025
|
تقويم |
3.0 |
25-Sep-2023
|
IOS XE المحدث (شرطة تمت إزالتها) والعلامات التجارية المضافة و SEO والتنسيق. |
2.0 |
21-Feb-2023
|
إعادة الاعتماد. |
1.0 |
04-Aug-2022
|
الإصدار الأولي |
التعليقات