فهم أخطاء التحقق الدوري من التكرار على محولات Nexus
المحتويات
المقدمة
يصف هذا المستند التفاصيل المحيطة بأخطاء التحقق الدوري من التكرار (CRC) التي تمت ملاحظتها على عدادات الواجهة وإحصائيات محولات Cisco Nexus.
المتطلبات الأساسية
المتطلبات
cisco يوصي أن يفهم أنت الأساسية من إثرنيت تحويل وال cisco NX-OS أمر خط قارن (CLI). لمزيد من المعلومات، ارجع إلى أحد هذه المستندات القابلة للتطبيق:
- دليل التكوين الأساسي لنظام التشغيل Cisco Nexus 9000 NX-OS، الإصدار 10.2(x)
- دليل التكوين الأساسي لنظام التشغيل Cisco Nexus 9000 Series NX-OS، الإصدار 9.3(x)
- دليل التكوين الأساسي لنظام التشغيل Cisco Nexus 9000 Series NX-OS، الإصدار 9.2(x)
- دليل التكوين الأساسي لنظام التشغيل Cisco Nexus 9000 Series NX-OS، الإصدار 7.x
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- محولات Nexus 9000 Series التي تبدأ من برنامج NX-OS، الإصدار 9.3(8)
- محولات Nexus 3000 Series التي تبدأ من برنامج NX-OS، الإصدار 9.3(8)
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يصف هذا المستند التفاصيل المحيطة بأخطاء التحقق الدوري من التكرار (CRC) التي تمت ملاحظتها على عدادات الواجهة على محولات سلسلة Cisco Nexus. يصف هذا المستند ما المقصود ب CRC، وكيف يتم إستخدامه في حقل تسلسل التحقق من الإطارات (FCS) لإطارات إيثرنت، وكيف تظهر أخطاء CRC على محولات Nexus، وكيف تتفاعل أخطاء CRC في سيناريوهات التحويل والتبديل من المتجر وإعادة التوجيه، والأسباب الجذرية المحتملة لأخطاء CRC، وكيفية أستكشاف أخطاء CRC وإصلاحها وحلها.
الأجهزة القابلة للتطبيق
المعلومات الواردة في هذا المستند تنطبق على جميع محولات Cisco Nexus Series Switches. كما يمكن تطبيق بعض المعلومات الواردة في هذا المستند على منصات التوجيه والتحويل الأخرى من Cisco، مثل موجهات ومحولات Cisco Catalyst.
تعريف CRC
CRC هي آلية اكتشاف أخطاء تستخدم بشكل شائع في شبكات الكمبيوتر والتخزين لتحديد البيانات التي تم تغييرها أو تلفها أثناء الإرسال. عندما يحتاج جهاز متصل بالشبكة إلى إرسال البيانات، يقوم الجهاز بتشغيل خوارزمية حساب تستند إلى أكواد دائرية مقابل البيانات التي ينتج عنها رقم ذي طول ثابت. ويطلق على هذا الرقم ذي الطول الثابت اسم قيمة CRC، ولكن يطلق عليه عموما اسم CRC بإختصار. يتم إلحاق قيمة CRC هذه بالبيانات ويتم إرسالها من خلال الشبكة نحو جهاز آخر. يقوم هذا الجهاز البعيد بتشغيل نفس خوارزمية الرمز الدوري مقابل البيانات ويقارن القيمة الناتجة مع CRC المضاف إليها البيانات. إذا تطابقت كلتا القيمتين، يفترض الجهاز البعيد أنه تم إرسال البيانات عبر الشبكة دون أن تكون تالفة. إذا لم تتطابق القيم، يفترض الجهاز البعيد أن البيانات تالفة أثناء الإرسال عبر الشبكة. لا يمكن الوثوق بهذه البيانات التالفة ويتم تجاهلها.
يتم إستخدام قوائم التحكم في الوصول (CRC) للكشف عن الأخطاء عبر تقنيات شبكات الكمبيوتر المتعددة، مثل إيثرنت (متغيرات سلكية ولاسلكية)، و Token Ring، ووضع النقل غير المتزامن (ATM)، وترحيل الإطارات. تحتوي إطارات الإيثرنت على حقل تسلسل التحقق من الإطارات (FCS) 32-بت في نهاية الإطار (مباشرة بعد حمولة الإطار) حيث يتم إدراج قيمة CRC 32-بت.
على سبيل المثال، ضع في الاعتبار سيناريو حيث يكون مضيفان يدعيان Host-A و Host-B متصلين مباشرة ببعضهما البعض من خلال بطاقات واجهة الشبكة (NICs) الخاصة بهما. يحتاج المضيف-A إلى إرسال الجملة "هذا مثال" إلى المضيف-B عبر الشبكة. يحرف المضيف-A إطار إيثرنت معد للمضيف-B مع حمولة من "هذا مثال" ويحسب أن قيمة CRC الخاصة بالإطار هي قيمة سداسية عشرية من 0xABCD. يدخل المضيف-A قيمة CRC الخاصة ب 0xCRC في حقل FCS في إطار الإيثرنت، ثم يرسل إطار الإيثرنت خارج بطاقة واجهة الشبكة (NIC) الخاصة بالمضيف-A تجاه المضيف-B.
عندما يستلم Host-B هذا الإطار، فإنه سيحسب قيمة CRC الخاصة بالإطار باستخدام نفس الخوارزمية تماما مثل Host-A. الدالة HOST-B تحسب أن قيمة CRC الخاصة بالإطار هي قيمة سداسية عشرية من 0xABCD، والتي تشير إلى Host-B أن إطار الإيثرنت لم يكن تالفا أثناء إرسال الإطار إلى Host-B.
تعريف خطأ CRC
يحدث خطأ CRC عندما يستقبل جهاز (إما جهاز شبكة أو مضيف متصل بالشبكة) إطار إيثرنت بقيمة CRC في حقل FCS من الإطار الذي لا يطابق قيمة CRC التي تم حسابها بواسطة الجهاز للإطار.
وأفضل مثال يوضح هذا المفهوم. ضع في الاعتبار سيناريو حيث يكون مضيفان يدعيان Host-A و Host-B متصلين مباشرة ببعضهما البعض من خلال بطاقات واجهة الشبكة (NICs) الخاصة بهما. يحتاج المضيف-A إلى إرسال الجملة "هذا مثال" إلى المضيف-B عبر الشبكة. يحرف المضيف-A إطار إيثرنت معد للمضيف-B مع حمولة من "هذا مثال" ويحسب أن قيمة CRC الخاصة بالإطار هي القيمة السداسعشرية 0xABCD. يدخل المضيف-A قيمة CRC الخاصة ب 0xCRC في حقل FCS في إطار الإيثرنت، ثم يرسل إطار الإيثرنت خارج بطاقة واجهة الشبكة (NIC) الخاصة بالمضيف-A تجاه المضيف-B.
ومع ذلك، فإن التلف على الوسائط المادية التي تربط المضيف-A بالمضيف-B يفسد محتويات الإطار بحيث تتغير الجملة الموجودة داخل الإطار إلى "هذا مثال" بدلا من الحمولة المطلوبة من "هذا مثال".
عندما يستلم Host-B هذا الإطار، فإنه سيحسب قيمة CRC الخاصة بالإطار بما في ذلك الحمولة التالفة. الدالة HOST-B تحسب أن قيمة CRC الخاصة بالإطار هي قيمة سداسية عشرية من 0xDEAD، والتي تختلف عن 0xCRC القيمة داخل حقل FCS من إطار الإيثرنت. هذا فرق في قيمة CRC يخبر المضيف-B أن إطار الإيثرنت كان تالفا أثناء إرسال الإطار إلى Host-B. ونتيجة لذلك، لا يمكن للمضيف-B الوثوق بمحتويات إطار الإيثرنت هذا، لذلك سيقوم بإسقاطه. كما سيزيد المضيف-B عادة من عداد أخطاء ما على بطاقة واجهة الشبكة (NIC) الخاصة به، مثل عدادات "أخطاء الإدخال" أو "أخطاء CRC" أو "أخطاء RX".
الأعراض الشائعة لأخطاء CRC
تظهر أخطاء CRC نفسها عادة بواحدة من طريقتين:
- عدادات أخطاء متزايدة أو غير صفرية على واجهات الأجهزة المتصلة بالشبكة.
- فقد الحزمة/الإطارات لحركة مرور البيانات التي تجتاز الشبكة بسبب إسقاط الأجهزة المتصلة بالشبكة للإطارات التالفة.
تظهر هذه الأخطاء نفسها بطرق مختلفة قليلا حسب الجهاز الذي تعمل به. وتدخل هذه الأقسام الفرعية في التفاصيل لكل نوع من الأجهزة.
تم تلقي أخطاء على Windows Hosts
تظهر أخطاء CRC في Windows Host بشكل خاص كعداد أخطاء غير مستلمة صفرية معروض في إخراج الأمر netstat -e من موجه الأوامر. يوجد هنا مثال على عداد الأخطاء المتلقاة غير الصفرية من موجه أوامر مضيف Windows:
>netstat -e
Interface Statistics
Received Sent
Bytes 1116139893 3374201234
Unicast packets 101276400 49751195
Non-unicast packets 0 0
Discards 0 0
Errors 47294 0
Unknown protocols 0
يجب أن تدعم بطاقة واجهة الشبكة (NIC) وبرنامج التشغيل الخاص بها محاسبة أخطاء CRC التي تم استقبالها من قبل بطاقة واجهة الشبكة (NIC) لضمان دقة عدد الأخطاء المستلمة التي تم الإعلام عنها بواسطة الأمر netstat -e. إن معظم بطاقات واجهة الشبكة (NIC) الحديثة وبرامج تشغيلها الخاصة تدعم المحاسبة الدقيقة لأخطاء CRC التي تتلقاها NIC.
أخطاء RX في أجهزة لينوكس المضيفة
تظهر أخطاء CRC في مضيفي Linux بشكل خاص كعداد "أخطاء RX" غير صفرية معروض في إخراج الأمر ifconfig. هناك مثال على عداد أخطاء RX غير صفرية من مضيف Linux:
$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.0.2.10 netmask 255.255.255.128 broadcast 192.0.2.255
inet6 fe80::10 prefixlen 64 scopeid 0x20<link>
ether 08:62:66:be:48:9b txqueuelen 1000 (Ethernet)
RX packets 591511682 bytes 214790684016 (200.0 GiB)
RX errors 478920 dropped 0 overruns 0 frame 0
TX packets 85495109 bytes 288004112030 (268.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
يمكن أن تظهر أخطاء CRC على مضيف Linux أيضا كعداد "أخطاء RX" غير صفرية معروض في أمر إخراج ip -s link show. هناك مثال على عداد أخطاء RX غير صفرية من مضيف Linux:
$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 08:62:66:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
32246366102 444908978 478920 647 0 419445867
TX: bytes packets errors dropped carrier collsns
3352693923 30185715 0 0 0 0
altname enp11s0
يجب أن تدعم بطاقة واجهة الشبكة (NIC) وبرنامج التشغيل الخاص بها محاسبة أخطاء CRC التي تم استقبالها بواسطة بطاقة واجهة الشبكة (NIC) لعدد أخطاء RX التي تم الإعلام عنها بواسطة أوامر ifconfig أو ip -s link لتكون دقيقة. إن معظم بطاقات واجهة الشبكة (NIC) الحديثة وبرامج تشغيلها الخاصة تدعم المحاسبة الدقيقة لأخطاء CRC التي تتلقاها NIC.
أخطاء CRC على أجهزة الشبكة
تعمل أجهزة الشبكة في أحد وضعي إعادة التوجيه - وضع إعادة التوجيه والتخزين وإعادة التوجيه ووضع إعادة التوجيه التفصيلي. تختلف طريقة معالجة جهاز الشبكة لخطأ CRC تم تلقيه بناء على أوضاع إعادة التوجيه الخاصة به. ستصف الأقسام الفرعية هنا السلوك المحدد لكل وضع إعادة توجيه.
أخطاء إدخال على أجهزة شبكة التخزين وإعادة التوجيه
عندما يستقبل جهاز شبكة يعمل في وضع إعادة توجيه وتخزين، فإن جهاز الشبكة يقوم بتخزين الإطار بالكامل مؤقتا ("تخزين") قبل التحقق من قيمة CRC للإطار، واتخاذ قرار إعادة توجيه على الإطار، وإرسال الإطار خارج الواجهة ("إعادة توجيه"). وبالتالي، عندما يستقبل جهاز شبكة يعمل في وضع إعادة توجيه التخزين وإعادة التوجيه إطارا تالفا بقيمة CRC غير صحيحة على واجهة معينة، فإنه يسقط الإطار ويزيد من عداد "أخطاء الإدخال" على الواجهة.
بمعنى آخر، لا يتم إعادة توجيه إطارات الإيثرنت الفاسدة بواسطة أجهزة الشبكة التي تعمل في وضع إعادة توجيه التخزين وإعادة التوجيه، ويتم إسقاطها على الدخول.
تعمل المحولات من السلسلة Cisco Nexus 7000 و 7700 في وضع إعادة توجيه التخزين وإعادة التوجيه. هنا مثال على عداد أخطاء إدخال غير صفرية وعداد CRC/FCS غير صفري من محول Nexus 7000 أو 7700 Series Switch:
switch# show interface
<snip>
Ethernet1/1 is up
RX
241052345 unicast packets 5236252 multicast packets 5 broadcast packets
245794858 input packets 17901276787 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 579204 CRC/FCS 0 no buffer
579204 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
كما يمكن أن تظهر أخطاء CRC نفسها كعداد "FCS-Err" غير صفري في إخراج أخطاء عدادات العرض. سيكون لعداد "Rcv-Err" في إخراج هذا الأمر أيضا قيمة غير صفرية، وهي مجموع جميع أخطاء الإدخال (CRC أو خلاف ذلك) التي تم تلقيها بواسطة الواجهة. ويتم توضيح مثال على ذلك هنا:
switch# show interface counters errors
<snip>
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/1 0 579204 0 579204 0 0
أخطاء الإدخال والإخراج على أجهزة التوصيل عبر الشبكة
عندما يبدأ جهاز شبكة يعمل في وضع إعادة التوجيه بالقطع في تلقي إطار، يقوم جهاز الشبكة باتخاذ قرار إعادة توجيه على رأس الإطار ويبدأ في إرسال الإطار خارج الواجهة بمجرد إستلامه ما يكفي من الإطار لاتخاذ قرار إعادة توجيه صالح. بما أن رؤوس الحزم والإطار في بداية الإطار، فإن قرار إعادة التوجيه هذا يتم إتخاذه عادة قبل إستلام حمولة الإطار.
يقع حقل FCS الخاص بإطار إيثرنت في نهاية الإطار، مباشرة بعد حمولة الإطار. لذلك، سيكون جهاز الشبكة الذي يعمل في وضع إعادة التوجيه بالقطع قد بدأ بالفعل في إرسال الإطار من واجهة أخرى بحلول الوقت الذي يمكنه فيه حساب CRC الخاص بالإطار. إذا لم تتطابق قيمة CRC التي تم حسابها بواسطة جهاز الشبكة للإطار مع قيمة CRC الموجودة في حقل FCS، فهذا يعني أن جهاز الشبكة قام بإعادة توجيه إطار تالف في الشبكة. عند حدوث ذلك، سيزيد جهاز الشبكة من عقيدين:
- العداد "أخطاء الإدخال" على الواجهة التي تم إستلام الإطار التالف فيها في الأصل.
- العداد "أخطاء الإخراج" على جميع الواجهات التي تم إرسال الإطار التالف إليها. ل unicast حركة مرور، هذا بشكل خاص يكون قارن وحيد - مهما، للبث، multicast، أو مجهول unicast حركة مرور، هذا أمكن كنت واحد أو أكثر قارن.
ويتم توضيح مثال على ذلك هنا، حيث يشير إخراج أمر show interface إلى أنه تم إستلام إطارات فاسدة متعددة على الإيثرنت 1/1 لجهاز الشبكة وتم إرسالها من الإيثرنت 1/2 بسبب وضع إعادة توجيه التوصيل التوصيل من جهاز الشبكة:
switch# show interface
<snip>
Ethernet1/1 is up
RX
46739903 unicast packets 29596632 multicast packets 0 broadcast packets
76336535 input packets 6743810714 bytes
15 jumbo packets 0 storm suppression bytes
0 runts 0 giants 47294 CRC 0 no buffer
47294 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
Ethernet1/2 is up
TX
46091721 unicast packets 2852390 multicast packets 102619 broadcast packets
49046730 output packets 3859955290 bytes
50230 jumbo packets
47294 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
كما يمكن أن تظهر أخطاء CRC نفسها كعداد "FCS-Err" غير صفري على واجهة الدخول والعدادات غير الصفرية "Xmit-Err" على واجهات الخروج في إخراج أخطاء show interface counters. سيكون لعداد "RCV-Err" على واجهة الدخول في إخراج هذا الأمر أيضا قيمة غير صفرية، وهي مجموع جميع أخطاء الإدخال (CRC أو خلاف ذلك) التي تم تلقيها بواسطة الواجهة. ويتم توضيح مثال على ذلك هنا:
switch# show interface counters errors
<snip>
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/1 0 47294 0 47294 0 0
Eth1/2 0 0 47294 0 0 0
سيقوم جهاز الشبكة أيضا بتعديل قيمة CRC في حقل FCS للإطار بطريقة محددة تدل على أجهزة الشبكة من الخادم أن هذا الإطار تالف. ويعرف هذا السلوك باسم "غمس" لجنة حقوق الطفل. تختلف الطريقة الدقيقة التي يتم بها تعديل CRC من نظام أساسي إلى آخر، ولكن بشكل عام، تتضمن عكس قيمة CRC الحالية الموجودة في حقل FCS للإطار. هنا مثال على ذلك:
Original CRC: 0xABCD (1010101111001101)
Stomped CRC: 0x5432 (0101010000110010)
ونتيجة لهذا السلوك، يمكن لأجهزة الشبكة التي تعمل في وضع إعادة التوجيه بالقطع أن تنشر إطارا فاسدا عبر الشبكة. إذا كانت الشبكة تتكون من أجهزة شبكة متعددة تعمل في وضع النقل من خلال إعادة التوجيه، يمكن أن يتسبب إطار فاسد واحد في زيادة عدادات خطأ الإدخال والخطأ للإخراج على أجهزة شبكة متعددة داخل شبكتك.
تتبع وعزل أخطاء CRC
تتمثل الخطوة الأولى لتحديد السبب الجذري لأخطاء CRC وحلها في عزل مصدر أخطاء CRC عن إرتباط محدد بين جهازين داخل الشبكة. يحتوي أحد الأجهزة المتصلة بهذا الارتباط على عداد أخطاء إخراج واجهة بقيمة صفر أو لا يزيد، بينما سيكون لدى الجهاز الآخر المتصل بهذا الارتباط عداد أخطاء إدخال واجهة غير صفرية أو يتزايد. هذا يقترح أن حركة مرور يفرز القارن من واحد أداة كامل تالفة في وقت الإرسال إلى الجهاز البعيد، ويحسب كخطأ إدخال من قبل المدخل قارن من الآخر أداة على الخطوة.
يعتبر تحديد هذا الارتباط في شبكة تتكون من أجهزة شبكة تعمل في وضع إعادة توجيه المتجر وإعادة التوجيه مهمة مباشرة. ومع ذلك، فإن تحديد هذا الارتباط في شبكة تتكون من أجهزة شبكة تعمل في وضع إعادة التوجيه بالقطع السريع أكثر صعوبة، نظرا لأن العديد من أجهزة الشبكة سيكون لديها عدادات أخطاء إدخال وإخراج غير صفرية. مثال من هذه الظاهرة يمكن ان نري في الطبولوجيا هنا، حيث الرابط ابرزت في الاحمر تالف بحيث حركة المرور عبر الرابط تالف. تشير الواجهات المسماة بحرف "I" إلى الواجهات التي قد تحتوي على أخطاء إدخال غير صفرية، بينما تشير الواجهات المسماة ب "O" الأزرق إلى الواجهات التي قد تحتوي على أخطاء إخراج غير صفرية.
يتطلب تحديد الارتباط المعيب تتبع الإطارات التالفة "للمسار" بشكل متكرر في الشبكة من خلال عدادات أخطاء الإدخال والإخراج غير الصفرية، مع وجود أخطاء إدخال غير صفرية تشير إلى الخادم نحو الارتباط التالف في الشبكة. هذا موضح في الرسم البياني هنا.
ومن خلال مثال على ذلك، يتم توضيح عملية مفصلة لتعقب إرتباط تالف والتعرف عليه. ولنتأمل هنا المخطط:
في هذا المخطط، تتصل الواجهة Ethernet1/1 لمحول Nexus المسمى Switch-1 بمضيف باسم Host-1 من خلال بطاقة واجهة الشبكة (NIC) ل Host-1. يتم توصيل الواجهة Ethernet1/2 الخاصة بالمحول 1 بمحول ثان من Nexus باسم المحول 2، من خلال واجهة إيثرنت للمحول 2/1. تتصل الواجهة Ethernet1/1 الخاصة بالمحول-2 بمضيف باسم Host-2 من خلال NIC الخاص بالمضيف-2.
يتلف الارتباط بين المضيف-1 والمحول-1 من خلال واجهة إيثرنت 1/1 الخاصة بالمحول، مما يتسبب في تلف حركة مرور البيانات التي تجتاز الارتباط بشكل متقطع. غير أننا لا نعرف حتى الآن أن هذا الارتباط تالف. يجب علينا تتبع المسار الذي تتركه الإطارات التالفة في الشبكة من خلال عدادات أخطاء الإدخال والإخراج غير صفرية أو متزايدة لتحديد موقع الارتباط التالف في هذه الشبكة.
في هذا المثال، تشير بطاقة واجهة الشبكة (NIC) الخاصة بالمضيف-2 إلى أنه يتلقى أخطاء CRC.
Host-2$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
32246366102 444908978 478920 647 0 419445867
TX: bytes packets errors dropped carrier collsns
3352693923 30185715 0 0 0 0
altname enp11s0
أنت تعرف أن بطاقة واجهة الشبكة (NIC) الخاصة بالمضيف-2 تتصل بالمحول 2 عبر واجهة إيثرنت 1/1. أنت يستطيع أكدت أن قارن إثرنيت 1/1 يتلقى غير صفري إنتاج خطأ عداد مع العرض قارن أمر.
Switch-2# show interface
<snip>
Ethernet1/1 is up
admin state is up, Dedicated Interface
RX
30184570 unicast packets 872 multicast packets 273 broadcast packets
30185715 input packets 3352693923 bytes
0 jumbo packets 0 storm suppression bytes
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
444907944 unicast packets 932 multicast packets 102 broadcast packets
444908978 output packets 32246366102 bytes
0 jumbo packets
478920 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
بما أن عداد أخطاء الإخراج للواجهة Ethernet1/1 غير صفري، فهناك على الأرجح واجهة أخرى للمحول-2 تحتوي على عداد أخطاء إدخال غير صفري. يمكنك إستخدام الأمر show interface counters non-zero لتحديد ما إذا كانت أي واجهات للمحول-2 تحتوي على عداد أخطاء إدخال غير صفرية.
Switch-2# show interface counters errors non-zero <snip> -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/1 0 0 478920 0 0 0 Eth1/2 0 478920 0 478920 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port InDiscards --------------------------------------------------------------------------------
أنت يستطيع رأيت أن إثرنيت 1/2 من مفتاح-2 يتلقى غير صفري مدخل خطأ عداد. هذا يقترح أن يستلم مفتاح-2 حركة مرور يفسد على هذا قارن. يمكنك تأكيد الجهاز المتصل بالإيثرنت 1/2 للمحول-2 من خلال ميزات بروتوكول اكتشاف الارتباط (CDP) أو بروتوكول اكتشاف الارتباط المحلي (LLDP). يتم عرض مثال على ذلك هنا باستخدام الأمر show cdp neighbors.
Switch-2# show cdp neighbors
<snip>
Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge
S - Switch, H - Host, I - IGMP, r - Repeater,
V - VoIP-Phone, D - Remotely-Managed-Device,
s - Supports-STP-Dispute
Device-ID Local Intrfce Hldtme Capability Platform Port ID
Switch-1(FDO12345678)
Eth1/2 125 R S I s N9K-C93180YC- Eth1/2
أنت الآن تعرف أن المحول 2 يتلقى حركة مرور تالفة على واجهة الإيثرنت 1/2 الخاصة به من واجهة الإيثرنت 1/2 الخاصة بالمحول-1، ولكن لا تعرف بعد ما إذا كان الارتباط بين إيثرنت 1/2 الخاص بالمحول 1 وإيثرنت المحول 2 1/2 تالفا ويتسبب في التلف، أو إذا كان المحول 1 عبارة عن حركة مرور تالفة يتم استقبالها عبر المحول. يجب تسجيل الدخول إلى المحول-1 للتحقق من ذلك.
يمكنك تأكيد أن واجهة إيثرنت 1/2 الخاصة بالمحول 1 تحتوي على عداد أخطاء إخراج غير صفرية باستخدام الأمر show interfaces.
Switch-1# show interface
<snip>
Ethernet1/2 is up
admin state is up, Dedicated Interface
RX
30581666 unicast packets 178 multicast packets 931 broadcast packets
30582775 input packets 3352693923 bytes
0 jumbo packets 0 storm suppression bytes
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
454301132 unicast packets 734 multicast packets 72 broadcast packets
454301938 output packets 32246366102 bytes
0 jumbo packets
478920 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
أنت يستطيع رأيت أن إثرنيت 1/2 من مفتاح-1 يتلقى غير صفري إنتاج خطأ عداد. وهذا يشير إلى أن الارتباط بين إيثرنت 1/2 الخاص بالمحول 1/2 وإيثرنت 1/2 الخاص بالمحول 2 غير تالف - وبدلا من ذلك، فإن المحول 1 هو عبارة عن محول تمرير مباشر لإعادة توجيه حركة مرور تالفة يتلقاها على بعض الواجهة الأخرى. كما هو موضح مسبقا مع المحول-2، يمكنك إستخدام الأمر show interface counters non-zero لتحديد ما إذا كانت أي واجهات للمحول-1 تحتوي على عداد أخطاء إدخال غير صفرية.
Switch-1# show interface counters errors non-zero <snip> -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/1 0 478920 0 478920 0 0 Eth1/2 0 0 478920 0 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port InDiscards --------------------------------------------------------------------------------
أنت يستطيع رأيت أن إثرنيت 1/1 من مفتاح-1 يتلقى غير صفري مدخل خطأ عداد. هذا يقترح أن المحول-1 يستلم حركة مرور تالفة على هذه الواجهة. نعلم أن هذه الواجهة تتصل ب Host-1's0 NIC. يمكننا مراجعة إحصائيات واجهة بطاقة واجهة الشبكة (NIC) ل Host-1 لتأكيد ما إذا كان Host-1 يرسل الإطارات التالفة من هذه الواجهة.
Host-1$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
73146816142 423112898 0 0 0 437368817
TX: bytes packets errors dropped carrier collsns
3312398924 37942624 0 0 0 0
altname enp11s0
تشير إحصائيات ETH0 NIC الخاصة ب Host-1 إلى أن المضيف لا يرسل حركة مرور تالفة. وهذا يشير إلى أن الارتباط بين ETH0 الخاص بالمضيف-1 وإيثرنت المحول-1 تالف وهو مصدر تلف حركة مرور البيانات هذه. يلزم إجراء المزيد من أستكشاف الأخطاء وإصلاحها على هذا الارتباط لتحديد المكون المعيب الذي يتسبب في هذا التلف واستبداله.
الأسباب الجذرية لأخطاء CRC
أكثر الأسباب الجذرية شيوعا لأخطاء CRC هو تلف أو خلل في مكون إرتباط فعلي بين جهازين. الأمثلة تتضمن:
- وسط طبيعي معطل أو تالف (نحاسي أو ليفي) أو كبلات متصلة مباشرة (DAC).
- أجهزة الإرسال والاستقبال/البصريات التي تعرضت للفشل أو التلف.
- منافذ لوحة تصحيح معطلة أو تالفة.
- أجهزة جهاز الشبكة المعيبة (بما في ذلك منافذ معينة ودوائر متكاملة خاصة بتطبيقات الخطوط [ASICs] وعناصر التحكم في الوصول إلى الوسائط [MACs] ووحدات البنية، وما إلى ذلك)،
- تم إدخال بطاقة واجهة شبكة غير صحيحة في مضيف.
من الممكن أيضا أن يتسبب جهاز واحد أو أكثر من الأجهزة التي تم تكوينها بشكل غير مقصود في أخطاء CRC داخل الشبكة. وأحد الأمثلة على ذلك هو عدم تطابق تكوين وحدة الإرسال القصوى (MTU) بين جهازين أو أكثر داخل الشبكة مما يتسبب في اقتطاع الحزم الكبيرة بشكل غير صحيح. من الممكن أن يؤدي تحديد مشكلة التكوين هذه وحلها إلى تصحيح أخطاء CRC داخل الشبكة أيضا.
حل أخطاء CRC
يمكنك تحديد المكون المعيب من خلال عملية إزالة:
- استبدل الوسط الفيزيائي (إما النحاس أو الألياف) أو DAC بوسيط فيزيائي معروف أنه جيد من النوع نفسه.
- استبدل جهاز الإرسال والاستقبال المدرج في واجهة جهاز واحد بجهاز إرسال واستقبال معروف بجودة النموذج نفسه. إذا لم يؤدي هذا إلى حل أخطاء CRC، فاستبدل جهاز الإرسال والاستقبال الذي تم إدخاله في واجهة الجهاز الآخر بجهاز إرسال/إستقبال معروف أنه جيد من النموذج نفسه.
- إذا تم إستخدام أي لوحات تصحيح كجزء من الارتباط التالف، فقم بنقل الارتباط إلى منفذ معروف جيدا على لوحة التصحيح. بدلا من ذلك، قم باستبعاد لوحة التصحيح كسبب جذري محتمل عن طريق توصيل الارتباط بدون إستخدام لوحة التصحيح إن أمكن.
- انقل الارتباط التالف إلى منفذ آخر معروف جيدا على كل جهاز. أنت تحتاج أن يختبر يتعدد ميناء مختلف أن يعزل MAC، ASIC، أو خط بطاقة إخفاق.
- إذا كان الرابط تالف يحتوي على مضيف، فقم بنقل الارتباط إلى بطاقة واجهة شبكة (NIC) مختلفة على المضيف. بدلا من ذلك، قم بتوصيل الارتباط التالف بمضيف معروف أنه جيد لعزل فشل في بطاقة واجهة الشبكة (NIC) للمضيف.
إذا كان المكون الذي لا يعمل بشكل صحيح عبارة عن منتج Cisco (مثل جهاز شبكة Cisco أو جهاز إرسال/إستقبال) الذي يغطيه عقد دعم نشط، فيمكنك فتح حالة دعم مع تفصيل Cisco TAC أستكشاف الأخطاء وإصلاحها لاستبدال المكون الذي لا يعمل بشكل صحيح من خلال "تفويض المواد العائدة" (RMA).
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
3.0 |
10-Nov-2021 |
تحسين التنسيق الثانوي للمستند |
2.0 |
10-Nov-2021 |
الإصدار الأولي |
1.0 |
10-Nov-2021 |
الإصدار الأولي |
التعليقات