CRC Error در سوئیچ سیسکو چیست؟ علت، تشخیص و رفع خطای CRC

اگر در یک سوئیچ Cisco مقدار CRC Error روی یکی از Interfaceها در حال افزایش است، صرفاً با دیدن این Counter نباید نتیجه گرفت که خود سوئیچ خراب شده است. CRC Error یک Symptom یا نشانه از وجود مشکل در دریافت Frame است و برای پیدا کردن علت واقعی باید مسیر انتقال داده، کابل، Patch Cord، Connector، SFP، Fiber، Interface و حتی کارت شبکه دستگاه مقابل بررسی شود.

در محیط‌های عملیاتی، نادیده گرفتن CRCهای رو به افزایش می‌تواند به افت کیفیت ارتباط، Retransmission، Packet Loss، افزایش Latency و در بعضی سناریوها اختلال محسوس در سرویس منجر شود. بنابراین مهم‌ترین سؤال این نیست که «CRC چیست؟» بلکه این است که CRC از چه زمانی شروع شده، روی کدام Interface دیده می‌شود و آیا Counter همچنان در حال افزایش است یا خیر.

در این مقاله از یک روش مرحله‌به‌مرحله برای Troubleshooting استفاده می‌کنیم تا بتوانید از روی Interface Counters و تست‌های Elimination، احتمال خرابی هر بخش را محدود کرده و به Root Cause برسید.

CRC Error در سوئیچ سیسکو چیست؟

CRC مخفف Cyclic Redundancy Check است و یکی از روش‌های تشخیص خطای داده در شبکه‌های Ethernet محسوب می‌شود. در زمان دریافت یک Frame، تجهیزات شبکه از اطلاعات کنترل خطا مانند Frame Check Sequence یا FCS برای تشخیص خراب شدن داده استفاده می‌کنند. اگر بررسی انجام‌شده با مقدار مورد انتظار مطابقت نداشته باشد، Frame دارای خطا تشخیص داده می‌شود.

در Cisco Switch، افزایش Counter مربوط به CRC معمولاً نشان می‌دهد که Interface در دریافت Frameهایی با مشکل یکپارچگی داده مواجه شده است. علت این اتفاق می‌تواند در مسیر فیزیکی انتقال، Transceiver، کابل، Connector، Interface یا دستگاه متصل به سمت دیگر لینک باشد. بنابراین CRC Error به‌تنهایی اثبات نمی‌کند که Switch خراب است.

CRC چیست و در Ethernet چه کاری انجام می‌دهد؟

در شبکه Ethernet، داده به شکل Frame منتقل می‌شود. Frame علاوه بر Payload و اطلاعات کنترلی، دارای سازوکاری برای بررسی صحت داده است. یکی از اجزای مهم این سازوکار Frame Check Sequence یا FCS است.

CRC یک محاسبه ریاضی است که برای تشخیص تغییر یا خراب شدن داده در مسیر انتقال استفاده می‌شود. فرستنده بر اساس داده موجود مقدار مشخصی تولید می‌کند و اطلاعات لازم برای بررسی در Frame قرار می‌گیرد. گیرنده نیز داده دریافت‌شده را بررسی می‌کند. اگر نتیجه بررسی با مقدار مورد انتظار مطابقت نداشته باشد، Frame به‌عنوان خراب تشخیص داده می‌شود.

نکته مهم این است که CRC اساساً یک Error Detection Mechanism است، نه مکانیزمی برای تعمیر داده خراب. یعنی CRC به تجهیزات کمک می‌کند بفهمند داده‌ای که دریافت شده سالم نیست؛ اما خودش داده خراب را اصلاح نمی‌کند.

FCS چه ارتباطی با CRC دارد؟

در Ethernet، FCS بخشی از Frame است که برای بررسی Integrity داده استفاده می‌شود و CRC الگوریتمی است که در تولید و بررسی این مقدار نقش دارد. به همین دلیل در خروجی بعضی ابزارهای Cisco ممکن است Counterهای CRC و FCS را مشاهده کنید.

نحوه نمایش و تفکیک این Counterها ممکن است با توجه به Platform، نسخه IOS یا IOS XE و نوع Interface متفاوت باشد؛ بنابراین نباید تعریف یک Counter در یک خانواده از تجهیزات را بدون بررسی مستندات همان Platform به تمام تجهیزات Cisco تعمیم داد.

CRC Error در Cisco Switch دقیقاً چه معنایی دارد؟

وقتی در خروجی Interface Counters یک Cisco Switch مقدار CRC مشاهده می‌کنید، باید آن را به‌عنوان یک نشانه از دریافت Frame دارای خطای Integrity در نظر بگیرید. این نشانه به‌تنهایی Root Cause را مشخص نمی‌کند.

