تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند المساهمين الرئيسيين في الحد الأقصى لحجم يمكن لعاكس المسار (RR) لبروتوكول العبارة الحدودية (BGP) تحقيق إرشادات حول مراقبة أداء BGP RR.
لا يكون BGP RR واسع النطاق عادة في مسار إعادة التوجيه للحزم التي تحمل الخدمات المقدمة من قبل موفر خدمة الإنترنت. وبالتالي، فإن متطلبات الأجهزة لموجه BGP والموجهات التي يتم غالبا إعادة توجيه الحزم في مسار البيانات مختلفة. يتم تصميم الموجهات القياسية باستخدام عنصر إعادة توجيه مسار بيانات فعال وعنصر تحكم مسار متوسط نسبيا. يقوم BGP RR بتنفيذ جميع مهامه في خطة تحكم.
ضمن مجموعة المنتجات Cisco IOS® XR، يمكنك الاختيار بين 3 معايير لمنصات الأجهزة/البرامج لدور BGP RR:
الموجه Physical IOS XR من Cisco |
جهاز Cisco IOS XRv 9000 |
الموجه Cisco IOS XRv 9000 Router (المعروف أيضا XRv9k) |
|
|
|
اعتبارا من هذه الكتابة، يعد جهاز XRv9k هو الاختيار الأمثل للنظام الأساسي ل BGP RR لأنه يوفر أعلى سعة على مستوى التحكم مع الحد الأقصى للأداء.
النطاق المدعوم لوحدات مستوى البيانات سهل نسبيا التعبير عنه لأن أداء عنصر مسار البيانات نادرا ما يعتمد على المقياس. على سبيل المثال، يأخذ بحث TCAM نفس الوقت بغض النظر عن عدد إدخالات TCAM النشطة.
غالبا ما يكون النطاق المدعوم لكيانات مستوى التحكم أكثر تعقيدا نظرا لترابط النطاق والأداء. ضع في اعتبارك مراجعة BGP مع مسارات بطول 1 متر. يعتمد العمل الذي يجب أن تقوم به عملية BGP للحفاظ على جدول BGP هذا على:
وعادة يكون عدد نظراء BGP هو الأول، ولسوء الحظ، غالبا الشيء الوحيد الذي يتبادر إلى الذهن عند النظر في مقياس BGP. في حين لا يمكن تمثيل مقياس BGP المدعوم دون ذكر عدد نظراء BGP، فإنه ليس العامل الأكثر أهمية. وهناك العديد من الجوانب الأخرى التي لا تقل أهمية.
يعد نوع مجموعة العناوين (AF) عاملا مهما في اعتبارات أداء بروتوكول BGP لأنه في عمليات النشر النموذجية يؤثر على حجم مسار واحد. إن عدد مسارات IPv4 التي يمكن حزمها في مقطع TCP واحد أعلى بشكل ملحوظ من عدد مسارات VPNv4. وبالتالي بالنسبة لنفس نطاق تغييرات جدول BGP، يكون ل IPv4 BGP RR عمل أقل للقيام به مقارنة ب VPNv4 BGP RR. ومن الواضح أنه في عمليات النشر التي يضاف فيها عدد كبير من المجتمعات المحلية إلى كل طريق، يصبح الفرق بين القوات المسلحة أقل أهمية، ولكن حجم طريق واحد يصبح حينئذ أكبر ويتطلب النظر.
تقوم عملية BGP بإعداد تحديث واحد لجميع أعضاء مجموعة التحديث نفسها. ثم تقوم عملية TCP بتقسيم بيانات التحديث إلى عدد مطلوب من شرائح TCP (حسب TCP MSS) تجاه كل عضو في مجموعة التحديث. يمكنك رؤية مجموعات التحديث النشطة وأعضائها باستخدام الأمرshow bgp update-group. يمكنك التأثير على أي النظراء أو عددهم أعضاء في مجموعة تحديث عن طريق إنشاء سياسة صادرة مشتركة لمجموعة النظراء الذين تريد أن يكونوا في مجموعة التحديث نفسها. يمكن أن يؤدي تحديث واحد يتم إرساله من قبل BGP RR إلى عدد كبير من عملاء BGP RR إلى إطلاق دفعة من حزم TCP التي يمكن إسقاطها في مكون خدمة نقل الحزم المحلية (LPTS) من موجهات Cisco IOS XR.
تعقيد RPLs (سياسات المسار)
يؤثر تعقيد سياسات المسار المستخدمة من قبل BGP على أداء عملية BGP. يجب تقييم كل مسار تم إستلامه أو إرساله مقابل سياسة المسار التي تم تكوينها. وتتطلب السياسة الطويلة جدا إستخدام دورات عديدة من وحدات المعالجة المركزية (CPU) على هذا الإجراء. تعد سياسة المسار التي تتضمن تعبيرا منتظما مهمة بشكل خاص في المعالجة. يساعدك التعبير العادي على التعبير عن سياسة المسار في عدد أقل من الخطوط ولكنه يتطلب دورات وحدة المعالجة المركزية (CPU) أكثر أثناء المعالجة من سياسة المسار المكافئة التي لا تستخدم التعبير العادي.
معدل تكرار التحديثات
ولتكرار التحديثات تأثير مهم على نطاق بروتوكول بوابة الحدود (BGP). غالبا ما يكون من الصعب التنبؤ بعدد التحديثات. يمكنك التأثير على معدل تكرار التحديثات باستخدام الأمر advertising-interval"، والذي يحدد الحد الأدنى للفاصل الزمني بين إرسال تحديثات توجيه BGP). القيمة الافتراضية تجاه نظائر iBGP هي 0 ثوان و 30 نحو نظائر eBGP هي 30 ثانية.
وحدة الحد الأقصى للنقل (MTU) للواجهة/المسار عبر بروتوكول TCP MSS
يمكن أن يؤدي تقسيم تحديث إلى العديد من مقاطع TCP إلى فرض الكثير من الضغوط على موارد عملية TCP في بيئة تردد ذات نطاق ترددي عال وتحديثات عالية. كما أن وحدة الحد الأقصى للنقل (MTU) الأكبر حجما وبروتوكول TCP MSS الأكبر هما الأفضل لأداء بروتوكول BGP وبروتوكول TCP.
NSR على موجهات RP المزدوجة
تعد NSR ميزة رائعة للتكرار، ولكنها تؤثر على أداء BGP. على موجهات Cisco IOS XR، يتلقى كلا RPs في وقت واحد كل تحديث BGP مباشرة من وحدة معالجة الرسومات (NPU) على بطاقة الخط المدخل، مما يعني أن RP النشط لا يحتاج إلى قضاء وقت على نسخ التحديث إلى RP في وضع الاستعداد. ومع ذلك، يجب إرسال كل تحديث تم إنشاؤه بواسطة RP النشط إلى RP الاحتياطي ومن هناك إلى نظير BGP. وهذا يسمح ل RP الاحتياطي بأن يكون دائما محدثا على التسلسل وأرقام الإقرار ولكنه يكون له تأثير على أداء BGP الإجمالي. ولهذا السبب يوصى بأن يكون موجه BGP RR هو موجه RP أحادي.
الأقران البطيئون
يمكن أن يبطئ النظير البطيء التحديثات تجاه جميع أعضاء مجموعة التحديث لأنه يجب أن تحتفظ عملية BGP بالتحديث في ذاكرتها حتى يعترف به جميع النظراء. إذا كنت تعرف أن بعض الأجهزة النظيرة بطيئة جدا (على سبيل المثال، الموجهات في جزء قديم من الشبكة)، فقم بفصلها من الأمام في مجموعة تحديث. افتراضيا، يبلغ Cisco IOS XR عن نظير بطيء عبر رسالة syslog. يمكنك إنشاء نظائر بطيئة ثابتة (لا تشارك مجموعة التحديث أبدا مع الآخرين) أو ضبط سلوك النظير البطيء الديناميكي بدقة باستخدام أمر تكوين BGP
slow-peer في وضع التكوين العام أو وضع التكوين لكل جار. يمكن العثور على قراءة أخرى جيدة على هذا في تقارب BGP البطيء لاستكشاف أخطاء هذه العملية وإصلاحها بسبب نهج المسار دون الأمثل على IOS-XR على بوابة Cisco xrdocs.io.
تأخير المشغل Nexthop
إذا تم تغيير نقلات BGP التالية المتعددة في فترة زمنية قصيرة وتم تكوين قيمة تأخر مشغل مشغل الخطوة الحرجة التالية التي تبلغ صفر في عائلة عناوين (AF) بعدد كبير من المسارات، فيجب تنفيذ المشي الكامل ل AF على كل حدث تغيير في الخطوة التالية. تزيد الخطوات المتكررة في هذه الخطة من وقت التقارب في معالجة الأسر ذات قيم تأخير البدء الحرجة المترابطة الأدنى. يمكنك رؤية قيم تأخير مشغل الخطوة التالية عن طريق تشغيل الأمر "show bgp all nexthops all".
مثال على مقياس BGP RR متعدد الأبعاد الذي تم التحقق من صحته
تعتمد نتائج المقياس متعدد الأبعاد، خاصة لميزات مستوى التحكم، تعتمد بشكل كبير على بيئة الاختبار المحددة. يمكن أن تختلف نتائج الاختبار بشكل ملحوظ إذا تم تغيير بعض المعلمات.
بارامتر |
القيمة |
القيمة |
المنصة |
جهاز XRv9k (يستند إلى UCS M5) |
ASR9902 |
IOS XR الإصدار |
7.5.2 + SMU umbrella لمعرف تصحيح الأخطاء من Cisco CSCwf09600 . (يتم دمج مكونات هذه الوحدة الصغيرة ومتوسطة الحجم (SMU) المظلة في الإصدار 7.9.2 من Cisco IOS XR والإصدارات الأحدث) |
7.11.2 |
أندادا |
VPNv4 eBGP: 2500 VPNv4 iBGP: 1700 |
VPNv4 iBGP: 2000 |
مسارات بروتوكول بوابة الحدود (BGP) |
لكل جلسة: 200 المجموع: 400 ألف المسارات لكل مسار: 1 |
لكل جلسة: 750 VPNv4: 1.36M VPNv6: 150 كيلو بروتوكول IPv4: بسرعة 950 ألف لفة في الدقيقة بروتوكول IPv6: بسرعة 200 ألف لفة في الدقيقة المجموع: حوالي 2.6 م المسارات لكل مسار: 1 |
مسارات بروتوكول العبارة الداخلية (IGP) |
10 آلاف (داعش) |
10 آلاف (داعش) |
مجموعات تحديث BGP |
1 |
1 |
مؤقتات BGP |
افتراضي |
افتراضي |
معدل واضع السياسات المعروف LPTS BGP |
50,000 |
25,000 |
تكوين مؤشر ترابط TCP num |
16 16 |
16 16 |
حجم BGP Send-buffer |
افتراضي |
افتراضي |
ملخص مؤشرات الأداء الرئيسية (KPI) |
|
|
اعتبارات التصميم
هناك نهجان لوضع محول BGP المماثل في الشبكة:
- تصميم BGP RR مركزي/مسطح.
- تصميم BGP RR الموزع/الهرمي.
في تصميم مركزي/مسطح، يقوم جميع عملاء BGP RR في الشبكة بإنشاء تجميع BGP باستخدام مجموعة (عادة زوج) من أجهزة BGP RR التي تحتوي على نفس المعلومات تماما. هذا النهج بسيط للتنفيذ ويعمل بشكل جيد في الشبكات الصغيرة إلى المتوسطة الحجم. يتم نشر أي تغيير في جدول BGP بسرعة لجميع عملاء BGP RR. مع نمو عدد عملاء BGP RR، يمكن أن يصل التصميم إلى حد القياس عندما ينمو عدد إتصالات TCP على أجهزة BGP RR إلى الحد الذي يتأثر به أداؤها.
في التصميم الموزع/الهرمي، يتم تقسيم الشبكة إلى عدة مناطق. تقوم جميع الموجهات في المنطقة بإنشاء نظير BGP باستخدام مجموعة (عادة زوج) من أجهزة BGP RR التي تحتوي على نفس المعلومات تماما. تعمل أجهزة BGP RR هذه كعملاء BGP RR إلى مجموعة أخرى (عادة زوج) من أجهزة BGP RR. يتيح أسلوب التصميم هذا إمكانية توسعة الشبكة بسهولة، مع الحفاظ على عدد إتصالات TCP على كل BGP RR واحد ضمن حدود معينة.
هناك إعتبار آخر للتصميم وهو تخصيص نطاق المستلمين لتحديثات BGP. بناء على توزيع تردد الراديو (VRF) بين عملاء بروتوكول بوابة الحدود (BGP)، يستحق إعتبار توزيع المسار المقيد بواسطة تقنية التوجيه السريع (RT). إذا كان لدى جميع عملاء BGP RR واجهات في نفس تردد الراديو (VRF)، فإن توزيع المسار المقيد ل RT لا يجلب العديد من الفوائد. ومع ذلك، إذا تم توزيع موارد بروتوكول بوابة الحدود (VRF) بشكل متفرق بين جميع عملاء بروتوكول بوابة الحدود (BGP) المرتجلة، فإن إستخدام توزيع المسار المقيد بالتردد (RT) يقلل بشكل ملحوظ ƒ الحمل على عملية بروتوكول بوابة الحدود (BGP) على موارد بروتوكول بوابة الحدود (BGP).
مراقبة مؤشرات الأداء الرئيسية لبروتوكول بوابة الحدود (BGP)
تعد مراقبة مؤشرات الأداء الرئيسية (KPI) الخاصة ب BGP مهمة لضمان تشغيل الشبكة بشكل صحيح.
يمكن أن يؤدي أي تغيير كبير في مخطط الشبكة (على سبيل المثال، رفرفة إرتباط DWDM رئيسي) إلى تشغيل تحديثات التوجيه التي تولد حركة مرور مفرطة من و/أو إلى BGP RR. حركة المرور الكبيرة التي تؤثر على BGP RR عادة ما تحمل:
- تحديثات من أقران BGP.
- وحدات TCP ACKs التي تم إنشاؤها بواسطة نظراء BGP، ردا على التحديثات التي تم إرسالها بواسطة BGP RR والعكس
يوضح هذا القسم من المستند مؤشر الأداء الأساسي (KPI) الذي يلزم مراقبته على مرجع حركة مرور BGP النموذجي وكيفية معرفة أي من نوعي حركة مرور BGP الهامين يتسبب في معدل حركة مرور مستوى التحكم المرتفع.
يمكن وصف مسار حزم BGP داخل الموجه كما يلي:
بانت |
وحدة تحكم في الإيثرنت -(الحزمة)-> أداة تنظيم بيانات -(الحزمة)-> LPTS -(الحزمة)-> SPP -(الحزمة) -> NetIO -(الحزمة)-> TCP -(الرسالة)-> BGP |
حقن |
BGP -(message)-> TCP -(packet)-> NetIO -(packet)-> SPP -(packet) -> أداة توجيه البيانات -(packet)-> وحدة تحكم الإيثرنت |
يمكن تقسيم مؤشرات KPI إلى:
الأساسيات:
- داتاباث فوردر
- LPTS (إعدادات أدوات تنظيم العناصر الفعالة للأجهزة، وقبول العدادات وعدادات الإسقاط)
- SPP
- NetIO
- قوائم انتظار IPC (NetIO <=> TCP <=> BGP)
- أحجام BGP InQ/OutQ
اختياري:
- إستخدام وحدة المعالجة المركزية
- إستخدام الذاكرة
- إحصائيات TCP
- أداء عملية BGP
- تقارب BGP
جهاز مراقبة DataPath
في XRv9000، يكون جهاز توجيه البيانات هو وكيل مستوى البيانات (DPA)، بينما على منصات ASR9000، يكون هو معالج الشبكة (NP).
وكيل مستوى البيانات (DPA) للطراز XRv9000
أمر مفيد أن يرى الحمل وإحصائيات ال DPA:
show controllers dpa statistics global
يوضح هذا الأمر جميع العداد غير الصفري، الذي يمنحك رؤية حول نوع الحزم التي يتم انتقاؤها من واجهات الشبكة إلى وحدة المعالجة المركزية ل RP وعددها، والتي تم حقنها من وحدة المعالجة المركزية ل RP نحو واجهات الشبكة، وعدد الحزم التي سقطت:
RP/0/RP0/CPU0:xrv9k-01#show controllers dpa statistics global Index Debug Count ---------------------------------------------------------------------------- 350 TBPG L2 mailbox events 1 Index Punt Count ---------------------------------------------------------------------------- 1500 CDP 46790 1503 ARP 212 1611 IFIB 595305 1776 LLDP 94037 2001 IPv4 incomplete Tx adjacency 2 Index Inject Count ---------------------------------------------------------------------------- 744 CLNS multicast from fabric pre-route 321250 749 IPv4 from fabric 273993 765 Inject to fabric 595245 766 Inject to port 141033 Index Drop Count ---------------------------------------------------------------------------- 416 Egress UIDB in down state 1 474 IPv4 egress UIDB down 2 673 Pre-route PIT lookup missed 2
معالج شبكة ASR9000 (NP) المدرب
الأوامر المفيدة لرؤية حمل وإحصائيات كل NP في النظام هي:
show controllers np load all
show controllers np counters all
يحتوي NP على ASR9000 على مجموعة ثرية من العدادات التي تظهر لك عدد الحزم التي تمت معالجتها وإسقاطها ومعدلها ونوعها،.
RP/0/RSP0/CPU0:ASR9k-B#show controllers np load all Node: 0/0/CPU0: ---------------------------------------------------------------- Load Packet Rate NP0: 0% utilization 937 pps NP1: 0% utilization 538 pps RP/0/RSP0/CPU0:ASR9k-B#
RP/0/RSP0/CPU0:ASR9k-B#show controllers np counters all Node: 0/0/CPU0: ---------------------------------------------------------------- Show global stats counters for NP0, revision v4 Last clearing of counters for this NP: NEVER Read 92 non-zero NP counters: Offset Counter FrameValue Rate (pps) ------------------------------------------------------------------------------------- 16 MDF_TX_LC_CPU 25475368 10 17 MDF_TX_WIRE 681957877 267 21 MDF_TX_FABRIC 683500690 267 33 PARSE_FAB_RECEIVE_CNT 681767730 267 37 PARSE_INTR_RECEIVE_CNT 1323024637 517 41 PARSE_INJ_RECEIVE_CNT 13949634 5 45 PARSE_ENET_RECEIVE_CNT 677655725 265 49 PARSE_TM_LOOP_RECEIVE_CNT 49331192 19 53 PARSE_TOP_LOOP_RECEIVE_CNT 1520846 1 109 RSV_DROP_EGR_UIDB_NO_MATCH 10 0 146 RSV_DROP_IPV4_RXADJ_DROP 1 0 164 RSV_DROP_ING_LAG_NO_MATCH 3 0 241 RSV_DROP_MPLS_LEAF_NO_MATCH 1312 0 <. . .>
شاشة LPTS
بما أن BGP RR القياسي ليس في مسار إعادة التوجيه، فإن جميع الحزم المستلمة على واجهة الشبكة يتم تخزينها على مستوى التحكم. يقوم عنصر مسار البيانات على BGP RR بتنفيذ عدد صغير من العمليات البسيطة قبل توجيه الحزم إلى مستوى التحكم. ونظرا لأنه من غير المحتمل أن يكون عنصر مسار البيانات نقطة إزدحام، فإن العنصر الوحيد الموجود على بطاقة الخط الذي يحتاج إلى مراقبة هو حالات LPTS.
الرجاء ملاحظة أنه في حالة وجود XRv9k، يتم تعيين استاتيكية الأجهزة إلى vPP
:
show lpts pifib hardware police location <location> | inc "Node|flow_type|BGP"
مثال:
RP/0/RP0/CPU0:xrv9k-01#sh lpts pifib hardware police location 0/0/CPU0 | i "Node|flow_type|BGP" Node 0/0/CPU0: flow_type priority sw_police_id hw_policer_addr Cur. Rate burst static_avgrate avgrate_type AggrAccepts AggrDrops TOS Value BGP-known high 6 220 50000 1250 2500 Global 16401392 0 01234567 BGP-cfg-peer medium 7 221 4000 1000 2000 Global 355976 1563 01234567 BGP-default low 8 222 3000 750 1500 Global 5212380 0 01234567 RP/0/RP0/CPU0:xrv9k-01#
ما الذي يجب البحث عنه:
إذا تم ملاحظة قفزة كبيرة في نقاط الوصول في مقابل نوع تدفق معروف في بروتوكول BGP، فعليك البدء في البحث عن تغييرات في مخطط الشبكة التي أدت إلى حدوث مثل هذا التغيير الهائل في مستوى التحكم.
مسار بيانات تتبع الاستخدام:
Cisco-IOS-XR-lpts-pre-ifib-oper:lpts-pifib
ملاحظة: يمكن مسح عدادات LPTS. يجب أن يراعي نظام المراقبة هذا الاحتمال.
جهاز العرض SPP
SPP هي الحزمة الأولى على معالج التوجيه أو وحدة المعالجة المركزية لبطاقة الخط التي تستلم الحزمة التي يتم انتقاؤها من NP أو DPA عبر البنية الداخلية، والنقطة الأخيرة في معالجة حزمة البرنامج قبل تسليمها إلى البنية لحقنها في NP أو DPA.
الأوامر ذات الصلة لمراقبة SPP:
show spp node-counters
show spp client
يعرض
show spp node-counters الأمر معدل الحزم المثقبة/التي تم حقنها ويكون من السهل قراءته وفهمه. بالنسبة لجلسات عمل BGP، تكون الموجهات ذات الصلة ضمن
client/punt وعلى
client/inject RP النشط.
يتميز
show spp client هذا الطراز بأنه أكثر ثراء في الإخراج، كما يوفر نظرة أكثر تفصيلا حول عدد الحزم التي يتم وضعها في قائمة الانتظار/إسقاطها تجاه العملاء، بالإضافة إلى العلامة المائية العالية.
RP/0/RP0/CPU0:xrv9k-01#show spp node-counters 0/RP0/CPU0: socket/rx Punted packets: 595305 Punt bulk reads: 6 Punt non-bulk reads: 595293 Management packets: 74200158 Management bulk reads: 1775930 Management non-bulk reads: 70031734 ------------------------------- socket/tx Injected packets: 595245 Management packets: 139939168 ------------------------------- xrv9k/classify Forwarded to SPP clients: 74795463 ------------------------------- client/inject Injected from client: 140534413 Non-bulk injects: 140534413 ------------------------------- client/punt punted to client: 74795371 no client found - send to defa: 92 ------------------------------- 0/0/CPU0: <. . .>
RP/0/RP0/CPU0:xrv9k-01#show spp client Sat Apr 20 17:11:40.725 UTC 0/RP0/CPU0: Clients ======= <. . .> netio, JID 254 (pid 4591) ---------------------------------------------------------- Reconnect Pending: F, Exited: F, Keep Queues: F, Pakman Client: T Quota Current: 0, Limit: 16384, Drops 0 Queues: Key Cur Max Enqueues High Watermark (Timestamp) Drops 0xffffffff 0 10 0 0 (22:13:52.195 Feb 21 24 UTC) 0 0x03000006 0 2048 0 0 (22:13:52.196 Feb 21 24 UTC) 0 0x03000007 0 3072 414881 1 (23:03:30.721 Feb 21 24 UTC) 0 0x03000008 0 1024 5 1 (13:41:28.389 Mar 13 24 UTC) 0 0x03000009 0 2048 180411 1 (23:03:31.565 Feb 21 24 UTC) 0
جهاز العرض NetIO
بينما يعرض منظم LPTS عدد الحزم التي تم قبولها أو إسقاطها بواسطة واضع السياسات المتوافق فقط، يمكننا أن نرى على مستوى NetIO معدل الحزم التي تم انتقاؤها إلى وحدة المعالجة المركزية ل RP. بما أن الغالبية العظمى من الحزم المستلمة في بروتوكول BGP النموذجي هي حزم BGP، فإن المعدل الإجمالي NetIO يشير عن قرب شديد إلى معدل حزم BGP المستلمة.
Command:
show netio rates
مثال:
RP/0/RP0/CPU0:xrv9k-01#show netio rates Netio packet rate for node 0/RP0/CPU0 ----------------------------------- Current rate (updated 0 seconds ago): Input: 7845 pkts/s Output: 10570 pkts/s Driver Output: 10598 pkts/s 1 minute rate (updated 0 seconds ago): Input: 7825 pkts/s Output: 10542 pkts/s Driver Output: 10569 pkts/s 5 minute rate (updated 0 seconds ago): Input: 7997 pkts/s Output: 10677 pkts/s Driver Output: 10704 pkts/s RP/0/RP0/CPU0:xrv9k-01#
ما الذي يجب البحث عنه:
- إذا تم ملاحظة قفزة كبيرة في معدل NetIO، فابدأ في البحث عن تغييرات في مخطط الشبكة التي أدت إلى حدوث مثل هذا التغيير الهائل في مستوى التحكم.
مسار بيانات تتبع الاستخدام:
- غير قابلة للتطبيق حيث يجب أن تقوم بيانات تتبع الاستخدام بدفق قيم العداد، وليس المعدلات. يمكن إستخدام عداد قبول LPTS المعروف باسم BGP على مجمع بيانات تتبع الاستخدام لتقدير متوسط معدل حزم BGP المستلمة من النظراء المعروفين.
مراقبة قوائم انتظار XIPC
على حزم مسار الحزم المؤقتة التي يتم استقبالها بواسطة NetIO من LPTS يتم تمريرها إلى TCP و BGP. من المهم مراقبة قوائم الانتظار هذه:
1. قائمة انتظار TCP عالية الأولوية التي يقوم NetIO من خلالها بتسليم الحزم إلى TCP
2. قائمة انتظار التحكم في BGP
3. قائمة انتظار بيانات BGP
في حزم مسار الإدخال يتم إنشاؤها بواسطة TCP وتمريرها إلى NetIO. من المهم مراقبة قوائم الانتظار هذه:
- قائمة انتظار OutputL XIPC
الأوامر:
show netio clients show processes bgp | i "Job Id" show xipcq jid <bgp_job_id> show xipcq jid <bgp_job_id> queue-id <n>
الأمثلة:
NetIO إلى TCP، عرض من وجهة نظر NetIO:
RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> Input Punt XIPC InputQ XIPC PuntQ ClientID Drop/Total Drop/Total Cur/High/Max Cur/High/Max <. . .> tcp L 0/340774 0/0 L 0/10/12800 0/0/0 H 0/44774091 H 0/784/12800
TCP إلى NetIO، عرض من وجهة نظر NetIO:
RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> XIPC queues Dropped/Queued Cur/High/Max ------------------------------------------------------------ OutputL 124860/9355257 0/14000/14000
NetIO إلى TCP، عرض من وجهة نظر عملية TCP:
RP/0/RP0/CPU0:xrv9k-01#show processes tcp | i "Job Id"
Job Id: 430
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 430 Mon Apr 17 16:16:11.315 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 17 XIPC_xipcq_12_0_9854_6506_i... 60000 0 39010269 0 960 16 XIPC_xipcq_12_0_9854_6506_i... 24000 0 31518436 0 1364 15 XIPC_tcp_124 3200 0 0 0 0 14 XIPC_tcp_125 9600 0 0 0 0 13 XIPC_tcp_psb_0 25600 0 0 0 0 10 XIPC_tcp_iq_9 102400 0 9486010 0 312 12 XIPC_tcp_iq_8 102400 0 8892274 0 280 9 XIPC_tcp_iq_5 102400 0 8291392 0 289 11 XIPC_tcp_iq_7 102400 0 9700123 0 319 8 XIPC_tcp_iq_6 102400 0 9378703 0 332 7 XIPC_tcp_iq_3 102400 0 7221706 0 261 6 XIPC_tcp_iq_4 102400 0 9791070 0 308 4 XIPC_tcp_ctrl_iq_1 4266 0 0 0 0 5 XIPC_tcp_iq_2 102400 0 9699027 0 295 3 XIPC_tcp_ctrl_iq_0 4266 0 209909 0 9 2 XIPC_tcp_i1 12800 0 39460564 0 784 1 XIPC_tcp_i0 12800 0 212540 0 10
بروتوكول TCP إلى BGP:
RP/0/RP0/CPU0:xrv9k-01#show processes bgp | i "Job Id" Job Id: 1078 RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 Mon Apr 17 16:09:33.046 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 2 XIPC_xipcq_12_0_9854_6506_i... 60000 2 35546667 0 15034 1 XIPC_xipcq_12_0_9854_6506_i... 24000 0 1369029 0 50 RP/0/RP0/CPU0:xrv9k-01#
قائمة انتظار بيانات BGP:
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 1 XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp: Magic: 12344321 Version: 0 SHM Size: 192392 Owner PID: 9854 Owner JID: 1078 Queue ID: 1 Owner MQ handle: 483 User Context: 0x64 Interrupt Flag: 0 Sent-on-full Flag: 0 Max Queue Size: 24000 Queue Size: 0 Client Queue Size: 24000 High watermark: 50 Last Trigger Sent: Mon Apr 17 16:11:10.009 CEST MQ Send Errors: 0 Priority Queues: Prio Size Drops Total ---------- ---------- ---------- ---------- Unspec 24000 0 0 Normal 24000 0 1396159 Medium 24000 0 0 High 24000 0 0 Crucial 24000 0 0 RP/0/RP0/CPU0:xrv9k-01#
قائمة انتظار التحكم في BGP:
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 2 XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp: Magic: 12344321 Version: 0 SHM Size: 480392 Owner PID: 9854 Owner JID: 1078 Queue ID: 2 Owner MQ handle: 485 User Context: 0x64 Interrupt Flag: 0 Sent-on-full Flag: 0 Max Queue Size: 60000 Queue Size: 0 Client Queue Size: 60000 High watermark: 15034 Last Trigger Sent: Mon Apr 17 16:12:49.483 CEST MQ Send Errors: 0 Priority Queues: Prio Size Drops Total ---------- ---------- ---------- ---------- Unspec 60000 0 0 Normal 60000 0 37313633 Medium 60000 0 0 High 60000 0 0 Crucial 60000 0 0 RP/0/RP0/CPU0:xrv9k-01#
ما الذي يجب البحث عنه:
- يجب ألا تكون هناك حالات سقوط في قوائم الانتظار ذات الصلة
- في حالات قائمة انتظار XIPC يجب ألا يتجاوز High Watermark (HWM) ال 50٪ من حجم قائمة الانتظار
من أجل تتبع أفضل لتطور قيمة العلامة المائية العالية، يجب مسح قيمة العلامة المائية العالية بعد كل قراءة. لاحظ أن هذا لا يمسح فقط عداد HWM ولكنه يمسح أيضا كافة إحصائيات قائمة الانتظار. تنسيق الأمر لمسح إحصائيات قائمة انتظار XIPC هو: clear xipcq statistics queue-name <queue_name>
بما أن اسم قائمة الانتظار غالبا ما يتضمن معرف العملية (PID)، فإن اسم قائمة الانتظار يتغير بعد إعادة تشغيل العملية.
بعض أمثلة الأوامر الخاصة بمسح إحصائيات قوائم الانتظار ذات الصلة:
clear xipcq statistics queue-name XIPC_tcp_i0
clear xipcq statistics queue-name XIPC_tcp_i1
clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp
clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp
مسار تتبع الاستخدام:
- لا توجد مسارات مستشعر تتبع الاستخدام ل XIPC.
مراقبة قوائم انتظار الإدخال والإخراج ل BGP
يحافظ بروتوكول BGP على قائمة انتظار الإدخال والإخراج لكل نظير BGP. توجد البيانات في InQ عندما يكون بروتوكول TCP قد مررها إلى BGP، لكن BGP لم يعالجها بعد. تبقى البيانات في OutQ بينما تنتظر BGP على TCP لتقسيم البيانات إلى حزم وإرسالها. يوفر الحجم الفوري لبروتوكول BGP InQ/OutQ مؤشرا جيدا على مدى انشغال عملية BGP.
:
show bgp <AFI> <SAFI> summary
مثال:
RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100
ما الذي يجب البحث عنه:
- يجب أن يكون حجم InQ/OutQ صفرا عندما تكون الشبكة مستقرة. يتغير بسرعة عند تبادل التحديثات.
- يجب ألا يزيد حجم InQ/OutQ بشكل متكرر مع مرور الوقت.
مسار تتبع الاستخدام:
- Cisco-IOS-XR-IPV4-bgp-oper:BGP
مراقبة معدلات رسائل BGP
يمكن لبعض جيران BGP إرسال التحديثات أو عمليات السحب باستمرار إذا كانت مخطط الشبكة غير مستقر. ويجب بعد ذلك أن يكرر BGP RR تغيير جدول التوجيه هذا آلاف المرات إلى جميع عملاء RR التابعين له. لذلك، من المهم مراقبة معدلات الرسائل التي يتم تلقيها من الجيران، لتعقب مصادر عدم الاستقرار.
:
show bgp <AFI> <SAFI> summary
مثال:
RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100
تحتوي قوائم انتظار عملاء RR على نفس كمية MSGsent تقريبا، ولكن يمكن أن يزيد عدد MSGrcvd عند بعض الجيران عن عدد MSGrcvd. يجب عليك التقاط لقطات متعددة من هذا الأمر لتقييم معدل الرسائل.
بمجرد أن تتعرف على الأقران المسيئين، يمكنك عندئذ المرور عبر أوامر أخرى مثل
show bgp neighbor <neighbor> detail و
show bgp neighbor <neighbor> performance-statistics
show bgp recent-prefixes أو محاولة فهم أي البادئات ترفرف وما إذا كانت دائما نفس البادئات أو بادئات مختلفة.
ملاحظة: عدادات MsgRcvd و MsgSent لكل جار ولكن ليس لكل عائلة عنوان. لذلك عند تشغيل أمر مثل، show bgp all all summary سترى نفس العدادات لكل جار في الأقسام الخاصة بعائلات العناوين المختلفة. وهي لا تمثل عدد الرسائل التي تم تلقيها/إرسالها من/إلى ذلك الجار لعائلة العناوين تلك ولكن عبر عائلات العناوين.
مراقبة إستخدام وحدة المعالجة المركزية
يجب مراقبة إستخدام وحدة المعالجة المركزية (CPU) على كل موجه، ولكن قد لا تكون بعض عمليات القراءة أمرا بديهيا على موجه مزود بعدد كبير من مراكز وحدة المعالجة المركزية (CPU) المخصصة لمستوى التحكم. على BGP RR مع عدد كبير من مراكز وحدة المعالجة المركزية المخصصة لمعالج التوجيه (RP)، كما في حالة جهاز XRv9k، تعمل الخيوط النشطة على مراكز وحدة المعالجة المركزية المختلفة، بينما يظل عدد من مراكز وحدة المعالجة المركزية في وضع الخمول. ونتيجة لذلك، يمكن أن تكون بعض مراكز وحدة المعالجة المركزية (CPU) مشغولة للغاية، ولكن يظل إستخدام وحدة المعالجة المركزية (CPU) الإجمالي الذي يتم حسابه عبر جميع مراكز وحدة المعالجة المركزية (CPU) معتدلا.
لذلك، من أجل المراقبة المناسبة لاستخدام مراكز وحدة المعالجة المركزية (CPU) عبر واجهة سطر الأوامر، أستخدم
show processes cpu thread الأمر.
مراقبة إحصائيات بروتوكول TCP
يحتفظ برنامج Cisco IOS® بإحصائيات تفصيلية حول كل جلسة عمل TCP. يعرض أمر CLI
show tcp brief قائمة جميع جلسات عمل TCP الموجودة. في مخرجات هذا الملخص، لكل جلسة TCP يمكنك الاطلاع على هذه المعلومات:
- PCB: معرف جلسة TCP الفريد.
- VRF-ID: معرف VRF الذي توجد فيه الجلسة.
- أن يرى ال يماثل VRF إسم، ركضت هذا أمر:
show cef vrf all summary | utility egrep "^VRF:|Vrfid" | utility egrep -B1 <VRF-ID>
- Recv-Q: الحجم الفوري لقائمة انتظار الاستلام يحمل الحزم المستلمة من NetIO. تستخرج عملية TCP البيانات من حزمة وتأرسلها إلى التطبيق المتوافق.
- Send-Q: الحجم الفوري لقائمة انتظار الإرسال يحمل البيانات المتلقاة من أحد التطبيقات. تقوم عملية TCP بتقسيم البيانات إلى شرائح TCP (التي يتم إقرارها بواسطة الحد الأقصى لحجم مقطع بروتوكول TCP - MSS)، وتضمين كل مقطع في رأس الطبقة 3 لعائلة العناوين المقابلة (IPv4 أو IPv6) وترسل الحزمة إلى NetIO.
- العنوان المحلي: عنوان IPv4 أو IPv6 المحلي المرتبط بمقبس TCP. تلتزم جلسات TCP في حالة الإصغاء عادة بعنوان IP any"، والذي يتم تمثيله على أنه "0.0.0.0" أو "::" في حالة IPv4 أو IPv6 على التوالي.
- العنوان الخارجي: عنوان IPv4 أو IPv6 البعيد المرتبط بمقبس TCP. تلتزم جلسات TCP في حالة الإصغاء عادة بعنوان IP any"، والذي يتم تمثيله على أنه "0.0.0.0" أو "::" في حالة IPv4 أو IPv6 على التوالي.
- الحالة: حالة جلسة عمل TCP. حالات جلسات عمل TCP المحتملة هي: الاستماع، مزامنة، SyncRCVD، ESTAB، LASTACK، الإغلاق، Closewait، Finwait1، Finwait2، TimeWait، مغلق.
بما أن رقم منفذ BGP المعروف هو 179، يمكنك تقييد جلسات عمل TCP المعروضة إلى تلك المقترنة بتطبيق BGP.
مثال:
RP/0/RSP0/CPU0:ASR9k-B#show tcp brief | include "PCB|:179 " PCB VRF-ID Recv-Q Send-Q Local Address Foreign Address State 0x00007ff7d403bde0 0x60000000 0 0 :::179 :::0 LISTEN 0x00007ff7d403b020 0x60000002 0 0 :::179 :::0 LISTEN 0x00007ff7d403d130 0x60000000 0 0 192.168.0.4:50144 192.168.0.5:179 ESTAB 0x00007ff7a4025650 0x60000000 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN 0x00007ff7a4024a50 0x60000002 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN
يمكنك إستخدام قيمة PCB المعروضة للحصول على الإحصائيات لجلسة عمل TCP معينة. أوامر CLI التي توفر نظرة متعمقة على إحصائيات عملية TCP:
عمومي:
show tcp statistics clients location <active_RP>
show tcp statistics summary location <active_RP>
لكل PCB:
show tcp brief | i ":179"
show tcp detail pcb <pcb> location 0/RP0/CPU0
show tcp statistics pcb <pcb> location <active_RP>
تعرض أوامر إحصائيات TCP العالمية الصحة العامة لجلسات عمل TCP. بالإضافة إلى إحصائيات حزمة البيانات (In/Out)، يمكنك أن ترى على سبيل المثال ما إذا كانت هناك حزم تحتوي على أخطاء المجموع الاختباري، وحزم ذات تكوين غير صحيح، وحزم سقطت بسبب أخطاء المصادقة، وحزم خارج الترتيب، وحزم ذات بيانات بعد الإطار، مما يمنحك إشارة إلى سلوك أقران TCP.
في أوامر لكل وحدة بينية، يمكنك رؤية معلمات مهمة لجلسة عمل TCP، مثل MSS، والحد الأقصى لوقت الذهاب والعودة، وما إلى ذلك.
العدادات ذات الصلة في إخراج
show tcp detail pcb الأمر هي:
- يبدأ مؤقت Retrans: يشير إلى عدد مرات بدء مؤقت إعادة الإرسال.
- عمليات تنبيه مؤقت إعادة الإرسال: يشير إلى عدد المرات التي تم فيها تشغيل مؤقت إعادة الإرسال، مما أدى إلى إعادة إرسال مقطع TCP.
- حجم قائمة انتظار الإرسال الحالية بالبايت: وحدات البايت غير المعترف بها من النظير.
- حجم قائمة انتظار الاستلام الحالي بالبايت/الحزم: وحدات البايت/الحزم التي لم يقرأها التطبيق بعد (BGP).
- وحدات البايت التي تم طلبها بشكل غير منتظم: وحدات البايت التي تم وضعها في قائمة انتظار الحفظ بسبب وجود ثقب في نافذة تلقي TCP.
RP/0/RSP0/CPU0:ASR9k-B#show tcp detail pcb 0x4a4400e4 ============================================================== Connection state is ESTAB, I/O status: 0, socket status: 0 Established at Sat Apr 20 18:26:26 2024 PCB 0x4a4400e4, SO 0x4a42c0ac, TCPCB 0x4a43b708, vrfid 0x60000000, Pak Prio: Normal, TOS: 64, TTL: 255, Hash index: 402 Local host: 10.10.10.229, Local port: 179 (Local App PID: 856311) Foreign host: 10.10.10.254, Foreign port: 46980 (Local App PID/instance/SPL_APP_ID: 856311/0/0) Current send queue size in bytes: 0 (max 16384) Current receive queue size in bytes: 0 (max 65535) mis-ordered: 0 bytes Current receive queue size in packets: 0 (max 60) Timer Starts Wakeups Next(msec) Retrans 2795 0 0 SendWnd 1341 0 0 TimeWait 0 0 0 AckHold 274 2 0 KeepAlive 333 1 299983 PmtuAger 0 0 0 GiveUp 0 0 0 Throttle 0 0 0 FirstSyn 0 0 0 iss: 2030796738 snduna: 2034498828 sndnxt: 2034498828 sndmax: 2034498828 sndwnd: 3291 sndcwnd: 4200 irs: 285455091 rcvnxt: 285455710 rcvwnd: 64917 rcvadv: 285520627
SRTT: 162 ms, RTTO: 415 ms, RTV: 253 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 247 ms ACK hold time: 200 ms, Keepalive time: 300 sec, SYN waittime: 30 sec Giveup time: 0 ms, Retransmission retries: 0, Retransmit forever: FALSE Connect retries remaining: 0, connect retry interval: 0 secs <...> RP/0/RSP0/CPU0:ASR9k-B#
مراقبة إستخدام الذاكرة
يتم تخزين جدول مسار BGP في ذاكرة كومة عملية BGP. يتم تخزين جدول التوجيه في ذاكرة كومة المعالجة الخاصة ب RIB.
أوامر مفيدة لمراقبة ذاكرة كومة الذاكرة المؤقتة:
show memory summary
show memory summary detail
show memory-top-consumers
show memory heap summary all
مسار مستشعر القياس عن بعد:
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail
يقوم FIB بتخزين إدخالات إعادة التوجيه في مساحة الذاكرة المشتركة.
أوامر مفيدة لمراقبة الذاكرة المشتركة:
show memory summary
show memory summary detail
show shmwin summary
مراقبة أداء عملية BGP
أمر مفيد يوفر بيانات داخلية على أداء عملية BGP:
show bgp process performance-statistics
show bgp process performance-statistics detail
تقارب BGP للشاشة
أمر مفيد آخر هو الذي يظهر الحالة العامة لتقارب BGP:
show bgp convergence
عندما تكون الشبكة مستقرة، سترى شيئا كهذا:
RP/0/RP0/CPU0:ASR9k-B#show bgp convergence Mon Dec 18 13:55:47.976 UTC Converged. All received routes in RIB, all neighbors updated. All neighbors have empty write queues. RP/0/RP0/CPU0:ASR9k-B#
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
01-Aug-2024 |
الإصدار الأولي |