چرا شبکه شما کند است؟ ۷ دلیل کندی شبکه که کمتر به آن توجه می‌شود.

1. لینک Ethernet برقرار است، اما CRC و FCS Error دارد

یکی از گمراه‌کننده‌ترین وضعیت‌ها زمانی است که Interface کاملاً Up است و حتی سرعت 1Gbps را هم نشان می‌دهد، اما روی لینک Frameهای خراب ایجاد می‌شوند. در این شرایط کاربر معمولاً قطعی کامل نمی‌بیند؛ Packetها دوباره ارسال می‌شوند و نتیجه به شکل کندی، Retransmission یا ناپایداری ظاهر می‌شود.

Cisco از کابل یا فیبر آسیب‌دیده، Transceiver معیوب، Patch Panel، پورت خراب، NIC و بعضی Configuration Mismatchها به‌عنوان دلایل رایج CRC Error نام می‌برد. Duplex Mismatch هم در شبکه‌های Ethernet قدیمی‌تر یا پیکربندی دستی اشتباه می‌تواند Collision و FCS Error ایجاد کند.

بنابراین قبل از تعویض Switch، Counterهای پورت را بررسی کنید. اگر CRC، FCS، Input Error یا Collision در حال افزایش هستند، مسیر فیزیکی را جدی بگیرید. در چنین پروژه‌ای کیفیت کابل شبکه، Patch Cord، Keystone و Patch Panel به‌اندازه خود تجهیزات اکتیو اهمیت دارد.

برای تست سریع نیز می‌توان کابل مشکوک را موقتاً با یک نمونه سالم مانند پچ کورد Cat6 نگزنس جایگزین کرد و بررسی کرد آیا Error Counter همچنان افزایش پیدا می‌کند یا خیر.

2. Microburst دارید، اما نمودار پهنای باند آن را نشان نمی‌دهد

ممکن است روی داشبورد ببینید یک لینک Gigabit فقط 30 یا 40 درصد استفاده می‌شود و در نتیجه آن را از فهرست مظنون‌ها حذف کنید. مشکل این است که ابزارهای Monitoring معمولاً ترافیک را در بازه‌های چندثانیه‌ای یا چنددقیقه‌ای Average می‌کنند.

Microburst یک افزایش بسیار کوتاه و شدید ترافیک در بازه میلی‌ثانیه یا حتی کوتاه‌تر است. اگر چند منبع هم‌زمان Packetهای زیادی را به یک Egress Port ارسال کنند، Buffer سخت‌افزاری سوئیچ می‌تواند برای لحظه‌ای پر شود و Packet Drop اتفاق بیفتد؛ حتی در شرایطی که Average Utilization پایین به نظر می‌رسد.

این اتفاق در Uplinkهای Aggregation، Backupهای هم‌زمان، Storage Traffic و سرورهایی که Burst زیادی تولید می‌کنند مهم است. اگر چند Access Switch روی یک Uplink جمع شده‌اند، فقط نمودار Utilization را نبینید؛ Output Drop و Queue Counter نیز باید بررسی شوند.

در شبکه‌هایی که Aggregation به گلوگاه تبدیل شده، طراحی مناسب سوئیچ شبکه و Uplink اهمیت پیدا می‌کند. برای نمونه تجهیزاتی مانند Cisco C1300-12XS برای نقش‌های Aggregation با لینک‌های پرظرفیت طراحی شده‌اند؛ البته انتخاب مدل باید براساس حجم واقعی ترافیک و معماری شبکه انجام شود.

3. پهنای باند کافی دارید، اما Bufferbloat تأخیر را بالا می‌برد

یکی از رایج‌ترین سناریوهای عجیب این است: وقتی کسی Download یا Backup انجام نمی‌دهد Ping مناسب است، اما به‌محض اشباع Upload یا Download، تماس VoIP خراب می‌شود، Remote Desktop Lag می‌زند و Ping به‌شدت بالا می‌رود.