برای مثال، اگر یک Server با کابل مسی به سوئیچ متصل باشد و CRC روی Port مربوط به Server افزایش پیدا کند، چند احتمال وجود دارد:

• Patch Cable معیوب است.
• یکی از Connectorها مشکل دارد.
• Patch Panel یا مسیر کابل‌کشی مشکل دارد.
• Port سوئیچ دچار مشکل شده است.
• NIC سرور مشکل دارد.
• در مسیر کابل اختلال فیزیکی وجود دارد.
• تنظیمات یا شرایط Link نیاز به بررسی بیشتر دارد.

بنابراین باید بین دو مفهوم تفاوت بگذاریم:

• Symptom: چیزی که در Counter می‌بینیم؛ مثلاً افزایش CRC.
• Root Cause: علت واقعی؛ مثلاً Patch Cord خراب، SFP معیوب یا مشکل Interface.

مهم‌ترین علت‌های CRC Error در سوئیچ Cisco

هیچ‌یک از موارد زیر نباید بدون تست به‌عنوان علت قطعی معرفی شود. هدف Troubleshooting این است که با تغییر کنترل‌شده یک متغیر، مشخص کنیم مشکل از کدام بخش است.

کابل شبکه خراب یا بی‌کیفیت

در لینک‌های Copper، کابل یکی از اولین مواردی است که باید بررسی شود. آسیب فیزیکی، کیفیت نامناسب، Termination ضعیف یا مشکل در زوج‌های کابل می‌تواند باعث خطا در انتقال داده شود.

روش تشخیص: کابل را با یک کابل سالم و دارای کیفیت مناسب تعویض کنید و Counter را قبل و بعد از تست مقایسه کنید.

اگر CRC متوقف شد: کابل قبلی یکی از مظنون‌های اصلی است.

اگر CRC ادامه داشت: کابل تنها علت نبوده و باید Port، سمت مقابل و مسیر فیزیکی بررسی شود.

Patch Cord خراب

گاهی کابل‌کشی دائمی کاملاً سالم است اما Patch Cord بین Patch Panel و Switch یا بین Patch Panel و Server دچار مشکل است. به همین دلیل تعویض Patch Cord یکی از سریع‌ترین تست‌های Elimination است.

Connector یا Keystone مشکل‌دار

Termination ضعیف، اتصال نامناسب یا خرابی Keystone می‌تواند باعث خطاهای انتقال شود. اگر تعویض Patch Cord هیچ تغییری ایجاد نکرد، مسیر فیزیکی و Terminationها را بررسی کنید.

Patch Panel

در شبکه‌های Structured Cabling، Patch Panel بخشی از مسیر فیزیکی لینک است. بنابراین نباید صرفاً به Switch و Patch Cord توجه کرد. اگر با تعویض Patch Cord مشکل باقی ماند، مسیر بین Switch و Endpoint را مرحله‌به‌مرحله بررسی کنید.

کابل‌کشی Structured Cabling

کابل‌کشی دائمی، طول مسیر، کیفیت Termination و وضعیت فیزیکی کابل باید در نظر گرفته شود. در صورت تکرار خطا، استفاده از تستر مناسب کابل‌کشی می‌تواند اطلاعات بیشتری نسبت به مشاهده صرف Counterهای Cisco ارائه کند.

SFP مشکل‌دار

در لینک‌های مبتنی بر Fiber یا برخی لینک‌های مسی، SFP یا Transceiver نیز باید بررسی شود. خرابی Transceiver ممکن است باعث مشکلات ارتباطی شود و در چنین شرایطی باید وضعیت Optical و اطلاعات Transceiver بررسی شود.

SFP ناسازگار یا معیوب

Compatibility میان Transceiver و Platform اهمیت دارد. اگر مشکل پس از نصب یا تعویض یک SFP جدید آغاز شده است، بررسی Part Number، نوع Transceiver، نوع Fiber و سازگاری آن با Platform ارزش بالایی دارد.

Transceiver

در لینک‌های Optical، Transceiver را می‌توان به‌عنوان یکی از متغیرهای مستقل تست کرد. در صورت وجود امکان، استفاده از یک Transceiver سالم و سازگار برای تست می‌تواند مشخص کند که آیا خطا همراه Transceiver جابه‌جا می‌شود یا خیر.

Fiber Optic

در لینک Fiber، کابل Patch، Connector، مسیر Fiber، نوع Fiber و وضعیت Optical باید بررسی شود. برخلاف کابل مسی، ظاهر سالم Fiber الزاماً به معنی سالم بودن لینک نیست.

کثیف بودن Connector فیبر

آلودگی روی Connector می‌تواند کیفیت Optical Link را کاهش دهد. در چنین شرایطی بررسی و نگهداری صحیح Connectorها اهمیت زیادی دارد. هرگونه تمیزکاری باید با ابزار و روش استاندارد مربوط به تجهیزات Fiber انجام شود.

