أستكشاف أخطاء إعادة تحميل مدير المكدس 3650/3850 وإصلاحها

المقدمة

يوضح هذا المستند كيفية الاستفادة من تقارير النظام لتشخيص مشاكل المكدس.

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

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

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

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

معلومات أساسية

إذا قمت باستكشاف أخطاء إعادة تحميل المكدس وإصلاحها من خلال تقرير نظام في غياب عطل، فعادة ما يتم القيام بذلك على منصات تحويل NGWC، فأنت تستخدم تقنية StackWise. تكون الوثائق الحالية محدودة على إستخدامات تقرير النظام ويشرح هذا الدليل كيفية الاستفادة من هذه التقارير لتشخيص المشاكل الموجودة عادة مع مشاكل التجميع. يكون هذا الدليل مركزا بشكل خاص على بنى المحولات Catalyst 3650/3850 Switch التي تعمل بنظام التشغيل Cisco IOS® XE مع قدرات تجميع الدعم.

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

تقرير النظام مقابل تقارير المحول

تقرير النظام هو تقرير شامل عن العضو من كيفية إدراكه لحالة المكدس. هذا ليس crashinfo (والذي يمكنه تفريغ الذاكرة لمزيد من تصحيح الأخطاء)، ولكن بدلا من ذلك، فهو تقرير يحتوي على سجلات ومعلومات تصحيح أخطاء للخدمات المختلفة التي يتم تشغيلها ضمن Cisco IOS XE والتي ستكون مفيدة للتطور لتعقب حالة هذه الخدمة. يمكن إنشاء تقرير نظام عند إعادة تحميل المحول بواسطة مدير المكدس، أو عند حدوث عطل في العملية، أو عند إنشاؤه يدويا بواسطة المستخدم أثناء عملية التشغيل المباشر.

في العديد من الحالات، هناك حالات يمكن أن يفشل فيها محول واحد في مكدس، ولكن يمكن أن يبقى باقي الأعضاء كما هي. للتجميع كمعلومات حول حالة المكدس في الوقت المحدد، تم تقديم SWITCH_REPORTS حتى يمكن للأعضاء الحاليين إنشاء واحد عندما يكتشف أن عضوا ما قد انخفض. يمكن أن يكون switch_report تقريرا محليا حول كيفية إدراك ذلك العضو للحالة الحالية للمكدس.

ملاحظة: تتم كتابة هذه التقارير وضغطها بحيث لا يمكن طباعتها إلى المحطة الطرفية باستخدام المزيد. قد يلزم نقلها من المحول وفك ضغطها لعرض السجل.

مكان تجميع تقارير النظام/المحول

عادة ما يمكن كتابة تقارير النظام في crashinfo: دليل العضو في هذا المكدس. على سبيل المثال، إذا كان هناك مكدس محول بعضو x، فيمكن أن يكون لكل محول دليل crashinfo خاص به ويمكن الوصول إليه باستخدام dir crashinfo-x حيث يتوافق x مع ذلك العضو داخل المكدس.

3850#dir crashinfo-1:

دليل crashinfo:/    

11 -rwx 355 أغسطس 2015 07:48:17 -04:00 last_systemreport_log  

12 -rwx 724015 أكتوبر 2014 07:14:32 -04:00 system-report_1_20141015-11342-UTC.gz

3850#dir crashinfo-2:

دليل crashinfo-2:/   

11 -rwx 357 أغسطس 2015 07:50:49 -04:00 last_systemreport_log  

12 -rwx 751340 أكتوبر 2014 06:41:12 -04:00 system-report_1_20141015-104022-utc.gz

ملاحظة: تأكد من تجميع الإخراج ل dir crashinfo-x لكل محول في هذا المكدس لأن show tech لا يمكنه سرد أنظمة الملفات المتوفرة أو ملفات crashinfo. من المهم أن تكون لديك الصورة الكاملة لكل عضو في تلك المكدس. تحديث: اعتبارا من إصدارات Cisco IOS XE الأحدث >3.6E، يمكن أن يعكس فني العرض معلومات نظام dir crashinfo: + إخراج أنظمة الملفات show. راجع معرف تصحيح الأخطاء من Cisco CSCun50428.

أقسام جديرة بالذكر في تقرير النظام

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

ملف السجل: /mnt/pss/sup_sysmgr_reset.log

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

