تحلیل Packet Drop در سوئیچ سیسکو بدون Error ظاهری

در بسیاری از پروژه‌های شبکه، مخصوصاً در سناریوهای سازمانی یا دیتاسنتری، با وضعیتی مواجه می‌شویم که کاربران از کندی، تاخیر یا قطع و وصل مقطعی سرویس‌ها شکایت دارند، اما وقتی به سوئیچ سیسکو مراجعه می‌کنیم، هیچ Error مشخصی روی پورت‌ها دیده نمی‌شود. نه CRC بالا رفته، نه input error داریم، نه لینک down شده است. با این حال Packet Drop رخ می‌دهد و کیفیت سرویس به‌طور محسوسی افت می‌کند. تحلیل Packet Drop در سوئیچ سیسکو بدون Error ظاهری دقیقاً همین سناریوی چالش‌برانگیز را هدف قرار می‌دهد.

در این مقاله، به‌صورت عملی و مرحله‌به‌مرحله بررسی می‌کنیم که چرا ممکن است سوئیچ‌های سیسکو مانند سری‌های Cisco Catalyst 2960X، Cisco Catalyst 3650 یا Cisco Catalyst 9300 بدون نمایش خطای واضح، اقدام به Drop کردن بسته‌ها کنند و چطور می‌توان این موضوع را با دستورات CLI و تحلیل دقیق بافر، صف و CPU ردیابی کرد.

Packet Drop چیست و چرا همیشه با Error همراه نیست

Packet Drop به معنای حذف شدن بسته‌های شبکه قبل از رسیدن به مقصد است. این Drop می‌تواند در لایه 2 یا لایه 3 رخ دهد و الزاماً با خطاهای فیزیکی همراه نیست. بسیاری تصور می‌کنند اگر پورت سوئیچ سالم باشد و خطای فیزیکی نداشته باشد، پس Drop هم وجود ندارد. اما واقعیت این است که اغلب Packet Dropها در لایه‌های منطقی‌تر مانند Queue Management، Buffer Exhaustion، Policing یا Congestion اتفاق می‌افتند.

در واقع، اگر لینک شما Up باشد و هیچ CRC یا input error نداشته باشید، باز هم ممکن است سوئیچ به دلیل پر شدن بافر داخلی، کمبود منابع پردازشی یا Oversubscription داخلی، بسته‌ها را حذف کند.

سناریوی رایج در شبکه‌های واقعی

فرض کنید در یک دفتر اداری در دبی، روی یک سوئیچ Catalyst چندین کاربر، یک سرور فایل، یک IP Phone و چند Access Point متصل هستند. کاربران گزارش می‌دهند که هنگام انتقال فایل سنگین یا Backup شبانه، تماس‌های VoIP قطع و وصل می‌شوند. شما وارد سوئیچ می‌شوید:

show interface gi1/0/10

هیچ error خاصی دیده نمی‌شود. اما مشکل همچنان پابرجاست. در چنین شرایطی باید فراتر از خطاهای فیزیکی فکر کنیم.

بررسی Queue و Output Drop

اولین نقطه شروع برای تحلیل Packet Drop در سوئیچ سیسکو بدون Error ظاهری بررسی صف خروجی پورت است.

دستور پایه:

show interface gi1/0/10

در خروجی به دنبال عباراتی مانند output drops یا queue drops باشید. ممکن است چیزی شبیه این ببینید:

Output queue: 0/40 (size/max)
5 minute output rate 8000000 bits/sec
Total output drops: 12543

اگر output drop در حال افزایش است، یعنی پورت مقصد نمی‌تواند بسته‌ها را به سرعت ارسال کند و بافر پر می‌شود.

چرا Output Drop بدون Error رخ می‌دهد؟

زیرا این Drop ناشی از congestion است نه خطای فیزیکی. لینک سالم است، اما ترافیک بیشتر از ظرفیت مؤثر آن است. این مسئله به‌ویژه در لینک‌های Uplink با Oversubscription بالا بسیار رایج است.

نقش Buffer در Packet Drop