خم شدید یا آسیب Fiber

خم شدن بیش از حد، آسیب مکانیکی یا مشکل در مسیر Fiber می‌تواند روی کیفیت سیگنال اثر بگذارد. اگر CRC روی یک لینک Optical به شکل مستمر افزایش پیدا می‌کند، بررسی مسیر و Optical Power می‌تواند مفید باشد.

مشکل Interface روی Switch

گاهی مشکل واقعاً از Port سوئیچ است. یکی از روش‌های مفید برای تشخیص این وضعیت، انتقال Endpoint به Port دیگری است؛ البته این تست باید به‌صورت کنترل‌شده انجام شود تا نتیجه قابل تفسیر باشد.

اگر همان Endpoint با کابل و شرایط مشابه روی Port دیگر بدون افزایش CRC کار کند، احتمال وجود مشکل در Port قبلی بیشتر می‌شود؛ اما باز هم باید سایر متغیرها را در نظر گرفت.

مشکل NIC روی Server یا Client

کارت شبکه دستگاه مقابل نیز بخشی از Link است. اگر CRC فقط روی ارتباط یک Server دیده می‌شود و تعویض کابل و Port نتیجه نمی‌دهد، بررسی NIC، Driver، Firmware و وضعیت Interface روی Server منطقی است.

مشکل تجهیزات طرف مقابل

در یک لینک، Switch تنها یک سمت ارتباط است. اگر دستگاه مقابل Switch، Router، Server، Firewall یا تجهیز دیگری باشد، Interface همان دستگاه نیز باید بررسی شود.

Speed، Duplex و Auto-Negotiation

Speed و Duplex باید در دو سمت لینک بررسی شوند. Cisco نیز در مستندات Troubleshooting Ethernet، برخی Errorها و Collisionها را در ارتباط با مشکلات Duplex بررسی می‌کند؛ با این حال نباید نتیجه گرفت که هر CRC Error حتماً ناشی از Duplex Mismatch است.

در شبکه‌های امروزی، مشکلات فیزیکی مانند کابل، Port، NIC و Transceiver از مهم‌ترین مسیرهای بررسی هستند و باید بر اساس شواهد واقعی اولویت‌بندی شوند.

EMI و شرایط محیطی

در کابل‌های مسی، شرایط محیطی و منابع نویز الکترومغناطیسی نیز در سناریوهای خاص قابل بررسی هستند؛ به‌خصوص اگر خطاها با شرایط محیطی، مسیر خاص کابل یا تجهیزات برقی مشخصی هم‌زمان شوند.

دستورهای Cisco برای بررسی CRC Error

اولین قدم عملی، مشاهده وضعیت Interface و Counterهاست. Syntax دقیق برخی دستورات ممکن است بسته به Platform متفاوت باشد؛ بنابراین در محیط واقعی باید مستندات مدل و نسخه IOS یا IOS XE همان دستگاه را نیز در نظر بگیرید.

دستور اصلی برای بررسی Interface:

show interfaces

برای بررسی یک Interface مشخص:

نمونه دستور:

show interfaces GigabitEthernet1/0/1

در خانواده‌های مختلف Cisco، دستورات دیگری برای مشاهده Error Counters وجود دارند. برای مثال، در بسیاری از Catalystها می‌توان از دستور زیر برای مشاهده Counterهای خطا استفاده کرد:

بررسی Error Counters:

show interfaces counters errors

برای مشاهده وضعیت کلی Portها نیز بسته به Platform می‌توان از دستور زیر استفاده کرد:

بررسی وضعیت Interfaceها:

show interfaces status

در خروجی show interfaces به چه چیزهایی نگاه کنیم؟

• input errors: مجموعه‌ای از خطاهای دریافت‌شده که Cisco در Counter مربوط به Interface گزارش می‌کند.
• CRC: Counter مرتبط با خطاهای CRC در دریافت Frame.
• frame: در برخی Platformها به Frameهایی با CRC و خطای Alignment اشاره می‌کند.
• overrun: Counter مرتبط با شرایطی که داده ورودی با سرعتی دریافت شده که پردازش آن با محدودیت مواجه شده است؛ معنای دقیق Counter را باید در Platform مربوطه بررسی کرد.
• ignored: Frameها یا Packetهایی که به دلایل خاص در Counter مربوطه ثبت شده‌اند؛ تفسیر دقیق آن وابسته به Platform است.
• output errors: خطاهای گزارش‌شده در سمت ارسال Interface.
• collisions: Collisionهای ثبت‌شده روی Interface در Platformهایی که این Counter را گزارش می‌کنند.
• interface resets: تعداد Resetهای Interface.
• speed: سرعت عملیاتی Interface.
• duplex: حالت Duplex عملیاتی Interface.
• line protocol: وضعیت پروتکل خط در خروجی Interface.

