عیب‌یابی Interface و کابل

تعریف مشکل و محدوده آن

اولین کار در عیب‌یابی این نیست که کابل عوض کنی یا دستور بزنی؛ باید بفهمی مشکل دقیقاً چیست. جمله «شبکه قطع است» اطلاعات کافی ندارد. می‌پرسی فقط یک کاربر مشکل دارد یا چند نفر؟ مشکل از چه زمانی شروع شده؟ آیا دستگاه جابه‌جا شده؟ آیا کابل یا Rack دستکاری شده؟ آیا Link کاملاً Down است یا ارتباط برقرار است ولی کند و ناپایدار؟ همین چند سؤال محدوده بررسی را کوچک می‌کند.

اگر فقط یک PC مشکل دارد و تمام کاربران همان Switch سالم‌اند، احتمال خرابی Uplink یا خاموش بودن کل Switch کمتر می‌شود. اگر تمام کاربران یک Access Switch هم‌زمان قطع شده‌اند، تمرکز روی یک Patch Cord کاربر منطقی نیست و باید Power، Uplink و وضعیت خود Switch را ببینی. Scope یعنی محدوده اثر مشکل. تعیین Scope به تو می‌گوید از کدام نقطه شروع کنی.

بعد وضعیت فعلی را بدون تغییر ثبت کن. شماره Interface، Status، Speed/Duplex و Counterهای مهم را یادداشت کن. اگر از راه دور هستی Description و مستندات را با دستگاه واقعی تطبیق بده. تغییر دادن Port قبل از ثبت وضعیت می‌تواند مدرکی را که به تشخیص علت کمک می‌کرد از بین ببرد. هدف این است که قبل از دست‌کاری بدانیم شبکه چه می‌گوید.

Switch# show interfaces status
Switch# show interfaces gigabitEthernet1/0/18

تست فیزیکی و Known-Good

Known-Good یعنی قطعه‌ای که می‌دانی سالم است. یک کابل نو لزوماً Known-Good نیست؛ بهتر است کابلی باشد که روی یک اتصال دیگر درست کار کرده یا با Tester معتبر تأیید شده است. استفاده از Known-Good کمک می‌کند یک متغیر را از معادله حذف کنی. اگر با کابل سالم Link بالا آمد، کابل قبلی مظنون جدی است. اگر Link همچنان Down ماند، باید به مرحله بعد بروی.

همین منطق برای Port هم وجود دارد. فرض کن PC روی Gi1/0/18 Link ندارد. PC را با همان کابل سالم به Gi1/0/19 که می‌دانی فعال و مناسب آزمایش است وصل می‌کنی. اگر Link تشکیل شد، NIC و کابل سالم احتمالاً کار می‌کنند و توجه به Port 18 یا Configuration آن بیشتر می‌شود. اگر روی Port دوم هم Link نیست، Endpoint یا کابل مسیر هنوز در فهرست علت‌هاست. هر تست باید فقط یک متغیر اصلی را عوض کند تا نتیجه قابل‌فهم باشد.

در مسیر واقعی ساختمان فقط Patch Cord کنار PC وجود ندارد. ممکن است مسیر شامل کارت شبکه PC، Patch Cord، Wall Outlet، کابل افقی، Patch Panel، Patch Cord داخل Rack و Port Switch باشد. اگر مستقیم با کابل سالم کنار Rack PC را به Switch وصل کنی و Link درست شود، بخش‌های حذف‌شده از مسیر ساختمان مشکوک می‌شوند. این نوع Bypass موقت یک ابزار تشخیصی است، نه راه‌حل دائمی برای رها کردن کابل وسط راهرو.

قبل از جدا کردن کابل‌ها Label و Port را ثبت کن. در Rack شلوغ اشتباه جدا کردن Uplink یا کابل دستگاه دیگر می‌تواند اختلال جدید بسازد. عیب‌یابی حرفه‌ای فقط پیدا کردن خطا نیست؛ باید هنگام پیدا کردن خطا از ساختن مشکل دوم هم جلوگیری کنی.

CLI و محدود کردن علت

خروجی CLI به تست فیزیکی جهت می‌دهد. administratively down یعنی اول Configuration را بررسی کن، نه اینکه پنج کابل مختلف عوض کنی. down/down یعنی Link پایه وجود ندارد و Media، Endpoint یا Port ارزش بررسی دارند. up/up همراه با CRC رو به افزایش یعنی اتصال تشکیل شده ولی کیفیت دریافت Frame مشکل دارد. a-100 روی دو Endpoint گیگابیتی می‌تواند تو را به سمت Pairهای کابل یا تنظیمات Endpoint ببرد.

Gi1/0/10 is administratively down, line protocol is down
Gi1/0/11 is down, line protocol is down
Gi1/0/12 is up, line protocol is up
  Full-duplex, 1000Mb/s
  210 input errors, 198 CRC

برای Port سوم لازم نیست چون up/up است پرونده فیزیکی را ببندی. CRC نشان می‌دهد Frameهایی با خطای صحت دریافت شده‌اند. مقدار را ثبت می‌کنی، Traffic ایجاد می‌کنی و روند افزایش را می‌بینی. برای Port دوم یک کابل سالم و دستگاه روشن در سمت مقابل تست مناسبی است. برای Port اول Configuration و علت shutdown اولویت دارد. یک دستور مشابه سه مسیر کاملاً متفاوت ساخته است.

