مشکل: یک برنامه پایگاه داده "slow" است. تیم شبکه تیم سرور را مقصر می داند. تیم سرور شبکه را مقصر می داند. در همین حال، کاربران ناامید هستند و ساعت ها در اشکال زدایی دایره ای تلف می شوند.
راه حل: یک رویکرد سیستماتیک و علمی برای عیب یابی که از شواهد استفاده می کند، نه فرضیات، برای شناسایی علل ریشه.
هزینه عیب یابی Haphazard : زمان تلف شده، اصلاح نادرست که مشکلات واقعی، اشاره انگشت بین تیم ها، و تجربه کاربری ضعیف را پنهان می کند.
عیب یابی شبکه اساسا یک تمرین در روش علمی است:
این مقاله یک چارچوب ساختاری برای عیب یابی شبکه فراهم می کند که از مشکلات رایج مانند:
قبل از غواصی در تشخیص های فنی، به این پنج سوال مهم برای محدود کردن دامنه تحقیقات خود پاسخ دهید:
تغییرات پیکربندی؟ سخت افزار جدید؟ به روز رسانی های نرم افزار؟ تغییرات Topology؟
یک کاربر؟ یک ساختمان؟ همه؟ فقط کاربرد خاص؟
آیا تمام وقت اتفاق می افتد؟ فقط در ساعات خاصی؟ حوادث تصادفی؟
آیا می توانید مشکل را در تقاضا ایجاد کنید؟
بررسی هر دو انتهای اتصال
مدل OSI یک چارچوب ساختاری برای عیب یابی فراهم می کند. کار از لایه 1 (Physical) به سمت بالا یا از لایه 7 (درخواست) به سمت پایین، بسته به علائم.
هنگام استفاده: از دست دادن اتصال کامل، نور لینک یا علائم لایه فیزیکی
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -anضبط بستهnslookup, dig, curl -vهنگام استفاده: مشکلات خاص کاربردی که در آن اتصال پایه وجود دارد
شروع در Layer 7 (آیا سرویس شیرپوینت در حال اجرا است؟) راه حل DNS برای تصحیح IP؟ و تنها در صورت نیاز کار می کند.
از این درخت تشخیصی سریع برای شناسایی اینکه کدام لایه شکست خورده است استفاده کنید:
TCP/IP کار نمی کند. خدمات سیستم عامل را بررسی کنید، رانندگان شبکه را مجددا نصب کنید.
NIC معلول، راننده اشتباه، کابل بدون اتصال. بررسی: ip link show یا Device Manager
بررسی: کابل فیزیکی، وضعیت پورت سوئیچ، تخصیص VLAN، جدول ARP
بررسی: جدول مسیریابی، قوانین فایروال، ACL استفاده از traceroute پیدا کردن جایی که بسته ها متوقف می شوند
بررسی: تنظیمات DNS سرور، دسترسی سرور DNS، پورت مسدود کننده فایروال 53
بررسی: قوانین فایروال، گروه های امنیتی، سرویس گوش دادن به پورت
مشکل این است که با برنامه خود، احراز هویت یا پیکربندی درخواست
هنگامی که شما یک فرضیه در مورد علت ریشه دارید، از این تکنیک های انزوا برای تأیید یا رد آن استفاده کنید:
ثبت ترافیک در منبع، نقاط متوسط و مقصد برای شناسایی جایی که بسته ها کاهش یا اصلاح می شوند:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
حذف متغیرهای خارجی با تست اتصال در یک دستگاه واحد:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
مقایسه پیکربندی و رفتار در برابر یک سیستم کاری:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
مستندات مناسب مانع از اشکال زدایی دایره ای می شوند که در آن شما چندین بار بدون درک آن تلاش می کنید.
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
زمان پاسخ درخواست پایگاه داده از <100ms به 5 ثانیه کاهش یافته است. تیم برنامه " تأخیر شبکه" را متهم کرد.
بافرهای سیستم عامل پایگاه داده برای محصول تاخیر با پهنای باند بالا بسیار کوچک بودند. پنجره TCP پر می شود و فرستنده را مجبور می کند منتظر بماند.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
فرض نکنید: “Slow” همیشه به معنای “شبکه تاخیر” نیست. همیشه شواهد را جمع آوری کنید (برای تاخیر، گرفتن بسته برای رفتار) قبل از پریدن به نتیجه گیری.
اتصال سرور به طور تصادفی کاهش می یابد، به ویژه تحت بار. گاهی اوقات خوب کار می کرد، گاهی کاملاً بی پاسخ.
شکست Auto-negotiation شکست خورد. سرور به طور کامل مذاکره کرد، سوئیچ به نیمه پیچیده بازگشت. تشنج ها تنها زمانی اتفاق افتاد که هر دو طرف سعی کردند به طور همزمان انتقال دهند.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
هر دو پایان را بررسی کنید: وضعیت رابط، تنظیمات مذاکره شده را نشان می دهد. عدم تطابق به این معنی است که مذاکره خودکار شکست خورد. همیشه سرعت کد سخت / پیچیده برای سرورها.
کاربران می توانند برخی از وب سایت ها را مرور کنند (گوگل، یاهو) اما نه برخی دیگر (وب سایت بانکی، پورتال شرکت). درخواست های کوچک HTTP کار می کردند، صفحات بزرگ از بین می رفتند.
ping -M do -s 1472 موفقیت، ping -M do -s 1473 شکست شکستتونل VPN MTU را به 1400 کاهش داد، اما فایروال پیام های ICMP را مسدود کرد. Path MTU Discovery (PMTUD) نمی تواند کار کند، ایجاد یک سیاه چاله MTU. بسته های کوچک مناسب هستند، بسته های بزرگ با تنظیمات DF کمی در سکوت کاهش یافت.
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
موضوعات: اگر درخواست های کوچک کار می کنند، اما نقل و انتقالات بزرگ شکست می خورند، مشکلات مشکوک به MTU/fragmentation. استفاده از پینگ با DF bit برای آزمایش مسیر MTU.
تماس های صوتی ضبط شده، ترک های متناوب. فقط در ساعات کاری (9am-5pm) اتفاق افتاد.
سیاست QoS وجود داشت اما تخصیص پهنای باند به عقب بود: بهترین بازده 60٪ رسید، صدا 5٪ رسید. در ساعات کسب و کار زمانی که ترافیک داده افزایش یافت، بسته های صوتی به دلیل سرریز صف کاهش یافت.
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
مسائل مبتنی بر زمان = ظرفیت: اگر مشکلات فقط در ساعات شلوغ رخ دهد، این یک شکست سخت نیست بلکه یک مسئله ظرفیت/QoS است. آمار صف را بررسی کنید نه فقط پهنای باند کامل.
| Symptom | لایه Layer Layer Layer | فرماندهی برای دویدن | چه چیزی برای نگاه کردن به |
|---|---|---|---|
| نور لینک | لایه 1 | show interfaces |
وضعیت: پایین، بدون حامل، کابل بدون اتصال |
| از دست دادن بسته | لایه 1/2 | show interfaces |
خطایCRC، اجراها، غول ها، برخوردها، برخوردهای دیر |
| نمی توان دروازه را تکان داد | لایه 2 | arp -a |
هیچ ورودی ARP، MAC یاد نگرفته، مسدود کردن STP |
| نمی توان به Subnet از راه دور دسترسی داشت | لایه 3 | traceroute |
مسیر گم شده، اشتباه بعدی، مسیریابی حلقه |
| اتصال امتناع | لایه ۴ | telnet host port |
سرویس بدون گوش دادن، بلوک فایروال، TCP RST |
| عملکرد آهسته | لایه 4+ | ping (RTT) |
تاخیر بالا، محدودیت پهنای باند، انتقال TCP، پنجره صفر |
| نمی توان نام میزبان را حل کرد | لایه 7 | nslookup |
DNS سرور غیر قابل دسترس، اشتباه DNS config، NXDOMAIN |
| قطره های Intermittent | Layer 1/2 | ping -f (flood) |
عدم تطابق دوگانه، کابل شکست خورده، STP reconvergence |
| گاهی اوقات کار می کند، نه دیگران | چندین | Extended ping |
موضوع تعادل بار، عدم تقارن ECMP، سربرگ جدول دولتی |
بدانید که چه زمانی به فروشنده TAC یا مهندسان ارشد افزایش می یابد. زمانی که:
هر جلسه عیب یابی یک فرصت یادگیری است. ایجاد یک پایگاه دانش شخصی:
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
دستورات اغلب استفاده شده توسط سناریو برای مرجع سریع در هنگام عیب یابی.
تغییر تنظیمات بدون درک مشکل اغلب باعث بدتر شدن چیزها می شود یا مسئله واقعی را پنهان می کند.
اغلب "مشکلات شبکه" کاربرد، سرور یا مشکلات مربوط به مشتری است. شواهد را قبل از پذیرفتن سرزنش جمع آوری کنید.
شما وقت خود را برای تکرار تست هایی که قبلا انجام داده اید هدر می دهید یا قادر به توضیح آنچه که امتحان کرده اید نیستید.
مشکلات متقابل اغلب نشانه های هشدار زودهنگام از شکست قریب الوقوع هستند. آنها را قبل از اینکه بحرانی شوند، سرمایه گذاری کنید.
بازسازی یک دستگاه ممکن است سرویس را بازیابی کند، اما اگر متوجه نشوید که چرا نیاز به راه اندازی مجدد دارد، مشکل عود خواهد کرد.
عیب یابی شبکه هم علم و هم هنر است. علم یک روش سیستماتیک را دنبال می کند، با استفاده از ابزارهای تشخیصی به درستی و پروتکل های درک. هنر دانستن این است که کدام تست ها برای اجرای اول بر اساس علائم، تشخیص الگوها از تجربه، و دانستن چه زمانی برای افزایش.
با پیروی از رویکرد سیستماتیک مندرج در این مقاله - با استفاده از سوالات درست، روش کار کردن از طریق مدل OSI، مستندسازی مراحل خود و یادگیری از هر مسئله - شما در عیب یابی و جلوگیری از مشکلات رایج که منجر به هدر رفتن زمان و اصلاح نادرست می شود، کارآمد تر خواهید شد.
به یاد داشته باشید: هدف این است که فقط برای بازگرداندن خدمات، بلکه برای درک اینکه چرا شکست خورده است، بنابراین شما می توانید از وقوع دوباره جلوگیری کنید.
آخرین به روز رسانی: فوریه 2، 2026 نویسنده: Baud9600 تیم فنی