نمونه خروجی Cisco و تحلیل CRC

نمونه خروجی زیر صرفاً فرضی و آموزشی است و نباید به‌عنوان خروجی واقعی یک مدل خاص از Cisco در نظر گرفته شود. ساختار دقیق خروجی می‌تواند با توجه به Platform و نسخه IOS یا IOS XE متفاوت باشد.

Switch# show interfaces GigabitEthernet1/0/1

GigabitEthernet1/0/1 is up, line protocol is up
  Hardware is Gigabit Ethernet
  Description: Server-01
  MTU 1500 bytes, BW 1000000 Kbit/sec
  Full-duplex, 1000Mb/s, media type is 1000BaseSX

  5 minute input rate 120000 bits/sec, 150 packets/sec
  5 minute output rate 90000 bits/sec, 110 packets/sec

     248734 packets input, 18392012 bytes
     0 runts, 0 giants, 0 throttles
     0 input errors, 37 CRC, 0 frame, 0 overrun
     0 ignored
     0 watchdog, 0 multicast
     0 input packets with dribble condition detected
     241810 packets output, 19283011 bytes
     0 output errors, 0 collisions
     0 interface resets

در این نمونه، Interface از نظر Link و Line Protocol فعال است، اما Counter مربوط به CRC مقدار 37 را نشان می‌دهد.

نکته مهم این است که همین عدد به‌تنهایی ثابت نمی‌کند که در لحظه حاضر 37 خطای فعال وجود دارد. ممکن است این مقدار مربوط به مدت طولانی گذشته باشد.

برای Troubleshooting باید ابتدا ببینیم آیا این عدد در حال افزایش است یا خیر.

چگونه افزایش CRC Counter را بررسی کنیم؟

یکی از مهم‌ترین اصول Troubleshooting این است که بین وجود Counter و افزایش Counter تفاوت بگذاریم.

1. Counter فعلی Interface را ثبت کنید.
2. مدتی ترافیک عادی شبکه را مشاهده کنید.
3. دوباره Interface را بررسی کنید.
4. مقدار CRC را با مقدار قبلی مقایسه کنید.

اگر مقدار CRC از 37 به 38 و سپس 39 افزایش پیدا کند، شواهد بسیار قوی‌تری برای وجود یک مشکل فعال دارید.

در مقابل، اگر CRC مدت زیادی روی همان مقدار باقی بماند، ممکن است خطا مربوط به گذشته باشد و در حال حاضر مشکل فعالی وجود نداشته باشد.

Increasing Counter از صرفاً وجود یک مقدار قدیمی مهم‌تر است.

Clear کردن Interface Counters

پاک کردن Counterها می‌تواند برای ایجاد یک Baseline جدید در Troubleshooting مفید باشد. در بسیاری از Cisco IOS و IOS XEها دستور clear counters برای پاک کردن Counterهایی که با show interfaces نمایش داده می‌شوند استفاده می‌شود؛ اما Syntax دقیق آن باید بر اساس Platform بررسی شود.

نمونه رایج:

clear counters

در برخی Platformها امکان مشخص کردن Interface نیز وجود دارد.

نمونه:

clear counters GigabitEthernet1/0/1

این Syntax را نباید بدون بررسی روی تمام مدل‌های Cisco یکسان فرض کرد.

نکته بسیار مهم: Clear کردن Counter مشکل CRC را حل نمی‌کند. این کار فقط Counter را برای Troubleshooting به یک نقطه شروع جدید برمی‌گرداند. Cisco نیز در مستندات Interface خود توضیح می‌دهد که Clear Counters برای پاک کردن آمار Interface مورد استفاده در خروجی show interfaces است و لزوماً Counterهای دریافت‌شده از SNMP را پاک نمی‌کند.

Workflow حرفه‌ای Troubleshooting CRC

بهترین روش برای برخورد با CRC Error این است که از ساده‌ترین و کم‌هزینه‌ترین تست شروع کرده و به‌صورت مرحله‌ای دامنه مشکل را محدود کنیم.