Logها هم می‌توانند کمک کنند. Link Flap، Err-Disable یا هشدار Duplex ممکن است در Log دیده شود. Err-Disable حالتی است که Switch برای محافظت در برابر بعضی خطاها یا Policyها Port را غیرفعال می‌کند. علت‌های Err-Disable را در بخش‌های امنیت و Switching کامل‌تر یاد می‌گیریم. اینجا فقط بدان اگر Status چیزی مثل err-disabled نشان داد، تعویض کابل بدون دیدن Reason ممکن است مشکل را حل نکند.

هر بار فقط آن تستی را اجرا کن که سؤال بعدی را جواب می‌دهد. اگر Link Down است، Ping به Server چیزی درباره کابل ثابت نمی‌کند چون هنوز مسیر فیزیکی شکل نگرفته است. اگر Link و IP سالم‌اند ولی فقط یک Application مشکل دارد، تعویض SFP قدم منطقی اول نیست. ترتیب تست باید با سطحی که شواهد نشان می‌دهند هماهنگ باشد.

مسیر عیب‌یابی Copper و Fiber

در Copper، اتصال فیزیکی دو سر، نوع و Category کابل، Termination و سالم بودن Pairها مهم‌اند. برای Link گیگابیتی که روی 100Mb/s بالا آمده، Known-Good Patch Cord، Cable Tester و بررسی Keystone/Patch Panel ارزش دارند. برای CRC رو به افزایش، کابل سالم و Port دیگر کمک می‌کنند مسیر را تقسیم کنی. اگر کابل در مسیر برق یا محیط نویزی بد نصب شده، مشکل ممکن است با تعویض Patch Cord کوتاه کنار میز کاملاً آشکار نشود و کابل افقی هم باید بررسی شود.

در Fiber، مسیر تشخیص فرق دارد. اول نوع Fiber و Transceiver دو سمت را تطبیق می‌دهی؛ SR با SR و LR با LR، طول موج و نوع Fiber مناسب. بعد Tx/Rx و Connectorها را بررسی می‌کنی. Connector آلوده یکی از علت‌های رایج افت Optical است و باید با ابزار و روش مناسب Cleaning انجام شود؛ نگاه مستقیم به انتهای Fiber برای بررسی نور کار ایمنی نیست. اگر DOM در دسترس باشد، Tx/Rx Power را با محدوده Transceiver مقایسه می‌کنی.

در هر دو Media می‌توانی لینک را بخش‌بندی کنی. اگر مسیر Fiber از Switch A به Patch Panel، سپس مسیر ساختمان، Patch Panel دوم و Switch B می‌رود، تست با Fiber سالم در بخش‌های مختلف می‌تواند مشخص کند مشکل در کدام Segment است. ابزار و روش دقیق به نوع شبکه و دسترسی تیم بستگی دارد، اما منطق ثابت است: مسیر را به بخش‌های کوچک‌تر تقسیم کن و هر بخش را با شواهد رد یا تأیید کن.

اگر بعد از تعویض Transceiver Link بالا آمد، Transceiver قبلی مظنون است، اما بهتر است آن را روی Lab یا با ابزار مناسب دوباره بررسی کنی؛ ممکن است مشکل اصلی Connector یا نشستن ناقص Module بوده و با بیرون آوردن و جا زدن موقتاً رفع شده باشد. علت نهایی باید با بیش از یک نشانه پشتیبانی شود.

Verification و مستندسازی

رفع ظاهری مشکل آخر کار نیست. Verification یعنی بررسی کنی چیزی که کاربر نیاز داشت واقعاً پایدار شده است. Link را دوباره می‌بینی، Speed/Duplex را تأیید می‌کنی، Counterهای خطا را در یک بازه بررسی می‌کنی و تست کاربردی انجام می‌دهی. اگر کاربر از انتقال فایل شکایت داشت، فقط Ping کافی نیست؛ همان انتقال فایل یا یک تست مشابه باید دوباره انجام شود.

بعد تغییر انجام‌شده را مستند کن. اطلاعات مفید شامل Interface، دستگاه، علائم اولیه، Counterهای مهم، تست‌هایی که انجام شد، علت نهایی و تغییری است که مشکل را برطرف کرد. جمله «کابل عوض شد» از جمله «CRC روی Gi1/0/18 هنگام انتقال فایل افزایش داشت؛ Patch Cord معیوب با کابل تست‌شده جایگزین شد؛ پس از ۱۰ دقیقه Traffic خطای جدید ثبت نشد» اطلاعات بسیار کمتری می‌دهد.

اگر علت کامل پیدا نشد ولی سرویس موقتاً برگشت، آن را صادقانه ثبت کن. مثلاً بنویس با Reseat کردن SFP Link برگشت ولی Root Cause هنوز قطعی نیست و نیاز به پایش دارد. Root Cause یعنی علت اصلی‌ای که مشکل را ایجاد کرده است. فرق بین «سرویس برگشته» و «علت اصلی اثبات شده» برای عملیات شبکه مهم است.

آخرین بررسی این است که تغییر تو مشکل دیگری نساخته باشد. اگر Port را جابه‌جا کردی، VLAN و Policy آن Port باید درست باشد. اگر SFP را عوض کردی، سرعت و سازگاری دو طرف را ببین. اگر کابل مسیر را عوض کردی، Label و مستندات را به‌روز کن. عیب‌یابی خوب با یک شبکه مرتب‌تر تمام می‌شود، نه با یک راه‌حل موقت و نامشخص.