ملف السجل: Cisco IOS

هذا هو المخزن المؤقت للسجل الذي يتم الاحتفاظ به من داخل Cisco IOSd. يمكن العثور على أي أوامر تم إصدارها بواسطة المستخدم أو syslog التي تم إنشاؤها داخل Cisco IOS في هذا القسم. توشك أحدث السجلات على نهاية هذا الإخراج.

Trace Buffer: stack-mgr-events

يتتبع الأحداث التي يتم رؤيتها من مدير المكدس والتي يمكن أن تتضمن عند انضمام/إزالة أعضاء آخرين من المكدس أو منفذ المكدس الذي يتم إرسال الرسائل من خلاله.

               

مخزن مؤقت التتبع: تكرار-timer-ha_mgr

يعرض الحفاظ على الأحداث بين المحولات في المكدس. يمكن أن تساعد الطوابع الزمنية في تحديد وقت بدء التعطل في الاتصال.

أنواع حالات الفشل

يمكن أن يسلط هذا القسم الضوء على بعض عمليات إعادة الضبط التي تتم رؤيتها بشكل شائع من تقرير نظام يتم استدعاؤها عادة بواسطة عملية إدارة المكدس. مدير المكدس هو عملية من نظام التشغيل Linux تقوم بإدارة الأعضاء في المكدس ويمكنها مراقبة أي تغييرات في الأدوار بين المحولات في المكدس. إذا اكتشف مدير المكدس مشكلة أثناء التهيئة أو إختيار الدور، فيمكنه إرسال إشارة إعادة تحميل إلى المحولات الفردية لإعادة تعيين المكدس. كما يمكن أن تسرد القائمة التالية الأخطاء المعروفة التي تم اقترانها بنوع الفشل الشخصي.

سبب إعادة التعيين:مطلوب إعادة تعيين/إعادة تحميل من قبل [مدير المكدس]. [عدم توافق ISSU]

يمكنك مشاهدة هذا النوع من إعادة الضبط عند حدوث فشل في المزامنة المجمعة عند محاولة مزامنة التكوين على النشط بين جميع الأعضاء في المكدس. تحقق من ملف السجل: يمكن أن يقوم Cisco IOS أو السجلات من المحول النشط بإبراز التكوينات التي ساهمت في إعادة التعيين هذه.

إعادة تعيين السبب:تم إنهاء الخدمة [iosd] pid:[xyz] بشكل غير طبيعي [11].

رأيت هذا عندما المفتاح يتعطل في cisco ios عملية. راجع أدلة crashinfo الخاصة بأي ملفات crashinfo + مكبات core يمكن إستخدامها لتصحيح هذا الفشل بشكل إضافي.

hr_sup_reset: سبب إعادة ضبط:إعادة ضبط/إعادة تحميل مطلوب بواسطة [stack-manager]. [دمج المكدس]

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

معرف تصحيح الأخطاء من Cisco CSCuh58098 - يمكن إعادة تحميل المكدس 3850 عند وجود مشاكل في كبلات المكدس

معرف تصحيح الأخطاء من Cisco CSCui56058 - تمكين منطق تعطيل كبل المكدس

معرف تصحيح الأخطاء من Cisco CSCup53338 - تعطل IOSD 3850 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hr_sup_reset: رمز السبب:[4] سبب إعادة الضبط:إعادة ضبط/إعادة تحميل مطلوب بواسطة [stack-manager]. [دمج المكدس بسبب عدم التوافق]

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

معرف تصحيح الأخطاء من Cisco CSCuo4955

معرف تصحيح الأخطاء من Cisco CSCup58016 - 3850/3650 يتعطل بسبب طوفان البث الأحادي على منفذ الإدارة

معرف تصحيح الأخطاء من Cisco CSCur07909 - دمج المكدس بسبب الاتصال النشط أو الاحتياطي المفقود

سبب إعادة التعيين:مطلوب إعادة تعيين/إعادة تحميل من قبل [مدير المكدس]. [جار غير مناسب تمت مواجهته بعد اقتراع اللجنة الانتخابية المستقلة]

تشارك المحولات في اقتراع ASIC أثناء التمهيد لتحديد المحولات المجاورة ضمن المكدس. يمكن ملاحظة إعادة التعيين هذه عند انتهاء صلاحية المؤقت لأحد الجيران لإعلان نفسه أو عند وجود خطأ منطقي أثناء محادثة NetCast. وقد شوهد ذلك في سياق كبلات المكدس المعيبة التي تم حلها من خلال الاستبدال.