1. Interface را شناسایی کنید. مشخص کنید CRC دقیقاً روی کدام Port دیده می‌شود.
2. Counterها را بررسی کنید. CRC، Input Errors، Frame، Overrun و سایر Counterهای مرتبط را مشاهده کنید.
3. روند افزایش را بررسی کنید. مشخص کنید Errorها واقعاً در حال افزایش هستند یا قدیمی‌اند.
4. Speed و Duplex را بررسی کنید. وضعیت عملیاتی دو سمت لینک را مقایسه کنید.
5. سمت مقابل را بررسی کنید. Interface دستگاه مقابل را نیز مشاهده کنید.
6. Patch Cable را تعویض کنید. از یک کابل سالم و مناسب استفاده کنید.
7. Port دیگری را تست کنید. در صورت امکان Endpoint را روی Port دیگری آزمایش کنید.
8. SFP یا Transceiver را بررسی کنید. در لینک‌های مربوطه، وضعیت Transceiver را بررسی کنید.
9. Fiber را بررسی کنید. Patch Cord، Connector، مسیر و Optical Power را بررسی کنید.
10. NIC را بررسی کنید. در صورت ارتباط با Server یا Client، کارت شبکه و وضعیت آن را بررسی کنید.
11. Logs را بررسی کنید. رخدادهای مرتبط با Link، Interface و Hardware را جست‌وجو کنید.
12. Hardware را بررسی کنید. اگر تمام متغیرهای بیرونی سالم هستند، Interface یا Hardware را جدی‌تر بررسی کنید.
13. بعد از رفع مشکل Monitoring انجام دهید. مطمئن شوید CRC دوباره افزایش پیدا نمی‌کند.

روش Elimination برای پیدا کردن Root Cause

یک Network Engineer نباید صرفاً بر اساس حدس قطعه‌ای را تعویض کند. روش بهتر این است که هر تست یک سؤال مشخص داشته باشد.

تست اول: تعویض Patch Cable

اگر CRC متوقف شد: احتمال مشکل در کابل قبلی بسیار بالا می‌رود.

اگر CRC ادامه داشت: تست بعدی باید Port یا سمت مقابل باشد.

تست دوم: تغییر Port

اگر Endpoint روی Port جدید بدون CRC کار کرد: Port قبلی یا مسیر مرتبط با آن باید بیشتر بررسی شود.

اگر CRC روی Port جدید نیز افزایش پیدا کرد: احتمال خرابی کابل، Endpoint، NIC یا سمت مقابل بیشتر می‌شود.

تست سوم: بررسی سمت مقابل

اگر روی Switch CRC مشاهده می‌شود، Interface دستگاه مقابل را نیز بررسی کنید. مقایسه دو سمت لینک می‌تواند اطلاعات مهمی درباره جهت مشکل ارائه کند.

تست چهارم: تعویض SFP

در لینک‌های Optical، اگر با تعویض SFP سالم و سازگار خطا متوقف شود، Transceiver قبلی مظنون اصلی خواهد بود.

تست پنجم: بررسی Fiber

اگر با تعویض SFP مشکل باقی ماند، مسیر Fiber، Patch Cord، Connector و Optical Power باید بررسی شوند.

تست ششم: بررسی NIC

اگر مشکل فقط با یک Server یا Client دیده می‌شود و تمام اجزای مسیر Switch سالم هستند، NIC و Driver یا Firmware آن دستگاه باید بررسی شود.

جدول Troubleshooting CRC Error

CRC Error روی Fiber

وقتی CRC روی یک Interface مبتنی بر Fiber دیده می‌شود، دامنه Troubleshooting کمی متفاوت است. در اینجا باید علاوه بر Interface، اجزای Optical Link را نیز بررسی کنید.

• SFP: نوع، Part Number و وضعیت Transceiver را بررسی کنید.
• SFP+: در لینک‌های 10Gbps و موارد مشابه، نوع و سازگاری Transceiver مهم است.
• QSFP: در لینک‌های سرعت بالاتر، بسته به Platform ممکن است QSFP یا QSFP-DD مورد استفاده باشد.
• Fiber Patch Cord: سلامت کابل و تطابق آن با نوع لینک را بررسی کنید.
• LC Connector: وضعیت Connectorها را بررسی کنید.
• Dirty Connector: آلودگی Optical می‌تواند کیفیت Link را کاهش دهد.
• Optical Power: در Platformهای پشتیبانی‌شده، مقدار Optical Power می‌تواند سرنخ مهمی باشد.
• DOM: Digital Optical Monitoring در Transceiverهای پشتیبانی‌شده می‌تواند اطلاعاتی مانند دما، ولتاژ و مقادیر Optical را ارائه کند.

بررسی Transceiver در Cisco

در بسیاری از Catalystها دستور زیر برای مشاهده اطلاعات Transceiver وجود دارد، اما قابلیت‌های دقیق آن وابسته به Platform است.

بررسی Transceiver:

show interfaces transceiver

برای اطلاعات جزئی‌تر در Platformهای پشتیبانی‌شده:

جزئیات Transceiver:

show interfaces transceiver detail

برای بررسی اطلاعات سخت‌افزاری و Inventory نیز می‌توان در Platformهای مربوطه از دستور زیر استفاده کرد:

بررسی Inventory:

show inventory

Cisco در مستندات Catalystهای مختلف توضیح می‌دهد که show interfaces transceiver و گزینه‌هایی مانند detail یا properties بسته به Platform برای مشاهده اطلاعات Transceiver و قابلیت‌های DOM مورد استفاده قرار می‌گیرند. بنابراین قبل از استفاده در یک مدل خاص، Syntax همان Platform را بررسی کنید.

