تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يوضح هذا المستند كيفية أستكشاف أخطاء بروتوكول العبارة الحدودية (BGP) وإصلاحها، كما يوفر حلولا وإرشادات أساسية.
لا توجد متطلبات أساسية خاصة لهذا المستند. معرفة بروتوكول BGP الأساسية مفيدة، يمكنك الرجوع إلى دليل تكوين BGP للحصول على مزيد من المعلومات.
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة، ولكن الأوامر قابلة للتطبيق على Cisco IOS® و Cisco IOS® XE.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
يصف هذا وثيقة دليل أساسي أن يتحرى المشاكل الأكثر شيوعا في بروتوكول العبارة الحدودية (BGP)، يعطي إجراءات تصحيحية، أمر/تصحيح مفيد أن يكشف السبب الجذر للمشكلة، و· تحديد أفضل ممارسة لتجنب المشاكل المحتملة. تذكر أنه لا يمكن أخذ جميع المتغيرات والسيناريوهات المحتملة في الاعتبار ويمكن أن يتطلب Cisco TAC تحليلا أعمق.
أستخدم مخطط المخطط الهيكلي هذا كمرجع للمخرجات الواردة في هذا المستند.
إذا كانت جلسة BGP معطلة ولا تظهر، قم بإصدار show 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
يمكن إستخدامها.إذا نجح إختبار الاتصال، فتأمل في ما يلي:
show logging
erasecat4000_flash:.%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
تحقق من تكوين BGP على كلا النهايتين لتصحيح AS Number أو عنوان 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. كأفضل ممارسة، تأكد من تعيين معرف الموجه يدويا على رقم فريد.
يتم تكوين معظم جلسات عمل iBGP عبر واجهات الاسترجاع التي يمكن الوصول إليها عبر بروتوكول العبارة الداخلية. يجب تعريف واجهة الاسترجاع هذه بشكل صريح كمصدر، قم بذلك باستخدام الأمر neighbor ip-address update-source interface-id
.
بالنسبة لنظير eBGP، عادة ما يتم إستخدام الواجهات المتصلة مباشرة لتقشير البيانات، وهناك التحقق من أن Cisco IOS/Cisco IOS XE يحقق هذا الغرض، أو يقوم بذلك لا تحاول حتى إنشاء جلسة عمل. إذا تم محاولة eBGP من الاسترجاع إلى الاسترجاع على الموجهات المتصلة مباشرة، يمكن تعطيل هذا التحقق لجارة معينة على كلا الطرفين عن طريق neighbor ip-address disable-connected-check
.
ومع ذلك، إذا كانت هناك نقلات متعددة بين أقران eBGP، يلزم عدد نقلات مناسب، فتأكد من neighbor ip-address ebgp-multihop [hop-count]
تم تكوينها باستخدام عدد الخطوات الصحيحة حتى يمكن إنشاء الجلسة.
إذا لم يتم تحديد عدد الخطوات، فإن قيمة TTL الافتراضية لجلسات عمل iBGP هي 255، بينما قيمة TTL الافتراضية لجلسات عمل eBGP هي 1.
الإجراء المفيد لاختبار المنفذ 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
إذا كانت الجلسة أعلى وأسفل، ابحث عن show log
و يمكنكم رؤية بعض السيناريوهات.
%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
يمكن إستخدامه لهذا الغرض. debug bgp [vrf name] ipv4 unicast keepalives
مفيد. show processes cpu [sorted|history]
يفيد في تحديد المشكلة. استنادا إلى النظام الأساسي، يمكنك العثور على الخطوة التالية لاستكشاف أخطاء وحدة المعالجة المركزية وإصلاحها باستخدام المستند المرجعي لوحدة المعالجة المركزية show ip bgp neighbors ip_address
.إختبار إختبار الاتصال لجار محدد مع مجموعة DF يمكن أن يظهر لك إذا كان MTU هذا صحيح على المسار:
ping 198.51.100.2 size max_seg_size df
إذا تم العثور على مشاكل متعلقة بوحدة الحد الأقصى للنقل (MTU)، فيجب إجراء مراجعة دقيقة للتكوين لضمان اتساق قيم وحدة الحد الأقصى للنقل (MTU) عبر الشبكة.
ملاحظة: للحصول على مزيد من المعلومات حول وحدة الحد الأقصى للنقل (MTU)، ارجع إلى نقاط الوصول المجاورة ل BGP المزودة باستكشاف أخطاء وحدة الحد الأقصى للنقل (MTU) وإصلاحها .
%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:
neighbor ip-address dont-capability-negotiate
في كلا الطرفين. للحصول على مزيد من المعلومات، ارجع إلى قدرات غير مدعومة تتسبب في تعطيل نظير BGP.للحصول على شرح أفضل حول كيفية عمل BGP، ولتحديد أفضل مسار، ارجع إلى خوارزمية تحديد أفضل مسار BGP.
لكي يتم تثبيت مسار في جدول التوجيه الخاص بنا، يلزم الوصول إلى الخطوة التالية، وإلا، حتى إذا كانت البادئة على جدول BGP الخاص ب Loc-RIB، فإنها لا تصل إلى 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. in order to أصلحت هذا حالة إما أنت يستطيع أعلنت التالي جنجل عن طريق IGP، طريق ساكن إستاتيكي أو استعملت ال
neighbor ip-address next-hop-self
أمر على نظير iBGP لتعديل عنوان IP للخطوة التالية (وهو متصل مباشرة). على مثال المخطط، يجب أن يكون هذا التكوين على R2، والجار باتجاه R3 (المجاور 10.0.23.3 التالي-hop-self).
ونتيجة لذلك، تتغير الخطوة التالية (بعد a clear ip bgp 10.0.23.2 soft
) إلى الواجهة المتصلة مباشرة (يمكن الوصول إليها) ويتم تثبيت البادئة.
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. للحصول على شرح أكثر عمقا، يمكنك مراجعة هذا الارتباط:
ملاحظة: يمكنك تحديد هذه المشكلة وتصحيحها كما هو موضح في فهم فشل BGP والأمر BGP suppress-inactive.
والمسألة الأكثر شيوعا التي لوحظت هي عندما يفضل بروتوكول العبارة الداخلية على بروتوكول eBGP في سيناريو إعادة التوزيع المتبادل. عندما تتم إعادة توزيع مسار بروتوكول العبارة الداخلية إلى BGP، فإنه يعتبر قد تم إنشاؤه محليا بواسطة BGP ويحصل على وزن 32768 بشكل افتراضي. يتم تعيين وزن محلي لكل البادئات المستلمة من نظير BGP بمقدار 0 بشكل افتراضي. لذلك، إذا كان يجب مقارنة البادئة نفسها، يتم تثبيت البادئة ذات الوزن الأعلى في جدول التوجيه استنادا إلى عملية تحديد مسار BGP الأفضل ولهذا السبب يتم تثبيت مسار IGP على RIB.
الحل لهذه المشكلة، هو تعيين وزن أعلى لجميع المسارات المستلمة من نظير BGP تحت تكوين BGP للموجه:
neighbor ip-address weight 40000
ملاحظة: للحصول على شرح تفصيلي، ارجع إلى فهم أهمية سمة مسار وزن BGP في سيناريوهات تجاوز فشل الشبكة.
إنه النظير الذي لا يمكنه مواكبة معدل إنشاء المرسل لرسائل التحديث. وهناك العديد من الأسباب التي تجعل النظير يعرض هذه المشكلة؛ إرتفاع وحدة المعالجة المركزية (CPU) في أحد الأجهزة النظيرة، أو زيادة حركة المرور أو فقدان حركة المرور على إرتباط، أو مورد النطاق الترددي، من بين أسباب أخرى.
ملاحظة: للمساعدة في تحديد مشاكل النظراء البطيئين وتصحيحها، ارجع إلى إستخدام ميزة "النظير البطيء" لبروتوكول BGP لحل مشاكل النظير البطيء.
يستخدم BGP الذاكرة التي يتم تعيينها لعملية Cisco IOS للحفاظ على بادئات الشبكة وأفضل المسارات والسياسات وجميع التكوين المرتبط بها للعمل بشكل صحيح. العمليات الشاملة تظهر مع القيادة show processes memory sorted
:
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 للحصول على الأداء الأمثل وتقليل إستهلاك الذاكرة.
تستخدم الموجهات عمليات مختلفة لبروتوكول BGP لتشغيلها. للتحقق من أن عملية BGP هي سبب إستخدام وحدة المعالجة المركزية (CPU) بشكل كبير، أستخدم show process cpu sorted
erasecat4000_flash:.
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:
ملاحظة: للحصول على مزيد من المعلومات حول كيفية أستكشاف أخطاء هذه العمليتين وإصلاحها، ارجع إلى أستكشاف أخطاء وحدة المعالجة المركزية (CPU) الفائقة وإصلاحها والتي تتسبب فيها عملية ماسح BGP الضوئي أو الموجه.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
3.0 |
25-Sep-2023 |
IOS XE المحدث (شرطة تمت إزالتها) والعلامات التجارية المضافة و SEO والتنسيق. |
2.0 |
21-Feb-2023 |
إعادة الاعتماد. |
1.0 |
04-Aug-2022 |
الإصدار الأولي |