معرف تصحيح الأخطاء من Cisco CSCun60777 - تم إعادة تحميل المحول بسبب جار غير صحيح تمت مصادفته بعد اقتراع ASIC

معرف تصحيح الأخطاء من Cisco CSCud93761 - تم إعادة تحميل المحول بسبب جار غير صحيح تمت مصادفته بعد اقتراع ASIC

يظهر معرف تصحيح الأخطاء من Cisco CSCun17506 - AMUR:ng3k:SAME neighbor على كلا منافذ المكدس على مكدس 3 أعضاء

hr_sup_reset: رمز السبب:[4] سبب إعادة ضبط:إعادة ضبط/إعادة تحميل مطلوب بواسطة [stack-manager]. [فقد في وضع نشط وفي وضع الاستعداد على السواء]

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

معرف تصحيح الأخطاء من Cisco CSCup53882- محولات الأعضاء في إعادة تمهيد مكدس 3850 - [مفقودة في وضع الاستعداد أو النشط]

hr_sup_reset: رمز السبب:[1] سبب إعادة ضبط:إعادة ضبط/إعادة تحميل مطلوب بواسطة [stack-manager]. [Keepalive_timeout]

يظهر عندما لا يتم تلقي رسائل الإبقاء على قيد الحياة من المحول في المكدس. انظر إلى Trace Buffer: Undancy-timer-ha_mgr وهو يعرض تبادل رسائل Keep Live ويوفر منظور الوقت عندما يبدأ التعطل في الاتصال. إذا قمت بتجميع تقارير المحولات من باقي المكدس ونظرت إلى السجلات عبر الإطار الزمني، فيمكن أن يساعد ذلك.

hr_sup_reset: سبب إعادة ضبط:إعادة ضبط/إعادة تحميل مطلوب بواسطة [stack-manager]. [أمر إعادة التحميل]

وهذا سبب إعادة تعيين بسيط للغاية - يظهر عندما يستقبل مدير المكدس طلب إعادة تحميل يمكن استدعاؤه من خلال واجهة سطر الأوامر (CLI) أو خارجيا من خلال جهاز الإدارة (SNMP). في حالات معرف تصحيح الأخطاء من Cisco CSCuj17317، يظهر هذا أيضا كأمر reload يصدر أيضا. من ملف السجل: يمكنك الاطلاع على Cisco IOS:

CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr:  Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr:  Reloading due to reason Reload command

الأخطاء ذات الصلة

معرف تصحيح الأخطاء من Cisco CSCur76872 - يتم إسقاط مدير المكدس عندما ينفذ النظام من المخزن المؤقت ل SDP.

معرف تصحيح الأخطاء من Cisco CSCup49704 - تعطل FED 3850 - انتظار قنوات SPI FED_SPI_FLCD، FED_SPI_FAST ...

تشخيص مشكلة محتملة في كبل المكدس أو المنفذ

العرض 1) تظهر أي علامات على مشكلة كبل مكدس بواسطة أي تدفق لمنفذ المكدس قبل إعادة الضبط. انظر إلى ملف السجل: يكون تقرير Cisco IOS قبل إعادة الضبط عادة مكانا جيدا للبدء. هنا مثال من حيث أنت ترى رفرفة من الكومة ميناء أي يكون سجلت على على حد سواء ال SW2 حالي وال SW1 إستعداد. كان منفذ المكدس هذا نفسه يرفرف كل مرة في كل مثيل من عملية إعادة الضبط وتم الحل بواسطة الوقت الذي تم فيه إستبدال كبل المكدس:

=====================  log file: Cisco IOS  =====================
.
.
Aug  8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is down  (SW1-1)
Aug  8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is up  (SW1-1)
Aug  8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr:  Switch 1 has been removed from the stack.
Aug  8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1

