أستكشاف أخطاء إعادة التوجيه داخل البنية الخاصة بعنصر التحكم في الوصول (ACI) وإصلاحها - عمليات السقوط المتقطعة

المقدمة

يصف هذا المستند خطوات أستكشاف أخطاء عمليات الإسقاط المتقطعة في قائمة التحكم في الوصول (ACI) وإصلاحها.

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

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

أستكشاف أخطاء إعادة التوجيه داخل البنية الخاصة بعنصر التحكم في الوصول (ACI) وإصلاحها - عمليات السقوط المتقطعة

مثال على الطوبولوجيا

في هذا المثال، يواجه إختبار الاتصال من EP A (10.1.1.1) إلى EP B (10.1.2.1) حالات السقوط المتقطعة.

[EP-A ~]$ ping 10.1.2.1 -c 10
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_seq=1 ttl=231 time=142 ms
64 bytes from 10.1.2.1: icmp_seq=2 ttl=231 time=141 ms
                                   <-- missing icmp_seq=3

64 bytes from 10.1.2.1: icmp_seq=4 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=5 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=6 ttl=231 time=141 ms
                                    <-- missing icmp_seq=7

64 bytes from 10.1.2.1: icmp_seq=8 ttl=231 time=176 ms
64 bytes from 10.1.2.1: icmp_seq=9 ttl=231 time=141 ms
64 bytes from 10.1.2.1: icmp_seq=10 ttl=231 time=141 ms

--- 10.1.2.1 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9012ms

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

1. تحديد الإتجاه الذي يسبب عمليات السقوط المتقطعة

أنجزت ربط على قبض (tcpdump، wireshark، ...) على الغاية مضيف (EP B). بالنسبة ل ICMP، ركز على الرقم التسلسلي لرؤية الحزم التي يتم إسقاطها بشكل متقطع على EP B.

[admin@EP-B ~]$ tcpdump -ni eth0 icmp
11:32:26.540957 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 1, length 64
11:32:26.681981 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 1, length 64
11:32:27.542175 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 2, length 64
11:32:27.683078 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 2, length 64
11:32:28.543173 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 3, length 64   <---
11:32:28.683851 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 3, length 64     <---
11:32:29.544931 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 4, length 64
11:32:29.685783 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 3569, seq 4, length 64
11:32:30.546860 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 3569, seq 5, length 64
...

• النمط 1 - تتم ملاحظة جميع الحزم على التقاط حزمة EP B.

يجب أن تكون عمليات الإسقاط في رد صدى ICMP (EP B إلى EP A).

• النمط 2 - تتم ملاحظة عمليات السقوط المتقطعة عند التقاط حزمة EP B.

يجب أن تكون عمليات الإسقاط في صدى ICMP (EP A إلى EP B).

2. تحقق مما إذا كان لبروتوكول آخر يحتوي على نفس المصدر/الوجهة IP نفس المشكلة

إن أمكن، حاول إختبار الاتصال بين نقطتي النهاية باستخدام بروتوكول مختلف يسمح به العقد بينهما (مثل ssh، telnet، http،..)

• النمط 1 - تحتوي البروتوكولات الأخرى على نفس الإسقاط المتقطع.

يمكن أن تكون المشكلة في نقطة النهاية يرفرف أو يقوم بوضع قوائم الانتظار/التخزين المؤقت كما هو موضح أدناه.

• النمط 2 - يكون لبروتوكول ICMP وحده السقوط المتقطع.

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

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

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

3. تأكد ما إذا كان مرتبطا بمشكلة تعلم نقطة نهاية

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

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

4. تأكد ما إذا كان مرتبطا بمشاكل التخزين المؤقت عن طريق تغيير تكرار حركة المرور

قم بزيادة أو تقليل الفاصل الزمني لعملية إختبار الاتصال لمعرفة ما إذا كانت نسبة الإسقاط تتغير. يجب أن يكون فرق الفاصل الزمني كبيرا بما يكفي.

في Linux، يمكن إستخدام الخيار '-i' لتغيير الفاصل الزمني (ثانية):