رابطه Speed، Duplex، Auto-Negotiation و CRC

Speed سرعت عملیاتی Interface است و Duplex مشخص می‌کند Interface در چه حالت Duplex کار می‌کند. Auto-Negotiation نیز سازوکاری برای مذاکره پارامترهای Link میان دو سمت ارتباط است.

مشکل در مذاکره یا عدم تطابق تنظیمات می‌تواند در برخی شرایط باعث مشکلات ارتباطی و Counterهای غیرعادی شود. Cisco نیز در مستندات Ethernet خود Collision و برخی Errorها را در ارتباط با Duplex Mismatch بررسی می‌کند.

اما یک اشتباه رایج این است که گفته شود:

هر CRC Error حتماً به دلیل Duplex Mismatch است.

این ادعا صحیح نیست. CRC می‌تواند با مشکلات فیزیکی مانند Cable، Connector، Port، NIC یا Transceiver نیز مرتبط باشد. بنابراین Speed و Duplex باید بررسی شوند، اما نباید بدون شواهد به‌عنوان Root Cause معرفی شوند.

CRC Error و Packet Loss چه ارتباطی دارند؟

وقتی یک Frame در مسیر انتقال خراب می‌شود و بررسی Integrity آن ناموفق است، آن Frame نمی‌تواند به‌عنوان یک Frame سالم مورد استفاده قرار گیرد. در نتیجه، بسته‌ای که در سطح بالاتر باید از طریق شبکه دریافت می‌شد ممکن است از دید ارتباط End-to-End از دست رفته باشد یا در لایه‌های بالاتر نیاز به ارسال مجدد پیدا کند.

این موضوع می‌تواند در شرایطی که Errorها به‌صورت مستمر رخ می‌دهند، خود را به شکل Packet Loss، کاهش Throughput، افزایش Retransmission یا افزایش Latency نشان دهد.

البته رابطه CRC و Packet Loss همیشه یک رابطه یک‌به‌یک نیست. برای تشخیص واقعی Packet Loss باید رفتار End-to-End شبکه، پروتکل مورد استفاده و تجهیزات موجود در مسیر نیز بررسی شوند.

آیا CRC Error خطرناک است؟

شدت مشکل به تعداد، روند و الگوی Errorها بستگی دارد.

یک CRC Error قدیمی

اگر Counter فقط یک مقدار قدیمی دارد و مدت زیادی افزایش پیدا نکرده است، الزاماً نشانه وجود یک مشکل فعال نیست.

CRC Errorهای رو به افزایش

این وضعیت مهم‌تر است و باید جدی بررسی شود، زیرا نشان می‌دهد Interface همچنان در حال دریافت Frameهای دارای خطاست.

تعداد زیاد CRC Error

اگر CRC با سرعت بالا افزایش پیدا کند، احتمال وجود مشکل جدی‌تر در مسیر Link بیشتر می‌شود و بهتر است Troubleshooting بدون تأخیر انجام شود.

CRC همراه با سایر Interface Errors

وقتی CRC همراه با Frame، Input Errors، Interface Resets یا سایر نشانه‌های غیرعادی دیده می‌شود، اطلاعات بیشتری برای پیدا کردن Root Cause در اختیار Network Engineer قرار می‌گیرد.

آیا Restart کردن Switch مشکل CRC را حل می‌کند؟

معمولاً خیر.

Restart کردن Switch ممکن است در بعضی شرایط موقتاً وضعیت Interface یا Software را تغییر دهد، اما اگر Root Cause کابل، Fiber، SFP، NIC یا یک مشکل فیزیکی باشد، Restart علت اصلی را برطرف نمی‌کند.

حتی ممکن است Restart باعث شود بخشی از شواهد Troubleshooting از بین برود یا بررسی زمان‌بندی رخدادها دشوارتر شود. بنابراین Restart نباید جایگزین Troubleshooting اصولی شود.

آیا Clear Counters مشکل CRC را حل می‌کند؟

خیر.

Clear Counters صرفاً یک ابزار تشخیصی است. اگر بعد از Clear کردن Counter، مقدار CRC دوباره افزایش پیدا کند، این موضوع اتفاقاً شواهد خوبی برای وجود یک مشکل فعال است.

روش درست این است که Counter را به صفر یا Baseline جدید برسانید، سپس وضعیت Interface را تحت شرایط عادی شبکه پایش کنید و ببینید آیا Error دوباره ایجاد می‌شود یا خیر.

تفاوت CRC با سایر Interface Errors

تعریف دقیق و نحوه افزایش Counterها ممکن است میان Platformهای مختلف Cisco تفاوت داشته باشد. بنابراین جدول بالا یک راهنمای مفهومی برای شروع Troubleshooting است، نه جایگزین مستندات مدل مشخص سوئیچ.