العرض 2) استنادا إلى إعداد StackWise الذي يتم إستخدامه (180، 480، بالإضافة إلى ذلك)، يختلف عدد حلقات الإرسال لكل منفذ ASIC. تقوم هذه الأوامر باستطلاع السجلات العمومية التي تحافظ على إجمالي يتزايد بمقدار عدد أخطاء القراءة التي يتم رؤيتها لكل حلقة إرسال. يماثل port-asic 0 إلى كومة ميناء 1 و port-asic 1 يماثل إلى كومة ميناء 2. يجب إصدار هذا لكل محول وأي علامات لأعداد متزايدة يمكن أن تعزل ما إذا كان هناك مشكلة في المنفذ أو مع كبل المكدس.

وهذه يمكن جمعها عدة مرات على مدى دقائق قليلة لمقارنة الدلتاوات في العدد:

show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>

• المقطع الذي يحتوي على خطأ CRC للبيانات.

show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>

• زيادة على أي فحص CRC فاشل.

show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>

• تم التزايد على رمز PCs غير صالح، وهو رمز PCs غير معروف، والذي يقوم بتشغيل خطأ تباين مكتشف.

show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>

• تسبب خطأ البت في المكدس في حدوث خطأ في كلمة المرور CRC.

ل Polaris (16.x رمز) هذا الأمر:

show plat hardware fed sw <#/active/standby> fwd-asic register-name SifRacDataCrcErrorCnt asic <0-1> 

show plat hardware fed sw <#/active/standby> fwd-asic register-name SifRacRwCrcErrorCnt asic<0-1>

show plat hardware fed sw <#/active/standby> fwd-asic سجل قراءة اسم السجل SifRacPcsCodeWordErrorCnt asic <0-1>

show plat hardware fed sw <#/active/standby> fwd-asic register-name SifRacInvalidRingWordCnt asic <0-1>

يوضح هذا المثال المكان الذي كان لديك حدث دمج مكدس فيه شهد كلا العضوين في مكدس مكون من عضوين دون أي علامات على منفذ مكدس رفرفة. يمكنك الاطلاع على زيادة الحلقة [0] مع CRCs على منفذ المكدس-1 في المحول 1 وللتغلب على هذه المشكلة، استبدل كبل المكدس.

3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x00000031 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001
                               
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x000000c9 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001

نصائح إضافية

1. أرشفة أدلة Crashinfo

المزيد من المحولات في المكدس يعني أنه يمكن أن يكون هناك المزيد من ملفات التقرير التي سيتم تجميعها. ومن السهل أن نصاب بالارتباك بسبب عدد التقارير التي تصدر. ان التنظيم حيوي للفصل بين الفشل. ابحث عن تناسق مع الطوابع الزمنية الخاصة عندما يقوم كل محول بكتابة ملف تقرير لحدث معين إذا أمكن. ومن هناك، اطلب هذه التقارير المحددة جدا من تلك المحولات المحددة حتى لا يقوم العميل بتحميل عدة ملفات. كما يمكن أرشفة دليل crashinfo حتى يمكن لمستخدم Cisco إرسال أرشيف واحد يحتوي على التقارير المهتمة. يمكن أن يقوم المثال التالي بإنشاء أرشيف باسم crashinfo-archive.tar في دليل Flash:

F340.03.10-3800-1#archive tar /create ?
 WORD Tar filename

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
 WORD Dir to archive files from

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
 WORD File or Dir
 <cr>

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:

2. إستعادة مكدس غير مستقر

يمكن أن يكون هناك بعض الحالات التي ترى فيها عدة أعضاء في إعادة تحميل مكدس أثناء التمهيد بعد إجراء عملية إختيار المكدس. إذا اعتبر محول تم إعادة تحميله نفسه هو النشط، فيمكن أن يؤدي ذلك غالبا إلى حدث دمج مكدس ويمكن أن يدخل في حالة حلقة التمهيد. في هذه الحالة، قد يكون من المستحسن أن نسأل عميل Cisco:

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

3. إنشاء تقارير النظام يدويا

تتطلب تقارير النظام التي تم إنشاؤها يدويا تمكين الخدمة الداخلية. يقوم هذا بكتابة تقرير نظام كملف نصي يمكن تنفيذه لكل محول.

3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit

3800-1#resource create_system_report ?
 WORD system report filename

3800-1#resource create_system_report sysreport.txt ?
 switch Switch number
 <cr>

3800-1#resource create_system_report sysreport.txt switch ?
 <1-1> Switch number

3800-1#resource create_system_report sysreport.txt switch 1 ?
 <cr>

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

• الدعم الفني والتنزيلات من Cisco