[EP-A ~]$ ping 10.1.2.1 -c 10 -i 5     -- Increase it to 5 sec
[EP-A ~]$ ping 10.1.2.1 -c 10 -i 0.2   -- Decrease it to 0.2 msec

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

نسبة الإسقاط التي يجب مراعاتها هي (عدد حالات الإسقاط/إجمالي الحزم المرسلة) بدلا من (عدد حالات الإسقاط/الوقت).

في مثل هذا سيناريو، فحصت هذا شرط:

1. تحقق من زيادة أي عدادات إسقاط على واجهات المحول باستخدام عملية إختبار الاتصال. راجع قسم "عمليات إسقاط الواجهة" في الفصل "إعادة التوجيه بين البنى" للحصول على تفاصيل.
2. تحقق مما إذا كان عداد Rx يتزايد مع الحزم الموجودة على نقطة نهاية الوجهة. إذا تمت زيادة عداد Rx بنفس رقم الحزم المرسلة، فمن المحتمل أن يتم إسقاط الحزم على نقطة النهاية نفسها. قد يكون ذلك بسبب التخزين المؤقت لنقطة النهاية على مكدس TCP/IP.

على سبيل المثال، إذا تم إرسال 100000 إختبار مع فاصل زمني قصير قدر الإمكان، يمكن ملاحظة عداد Rx على نقطة النهاية مع زيادته بمقدار 100000.