علت می‌تواند Bufferbloat باشد. وقتی نرخ ورود Packetها از نرخ خروج آن‌ها بیشتر می‌شود، Queue تشکیل می‌شود. Buffer برای جذب Burst لازم است، اما Queue بیش از حد بزرگ Packetها را برای مدت طولانی نگه می‌دارد و Latency افزایش پیدا می‌کند.

برای تشخیص، فقط Speedtest Download را نگاه نکنید. Ping را در حالت Idle ثبت کنید و همان تست را هنگام اشباع لینک تکرار کنید. اگر Throughput خوب باقی مانده اما Latency زیر بار جهش کرده است، باید Queue Management، QoS، Shaping و سیاست پهنای باند روی Router/Gateway بررسی شوند.

راه‌حل هم همیشه «خرید اینترنت سریع‌تر» نیست. در بسیاری از شبکه‌ها مدیریت صحیح Queue با AQM یا Fair Queueing می‌تواند تجربه تماس، DNS، Web و Remote Access را بهبود دهد.

4. MTU یا MSS در بخشی از مسیر اشتباه است

MTU مشکل عجیبی ایجاد می‌کند، چون شبکه ممکن است تقریباً سالم به نظر برسد. Ping کوچک جواب می‌دهد، بعضی سایت‌ها باز می‌شوند و Login هم انجام می‌شود؛ اما دانلود فایل، VPN، یک نرم‌افزار خاص یا صفحات سنگین گیر می‌کنند.

این اتفاق به‌خصوص در مسیرهایی که PPPoE، GRE، IPsec، VXLAN یا سایر Encapsulationها وجود دارند مهم است. Headerهای اضافه فضای Payload را کاهش می‌دهند و اگر Packet بزرگ‌تر از Path MTU باشد، Fragmentation یا Drop اتفاق می‌افتد.

Cisco توضیح می‌دهد MTU کوچک‌تر در مسیر می‌تواند Fragmentation، Retransmission، Latency بیشتر و Throughput کمتر ایجاد کند. اگر Path MTU Discovery هم به دلیل مسدود شدن ICMP درست عمل نکند، PMTUD Black Hole شکل می‌گیرد و Packetهای بزرگ ممکن است بدون بازگشت اطلاعات لازم Drop شوند.

اگر مشکل فقط روی VPN یا بعضی Destinationها ظاهر می‌شود، MTU و TCP MSS را فراموش نکنید. تست Packet با DF Bit و اندازه‌های مختلف می‌تواند کوچک‌ترین MTU مسیر را مشخص کند.

5. مشکل DNS است، اما کاربر آن را «کندی اینترنت» می‌بیند

قبل از اینکه Browser بتواند به بسیاری از سایت‌ها متصل شود، Domain Name باید به IP تبدیل شود. اگر DNS Resolver پاسخ دیر بدهد، کاربر چند لحظه صفحه سفید می‌بیند و نتیجه می‌گیرد اینترنت کند است؛ درحالی‌که بعد از برقرار شدن Connection ممکن است دانلود با سرعت کامل انجام شود.

Cloudflare نیز DNS Resolution Time را یکی از مراحل قابل اندازه‌گیری Performance می‌داند و اشاره می‌کند DNS Latency بالا می‌تواند پاسخ را کند یا حتی باعث Timeout شود.

علامت رایج این مشکل این است که اتصال مستقیم به IP سریع‌تر از باز کردن Hostname عمل می‌کند یا تأخیر بیشتر در شروع Load دیده می‌شود تا خود انتقال. DNS Server داخلی، Forwarder، WAN DNS، Cache و مسیر Resolver باید جداگانه بررسی شوند.

در شبکه سازمانی همچنین ممکن است DNS داخلی برای Domainهای Local مشکل داشته باشد، درحالی‌که DNS عمومی کاملاً سالم است. بنابراین عوض کردن تصادفی DNS همه Clientها همیشه راه‌حل مناسبی نیست؛ ابتدا باید مشخص شود Delay در کدام Resolver ایجاد می‌شود.