هر سوئیچ سیسکو دارای مقدار مشخصی حافظه بافر برای نگهداری موقت بسته‌هاست. وقتی حجم ترافیک ناگهان افزایش می‌یابد، بسته‌ها در بافر صف می‌شوند. اگر بافر پر شود، سوئیچ ناچار به Drop کردن بسته‌های جدید می‌شود.

در برخی مدل‌ها می‌توانید وضعیت بافر را بررسی کنید:

show platform port-asic stats drop
یا
show platform hardware capacity buffer

در سری‌های پیشرفته‌تر مانند Catalyst 9300، تحلیل بافر بسیار دقیق‌تر قابل انجام است.

Oversubscription داخلی سوئیچ

بسیاری از مدیران شبکه فقط به سرعت پورت‌ها نگاه می‌کنند. مثلاً 48 پورت 1Gbps و دو Uplink ده گیگ. روی کاغذ همه چیز عالی به نظر می‌رسد. اما اگر ترافیک سنگین همزمان از چندین پورت Access به سمت یک Uplink سرازیر شود، نسبت Oversubscription بالا می‌رود. حتی اگر Uplink ده گیگ باشد، Backplane داخلی سوئیچ و ASIC محدودیت دارند. در چنین شرایطی Packet Drop رخ می‌دهد بدون اینکه خطای ظاهری ببینید.

تاثیر CPU بالا بر Drop مخفی

در برخی سناریوها، Drop به دلیل فشار روی CPU رخ می‌دهد، نه به دلیل محدودیت پورت.

دستور:

show processes cpu sorted

اگر CPU به‌طور مداوم بالای 80 درصد باشد، ممکن است Control Plane تحت فشار باشد. به‌ویژه در صورت وجود Broadcast Storm، ARP Flood یا حملات کوچک اما پیوسته.

برای بررسی دقیق‌تر:

show platform cpu packet statistics

اگر تعداد packetهای punt شده به CPU زیاد باشد، احتمال Drop در مسیر پردازشی وجود دارد.

Microburst و مشکل پنهان

یکی از مهم‌ترین دلایل Packet Drop در سوئیچ سیسکو بدون Error ظاهری پدیده Microburst است. Microburst زمانی رخ می‌دهد که در بازه زمانی بسیار کوتاه، حجم زیادی از ترافیک به یک پورت وارد شود. این پدیده در نمودارهای پنج دقیقه‌ای دیده نمی‌شود، چون میانگین‌گیری انجام می‌شود. راهکار تشخیص Microburst:

استفاده از SNMP با interval کوتاه
استفاده از NetFlow
بررسی Queue statistics در بازه‌های کوتاه

Microburst معمولاً در شبکه‌هایی با Storage، Backup یا VM Migration زیاد دیده می‌شود.

نقش QoS در جلوگیری از Drop

اگر QoS فعال نباشد، تمام ترافیک در یک صف قرار می‌گیرد. در زمان congestion، بسته‌های حساس مانند VoIP یا Video نیز Drop می‌شوند.

برای بررسی وضعیت QoS:

show mls qos interface gi1/0/10 statistics

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

Policing و Shaping ناخواسته

گاهی Packet Drop ناشی از Policyهایی است که فراموش کرده‌ایم فعال هستند.

بررسی کنید:

show policy-map interface gi1/0/10

اگر policing فعال باشد و نرخ ترافیک از حد تعریف‌شده عبور کند، بسته‌ها Drop می‌شوند بدون اینکه Error فیزیکی ثبت شود.

Duplex و Speed Mismatch مخفی

گاهی mismatch کامل نیست که لینک down شود، بلکه شرایط نیمه‌پایدار ایجاد می‌شود.

بررسی کنید:

show interface status
show interface gi1/0/10

اگر یکی از سمت‌ها auto و دیگری forced باشد، احتمال رفتار غیرقابل پیش‌بینی وجود دارد.

تحلیل عملی مرحله‌به‌مرحله

برای تحلیل Packet Drop در سوئیچ سیسکو بدون Error ظاهری این چک‌لیست را دنبال کنید:

• مرحله اول: بررسی basic counters
  show interface
• مرحله دوم: بررسی output drop
  show interface | include drop
• مرحله سوم: بررسی Queue
  show platform port-asic stats
• مرحله چهارم: بررسی CPU
  show processes cpu
• مرحله پنجم: بررسی QoS
  show policy-map interface
• مرحله ششم: بررسی Broadcast و Multicast
  show interface counters errors
• مرحله هفتم: بررسی MAC table overflow
  show mac address-table count

تاثیر Broadcast Storm بدون Error واضح

Broadcast Storm همیشه CRC تولید نمی‌کند. اگر تعداد Broadcast بیش از حد باشد، ممکن است بافر پر شود و Drop رخ دهد.

بررسی:

show interface counters
show storm-control

اگر storm-control فعال نیست، در شبکه‌های بزرگ توصیه می‌شود آن را تنظیم کنید.

نقش Spanning Tree و Loopهای لحظه‌ای

Loop کوتاه‌مدت ممکن است فقط باعث congestion شود نه اینکه پورت err-disable شود.

بررسی وضعیت STP:

show spanning-tree detail

اگر تعداد topology change زیاد باشد، احتمال Loop یا flapping وجود دارد.

بررسی Throughput واقعی در برابر پهنای باند اسمی

بسیاری از مدیران شبکه تصور می‌کنند اگر پورت 1Gbps است، پس همیشه می‌تواند یک گیگ ترافیک را بدون مشکل عبور دهد. اما throughput واقعی وابسته به سایز پکت، پردازش ASIC و وضعیت صف‌هاست. پکت‌های کوچک CPU بیشتری مصرف می‌کنند. بنابراین حتی با نرخ پایین‌تر از یک گیگ نیز ممکن است Drop رخ دهد.

Packet Drop در Stack سوئیچ‌ها

در Stackهایی مانند Catalyst 3650 یا 9300، ترافیک بین اعضای Stack از طریق StackWise عبور می‌کند. اگر ترافیک زیادی بین اعضا جریان داشته باشد، لینک Stack می‌تواند bottleneck شود.

بررسی:

show switch stack-ports

اگر utilization بالا باشد، Packet Drop داخلی رخ می‌دهد.

تاثیر ACL سنگین بر Drop

ACLهای بزرگ و پیچیده، مخصوصاً در لایه 3، می‌توانند باعث افزایش latency و Drop شوند.

بررسی:

show access-lists
show platform hardware acl usage

اگر TCAM پر باشد، عملکرد تحت تاثیر قرار می‌گیرد.

ارتباط Packet Drop با Latency بالا

گاهی کاربران فقط latency را حس می‌کنند، نه قطع کامل سرویس. Dropهای پراکنده باعث Retransmission در TCP می‌شوند و همین باعث کندی می‌شود. تحلیل با Wireshark نشان می‌دهد که TCP Retransmission افزایش یافته است، حتی اگر سوئیچ Error نداشته باشد.

جمع‌بندی عملی

تحلیل Packet Drop در سوئیچ سیسکو بدون Error ظاهری نیازمند نگاه عمیق‌تر به منابع داخلی سوئیچ است. همیشه به موارد زیر توجه کنید:

بافر و Queue
Oversubscription
Microburst
CPU و Control Plane
QoS و Policing
Stack bottleneck
ACL و TCAM

اگر فقط به CRC و input error نگاه کنید، بخش بزرگی از مشکل را نخواهید دید. در پروژه‌های واقعی، مخصوصاً در شبکه‌های ترکیبی که VoIP، Video، Backup و ترافیک دیتا همزمان جریان دارند، Drop پنهان بسیار رایج است. با استفاده از دستورات مناسب CLI و تحلیل منطقی ترافیک، می‌توان این مشکلات را قبل از تبدیل شدن به بحران جدی شناسایی و برطرف کرد. اگر به‌صورت سیستماتیک و مرحله‌به‌مرحله پیش بروید، تقریباً همیشه می‌توان ریشه Packet Drop را حتی بدون Error ظاهری پیدا کرد.