سناریوی عملی Troubleshooting

فرض کنید یک Server روی Port زیر متصل است:

GigabitEthernet1/0/24

Network Administrator متوجه شده است که CRC این Interface در حال افزایش است.

مرحله اول: بررسی Interface

show interfaces GigabitEthernet1/0/24

در خروجی مشاهده می‌شود که CRC در حال افزایش است و Link از نظر فیزیکی Up است.

مرحله دوم: ثبت Baseline

Counter فعلی ثبت می‌شود. پس از مدتی Interface دوباره بررسی می‌شود و مشخص می‌شود که CRC افزایش یافته است. بنابراین مشکل فعال است.

مرحله سوم: تعویض Patch Cable

Patch Cable با یک کابل سالم تعویض می‌شود. پس از چند دقیقه Counter دوباره بررسی می‌شود.

اگر CRC دیگر افزایش پیدا نکند، Cable قبلی مظنون اصلی است. اما اگر CRC همچنان افزایش پیدا کند، باید تست بعدی انجام شود.

مرحله چهارم: تغییر Port

Server در صورت امکان به Port دیگری منتقل می‌شود.

اگر مشکل روی Port جدید نیز تکرار شود، احتمال اینکه مشکل صرفاً از Port قبلی باشد کمتر می‌شود. در این مرحله NIC، مسیر کابل‌کشی و سمت مقابل اهمیت بیشتری پیدا می‌کنند.

مرحله پنجم: بررسی NIC Server

وضعیت کارت شبکه، Driver، Firmware و Interface Server بررسی می‌شود. اگر NIC دیگری برای تست وجود داشته باشد، مقایسه می‌تواند به تشخیص کمک کند.

نتیجه

فرض کنید پس از تعویض NIC، CRC دیگر افزایش پیدا نمی‌کند. در این حالت شواهد نشان می‌دهد که مشکل احتمالاً در سمت Server و NIC بوده است؛ نه اینکه صرفاً به دلیل مشاهده CRC در Switch نتیجه بگیریم Switch خراب است.

این دقیقاً تفاوت میان مشاهده Symptom و پیدا کردن Root Cause است.

Checklist نهایی Troubleshooting CRC

• Interface را شناسایی کردم.
• CRC Counter را بررسی کردم.
• روند افزایش Error را بررسی کردم.
• Input و Output Errors را بررسی کردم.
• Speed را بررسی کردم.
• Duplex را بررسی کردم.
• سمت مقابل Link را بررسی کردم.
• Cable را بررسی کردم.
• Patch Cord را تعویض یا تست کردم.
• Patch Panel و Connector را بررسی کردم.
• Port دیگر را تست کردم.
• SFP را بررسی کردم.
• Fiber را بررسی کردم.
• Optical Power و DOM را در صورت پشتیبانی بررسی کردم.
• NIC را بررسی کردم.
• Logs را بررسی کردم.
• در صورت نیاز Hardware را بررسی کردم.
• بعد از رفع مشکل Counter را دوباره بررسی کردم.
• Monitoring بعد از رفع مشکل انجام دادم.

جمع‌بندی

CRC Error در Cisco Switch یک علامت مهم برای بررسی سلامت Link است، اما نباید آن را به‌صورت خودکار معادل خرابی Switch دانست. مهم‌ترین کار این است که مشخص کنیم Counter در حال افزایش است یا صرفاً یک مقدار قدیمی روی Interface باقی مانده است.

اگر CRC در حال افزایش باشد، Troubleshooting باید از ساده‌ترین متغیرها شروع شود: Cable و Patch Cord، سپس Port، سمت مقابل، SFP یا Fiber و در ادامه NIC و Hardware. در هر مرحله باید نتیجه تست ثبت شود تا بتوان از روش Elimination به Root Cause رسید.

همچنین Clear Counters راه‌حل CRC نیست؛ فقط یک Baseline جدید برای مشاهده رفتار Interface ایجاد می‌کند. بعد از رفع مشکل نیز باید Interface را برای مدتی Monitoring کرد تا مطمئن شویم Error دوباره ایجاد نمی‌شود.

سوالات متداول درباره CRC Error در سوئیچ سیسکو

CRC Error در سوئیچ سیسکو چیست؟

CRC Error نشانه‌ای از دریافت Frame دارای مشکل در Integrity داده است. این خطا می‌تواند با مشکلات فیزیکی یا سایر مشکلات Link مرتبط باشد و به‌تنهایی به معنی خرابی Switch نیست.

علت CRC Error در Cisco چیست؟

علت می‌تواند کابل، Patch Cord، Connector، Patch Panel، Port، SFP، Fiber، NIC یا دستگاه طرف مقابل باشد. علت قطعی باید با Troubleshooting مشخص شود.

