استيعاب أخطاء التحقق من التكرار الدوري على مبدلات 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 التي تبدأ من برنامج NX-OS، الإصدار 9.3(8)

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

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

يصف هذا المستند تفاصيل حول أخطاء التحقق الدوري من التكرار (CRC) التي تمت ملاحظتها على عدادات الواجهة على محولات Cisco Nexus Series. يصف هذا المستند ما هو 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 نفسها عادة بواحدة من طريقتين: 

1. عدادات أخطاء متزايدة أو غير صفرية على واجهات الأجهزة المتصلة بالشبكة.
2. فقد الحزمة/الإطارات لحركة مرور البيانات التي تجتاز الشبكة بسبب الأجهزة المتصلة بالشبكة التي تسقط الإطارات التالفة.

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

تم تلقي أخطاء على 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، فهذا يعني أن جهاز الشبكة قام بإعادة توجيه إطار تالف في الشبكة. عند حدوث ذلك، يمكن لجهاز الشبكة زيادة عدادات إثنين: 

1. العداد "أخطاء الإدخال" على الواجهة التي تم إستلام الإطار التالف فيها في الأصل. 
2. العداد "أخطاء الإخراج" على جميع الواجهات التي تم إرسال الإطار التالف إليها. ل 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 Frame's CRC: 0xABCD (1010101111001101)
          Corrupted Frame's CRC: 0xDEAD (1101111010101101)
  Corrupted Frame's Stomped CRC: 0x2152 (0010000101010010)

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

تتبع وعزل أخطاء CRC

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

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

يصف هذا المستند أخطاء التحقق الدوري من التكرار (CRC) التي تمت ملاحظتها على عدادات الواجهة وإحصائيات محولات Cisco Nexus.

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

في هذا المخطط، تتصل الواجهة Ethernet1/1 لمحول Nexus المسمى Switch-1 بمضيف باسم Host-1 من خلال بطاقة واجهة الشبكة (NIC) ل Host-1. يتم توصيل الواجهة Ethernet1/2 الخاصة بالمحول 1 بمحول ثان من Nexus باسم المحول 2، من خلال واجهة إيثرنت للمحول 2/1. تتصل الواجهة Ethernet1/1 من المحول-2 بمضيف باسم Host-2 من خلال Host-2 NIC0.

يتلف الارتباط بين المضيف-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 هو عبارة عن محول pass-through يقوم بإعادة توجيه حركة مرور تالفة يتلقاها على بعض الواجهة الأخرى. كما هو موضح مسبقا مع المحول 2، يمكنك إستخدام الأمرshow interface counters errors 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 يستلم حركة مرور تالفة على هذه الواجهة. أنت تعرف أن هذا قارن يربط إلى مضيف-1'th0 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

يمكنك تحديد المكون المعيب من خلال عملية إزالة:

1. استبدل الوسط الفيزيائي (إما النحاس أو الألياف) أو DAC بوسيط فيزيائي معروف أنه جيد من النوع نفسه.
2. استبدل جهاز الإرسال والاستقبال المدرج في واجهة جهاز واحد بجهاز إرسال واستقبال معروف بجودة النموذج نفسه. إذا لم يؤدي هذا إلى حل أخطاء CRC، فاستبدل جهاز الإرسال والاستقبال الذي تم إدخاله في واجهة الجهاز الأخرى بجهاز إرسال/إستقبال معروف أنه جيد من النموذج نفسه.
3. إذا تم إستخدام أي لوحات تصحيح كجزء من الارتباط التالف، فقم بنقل الارتباط إلى منفذ معروف جيدا على لوحة التصحيح. بدلا من ذلك، قم باستبعاد لوحة التصحيح كسبب جذري محتمل عن طريق توصيل الارتباط بدون لوحة التصحيح إن أمكن.
4. انقل الارتباط التالف إلى منفذ آخر معروف جيدا على كل جهاز. أنت يستطيع تحتاج أن يختبر يتعدد ميناء مختلف أن يعزل MAC، ASIC، أو بطاقة خط إخفاق.
5. إذا كان الرابط تالف يحتوي على مضيف، فقم بنقل الارتباط إلى بطاقة واجهة شبكة (NIC) مختلفة على المضيف. بدلا من ذلك، قم بتوصيل الارتباط التالف بمضيف معروف أنه جيد لعزل فشل في بطاقة واجهة الشبكة (NIC) للمضيف.

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

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

• إجراء التعرف على ASIC CRC وتعقبه على مقياس السحابة Nexus 9000
• الدعم الفني والتنزيلات من Cisco