6. Signal وای‌فای خوب است، اما Airtime دیگر ظرفیت ندارد

چهار خط کامل Wi-Fi روی موبایل به معنی شبکه سریع نیست. در Wireless، همه Clientها برای دسترسی به یک Medium مشترک رقابت می‌کنند. اگر Channel Utilization بالا باشد، Deviceها باید بیشتر منتظر فرصت ارسال بمانند و Retransmission نیز می‌تواند زمان بیشتری از Airtime را مصرف کند.

Cisco در راهنمای جدید عیب‌یابی Throughput وای‌فای تأکید می‌کند تعداد Client به‌تنهایی معیار مناسبی نیست و Channel Utilization شاخص مهم‌تری است. یک AP با Client کم هم می‌تواند به‌دلیل استفاده زیاد از کانال یا Interference عملکرد ضعیفی داشته باشد.

پس اگر فقط کاربران Wireless مشکل دارند، RSSI را تنها معیار قرار ندهید. Channel Utilization، Retry Rate، Data Rate، Channel Width، Co-channel Interference و تعداد APهای هم‌کانال را بررسی کنید.

در طراحی یا ارتقای شبکه، انتخاب درست اکسس پوینت فقط یک بخش کار است. برای مثال UniFi U6 Mesh Pro برای سناریوهای پرتراکم‌تر و پوشش گسترده طراحی شده، اما حتی AP قوی‌تر هم نمی‌تواند طراحی RF اشتباه یا کانال شلوغ را به‌تنهایی اصلاح کند.

7. یک Loop کوچک یا Broadcast غیرعادی کل شبکه را مشغول کرده است

Loop لایه 2 همیشه با قطع کامل شبکه شروع نمی‌شود. ممکن است یک کابل اشتباه بین دو Switch، یک سوئیچ غیرمدیریتی اضافه‌شده توسط کاربر یا تنظیم نادرست STP باعث شود Frameها در شبکه بچرخند و Broadcast/Multicast افزایش پیدا کند.

در شرایط شدید، Broadcast Storm می‌تواند پهنای باند و حتی Control Plane سوئیچ‌ها را تحت فشار قرار دهد. Cisco برای تشخیص Layer 2 Loop بررسی Input Rate غیرعادی، Broadcast/Multicast و وضعیت Spanning Tree را پیشنهاد می‌کند.

نکته مهم این است که ممکن است Port Graph یک Switch خاص مظنون اصلی به نظر برسد، درحالی‌که آن Switch فقط قربانی Loop پایین‌دست است. Topology، MAC Learning و STP باید مرحله‌ای دنبال شوند.

اشتباه رایج:

وقتی کل شبکه کند می‌شود، فوراً Gateway یا اینترنت را مقصر ندانید. یک Loop لایه 2 یا Broadcast Storm می‌تواند بدون هیچ مشکل WAN تمام کاربران LAN را تحت تأثیر قرار دهد.

برای پیدا کردن علت کندی، از چه ترتیبی جلو برویم؟

اگر بدون ترتیب شروع به تغییر DNS، تعویض Switch، تغییر Channel و دستکاری QoS کنید، احتمالاً تشخیص علت اصلی سخت‌تر می‌شود. روش بهتر این است که شبکه را از پایین‌ترین لایه به بالا بررسی کنید.

نقاط قوت و محدودیت‌های Speedtest در عیب‌یابی شبکه

سناریوی واقعی؛ اینترنت 500Mbps است اما شرکت هنوز کند است

فرض کنید یک شرکت 40 کاربر دارد و Speedtest روی لپ‌تاپ مدیر IT حدود 500Mbps نشان می‌دهد. با این حال تماس‌های آنلاین در ساعات شلوغ Lag دارند و انتقال Backup شبانه باعث می‌شود Remote Desktop تقریباً غیرقابل استفاده شود.