چگونه CRC Error را در Cisco بررسی کنیم؟

با دستور show interfaces می‌توان وضعیت Interface و Counterهای آن را بررسی کرد. برای یک Interface مشخص نیز می‌توان نام Interface را به دستور اضافه کرد.

دستور مشاهده CRC Error در Cisco چیست؟

یک دستور رایج برای بررسی Interface، show interfaces است. در خروجی Interface می‌توان Counter مربوط به CRC را مشاهده کرد.

آیا CRC Error به معنی خرابی Switch است؟

خیر. CRC فقط یک Symptom است. برای پیدا کردن Root Cause باید تمام اجزای Link از جمله کابل، Transceiver، Endpoint و سمت مقابل بررسی شوند.

آیا کابل خراب باعث CRC Error می‌شود؟

بله، کابل یا Patch Cord معیوب یکی از مواردی است که باید در Troubleshooting لینک‌های مسی بررسی شود؛ اما صرف مشاهده CRC اثبات نمی‌کند که کابل خراب است.

آیا SFP خراب باعث CRC Error می‌شود؟

در لینک‌های مبتنی بر Transceiver، خرابی یا مشکل سازگاری SFP می‌تواند یکی از مظنون‌ها باشد. بررسی Transceiver و در صورت امکان تست با یک نمونه سالم و سازگار می‌تواند به تشخیص کمک کند.

چگونه CRC Error را رفع کنیم؟

ابتدا علت را پیدا کنید. کابل، Patch Cord، Port، SFP، Fiber، سمت مقابل و NIC را به‌ترتیب بررسی کنید. راهکار واقعی زمانی مشخص می‌شود که Root Cause شناسایی شده باشد.

آیا Clear Counters مشکل CRC را حل می‌کند؟

خیر. Clear Counters فقط Counterهای نمایش داده‌شده را برای ایجاد Baseline جدید پاک می‌کند و مشکل فیزیکی یا منطقی Link را برطرف نمی‌کند.

تفاوت CRC و FCS چیست؟

FCS بخشی از Frame Ethernet برای بررسی صحت داده است و CRC الگوریتمی است که در محاسبه و بررسی این مقدار نقش دارد. نحوه نمایش Counterهای CRC و FCS بسته به Platform ممکن است متفاوت باشد.

آیا CRC Error باعث Packet Loss می‌شود؟

Frame خراب نمی‌تواند به‌عنوان داده سالم مورد استفاده قرار گیرد و در یک ارتباط End-to-End می‌تواند به از دست رفتن داده یا نیاز به ارسال مجدد در لایه‌های بالاتر منجر شود. برای اثبات Packet Loss باید رفتار کل مسیر بررسی شود.

چرا CRC Error بعد از تعویض کابل دوباره ایجاد می‌شود؟

اگر کابل سالم باشد، علت می‌تواند در Port، NIC، Patch Panel، Connector، SFP، Fiber یا سمت مقابل باشد. در این شرایط باید تست Elimination را ادامه داد و فقط روی کابل تمرکز نکرد.

چه زمانی از خدمات تخصصی شبکه استفاده کنیم؟

اگر CRC Error به‌صورت مداوم افزایش پیدا می‌کند و با بررسی‌های اولیه مانند تعویض Patch Cord، بررسی Port و کنترل سمت مقابل برطرف نمی‌شود، بهتر است قبل از تعویض تصادفی تجهیزات، مسیر Link به‌صورت ساختاریافته بررسی شود.

ونداد آی‌تی در حوزه خدمات شبکه و زیرساخت IT فعالیت می‌کند و در صورت حل نشدن مشکل با Troubleshooting اولیه، می‌تواند در بررسی و عیب‌یابی تخصصی شبکه، Interfaceها و مسیر ارتباطی به شما کمک کند.

اگر CRC Error در شبکه شما به‌صورت مداوم تکرار می‌شود، بهتر است ابتدا Counterها و روند افزایش آن‌ها را مستند کنید و سپس برای پیدا کردن Root Cause، عیب‌یابی مرحله‌ای انجام دهید.

منابع فنی پیشنهادی

• Cisco — Configure and Verify Ethernet Duplex Auto-Negotiation
• Cisco — Catalyst 3850 Interface Configuration Guide
• Cisco — Catalyst 9600 Interface and Hardware Commands
• Cisco — Troubleshoot Interface CRC Errors

یادآوری فنی: Commandها و Counterهای Cisco ممکن است بر اساس مدل Switch، Platform، نوع Interface و نسخه IOS یا IOS XE تفاوت داشته باشند. قبل از اجرای Commandهای عملیاتی در محیط Production، Syntax و قابلیت پشتیبانی آن را در مستندات همان Platform بررسی کنید.