اگر هنگام اتصال به کنسول سوئیچ متوجه شدید دستورات با تأخیر اجرا میشوند یا حتی اجرای یک دستور ساده چند ثانیه طول میکشد، نشان از این است که CPU سوئیچ تحت فشار قرار گرفته است. در چنین شرایطی مشکل فقط کند شدن CLI نیست. ممکن است پکتها با تأخیر پردازش شوند، پروتکلهای کنترلی ناپایدار شوند و حتی در موارد شدید سوئیچ ریبوت شود. این وضعیت در شبکههای سازمانی زیاد دیده میشود. بهخصوص وقتی که ترافیک غیرعادی، اسکن شبکه یا یک Loop در لایه دوم اتفاق میافتد. در ادامه بهصورت عملی به رفع مشکل CPU Load در سوئیچ سیسکو میپردازیم.
⏲ مدت زمان تخمینی مطالعه: 12 دقیقه
فهرست موضوعات
علائم High CPU در سوئیچ سیسکو و راهکار سریع
| علامت / نشانه | راهکار سریع |
|---|---|
| CLI با تأخیر چند ثانیهای پاسخ میدهد | show processes cpu sorted — Process پرمصرف را شناسایی کن |
| کاربران از کندی ناگهانی شبکه شکایت دارند | show processes cpu history — بررسی کن مشکل موقتی است یا مداوم |
| Packet Loss در مانیتورینگ نمایش داده میشود | show interfaces counters — پورت پرترافیک را پیدا و موقتاً غیرفعال کن |
| پینگ Gateway ناپایدار یا متناوب است | show ip arp summary — بررسی ARP Flood یا Broadcast Storm |
عدد Interrupt در خروجی CPU بالاست (مثلاً 80%/55%) |
show ip traffic — ترافیک Control Plane را بررسی کن؛ احتمالاً ARP Flood یا ICMP Storm |
| Process Spanning Tree در صدر لیست CPU است | show spanning-tree detail — تعداد Topology Change را بررسی کن؛ احتمال Loop در لایه ۲ |
| Process ARP Input در صدر لیست است | ابزار اسکن یا VM معیوب را پیدا کن؛ CoPP برای ARP اعمال کن |
| Process SNMP Engine CPU بالا دارد | بازه Polling را به حداقل ۶۰ ثانیه برای اینترفیس و ۱۲۰ ثانیه برای CPU تنظیم کن |
| CPU در ساعات غیراوج هم بالای ۷۰٪ است | show sdm prefer — بررسی SDM Template؛ احتمال Overflow از TCAM به CPU |
| سوئیچ بدون دلیل ریبوت میکند | show log — بررسی Memory Leak یا Crash در IOS؛ بهروزرسانی فوری |
نشانههای اشباع شدن پردازنده در شبکه (کندی و پکت لاس)
قبل از اینکه سراغ کنسول بروید، معمولاً علائم زیر در شبکه دیده میشود.
- کاربران از کندی ناگهانی شبکه شکایت میکنند
- مانیتورینگ شبکه Packet Loss نشان میدهد
- پینگ Gateway ناپایدار میشود
- دستورات CLI با چند ثانیه تأخیر اجرا میشوند
اینها اولین نشانههای High CPU در Control Plane هستند.
تفاوت بار پردازشی نرمافزاری با سربار Interrupt
در خروجی CPU دو عدد بیشتر از بقیه مهم هستند. اولی مصرف کلی پردازنده را نشان میدهد و دومی سهم Interrupt را.
- وقتی مقدار Interrupt در خروجی CPU بالا باشد، سوئیچ تعداد زیادی بسته را بهطور مستقیم به پردازنده ارسال کرده است. این بستهها دیگر در مسیر عادی سوئیچینگ سختافزاری پردازش نمیشوند و به Control Plane منتقل میشوند. این وضعیت در سناریوهایی مثل ARP Flood، Broadcast Storm یا حجم بالای ترافیک کنترلی دیده میشود.
- در مقابل وقتی مصرف نرمافزاری CPU بالا باشد، یکی از فرآیندها یا سرویسهای سیستمعامل IOS منابع پردازشی زیادی را مصرف میکند. بنابراین برای پیدا کردن علت اصلی High CPU باید مشخص کنید افزایش مصرف مربوط به Interruptها است یا فرآیندهای نرمافزاری.
چطور وضعیت فعلی CPU سوئیچ را بررسی کنیم؟
اول باید بفهمید CPU واقعاً درگیر است یا فقط یک پیک لحظهای اتفاق افتاده. به همین دلیل به سراغ دستوراتی میرویم که در این بخش آنها را تحلیل میکنیم. ابزار اصلی برای این کار CLI سوئیچ است.
تحلیل خروجی دستور show processes cpu sorted
با استفاده از این دستور لیست پردازشها بر اساس مصرف CPU مرتب میشود:
show processes cpu sorted
نمونه خروجی این کد به صورت زیر است:
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
123 3456789 45678 75 40% 32% 28% 0 IP Input
89 1234567 23456 52 18% 12% 10% 0 ARP Input
55 456789 9876 46 10% 8% 7% 0 Spanning Tree
در این خروجی سه ستون بیشتر از بقیه برای عیبیابی مناسبند:
- 5Sec نشان دهنده میزان مصرف لحظهای CPU است.
- 1Min میانگین مصرف CPU در یک دقیقه گذشته است.
- 5Min مصرف CPU در پنج دقیقه اخیر را نشان میدهد.
اگر فقط مقدار 5Sec بالا باشد با یک افزایش مصرف موقت روبهرو هستید و مشکل جدی وجود ندارد. اما اگر مقدار 5Min هم بالا باشد، یعنی فشار روی CPU برای مدت طولانی ادامه داشته که باید علت آن را بررسی کنید.
تشخیص لحظهای بودن مشکل یا دائمی بودن آن با History
دستور زیر کمک میکند بفهمید مصرف CPU فقط یک جهش لحظهای بوده یا مدت طولانی ادامه داشته است.
show processes cpu history
خروجی این دستور یک نمودار ساده ASCII نمایش میدهد که رفتار CPU را در بازههای زمانی مختلف نشان میدهد. اگر فقط چند قله کوتاه در نمودار دیده شود مشکل موقتی است. اما وقتی بخش زیادی از نمودار در محدوده بالا قرار دارد، یعنی CPU برای مدت طولانی تحت فشار بوده و باید علت آن را جدیتر بررسی کرد.
کدام پروسه باعث افزایش CPU Load در سوئیچ سیسکو میشود؟
وقتی CPU بالا میرود چند Process خاص بیشتر از بقیه در خروجی دیده میشوند. در جدول زیر چند Process مهم را میبینید که در زمان High CPU بیشتر از بقیه دیده میشوند.
| Process | دلیل متداول |
|---|---|
| IP Input | حجم بالای ترافیک مسیریابی، اسکن شبکه یا حملات مخرب |
| ARP Input | ارسال بیش از حد درخواستهای ARP یا وجود کلاینتهای معیوب |
| Spanning Tree | بروز لوپ در لایه دوم شبکه یا تغییرات مکرر در توپولوژی |
| SNMP Engine | تعداد زیاد درخواستهای مانیتورینگ از سمت سیستمهای نظارتی |
بررسی پروسه IP Input (ترافیک مسیریابی و حملات)
اگر پروسه IP Input سهم قابلتوجهی از CPU را مصرف کند یکی از عوامل زیر در شبکه وجود دارد:
- اجرای اسکن پورت توسط یک دستگاه یا کاربر
- ارسال حجم زیادی از بستههای ICMP
- عبور ترافیکی که امکان پردازش آن توسط ASIC وجود ندارد و مستقیماً به CPU ارجاع داده میشود
در این حالت باید ببینید این ترافیک از کدام پورت یا کدام میزبان وارد شبکه میشود که با دو دستور زیر میتوانید به نتیجه برسید:
show ip traffic
show interfaces counters
بررسی پروسه ARP Input (اسکنهای شبکه و نقص کلاینتها)
افزایش مصرف CPU توسط ARP Input اغلب به دلیل حجم غیرعادی درخواستهای ARP رخ میدهد. از مهمترین عوامل ایجاد این مشکل اجرای ابزارهای اسکن شبکه، ماشینهای مجازی یا کلاینتهای دارای اختلال و وجود Loop در محدوده Broadcast Domainمیباشد. میتوانید از دستور زیر برای ارزیابی وضعیت جدول ARP و بررسی حجم درخواستها استفاده کنید:
show ip arp summary
بررسی پروسه Spanning Tree
بالا بودن مصرف CPU توسط پروسه Spanning Tree یعنی وجود مشکل در لایه دوم. اولین کاری که باید انجام دهید، بررسی توپولوژی و وضعیت لینکهاست. دستور مورد نیاز برای مشاهده جزئیات و بررسی تغییرات توپولوژی:
show spanning-tree detail
اگر مقدار Topology Change بهصورت مداوم افزایش پیدا میکند احتمال وجود Loop در شبکه بسیار زیاد است و باید مسیر آن شناسایی و برطرف شود.
مراحل عملیاتی برای پایین آوردن بار پردازنده سوئیچ
بعد از شناسایی علت مصرف بالای CPU نوبت به اجرای اقدامات اصلاحی است. در این مرحله فقط مشاهده وضعیت کافی نیست و باید با اعمال تنظیمات مناسب، فشار وارد شده به پردازنده را کم کنید.
شناسایی و مسدودسازی اینترفیسهای پر ترافیک (Top Talkers)
اولین مرحله پیدا کردن پورتی است که بیشترین حجم ترافیک را به شبکه وارد میکند. این پورتها در بسیاری از موارد عامل اصلی افزایش بار پردازشی سوئیچ هستند. برای بررسی میزان ترافیک هر اینترفیس میتوانید از دستورات زیر استفاده کنید:
show interfaces counters
در برخی مدلهای جدیدتر نیز دستور زیر کاربرد دارد:
show platform port-asic stats drop
اگر مشاهده کردید یک پورت حجم غیرعادی از ترافیک را تولید میکند، بهصورت موقت آن را غیرفعال کنید و تغییرات مصرف CPU را زیر نظر بگیرید. کاهش محسوس بار پردازنده بعد از این کار نشان دهنده ارتباط مستقیم آن پورت با مشکل است.
محدود کردن ترافیک ورودی به پردازنده با CoPP
از مهمترین روشهایی که برای محافظت از پردازنده سوئیچ وجود دارد استفاده از قابلیت Control Plane Policing یا CoPP است. این قابلیت به شما امکان میدهد میزان ترافیکی که مستقیماً به CPU ارسال میشود را کنترل و محدود کنید. بنابراین در شرایطی که حجم زیادی از بستههای کنترلی یا مخرب وارد شبکه شوند پردازنده اشباع نخواهد شد. نمونهای از پیادهسازی ساده CoPPرا بیان میکنیم. این سیاست، ترافیک ARP و ICMP را پیش از رسیدن به CPU کنترل میکند. همچنین از افزایش ناگهانی مصرف پردازنده جلوگیری میکند.
class-map match-any CONTROL-PLANE-TRAFFIC
match protocol arp
match protocol icmp
policy-map CONTROL-PLANE-POLICY
class CONTROL-PLANE-TRAFFIC
police rate 8000 pps
control-plane
service-policy input CONTROL-PLANE-POLICY
بهینهسازی تنظیمات مانیتورینگ و SNMP برای کاهش فشار
گاهی مشکل از شبکه نیست، از سیستم مانیتورینگ میآید. در بعضی سازمانها ابزار مانیتورینگ هر چند ثانیه یک بار وضعیت اینترفیسها، CPU و حافظه سوئیچ را Poll میکند. وقتی تعداد این درخواستها زیاد باشد، سوئیچ باید مرتب به آنها پاسخ بدهد و همین موضوع به مرور باعث بالا رفتن مصرف CPU میشود.
به همین دلیل بهتر است فاصله Polling منطقی تنظیم شود:
- Poll مربوط به اینترفیسها: هر 60 ثانیه
- Poll مربوط به مصرف :CPU هر 120 ثانیه
طبق تجربه تیم تجارت سرور پارسه تنها با اصلاح بازههای Polling و کاهش تعداد درخواستهای مانیتورینگ میتوانید مصرف CPU را کاهش دهید.
اشتباهات رایج در عیبیابی CPU سیسکو
هنگام جستجو برای رفع مشکل CPU Load در تجهیزات سیسکو، با توصیههای مختلفی در اینترنت روبهرو میشوید. این راهکارها تخصصی نیستند و برخی از آنها حتی مشکل را بدتر میکنند. پس قبل ازهر اقدامی ابتدا علت اصلی افزایش مصرف CPU را شناسایی کنید.
آیا غیرفعال کردن CDP یا تغییر Port-Security واقعاً تاثیر دارد؟
یکی از پیشنهادهای رایج غیرفعال کردن CDP یا تغییر تنظیمات Port Security است. این راهکار در عمل تأثیر محسوسی بر کاهش مصرف CPU ندارد. زیرا پروتکل CDP حجم بسیار کمی از منابع پردازشی را مصرف میکند پس عامل اصلی بروز High CPU نیست. غیرفعال کردن CDP بدون بررسی دقیق شرایط شبکه، بیشتر یک اقدام حدسی است تا یک راهکار فنی.
اما منشأ واقعی مشکل به حجم بالای ترافیکی مربوط است که به بخش Control Plane ارسال میشود. بنابراین تمرکز عیبیابی باید روی شناسایی این ترافیک و علت ورود آن به پردازنده باشد، نه غیرفعال کردن سرویسهایی که نقش ناچیزی در مصرف CPU دارند.
نقش اشتباه قالبهای SDM در درگیر شدن پردازنده
SDM Template مشخص میکند TCAM چگونه بین Routing و Switching تقسیم شود. اگر Template انتخابشده متناسب با نیاز شبکه نباشد، ظرفیت TCAM سریعتر پر میشود و بخشی از ترافیک به CPU ارسال خواهد شد. این موضوع مصرف پردازنده را بالا برده و عملکرد سوئیچ را کاهش میدهد.
در کلTCAM برای پردازش سریع و سختافزاری بستهها طراحی شده است اما CPU وظیفه پردازش نرمافزاری را بر عهده دارد. پس هرچه ترافیک بیشتری در TCAM پردازش شود فشار کمتری به CPU وارد خواهد شد.
چک لیست پیشگیری از بالا رفتن مجدد بار پردازنده
بهروزرسانی IOS و رفع باگهای نرمافزاری Memory Leak: بعضی نسخههای IOS باگهایی دارند که باعث Memory Leak و افزایش مصرف CPU میشوند. قبل از ارتقا Release Notes را بررسی کنید.
استفاده از EEM Script برای ارسال هشدار خودکار در زمان بحران: میتوانید هنگام افزایش CPU با نمونه اسکریپت ساده زیر هشدار دریافت کنید:
event manager applet HIGH_CPU_ALERT
event snmp oid 1.3.6.1.4.1.9.2.1.58 get-type exact entry-op ge entry-val 80 poll-interval 30
action 1.0 syslog msg “WARNING: CPU usage exceeded 80%”
action 2.0 mail server 192.168.1.10 to admin@network.com from switch@network.com subject “High CPU Alert”
این اسکریپت وقتی CPU از 80٪ عبور کند هشدار ارسال میکند.
جمعبندی
برای حل مشکل CPU Load در سوئیچ سیسکو در باید سه مرحله را طی کنید:
- اول وضعیت واقعی CPU را بررسی کنید و ببینید کدام Process بیشترین مصرف را دارد.
- بعد از آن منبع ترافیکی که باعث درگیر شدن پردازنده شده را پیدا کنید. گاهی یک پورت خاص یا یک Broadcast Domain مشکلدار است.
- در نهایت با اعمال محدودیت روی Control Plane یا اصلاح تنظیمات شبکه فشار وارد شده به CPU را کاهش دهید.
اگر سوئیچ شما قدیمی است و توان پردازش ترافیک جدید را ندارد، بهتر است مشخصات سوئیچهای نسل جدید سیسکو را بررسی کنید. تیم فنی تجارت سرور پارسه میتواند در انتخاب مدل مناسب برای شبکههای سازمانی کمک کند.
سوالات متداول درباره High CPU در سوئیچ سیسکو
✔ دمای بالا و High CPU سوئیچ سیسکو چه ربطی به هم دارند؟
مستقیم ربطی ندارند، ولی وقتی سوئیچ داغ میکنه، پردازنده سرعتش رو کم میکنه تا کمتر گرما تولید کنه. نتیجهاش اینه که همون کار قبلی الان CPU بیشتری میبره. اگه High CPU داری، یه نگاه هم به دما و فنها بنداز:
show environment temperature
show environment fan
✔ عدد دوم در خروجی show processes cpu یعنی چی؟
مثلاً توی 75%/30%، اون 30% سهم Interrupt هست؛ یعنی پکتهایی که ASIC نتونسته پردازش کنه و مستقیم رفتن سراغ CPU. اگه این عدد بالا باشه، مشکل از ترافیک زیاده، نه یه Process نرمافزاری.
✔ کِی باید سوئیچ رو عوض کنیم؟
وقتی CPU حتی در ساعات آروم بالای 70% بمونه، TCAM مدام پر بشه، یا سوئیچ خودش ریبوت کنه. اگه مدل هم End of Support شده، دیگه Tuning فایده نداره.
✔ پر شدن RAM چه تأثیری روی CPU داره؟
وقتی حافظه کم میاد، IOS مدام داره مدیریتش میکنه و این CPU میبره. بیشتر اوقات یه Process داره Memory Leak داره. با این دستورا چک کن:
show processes memory sorted
show memory statistics