[EP-B ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 10.1.2.1  netmask 255.255.255.0  broadcast 10.1.2.255
       ether 00:00:10:01:01:02  txqueuelen 1000  (Ethernet)
       RX packets 101105  bytes 1829041
       RX errors 0  dropped 18926930  overruns 0  frame 0
       TX packets 2057  bytes 926192
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

5. تحقق مما إذا كانت قائمة التحكم في الوصول (ACI) ترسل الحزم إلى الخارج أو أن الوجهة تتلقى الحزم

أخذت فسحة بين دعامتين التقاط على المخرج ميناء من الورقة مفتاح أن يزيل ACI بناء من ال يتحرى ممر.

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

رفرفة نقطة النهاية

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

• التقرير الرسمي حول "تعلم نقطة نهاية نهاية بنية بنية ACI" على موقع www.cisco.com
• "أستكشاف أخطاء Cisco Live BRKACI-2641 ACI وإصلاحها: نقاط النهاية على www.ciscolive.com

عندما يعلم ACI نفس MAC أو عنوان IP في مواقع متعددة، فإنه يبدو كما لو كانت نقطة النهاية قد تحركت. كما يمكن أن يحدث ذلك بسبب جهاز انتحال أو تكوين غير صحيح. ويشار إلى هذا السلوك باسم رفرفة نقطة النهاية. في مثل هذا السيناريو، تفشل حركة المرور نحو نقطة نهاية النقل/الارتحال (عنوان MAC لحركة المرور العابرة، عنوان IP لحركة المرور الموجهة) بشكل متقطع.

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

متعقب نقطة النهاية المحسن

تحذير إهمال! وقد كتب هذا الدليل في 4-2؛ ومنذ ذلك الحين، تم إهمال تطبيق Enhanced Endpoint Tracker لصالح وظائف "رؤى لوحة معلومات Nexus". للحصول على مزيد من المعلومات، راجع معرف تصحيح الأخطاء من Cisco CSCvz59365 .

تظهر هذه الصورة متتبع نقاط النهاية المحسن في AppCenter. يوضح هذا المثال كيفية العثور على نقاط النهاية الخاصة بالرفرفة مع متعقب نقطة النهاية المحسن.

مثال رفرفة نقطة النهاية

في هذا المثال، يمكن أن ينتمي IP 10.1.2.1 إلى EP B مع MAC 0000.1001.0102. ومع ذلك، تعمل EP X مع MAC 0000.1001.999 أيضا على توفير حركة مرور البيانات باستخدام IP 10.1.2.1 بسبب MIS-config أو ربما انتحال IP.

إخراج متعقب نقطة النهاية المحسن — التنقلات

يظهر متعقب نقطة النهاية المحسن متى وأين تم التعرف على IP 10.1.2.1. كما هو موضح في لقطة الشاشة السابقة، يرفرف 10.1.2.1 بين نقطتي نهاية مع MAC 0000.1001.0102 (متوقع) و 000.1001.999 (غير متوقع). هذا يسبب إصدار reachability نحو IP 10.1.2.1 لأن عندما يكون علمت على الخطأ {upper}mac address، الربط كنت أرسلت إلى أداة خطأ عن طريق القارن خاطئ. لحل هذه المشكلة، قم باتخاذ الخطوات اللازمة لمنع الأجهزة الافتراضية (VM) غير المتوقعة من إنشاء مصدر لحركة المرور باستخدام عنوان IP غير مناسب.

يوضح هذا المثال رفرفة نقطة النهاية بسبب تكوين غير مناسب.

مثال المخطط الذي قد يتسبب في رفرفة نقطة النهاية

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

عمليات إسقاط الواجهة

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

أنواع عداد إسقاط الأجهزة

في محولات Nexus 9000 التي تعمل في وضع قائمة التحكم في الوصول (ACI)، هناك ثلاثة عدادات أجهزة رئيسية على واجهة التحكم في الوصول لعمليات إسقاط واجهة الدخول.

إلى الأمام

الأسباب الرئيسية للانخفاض هي:

• Security_GROUP_DENY: إسقاط بسبب العقود المفقودة للسماح بالاتصال.
• vlan_xlate_ms: قطرة بسبب شبكة VLAN غير مناسبة. على سبيل المثال، يدخل إطار البنية مع شبكة 802.1Q VLAN رقم 10. إذا كان المحول لديه شبكة VLAN رقم 10 على المنفذ، فإنه يفحص المحتويات ويتخذ قرار إعادة التوجيه استنادا إلى MAC الوجهة. مهما، إن لا يسمح VLAN 10 يكون على الميناء، هو يسقطه ويلصقه ك VLAN_XLATE_MISS.
• ACL_DROP: قطرة بسبب "sup-tcam". يحتوي SUP-TCAM في محولات ACI على قواعد خاصة ليتم تطبيقها فوق قرار إعادة توجيه المستوى 2/L3 العادي. تم تضمين القواعد الموجودة في SUP-TCAM وهي ليست قابلة للتهيئة من قبل المستخدم. الهدف من قواعد SUP-TCAM بشكل رئيسي هو معالجة بعض الاستثناءات أو بعض حركة مرور مستوى التحكم وليس المقصود أن يتم فحصها أو مراقبتها من قبل المستخدمين. عندما تصل الحزمة إلى قواعد SUP-TCAM وتكون القاعدة هي إسقاط الحزمة، يتم حساب الحزمة التي سقطت ك ACL_DROP وتزيد من عداد الإسقاط الأمامي.

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

الخطأ

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

مصدا

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

عدادات التجميع باستخدام API

تجدر الإشارة إلى أنه من خلال الاستفادة من واجهة برمجة التطبيقات (API) ونموذج الكائن، يمكن للمستخدم الاستعلام بسرعة عن البنية لجميع مثيلات هذه عمليات الإسقاط (قم بتشغيل هذه من واجهة برمجة التطبيقات) - 

# FCS Errors (non-stomped CRC errors)
moquery -c rmonDot3Stats -f 'rmon.Dot3Stats.fCSErrors>="1"' | egrep "dn|fCSErrors"

# FCS + Stomped CRC Errors
moquery -c rmonEtherStats -f 'rmon.EtherStats.cRCAlignErrors>="1"' | egrep "dn|cRCAlignErrors"

# Output Buffer Drops
moquery -c rmonEgrCounters -f 'rmon.EgrCounters.bufferdroppkts>="1"' | egrep "dn|bufferdroppkts"

# Output Errors
moquery -c rmonIfOut -f 'rmon.IfOut.errors>="1"' | egrep "dn|errors"

عرض حالات الإسقاط في CLI

إذا تم ملاحظة وجود أخطاء، أو كانت هناك حاجة للتحقق من عمليات إسقاط الحزم على الواجهات باستخدام واجهة سطر الأوامر، فإن أفضل طريقة للقيام بذلك هي عرض عدادات النظام الأساسي في الجهاز. لا يتم عرض جميع العدادات باستخدام 'show interface'. يمكن عرض أسباب الإسقاط الرئيسية الثلاثة فقط باستخدام عدادات النظام الأساسي. لعرض هذه الخطوات، قم بتنفيذ الخطوات التالية:

ورقة

SSH إلى الورقة وشغل هذه الأوامر. هذا المثال خاص بالإيثرنت 1/31.

ACI-LEAF# vsh_lc
module-1# show platform internal counters port 31
Stats for port 31
(note: forward drops includes sup redirected packets too)
IF          LPort                    Input                       Output
                              Packets       Bytes          Packets    Bytes
eth-1/31    31  Total          400719   286628225      2302918    463380330
                   Unicast     306610   269471065       453831     40294786
                   Multicast        0           0      1849091    423087288
                   Flood        56783     8427482            0            0
                Total Drops     37327                        0
                   Buffer           0                        0
                   Error            0                        0
                   Forward      37327
                   LB               0
                   AFD RED                                   0
...

​ سباين

يمكن التحقق من عمود فقري ثابت (N9K-C9332C و N9K-C9364C) باستخدام نفس الطريقة كمحولات الأوراق.

بالنسبة لعمود فقري نمطي (N9K-C9504، ...)، يجب إرفاق بطاقة الخط قبل عرض عدادات النظام الأساسي. SSH إلى العامود الرئيسي وتشغيل هذه الأوامر. هذا المثال هو للإيثرنت 2/1.

ACI-SPINE# vsh
ACI-SPINE# attach module 2
module-2# show platform internal counters port 1
Stats for port 1
(note: forward drops include sup redirected packets too)
IF          LPort                    Input                       Output
                              Packets       Bytes          Packets    Bytes
eth-2/1      1  Total        85632884  32811563575     126611414   25868913406
                   Unicast   81449096  32273734109     104024872   23037696345
                   Multicast  3759719   487617769     22586542   2831217061
                   Flood            0           0            0            0
                Total Drops         0                        0
                   Buffer           0                        0
                   Error            0                        0
                   Forward          0
                   LB               0
                   AFD RED                                   0
...

يتم عرض عدادات حالات قوائم الانتظار باستخدام 'show queuing interface'. هذا المثال خاص بالإيثرنت 1/5.

ACI-LEAF# show queuing interface ethernet 1/5
================================================================================
                 Queuing stats for ethernet 1/5
================================================================================
================================================================================
                 Qos Class level1
================================================================================
Rx Admit Pkts :  0                      Tx Admit Pkts :  0                   
Rx Admit Bytes:  0                      Tx Admit Bytes:  0                   
Rx Drop Pkts  :  0                      Tx Drop Pkts  :  0                   
Rx Drop Bytes :  0                      Tx Drop Bytes :  0                   

================================================================================
                 Qos Class level2
================================================================================
Rx Admit Pkts :  0                      Tx Admit Pkts :  0                   
Rx Admit Bytes:  0                      Tx Admit Bytes:  0                   
Rx Drop Pkts  :  0                      Tx Drop Pkts  :  0                   
Rx Drop Bytes :  0                      Tx Drop Bytes :  0                   

================================================================================
                 Qos Class level3
================================================================================
Rx Admit Pkts :  1756121                Tx Admit Pkts :  904909              
Rx Admit Bytes:  186146554              Tx Admit Bytes:  80417455            
Rx Drop Pkts  :  0                      Tx Drop Pkts  :  22                  
Rx Drop Bytes :  0                      Tx Drop Bytes :  3776   

...

عرض الإحصائيات في واجهة المستخدم الرسومية (GUI)

الموقع هو 'بناء > جرد > ورقة/عمود فقري > واجهة مادية > حالات'.

إحصائيات واجهة GUI

إحصائيات الخطأ يمكن رؤيتها في نفس المكان:

أخطاء واجهة GUI

وأخيرا، يمكن لواجهة المستخدم الرسومية (GUI) عرض حالات جودة الخدمة لكل واجهة:

عدادات جودة خدمة واجهة GUI

CRC — FCS — التحويل المباشر

ما هو التحقق الدوري من التكرار (CRC)؟

تعتبر CRC وظيفة متعددة حدود على الإطار الذي يرجع رقم 4B في الإيثرنت. إنها تلتقط كل أخطاء البت المفردة ونسبة جيدة من أخطاء البت المزدوجة. وبالتالي فإن المقصود منه هو التأكد من أن الإطار لم يكن فاسدا أثناء النقل. إذا كان عداد أخطاء CRC في أزدياد، فهذا يعني أنه عندما قام الجهاز بتشغيل الدالة متعددة الحدود على الإطار، كانت النتيجة رقم 4B الذي يختلف عن رقم 4B الموجود على الإطار نفسه. يمكن أن تتلف الإطارات نظرا لعدة أسباب مثل عدم تطابق الإرسال ثنائي الإتجاه، والكابلات المعيبة، والأجهزة المكسورة. ومع ذلك، من المتوقع وجود مستوى ما من أخطاء CRC ويسمح المعيار بمعدل خطأ يصل إلى 10-12 بت على الإيثرنت (يمكن تحريك 1 بت من 1012).

التخزين وإعادة التوجيه مقابل التحويل المباشر

وتقوم كل من محولات الطبقة 2 للتخزين وإعادة التوجيه والتمرير على قرارات إعادة التوجيه الخاصة بها على عنوان MAC الوجهة لحزم البيانات. ويتعلمون أيضا عناوين MAC بينما يفحصون حقول MAC المصدر (SMAC) للحزم حيث تتصل المحطات بعقد أخرى على الشبكة.

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

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

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

قزم

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

ACI و CRC: البحث عن الواجهات المعيبة

• إن يرى ورقة خطأ CRC على خطوة لأسفل ميناء، هو غالبا مشكلة على ال downlink SFP أو مع مكون على الأداة/الشبكة الخارجية.
• إذا رأى العمود الرئيسي أخطاء CRC، فإنها مشكلة في الغالب على ذلك المنفذ المحلي أو SFP أو الألياف أو SFP المجاور. لا يتم غمر حزم CRC الفاشلة من الارتباطات السفلية لأوراق اللعب إلى العمود الفقري. كما لو كانت رؤوس VXLAN مقروءة، هو VXLAN مغلف ويحسب CRC جديد. إذا لم تكن الرؤوس قابلة للقراءة من تلف الإطار، سيتم إسقاط الحزمة.
• إذا رأت الورقة أخطاء CRC على روابط البنية، يمكن أن تكون:
  • مشكلة في زوج الألياف/SFP المحلي، أو مدخل العامود الرئيسي للألياف، أو زوج SFP.
  • إطار ممغوط يشق طريقه عبر النسيج.

الاستيعاب: أستكشاف أخطاء الاستيعاب وإصلاحها

• ابحث عن الواجهات التي بها أخطاء في تسلسل التحقق من الإطارات (FCS) على البنية. بما أن FCS يقع محلي إلى ميناء، هو على الأرجح الألياف أو SFP على أي طرف.
• تعكس أخطاء CRC في إخراج "show interface" إجمالي قيمة FCS+Stomp.\

انظر إلى مثال:

فحصت على ميناء مع الأمر

vsh_lc: 'show platform internal counter port <X>'

في هذا الأمر 3 قيمة مهمة:

• Rx_FCS_ERR - فشل FCS.
• RX_CRCERR - إطار خطأ CRC تم إستلامه.
• TX_FRM_ERROR - إطار خطأ CRC المنتقل.

module-1# show platform internal counters port 1 | egrep ERR
        RX_FCS_ERR           0     ---- Real error local between the devices and its direct neighbor
        RX_CRCERR            0     ---- Stomped frame --- so likely stomped by underlying devices and generated further down the network 
        TX_FRM_ERROR         0     ---- Packet received from another interface that was stomp on Tx direction

سيناريو أستكشاف أخطاء CRC الخاصة بالجهاز وإصلاحها

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