Network Troubleshooting Methodology - The Systematic Approach
روش عیب یابی شبکه: رویکرد سیستماتیک
چرا زبان شناسی اهمیت دارد
مشکل: یک برنامه پایگاه داده "slow" است. تیم شبکه تیم سرور را مقصر می داند. تیم سرور شبکه را مقصر می داند. در همین حال، کاربران ناامید هستند و ساعت ها در اشکال زدایی دایره ای تلف می شوند.
راه حل: یک رویکرد سیستماتیک و علمی برای عیب یابی که از شواهد استفاده می کند، نه فرضیات، برای شناسایی علل ریشه.
هزینه عیب یابی Haphazard : زمان تلف شده، اصلاح نادرست که مشکلات واقعی، اشاره انگشت بین تیم ها، و تجربه کاربری ضعیف را پنهان می کند.
مقدمه: روش علمی کاربردی برای شبکه سازی
عیب یابی شبکه اساسا یک تمرین در روش علمی است:
- مشاهده کننده علائم و جمع آوری داده ها
- شکل گیری فرضیه درباره ریشه علت
- آزمون فرضیه ابزارهای تشخیصی
- تحلیل نتایج تایید یا رد کردن فرضیه
- پیاده سازی یک تعمیر بر اساس علل ریشه تایید شده
- بررسی مشکل حل شده است
این مقاله یک چارچوب ساختاری برای عیب یابی شبکه فراهم می کند که از مشکلات رایج مانند:
- سوگیری تایید (به نظر می رسد فقط برای شواهدی که از حدس اولیه شما حمایت می کند)
- تغییرات تصادفی بدون تشخیص ( رویکرد "دعا و دعا")
- رفع علائم به جای علل ریشه
- اشکال زدایی دایره ای بدون مستندسازی آنچه که امتحان شده است
پنج سوال کلیدی
قبل از غواصی در تشخیص های فنی، به این پنج سوال مهم برای محدود کردن دامنه تحقیقات خود پاسخ دهید:
تغییرات پیکربندی؟ سخت افزار جدید؟ به روز رسانی های نرم افزار؟ تغییرات Topology؟
- گزینه Change Management logs را بررسی کنید
- تعهد اخیر در سیستم های مدیریت پیکربندی
- بپرسید: «آیا دیروز کار می کند؟»
یک کاربر؟ یک ساختمان؟ همه؟ فقط کاربرد خاص؟
- یک دستگاه: یک مسئله محلی (NIC، کابل، پیکربندی)
- یک Subnet : Gateway، DHCP یا Change Issue
- همه: زیرساخت های اصلی، ISP یا مسئله گسترده
- برنامه خاص: سرور کاربردی، قانون فایروال یا DNS
آیا تمام وقت اتفاق می افتد؟ فقط در ساعات خاصی؟ حوادث تصادفی؟
- ثابت: شکست سخت (کاهش، پیکربندی نادرست، خدمات پایین)
- زمان بر اساس: در طول ساعات کاری، فرآیندهای برنامه ریزی شده
- Intermittent/Random: عدم تطابق دوگانه، شکست سخت افزار، لینک متناوب
آیا می توانید مشکل را در تقاضا ایجاد کنید؟
- بله: بسیار آسان تر برای تشخیص (می تواند فرضیه های آزمایشی)
- نه: تنظیم نظارت / ارسال و منتظر بازگشت
بررسی هر دو انتهای اتصال
- دیدگاه مشتری در مقابل دیدگاه سرور
- ثبت بسته در منبع در مقابل مقصد
- مسیریابی نامتقارن؟ راه های مختلف برای ارسال در مقابل دریافت کنید؟
رویکرد تشخیصی مبتنی بر مدل OSI
مدل OSI یک چارچوب ساختاری برای عیب یابی فراهم می کند. کار از لایه 1 (Physical) به سمت بالا یا از لایه 7 (درخواست) به سمت پایین، بسته به علائم.
پایین-Up Approach (Layer 1 – Layer 7)
هنگام استفاده: از دست دادن اتصال کامل، نور لینک یا علائم لایه فیزیکی
- بررسی: کابل متصل؟ چراغ های لینک روشن؟ فیبر تمیز؟
- فرماندهی:
show interfaces,ethtool eth0 - به دنبال: خطایCRC، برخورد، برخورد های دیرهنگام، دویدن، غول ها
- بررسی: VLAN صحیح؟ پورت فعال شد؟ مسدود کردن STP
- فرماندهی:
show mac address-table,show spanning-tree - به دنبال: تغییرات توپولوژی MAC، VLAN ناسازگار
- بررسی: آیا می توان دروازه پیش فرض را برداشت؟ جدول مسیریابی درست است؟
- فرماندهی:
ping,traceroute,show ip route - به دنبال: مسیرهای گم شده، مسیر های نادرست بعدی، حلقه های مسیریابی
- بررسی: آیا می توان اتصال TCP را برقرار کرد؟ پورت مسدود کننده فایروال؟
- فرماندهی:
telnet host port,netstat -anضبط بسته - به دنبال: انتقال TCP، پنجره های صفر، RST بسته
- بررسی: DNS حل کردن؟ پاسخ دادن؟ اعتبار کار می کند؟
- فرماندهی:
nslookup,dig,curl -v - به دنبال: شکست های DNS، خطاهای کاربردی، مسائل زمان بندی
Top-Down Approach (Layer 7) Layer 1)
هنگام استفاده: مشکلات خاص کاربردی که در آن اتصال پایه وجود دارد
شروع در Layer 7 (آیا سرویس شیرپوینت در حال اجرا است؟) راه حل DNS برای تصحیح IP؟ و تنها در صورت نیاز کار می کند.
درخت تصمیم: آیا لایه 1، 2 یا 3 است؟
از این درخت تشخیصی سریع برای شناسایی اینکه کدام لایه شکست خورده است استفاده کنید:
TCP/IP کار نمی کند. خدمات سیستم عامل را بررسی کنید، رانندگان شبکه را مجددا نصب کنید.
NIC معلول، راننده اشتباه، کابل بدون اتصال. بررسی: ip link show یا Device Manager
بررسی: کابل فیزیکی، وضعیت پورت سوئیچ، تخصیص VLAN، جدول ARP
بررسی: جدول مسیریابی، قوانین فایروال، ACL استفاده از traceroute پیدا کردن جایی که بسته ها متوقف می شوند
بررسی: تنظیمات DNS سرور، دسترسی سرور DNS، پورت مسدود کننده فایروال 53
بررسی: قوانین فایروال، گروه های امنیتی، سرویس گوش دادن به پورت
مشکل این است که با برنامه خود، احراز هویت یا پیکربندی درخواست
تکنیک های حل
هنگامی که شما یک فرضیه در مورد علت ریشه دارید، از این تکنیک های انزوا برای تأیید یا رد آن استفاده کنید:
۱- جایگزین کردن قطعات Systematic
- کابل پچ با کابل شناخته شده
- تست در پورت سوئیچ مختلف
- سعی کنید NIC مختلف (یا آداپتور شبکه USB)
- تست از دستگاه های مختلف مشتری
- حرکت به VLAN / Subnet
۲- ثبت نام در چندین امتیاز
ثبت ترافیک در منبع، نقاط متوسط و مقصد برای شناسایی جایی که بسته ها کاهش یا اصلاح می شوند:
# 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")
مستند سازی در هنگام عیب یابی
مستندات مناسب مانع از اشکال زدایی دایره ای می شوند که در آن شما چندین بار بدون درک آن تلاش می کنید.
عیب یابی Template
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
مطالعات موردی در دنیای واقعی
مطالعه موردی 1: "شبکه آهسته است" (به طور واقعی: خستگی پنجره TCP)
Symptom
زمان پاسخ درخواست پایگاه داده از <100ms به 5 ثانیه کاهش یافته است. تیم برنامه " تأخیر شبکه" را متهم کرد.
فرضیات اولیه (Wrong)
- ترافیک شبکه
- لینک WAN اشباع شده
- دیواره های آتش
فرآیند تشخیصی
- تست پینگ: RTT = 2ms (excellent، قوانین تأخیر لایه 3)
- تست پهنای باند (iperf): 950 Mbps در لینک 1 گیگابیت در ثانیه (بدون تراکم)
- ثبت نام: بسته های TCP Zero Window از سرور پایگاه داده
- بازرسی سرور: سرور پایگاه داده بافرهایی معادل 64KB (tiny) دریافت می کند!
ریشه علت
بافرهای سیستم عامل پایگاه داده برای محصول تاخیر با پهنای باند بالا بسیار کوچک بودند. پنجره 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” همیشه به معنای “شبکه تاخیر” نیست. همیشه شواهد را جمع آوری کنید (برای تاخیر، گرفتن بسته برای رفتار) قبل از پریدن به نتیجه گیری.
مطالعه موردی 2: اتصال متقابل (Actually: Duplex Mismatch)
Symptom
اتصال سرور به طور تصادفی کاهش می یابد، به ویژه تحت بار. گاهی اوقات خوب کار می کرد، گاهی کاملاً بی پاسخ.
Initial Assumptions (Wrong)
- شکست NIC
- کابل های بد
- سوئیچ سخت افزار
Diagnostic Process
- بررسی رابط: سرور NIC = 1000 / کامل، پورت سوئیچ = 1000/Half (اشتباه!)
- خطای مقابله: تعداد برخورد گسترده در پورت سوئیچ
- برخورد های اخیر: شاخص های خطای دوبلکس
Root Cause
شکست Auto-negotiation شکست خورد. سرور به طور کامل مذاکره کرد، سوئیچ به نیمه پیچیده بازگشت. تشنج ها تنها زمانی اتفاق افتاد که هر دو طرف سعی کردند به طور همزمان انتقال دهند.
Resolution
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Lesson Learned
هر دو پایان را بررسی کنید: وضعیت رابط، تنظیمات مذاکره شده را نشان می دهد. عدم تطابق به این معنی است که مذاکره خودکار شکست خورد. همیشه سرعت کد سخت / پیچیده برای سرورها.
مطالعه موردی 3: "نمی تواند به برخی از وب سایت ها" (به طور واقعی: MTU / PMTUD سیاه چاله)
Symptom
کاربران می توانند برخی از وب سایت ها را مرور کنند (گوگل، یاهو) اما نه برخی دیگر (وب سایت بانکی، پورتال شرکت). درخواست های کوچک HTTP کار می کردند، صفحات بزرگ از بین می رفتند.
Initial Assumptions (Wrong)
- مشکل DNS
- مسدود کردن سایت های خاص
- مشکل مسیریابی ISP
Diagnostic Process
- DNS Resolution: برای همه سایت ها خوب است
- تست پینگ: می تواند سایت های "غیر قابل دسترس" را ردیابی کند
- درخواست کوچک HTTP (curl): کار برای صفحات کوچک
- دانلود بزرگ: دانلود زیرنویس فارسی بازی Thells after TCP Handhake
-
تست MTU:
ping -M do -s 1472موفقیت،ping -M do -s 1473شکست شکست - نظارت ICMP: هیچ "تحریم لازم" (نوع 3 کد 4) پیام دریافت شده
Root Cause
تونل VPN MTU را به 1400 کاهش داد، اما فایروال پیام های ICMP را مسدود کرد. Path MTU Discovery (PMTUD) نمی تواند کار کند، ایجاد یک سیاه چاله MTU. بسته های کوچک مناسب هستند، بسته های بزرگ با تنظیمات DF کمی در سکوت کاهش یافت.
Resolution
! 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
Lesson Learned
موضوعات: اگر درخواست های کوچک کار می کنند، اما نقل و انتقالات بزرگ شکست می خورند، مشکلات مشکوک به MTU/fragmentation. استفاده از پینگ با DF bit برای آزمایش مسیر MTU.
مطالعه موردی 4: مسائل کیفیت VoIP (به طور واقعی: QoS Misconfiguration)
Symptom
تماس های صوتی ضبط شده، ترک های متناوب. فقط در ساعات کاری (9am-5pm) اتفاق افتاد.
Initial Assumptions (Wrong)
- در پهنای باند ناکافی
- سرویس دهنده VoIP Overed
- اتصال ISP کیفیت
Diagnostic Process
- تست پهنای باند: لینک تنها ۴۰ درصد در ساعات شلوغ استفاده می شود
- بررسی QoS: ترافیک صوتی مشخص شده با DSCP EF (46)
- بازرسی Queue: صف صدا فقط 5٪ تخصیص پهنای باند (باید 33٪)
- ثبت نام: بسته های صوتی در هنگام ازدحام کاهش می یابد
Root Cause
سیاست QoS وجود داشت اما تخصیص پهنای باند به عقب بود: بهترین بازده 60٪ رسید، صدا 5٪ رسید. در ساعات کسب و کار زمانی که ترافیک داده افزایش یافت، بسته های صوتی به دلیل سرریز صف کاهش یافت.
Resolution
! 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
Lesson Learned
مسائل مبتنی بر زمان = ظرفیت: اگر مشکلات فقط در ساعات شلوغ رخ دهد، این یک شکست سخت نیست بلکه یک مسئله ظرفیت/QoS است. آمار صف را بررسی کنید نه فقط پهنای باند کامل.
مرجع فرماندهی توسط Symptom
| 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 یا مهندسان ارشد افزایش می یابد. زمانی که:
- شما تمام مراحل عیب یابی را در پایگاه دانش خود خسته کرده اید
- مسئله نیاز به دسترسی / خروجی دارد که شما ندارید
- مشکل شامل اشکال نرم افزار فروشنده یا نقص سخت افزار
- تاثیر کسب و کار مهم و حساس به زمان است
- تیم های متعدد باید همکاری کنند (برنامه + شبکه + سرور)
- شرح کامل علائم
- زمانی که مسئله شروع شد
- دستورات تشخیصی اجرا می شوند و خروجی آنها
- تنظیمات پشتیبان
- ضبط بسته (در صورت لزوم)
- آنچه قبلا امتحان کرده اید
ساخت پایگاه دانش شخصی شما
هر جلسه عیب یابی یک فرصت یادگیری است. ایجاد یک پایگاه دانش شخصی:
1- ایجاد یک ژورنال عیب یابی
# 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
۲- ایجاد یک برگه تقلب فرمان
دستورات اغلب استفاده شده توسط سناریو برای مرجع سریع در هنگام عیب یابی.
مستند شبکه شما
- نمودارهای Topology (Layer 2 و Layer 3)
- برنامه آدرس IP
- وظایف VLAN
- تنظیمات استاندارد (templates)
- پایه های خوب شناخته شده (اطلاعات مربوط به قبل از مشکلات)
آنتی بادی های رایج برای جلوگیری از
۳- تغییرات تصادفی را بدون تشخیص ایجاد کنید
تغییر تنظیمات بدون درک مشکل اغلب باعث بدتر شدن چیزها می شود یا مسئله واقعی را پنهان می کند.
فرض کنید شبکه همیشه مقصر است
اغلب "مشکلات شبکه" کاربرد، سرور یا مشکلات مربوط به مشتری است. شواهد را قبل از پذیرفتن سرزنش جمع آوری کنید.
❌t: ثبت مراحل عیب یابی خود
شما وقت خود را برای تکرار تست هایی که قبلا انجام داده اید هدر می دهید یا قادر به توضیح آنچه که امتحان کرده اید نیستید.
❌ نگذارید: مسائل متناوب را نادیده بگیرید
مشکلات متقابل اغلب نشانه های هشدار زودهنگام از شکست قریب الوقوع هستند. آنها را قبل از اینکه بحرانی شوند، سرمایه گذاری کنید.
❌ انجام ندهید: علائم را به جای علل ریشه حل کنید
بازسازی یک دستگاه ممکن است سرویس را بازیابی کند، اما اگر متوجه نشوید که چرا نیاز به راه اندازی مجدد دارد، مشکل عود خواهد کرد.
خلاصه داستان : The Systematic Troubleshooting Checklist
قبل از اینکه شروع کنید
- به پنج سوال کلیدی پاسخ دهید (چه چیزی تغییر کرد؟) چه کسی آسیب دیده است؟ دائمی یا متناوب؟ بازگشت ناپذیر؟ طرف دیگر چه می بیند؟)
- جمع آوری علائم اولیه و گزارش های کاربر
- بررسی تغییرات اخیر یا تعمیر و نگهداری
در هنگام عیب یابی
- روش کار از طریق لایه های OSI (پایین یا بالا)
- تغییر یک متغیر در یک زمان هنگام تست
- مستند هر آزمون و نتیجه آن
- استفاده از ضبط بسته برای دیدن رفتار ترافیک واقعی
- مقایسه با پایه های شناخته شده
پس از قطعنامه
- بررسی اصلاح در واقع حل مسئله
- دلیل ریشه سند و قطعنامه
- به روز رسانی پایگاه دانش خود
- اگر پیکربندی تغییر کرد، به روز رسانی مستندات
- در نظر داشته باشید: آیا نظارت می تواند زودتر به این موضوع رسیدگی کند؟
نتیجه گیری
عیب یابی شبکه هم علم و هم هنر است. علم یک روش سیستماتیک را دنبال می کند، با استفاده از ابزارهای تشخیصی به درستی و پروتکل های درک. هنر دانستن این است که کدام تست ها برای اجرای اول بر اساس علائم، تشخیص الگوها از تجربه، و دانستن چه زمانی برای افزایش.
با پیروی از رویکرد سیستماتیک مندرج در این مقاله - با استفاده از سوالات درست، روش کار کردن از طریق مدل OSI، مستندسازی مراحل خود و یادگیری از هر مسئله - شما در عیب یابی و جلوگیری از مشکلات رایج که منجر به هدر رفتن زمان و اصلاح نادرست می شود، کارآمد تر خواهید شد.
به یاد داشته باشید: هدف این است که فقط برای بازگرداندن خدمات، بلکه برای درک اینکه چرا شکست خورده است، بنابراین شما می توانید از وقوع دوباره جلوگیری کنید.
آخرین به روز رسانی: فوریه 2، 2026 نویسنده: Baud9600 تیم فنی