وبلاگ
- مهسا رهنمایی
- سوئیچ شبکه
اختلال در Cisco Switch همیشه به معنی خرابی فیزیکی دستگاه نیست. در بسیاری از شبکهها، مشکل از کانفیگ، VLAN، Trunk، STP، جدول MAC، خطاهای Interface، نسخه IOS، دسترسی مدیریتی یا فعال بودن نادرست Featureهای امنیتی و کنترلی ایجاد میشود. این نوع مشکلات معمولاً با بررسی مرحلهای، تحلیل لاگها و اصلاح تنظیمات قابل تشخیص و رفع هستند.
در این مقاله، مشکلات رایج در Cisco Switch را از زاویه عیبیابی شبکه بررسی میکنیم. تمرکز این صفحه روی خطاهای نرمافزاری، پیکربندی، لاگها و ارتباطات لایه ۲ و ۳ است. اگر دستگاه روشن نمیشود، پاور خطا دارد، فن کار نمیکند، پورت از نظر فیزیکی آسیب دیده یا احتمال خرابی برد وجود دارد، مقاله خرابی سختافزاری دستگاه را مطالعه کنید.
از کجا عیبیابی را شروع کنیم؟
عیبیابی باید از سادهترین لایه شروع شود و بهتدریج به تنظیمات پیچیدهتر برسد. اگر بدون بررسی وضعیت فیزیکی، لاگها، VLANها و جدول MAC مستقیم سراغ تغییرات بزرگ در کانفیگ بروید، احتمال تشخیص اشتباه بالا میرود. روش درست این است که ابتدا علائم را مشخص کنید، سپس مرحلهبهمرحله مسیر ارتباط، وضعیت پورت، جدولهای کنترلی و تنظیمات نرمافزاری را بررسی کنید.
در بیشتر سناریوها، باید ابتدا مشخص شود مشکل فقط روی یک کاربر یا پورت دیده میشود، روی یک VLAN رخ داده، بین دو سوئیچ وجود دارد، یا کل شبکه را تحت تأثیر قرار داده است. همین تفکیک اولیه مسیر عیبیابی را کوتاهتر میکند.
چارچوب مرحلهای برای عیبیابی
برای بررسی دقیق، میتوان از یک چارچوب چهار مرحلهای استفاده کرد. این چارچوب کمک میکند مشکل از کابل، پورت، VLAN، Trunk، STP، لاگها یا نرمافزار دستگاه جدا شود.
- بررسی اولیه لینک و پورت: وضعیت چراغها، کابل، Speed/Duplex و Interface بررسی شود.
- بررسی لایه ۲: VLAN، Trunk، MAC Table، STP و EtherChannel کنترل شود.
- تحلیل لاگ و منابع سیستم: Syslog، CPU، Memory، Interface Counters و Eventها بررسی شوند.
- بررسی IOS و Featureها: نسخه نرمافزار، ACL، QoS، DHCP Snooping، Port Security و دسترسی مدیریتی کنترل شود.
چارچوب مرحلهای برای عیبیابی Cisco Switch
مرحله ۱
بررسی اولیه لینک و پورت
Basic Physical Check
مرحله ۲
تست ارتباط و لایه شبکه
Connectivity & Layer Diagnostics
مرحله ۳
تحلیل لاگها و وضعیت سیستم
Logs, Events, CPU & Memory
مرحله ۴
تحلیل نرمافزار، IOS و پیکربندی
Configuration & IOS Review
مشکل در شناسایی دستگاهها و MAC Table
یکی از مشکلات رایج این است که کلاینتها یا سرورها به پورت متصل هستند، اما در شبکه دیده نمیشوند. در این حالت ممکن است MAC Address دستگاه در جدول MAC ثبت نشود یا روی VLAN اشتباه قرار گرفته باشد. این مشکل معمولاً به تنظیم نادرست VLAN، Shutdown بودن پورت، Trunk اشتباه، محدودیت Port Security یا اتصال به Access Port نادرست مربوط است.
برای بررسی، ابتدا وضعیت پورت را کنترل کنید. اگر پورت Up است اما MAC Address دیده نمیشود، باید VLAN، Port Mode، محدودیتهای امنیتی و جدول MAC بررسی شود. دستورهایی مانند show mac address-table، show vlan brief و show interfaces status در این مرحله کاربرد دارند.
اگر MAC Address روی پورت دیگری دیده میشود، احتمال جابهجایی کابل، اتصال به سوئیچ شبکه دیگر یا وجود Loop در شبکه مطرح میشود. اگر MAC Table مرتباً تغییر کند، باید STP و مسیرهای لایه ۲ هم بررسی شوند.
خطاهای VLAN و Trunk
بخش زیادی از اختلالات ارتباطی به VLAN و Trunk مربوط میشود. اگر VLAN روی یک سوئیچ وجود داشته باشد اما روی سوئیچ دیگر تعریف نشده باشد، یا پورت بین دو دستگاه در حالت Trunk تنظیم نشده باشد، ترافیک بین بخشهای مختلف شبکه بهدرستی عبور نمیکند.
اشتباه در Native VLAN، مجاز نبودن VLAN روی Trunk، تنظیمات نادرست VTP یا تعریف اشتباه Access VLAN میتواند باعث شود دستگاهها به ظاهر وصل باشند اما ارتباط نداشته باشند. برای تشخیص، دستورهای show vlan brief، show interfaces trunk و show vtp status کمککننده هستند.
در این بخش نباید فقط یک سمت لینک بررسی شود. اگر بین دو دستگاه ارتباط Trunk وجود دارد، تنظیمات هر دو سمت باید از نظر Mode، Native VLAN و VLANهای مجاز با هم هماهنگ باشند.
Loop، STP و ناپایداری ارتباط
قطع و وصل شدن شبکه، افزایش Broadcast، کندی ناگهانی یا تغییر مداوم مسیرهای لایه ۲ میتواند نشانه وجود Loop یا تنظیمات نادرست STP باشد. در شبکههایی که چند سوئیچ به هم متصل هستند، کوچکترین اشتباه در طراحی لینکها یا غیرفعال کردن تنظیمات حفاظتی میتواند باعث اختلال گسترده شود.
برای عیبیابی، وضعیت Root Bridge، پورتهای Blocking، تغییرات Topology و لاگهای STP باید بررسی شود. دستورهایی مانند show spanning-tree و بررسی پیامهای Syslog در این مرحله اهمیت دارند.
اگر Topology Change زیاد ثبت میشود یا یک پورت مرتباً بین حالتهای مختلف جابهجا میشود، باید لینکهای فیزیکی، تنظیمات EtherChannel، مسیرهای افزونه و احتمال اتصال اشتباه کابل بررسی شود.
مشکلات EtherChannel و لینکهای تجمیعی
EtherChannel زمانی مفید است که چند لینک فیزیکی بهصورت یک لینک منطقی کار کنند. اما اگر تنظیمات دو سمت لینک یکسان نباشد، ممکن است بخشی از ترافیک عبور نکند، لینک ناپایدار شود یا پورتها وارد وضعیت Suspended شوند.
اختلاف در Mode، سرعت، Duplex، VLANهای مجاز، Native VLAN یا پروتکلهایی مثل LACP و PAgP از دلایل رایج اختلال در EtherChannel است. برای بررسی، میتوان از دستورهایی مانند show etherchannel summary و show interfaces trunk استفاده کرد.
اگر یک لینک داخل Port-Channel مشکل دارد، نباید فقط همان پورت بررسی شود. هماهنگی کل گروه، تنظیمات هر دو سمت و وضعیت لاگها باید با هم بررسی شوند.
خطاهای Speed، Duplex و Interface Counters
گاهی ارتباط برقرار است، اما سرعت شبکه پایین است یا Packet Loss دیده میشود. در چنین شرایطی، باید وضعیت Speed و Duplex و خطاهای Interface بررسی شود. عدم تطابق Duplex بین دو سمت لینک میتواند باعث CRC Error، Collision، کندی و ناپایداری ارتباط شود.
در خروجی Interface Counters باید به خطاهایی مانند CRC، Input Errors، Output Errors، Drops و Late Collisions توجه شود. اگر خطا فقط روی یک پورت دیده میشود، کابل، دستگاه متصل و تنظیمات همان لینک بررسی شود. اگر خطا روی چند پورت یا لینک اصلی دیده میشود، احتمال مشکل طراحی، ترافیک غیرعادی یا خطای گستردهتر وجود دارد.
در بسیاری از موارد، تنظیم درست Speed و Duplex، تعویض کابل، اصلاح Trunk یا حذف Loop باعث رفع مشکل میشود. اگر بعد از این اقدامات خطا باقی بماند، احتمال خرابی فیزیکی پورت باید جداگانه بررسی شود.
مصرف بالای CPU و Memory
مصرف بالای CPU یا Memory میتواند باعث کندی دسترسی مدیریتی، تأخیر در پاسخ، اختلال در بعضی Featureها یا ثبت لاگهای متعدد شود. این وضعیت همیشه به معنی خرابی دستگاه نیست و ممکن است به Broadcast زیاد، Loop، پردازش غیرعادی پروتکلها، ACLهای سنگین، SNMP Polling زیاد یا باگ نرمافزاری مربوط باشد.
برای بررسی، ابتدا باید مشخص شود مصرف منابع دائمی است یا مقطعی. سپس فرآیندهای فعال، حجم لاگها، وضعیت STP، ترافیک ورودی و Featureهای فعال بررسی شوند. دستورهای مرتبط با CPU، Memory و Logging در این مرحله مسیر تشخیص را روشنتر میکنند.
اگر مصرف بالا همزمان با تغییر در توپولوژی، فعال شدن یک سرویس جدید یا اتصال یک لینک جدید شروع شده باشد، باید همان تغییرات اخیر بهعنوان نقطه شروع بررسی شوند.
تحلیل Syslog و پیامهای خطا
Syslog یکی از مهمترین منابع عیبیابی است. بسیاری از خطاها قبل از اینکه به قطعی کامل تبدیل شوند، در لاگها دیده میشوند. پیامهای مربوط به Up/Down شدن پورتها، تغییرات STP، خطاهای امنیتی، مشکل احراز هویت، خطاهای Interface یا هشدارهای IOS باید بهصورت مرحلهای بررسی شوند.
اگر مشکل بهصورت تصادفی رخ میدهد، زمان وقوع خطا اهمیت زیادی دارد. باید زمان ثبت لاگ با قطعی سرویس، تغییرات شبکه، افزایش ترافیک یا ریست شدن دستگاه مقایسه شود. این کار باعث میشود علت اصلی از نشانههای فرعی جدا شود.
در شبکههای سازمانی، ارسال لاگها به یک Syslog Server مرکزی باعث میشود حتی بعد از ریبوت یا پاک شدن لاگ محلی، سابقه خطاها قابل بررسی باشد.
مشکلات IOS و ناسازگاری نسخه نرمافزار
نسخه IOS میتواند روی پایداری، امکانات فعال، سازگاری ماژولها و رفتار کلی دستگاه اثر بگذارد. گاهی یک نسخه قدیمی یا ناسازگار باعث ریست ناگهانی، مشکل در Featureها، ناپایداری Stack یا اختلال در SFP و ماژولها میشود.
قبل از ارتقا یا Rollback، باید مدل دستگاه، نسخه فعلی، حافظه در دسترس، نیاز شبکه و سازگاری Featureها بررسی شود. تغییر نسخه نرمافزار بدون بررسی میتواند مشکل جدید ایجاد کند؛ مخصوصاً در شبکههایی که Stack، EtherChannel، Routing یا Featureهای امنیتی فعال دارند.
در صورت مشاهده Crash، ریبوتهای ناگهانی یا رفتار غیرعادی بعد از ارتقا، بررسی Release Notes، Crash Info و سازگاری نسخه با مدل دستگاه ضروری است.
اختلال در SSH، SNMP، Syslog و دسترسی مدیریتی
گاهی شبکه کار میکند، اما مدیریت دستگاه مختل شده است. قطع شدن SSH، پاسخ ندادن SNMP، ثبت نشدن Syslog یا محدود شدن دسترسی مدیریتی میتواند عیبیابی را سخت کند. این مشکلات معمولاً به ACL، تنظیمات VTY، Community، آدرس سرور مقصد، Routing مدیریتی یا تنظیمات احراز هویت مربوط هستند.
برای بررسی SSH و Telnet، وضعیت خطوط VTY، ACLهای دسترسی، نام کاربری، روش احراز هویت و آدرس مدیریتی کنترل شود. برای SNMP، نسخه SNMP، Community یا User، Access List و دسترسی سرور مانیتورینگ باید بررسی شود.
در مورد Syslog نیز باید آدرس سرور، سطح Logging، مسیر ارتباطی و ساعت دستگاه بررسی شود. اگر زمان دستگاه درست نباشد، تحلیل لاگها دشوار میشود.
خطاهای ACL، QoS و Featureهای امنیتی
بعضی اختلالات بهدلیل فعال بودن یا تنظیم اشتباه Featureهای کنترلی ایجاد میشوند. ACLهای نادرست میتوانند ترافیک مجاز را مسدود کنند. تنظیم نادرست QoS ممکن است باعث محدود شدن ترافیک حساس شود. DHCP Snooping، Dynamic ARP Inspection، Port Security یا Storm Control هم اگر بدون طراحی درست فعال شوند، میتوانند ارتباط بعضی کلاینتها را مختل کنند.
در این بخش باید آخرین تغییرات کانفیگ، لاگهای مربوط به Drop یا Violation، وضعیت پورتها و سیاستهای فعال بررسی شود. گاهی مشکل فقط با اصلاح یک ACL، افزایش MAC Limit، هماهنگ کردن Trusted Portها یا اصلاح Policy برطرف میشود.
برای جلوگیری از قطعی ناخواسته، فعالسازی Featureهای امنیتی باید مرحلهای انجام شود و بعد از هر تغییر، وضعیت لاگها و ارتباط کاربران بررسی شود.
جدول خلاصه عیبیابی
| نشانه مشکل | علت احتمالی | بررسی پیشنهادی | مسیر رفع مشکل |
|---|---|---|---|
| کلاینتها دیده نمیشوند | VLAN اشتباه، پورت Shutdown، MAC Table خالی | بررسی VLAN، Port Status و MAC Table | اصلاح Access VLAN، فعالسازی پورت و بررسی مسیر اتصال |
| ارتباط بین دو دستگاه قطع است | Trunk نادرست، Native VLAN mismatch، VLAN مجاز نیست | بررسی Trunk و VLANهای مجاز در هر دو سمت | هماهنگسازی Trunk، Native VLAN و تنظیمات دو سمت لینک |
| شبکه کند یا ناپایدار است | Loop، STP نامناسب، Broadcast زیاد | بررسی STP، لاگها و تغییرات Topology | اصلاح طراحی لایه ۲، بررسی لینکهای افزونه و کنترل Broadcast |
| پورت خطا ثبت میکند | Duplex mismatch، کابل نامناسب، خطای Interface | بررسی Counters، Speed/Duplex و کابل | اصلاح تنظیمات لینک، تعویض کابل و تست روی پورت دیگر |
| دسترسی مدیریتی قطع شده | ACL، VTY، SSH، SNMP یا Routing مدیریتی | بررسی ACL، خطوط VTY، آدرس مدیریتی و مسیر ارتباط | اصلاح دسترسی مدیریتی، SNMP، SSH و Syslog |
| ریست یا رفتار غیرعادی دیده میشود | IOS، باگ نرمافزاری، ناسازگاری ماژول یا Feature | بررسی IOS، Crash Info، Release Notes و لاگها | Rollback یا ارتقای کنترلشده پس از بررسی سازگاری |
چه زمانی احتمال خرابی سختافزاری مطرح میشود؟
اگر بعد از بررسی کابل، VLAN، Trunk، STP، Interface Counters، IOS و لاگها همچنان مشکل باقی بماند، باید احتمال خرابی فیزیکی بررسی شود. مخصوصاً وقتی یک پورت با کابل و دستگاه سالم همچنان لینک نمیگیرد، دستگاه بدون دلیل خاموش میشود، Fan Error ثبت میشود یا چند پورت همزمان رفتار غیرعادی دارند.
در چنین شرایطی بهتر است مسیر نرمافزاری و سختافزاری از هم جدا شود. اگر مشکل به پاور، فن، برد، ASIC، دما یا آسیب فیزیکی مربوط باشد، ادامه عیبیابی نرمافزاری نتیجهای ندارد و باید دستگاه از نظر فنی بررسی شود.
چکلیست سریع عیبیابی
- مشخص کنید مشکل روی یک پورت است یا کل شبکه.
- وضعیت لینک، کابل و Speed/Duplex را بررسی کنید.
- VLAN و Trunk دو سمت لینک را کنترل کنید.
- MAC Table و ARP را بررسی کنید.
- STP و تغییرات Topology را کنترل کنید.
- Interface Counters و خطاهای CRC یا Drops را بررسی کنید.
- Syslog و زمان وقوع خطا را با قطعی شبکه مقایسه کنید.
- مصرف CPU و Memory را بررسی کنید.
- IOS، Crash Info و تغییرات اخیر کانفیگ را کنترل کنید.
- ACL، QoS، Port Security، DHCP Snooping و Featureهای فعال را بررسی کنید.
جمعبندی
بیشتر مشکلات Cisco Switch از چند مسیر مشخص قابل بررسی هستند: وضعیت پورت و لینک، VLAN و Trunk، STP، جدول MAC، لاگها، IOS و Featureهای فعال. اگر عیبیابی مرحلهبهمرحله انجام شود، بسیاری از خطاها بدون تعویض دستگاه و فقط با اصلاح تنظیمات یا بررسی نرمافزار برطرف میشوند.
اگر پس از بررسیهای نرمافزاری مشخص شد دستگاه دیگر پاسخگوی نیاز شبکه نیست، میتوانید برای مقایسه گزینههای جایگزین، دسته مدلهای Cisco Switch را مشاهده کنید. این مقاله برای عیبیابی فنی نوشته شده و تمرکز آن روی فروش یا مقایسه مدلها نیست.
سوالات متداول
اولین مرحله در عیبیابی Cisco Switch چیست؟
ابتدا باید مشخص شود مشکل روی یک پورت، یک VLAN، یک لینک بین تجهیزات یا کل شبکه دیده میشود. سپس وضعیت لینک، کابل، پورت، VLAN و لاگها بررسی شود.
چرا دستگاهها در MAC Table دیده نمیشوند؟
این مشکل معمولاً به Access VLAN اشتباه، Shutdown بودن پورت، Trunk نادرست، Port Security یا اتصال اشتباه کابل مربوط است. بررسی show mac address-table و show vlan brief میتواند مسیر تشخیص را مشخص کند.
علت قطع و وصل شدن ارتباط در شبکه چیست؟
قطع و وصل شدن ارتباط ممکن است به Loop، STP نامناسب، Duplex mismatch، خطای Trunk، کابل مشکلدار یا تغییرات مکرر Topology مربوط باشد. لاگها و Interface Counters باید بررسی شوند.
مشکل VLAN و Trunk چگونه تشخیص داده میشود؟
باید وضعیت VLANها، Trunk Mode، Native VLAN و VLANهای مجاز در هر دو سمت لینک بررسی شود. اختلاف تنظیمات دو سمت یکی از دلایل رایج قطعی ارتباط است.
مصرف بالای CPU همیشه نشانه خرابی است؟
خیر. مصرف بالای CPU میتواند ناشی از Broadcast زیاد، Loop، SNMP Polling، ACL سنگین، Featureهای فعال یا باگ نرمافزاری باشد. ابتدا باید لاگها، فرآیندها و تغییرات اخیر بررسی شوند.
چه زمانی باید احتمال خرابی سختافزاری را بررسی کرد؟
اگر بعد از بررسی کابل، VLAN، Trunk، STP، IOS و لاگها مشکل باقی بماند، یا نشانههایی مثل روشن نشدن دستگاه، Fan Error، خطای پاور یا خرابی چند پورت دیده شود، باید سلامت سختافزار بررسی شود.
جهت هرگونه مشاوره در زمینه خرید تجهیزات شبکه با ما تماس بگیرید کارشناسان ما آماده پاسخگویی به شما هستند.