در مرحله اول اگر Ping هنگام Idle مناسب باشد اما هم‌زمان با Backup چند برابر شود، Bufferbloat یا Congestion باید بررسی شود. حالا اگر روی Uplink سوئیچ هم Output Drop مشاهده شود، ممکن است Microburst یا Oversubscription وجود داشته باشد.

در بخش دیگری از ساختمان کاربران Wi-Fi همچنان مشکل دارند، اما کاربران کابلی سالم هستند. اینجا مشکل کلی WAN نیست و باید Channel Utilization و Retry روی APها بررسی شود. به این ترتیب یک عبارت ساده مثل «شبکه کند است» ممکن است در یک مجموعه سه علت مستقل داشته باشد.

این راهنما برای چه کسانی مناسب است؟

این روش برای مدیران IT، تکنسین‌های شبکه، شرکت‌های کوچک و متوسط و تیم‌هایی مناسب است که با شکایت عمومی «شبکه کند شده» روبه‌رو هستند اما دلیل مشخصی در Monitoring نمی‌بینند.

اگر شبکه فقط یک مودم و چند Client دارد، تمام این مراحل لزوماً لازم نیست؛ اما در شبکه‌ای با چند Switch، VLAN، Access Point، Server، NAS، Camera و VoIP، بررسی مرحله‌ای بسیار سریع‌تر از تعویض تصادفی تجهیزات نتیجه می‌دهد.

اشتباهات رایج هنگام عیب‌یابی کندی شبکه

فقط Speedtest گرفتن: Bandwidth تنها یکی از شاخص‌های Performance است و Latency، Loss و Error را جایگزین نمی‌کند.

تعویض تجهیزات قبل از خواندن Counterها: بسیاری از خرابی‌های کابل و پورت از روی CRC، FCS و Drop قابل تشخیص هستند.

مقصر دانستن Wi-Fi فقط به‌خاطر Signal: RSSI خوب ممکن است همراه Channel Utilization و Retry بالا باشد.

افزایش پهنای باند برای حل Bufferbloat: اگر Queue Management مشکل داشته باشد، افزایش ظرفیت همیشه علت را برطرف نمی‌کند.

تغییر چند تنظیم هم‌زمان: وقتی DNS، QoS، Channel و MTU را هم‌زمان تغییر دهید، مشخص نمی‌شود کدام تغییر واقعاً مؤثر بوده است.

پیشنهاد متخصص:

برای هر مشکل یک Baseline ثبت کنید: Ping، Packet Loss، Interface Error، Utilization و زمان وقوع. بعد فقط یک متغیر را تغییر دهید و همان شاخص‌ها را دوباره اندازه‌گیری کنید.

جمع‌بندی؛ کندی شبکه همیشه کمبود پهنای باند نیست

اگر شبکه کند است اما سرعت اینترنت ظاهراً مناسب به نظر می‌رسد، عیب‌یابی را متوقف نکنید. CRC و FCS روی کابل، Microburst روی Uplink، Bufferbloat در Gateway، MTU اشتباه روی Tunnel، DNS کند، Channel Utilization بالای Wi-Fi و Loop لایه 2 همگی می‌توانند تجربه کاربر را خراب کنند بدون اینکه لزوماً Speedtest عدد بدی نشان دهد.

بهترین رویکرد، جدا کردن لایه‌هاست: ابتدا کابل و Interface، بعد Queue و Congestion، سپس IP/MTU، DNS، Wireless و در نهایت Application. این ترتیب کمک می‌کند به‌جای حدس زدن، علت واقعی را با داده پیدا کنید.

اگر در مرحله عیب‌یابی مشخص شد محدودیت از خود زیرساخت است و شبکه به Uplink سریع‌تر، Switch مدیریتی، کابل استاندارد یا Access Point مناسب‌تری نیاز دارد، انتخاب تجهیزات شبکه متناسب با معماری واقعی پروژه باید بعد از شناسایی گلوگاه انجام شود؛ نه قبل از آن.