چرا سوئیچ سیسکو بعضی بسته‌ها را به CPU منتقل می‌کند؟ بررسی دلایل و روش‌های عیب‌یابی

در شبکه‌های سازمانی، سوئیچ‌های سیسکو معمولاً بسته‌های اطلاعاتی را با سرعت بالا و از طریق سخت‌افزار اختصاصی پردازش می‌کنند. بااین‌حال، گاهی برخی بسته‌ها به‌جای عبور مستقیم از مسیر سخت‌افزاری، به پردازنده مرکزی یا CPU سوئیچ منتقل می‌شوند. این اتفاق که در تجهیزات شبکه با عنوان CPU Punt شناخته می‌شود، بخشی طبیعی از عملکرد سوئیچ است؛ اما افزایش غیرعادی تعداد این بسته‌ها می‌تواند باعث بالا رفتن مصرف CPU، کندی پاسخ‌گویی دستگاه و حتی اختلال در پروتکل‌های مدیریتی و کنترلی شبکه شود.

برای درک اینکه چرا سوئیچ سیسکو بعضی بسته‌ها را به CPU منتقل می‌کند، باید ابتدا با تفاوت پردازش سخت‌افزاری و نرم‌افزاری بسته‌ها آشنا شویم. در این مقاله، دلایل انتقال بسته‌ها به CPU در سوئیچ Cisco، انواع ترافیک درگیر، تأثیر این فرایند بر عملکرد شبکه و روش‌های کاربردی شناسایی و عیب‌یابی آن را بررسی می‌کنیم.

تفاوت پردازش بسته‌ها توسط ASIC و CPU در سوئیچ سیسکو

سوئیچ‌های سیسکو برای پردازش سریع ترافیک شبکه از تراشه‌های اختصاصی ASIC یا Application-Specific Integrated Circuit استفاده می‌کنند. این تراشه‌ها برای انجام عملیات مشخصی مانند بررسی آدرس MAC، اعمال VLAN، پردازش ACL و ارسال بسته‌ها طراحی شده‌اند.

در حالت عادی، وقتی یک بسته وارد سوئیچ می‌شود، سخت‌افزار دستگاه اطلاعات لازم را بررسی کرده و بسته را به پورت خروجی مناسب هدایت می‌کند. این عملیات بدون نیاز به دخالت مستقیم CPU برای هر بسته انجام می‌شود.

اما CPU وظایف متفاوتی دارد. پردازنده مرکزی معمولاً مسئول اجرای سیستم‌عامل Cisco IOS یا IOS XE، مدیریت دستگاه، اجرای پروتکل‌های کنترلی و رسیدگی به رویدادهایی است که به پردازش نرم‌افزاری نیاز دارند.

تفاوت این دو روش را می‌توان در جدول زیر مشاهده کرد:

ویژگی	پردازش توسط ASIC	پردازش توسط CPU
سرعت پردازش	بسیار بالا	محدودتر
وظیفه اصلی	ارسال و فیلتر ترافیک	مدیریت و کنترل شبکه
نوع پردازش	سخت‌افزاری	نرم‌افزاری
ظرفیت پردازش بسته	معمولاً بسیار زیاد	وابسته به مدل و منابع CPU
نمونه کاربرد	ارسال بسته بین پورت‌ها	پردازش برخی پیام‌های کنترلی
تأثیر بار زیاد	وابسته به ظرفیت سخت‌افزار	احتمال افزایش مصرف CPU

بنابراین، انتقال بعضی بسته‌ها به CPU لزوماً نشانه خرابی سوئیچ نیست، بلکه در بسیاری از شرایط برای عملکرد صحیح شبکه ضروری است.

CPU Punt در سوئیچ سیسکو چیست؟

اصطلاح CPU Punt به فرایندی گفته می‌شود که طی آن یک بسته از مسیر پردازش سخت‌افزاری به پردازنده مرکزی سوئیچ منتقل می‌شود.

برای مثال، فرض کنید یک سوئیچ Cisco Catalyst در حال انتقال هزاران بسته بین کامپیوترها و سرورها است. بیشتر این بسته‌ها مستقیماً توسط ASIC پردازش می‌شوند؛ اما اگر بسته‌ای نیازمند بررسی توسط یکی از پروتکل‌های کنترلی باشد، ممکن است سخت‌افزار آن را به CPU ارسال کند.

این فرایند معمولاً به دلایل زیر انجام می‌شود:

• بسته مستقیماً برای خود سوئیچ ارسال شده است.
• بسته متعلق به یکی از پروتکل‌های کنترلی شبکه است.
• بسته به پردازش ویژه‌ای نیاز دارد که در مسیر سخت‌افزاری مربوطه انجام نمی‌شود.
• یک رویداد یا استثنای مشخص در فرایند Forwarding رخ داده است.
• بسته برای بررسی یا اجرای یک قابلیت مدیریتی به پردازنده نیاز دارد.

البته تمام بسته‌هایی که وارد CPU می‌شوند، الزاماً Punt نیستند. برخی بسته‌ها از ابتدا برای Control Plane سوئیچ ارسال شده‌اند و در دسته ترافیک دریافتی توسط CPU قرار می‌گیرند.

مهم‌ترین دلایل انتقال بسته‌ها به CPU در سوئیچ سیسکو

1. پردازش پروتکل‌های کنترلی شبکه

یکی از رایج‌ترین دلایل انتقال بسته‌ها به CPU، اجرای پروتکل‌هایی است که برای حفظ ساختار و پایداری شبکه ضروری هستند. برای مثال، پروتکل Spanning Tree یا STP برای جلوگیری از ایجاد Loop در شبکه از پیام‌های BPDU استفاده می‌کند.

سوئیچ باید این پیام‌ها را دریافت و پردازش کند تا بتواند وضعیت پورت‌ها و توپولوژی شبکه را مدیریت کند. پروتکل‌های دیگری مانند OSPF، EIGRP و BGP نیز در سوئیچ‌های لایه 3 پشتیبانی‌شده، به پردازش کنترلی نیاز دارند.

نکته مهم این است که پردازش پیام‌های کنترلی توسط CPU با ارسال معمولی بسته‌های داده تفاوت دارد. وجود این پیام‌ها در شرایط عادی کاملاً طبیعی است.

2. بسته‌هایی که مقصد آن‌ها خود سوئیچ است

گاهی بسته‌های شبکه برای عبور از سوئیچ ارسال نشده‌اند، بلکه مقصد اصلی آن‌ها خود دستگاه است. برای مثال، زمانی که مدیر شبکه از طریق SSH به سوئیچ متصل می‌شود، ترافیک مربوط به این ارتباط باید توسط بخش مدیریتی دستگاه پردازش شود.

نمونه‌های دیگر عبارت‌اند از:

• درخواست‌های SNMP برای مانیتورینگ سوئیچ
• بسته‌های ICMP با مقصد آدرس IP سوئیچ
• ارتباطات SSH و Telnet
• درخواست‌های مدیریتی مربوط به سرویس‌های فعال دستگاه

در این شرایط، ورود بسته‌ها به CPU بخشی از عملکرد طبیعی سوئیچ محسوب می‌شود. بااین‌حال، ارسال تعداد زیادی درخواست مدیریتی در مدت کوتاه می‌تواند منابع پردازشی دستگاه را تحت فشار قرار دهد.

3. بسته‌های ARP و فرایند شناسایی آدرس‌ها

پروتکل ARP برای شناسایی آدرس MAC متناظر با یک آدرس IPv4 در شبکه استفاده می‌شود. در سوئیچ‌های لایه 3، بعضی پیام‌های ARP که به اینترفیس‌های لایه 3 دستگاه مربوط هستند، باید توسط Control Plane پردازش شوند.

برای مثال، اگر یک کامپیوتر بخواهد آدرس MAC مربوط به Default Gateway خود را پیدا کند و این Gateway روی سوئیچ تعریف شده باشد، سوئیچ باید به درخواست ARP پاسخ دهد. اما یک نکته مهم وجود دارد: تمام بسته‌های ARP عبوری از سوئیچ الزاماً به CPU منتقل نمی‌شوند. رفتار دقیق دستگاه به معماری سخت‌افزاری، تنظیمات و نوع پیام بستگی دارد.

افزایش غیرعادی درخواست‌های ARP، به‌خصوص در شبکه‌هایی با تعداد زیاد کلاینت یا هنگام وقوع ARP Flood، می‌تواند باعث افزایش ترافیک ورودی به CPU شود.

4. بسته‌های دارای TTL منقضی‌شده

در شبکه‌های IP، فیلد TTL یا Time to Live مشخص می‌کند یک بسته تا چند مرحله مسیریابی می‌تواند حرکت کند. هر روتر یا سوئیچ لایه 3 هنگام مسیریابی، مقدار TTL بسته را کاهش می‌دهد. اگر TTL به پایان برسد، بسته نباید به مسیر بعدی ارسال شود.

در برخی معماری‌های سیسکو، این وضعیت می‌تواند باعث انتقال بسته به CPU برای پردازش استثنا و تولید پیام ICMP Time Exceeded شود. البته در بعضی پلتفرم‌ها، بخشی از این عملیات توسط سخت‌افزار انجام می‌شود.

اگر شبکه دچار Routing Loop شود، تعداد زیادی بسته ممکن است با TTL منقضی‌شده مواجه شوند و ترافیک استثنایی ایجاد کنند.

5. بسته‌هایی که مسیر سخت‌افزاری مناسبی ندارند

گاهی سوئیچ نمی‌تواند یک بسته را از مسیر عادی سخت‌افزاری پردازش کند. این وضعیت ممکن است به دلیل محدودیت قابلیت‌های سخت‌افزاری، برخی شرایط استثنایی Forwarding یا ویژگی‌های خاص بسته رخ دهد.

برای مثال، در بعضی پلتفرم‌ها، بسته‌هایی که به پردازش ویژه نیاز دارند ممکن است به CPU منتقل شوند. بااین‌حال، نباید تصور کرد هر بسته‌ای که مسیر آن در جدول سخت‌افزاری پیدا نمی‌شود، مستقیماً به CPU ارسال خواهد شد. بسته به مدل سوئیچ و نوع خطا، ممکن است بسته Drop، Flood یا به مسیر پردازشی دیگری هدایت شود.

آیا انتقال بسته‌ها به CPU باعث کند شدن سوئیچ می‌شود؟

انتقال تعداد محدودی بسته به CPU معمولاً مشکلی ایجاد نمی‌کند؛ زیرا سوئیچ برای مدیریت این نوع ترافیک طراحی شده است. مشکل زمانی آغاز می‌شود که حجم بسته‌های ارسالی به CPU از ظرفیت پردازشی یا محدودیت‌های تعیین‌شده برای Control Plane بیشتر شود.

در چنین شرایطی، ممکن است علائم زیر مشاهده شوند:

• افزایش غیرعادی CPU Utilization
• تأخیر در اتصال SSH به سوئیچ
• کند شدن اجرای دستورات مدیریتی
• تأخیر در پردازش برخی پیام‌های پروتکل‌های کنترلی
• از دست رفتن بعضی بسته‌های مدیریتی
• ناپایداری همسایگی پروتکل‌های مسیریابی در شرایط شدید

نکته مهم این است که بالا رفتن مصرف CPU الزاماً به معنای کاهش سرعت تمام پورت‌های سوئیچ نیست. در بسیاری از سوئیچ‌های Catalyst، ترافیکی که کاملاً توسط ASIC پردازش می‌شود، حتی هنگام افزایش مصرف CPU نیز می‌تواند با سرعت عادی عبور کند.

بااین‌حال، اگر پردازنده نتواند وظایف کنترلی را به‌موقع انجام دهد، عملکرد کلی شبکه ممکن است تحت تأثیر قرار بگیرد.

چگونه بسته‌های منتقل‌شده به CPU را در سوئیچ سیسکو شناسایی کنیم؟

برای عیب‌یابی این مشکل، ابتدا باید میزان مصرف CPU و سپس نوع ترافیک ورودی به پردازنده بررسی شود. دستورات زیر عمدتاً برای خانواده‌های مشخصی از Cisco IOS و IOS XE کاربرد دارند و پشتیبانی از آن‌ها به مدل و نسخه نرم‌افزار بستگی دارد.

مرحله اول: بررسی میزان مصرف CPU

در بسیاری از سوئیچ‌های Cisco IOS می‌توان از دستور زیر استفاده کرد:

show processes cpu sorted

این دستور میزان مصرف CPU و پردازش‌هایی را که بیشترین منابع را استفاده می‌کنند نمایش می‌دهد.

اگر مصرف CPU به‌صورت مداوم بالا باشد، باید مشخص شود کدام فرایند یا نوع ترافیک مسئول این وضعیت است.

در برخی مدل‌ها، برای بررسی تاریخچه مصرف CPU نیز می‌توان از دستور زیر استفاده کرد:

show processes cpu history

مرحله دوم: بررسی ترافیک Punt در سوئیچ‌های Catalyst

در برخی سوئیچ‌های Catalyst مبتنی بر IOS XE، به‌خصوص مدل‌های Catalyst 9000، دستور زیر برای مشاهده آمار بسته‌های Punt کاربرد دارد:

show platform software fed switch active punt statistics

این دستور می‌تواند آمار بسته‌هایی را که به CPU هدایت شده‌اند، بر اساس دسته‌بندی‌های پشتیبانی‌شده نمایش دهد.

در دستگاه‌های Stack یا پلتفرم‌های متفاوت، ساختار دستور ممکن است تغییر کند.

برای بررسی جزئیات بیشتر، می‌توان از دستورات پلتفرم‌محور مربوط به Punt Cause و CPU Queue نیز استفاده کرد.

مرحله سوم: بررسی وضعیت Control Plane Policing

در پلتفرم‌هایی که از CoPP پشتیبانی می‌کنند، دستور زیر می‌تواند برای مشاهده Policy اعمال‌شده روی Control Plane مفید باشد:

show policy-map control-plane

در خروجی این دستور، بسته به پلتفرم، می‌توان اطلاعاتی مانند تعداد بسته‌های تطبیق‌یافته با Policy، نرخ ترافیک و تعداد بسته‌های Drop شده را مشاهده کرد.

این اطلاعات کمک می‌کند مشخص شود آیا ترافیک ورودی به CPU از محدودیت‌های تعیین‌شده عبور کرده است یا خیر.

نقش Control Plane Policing در محافظت از CPU سوئیچ سیسکو

یکی از مهم‌ترین قابلیت‌های امنیتی و مدیریتی در تجهیزات Cisco، فناوری Control Plane Policing یا CoPP است. این قابلیت برای محدود کردن نرخ ترافیکی طراحی شده که به Control Plane دستگاه وارد می‌شود.

برای مثال، اگر یک دستگاه در شبکه هزاران بسته ICMP در ثانیه به آدرس مدیریتی سوئیچ ارسال کند، پردازش تمام این درخواست‌ها می‌تواند CPU را درگیر کند.

CoPP می‌تواند با استفاده از Policyهای مشخص، نرخ برخی گروه‌های ترافیکی را کنترل کند و بسته‌های اضافی را Drop کند. مزایای این قابلیت عبارت‌اند از:

• کاهش تأثیر حملات DoS علیه Control Plane
• جلوگیری از اشباع CPU توسط بعضی انواع ترافیک
• محافظت از منابع موردنیاز پروتکل‌های کنترلی
• افزایش پایداری مدیریت و مسیریابی دستگاه

البته تنظیم نادرست CoPP نیز خطرناک است. اگر محدودیت‌ها بیش‌ازحد سخت‌گیرانه باشند، ممکن است بسته‌های ضروری پروتکل‌های کنترلی حذف شوند. به همین دلیل، تغییر Policyهای پیش‌فرض باید با شناخت دقیق معماری دستگاه و الگوی ترافیک شبکه انجام شود.

تفاوت CPU Punt با Process Switching در تجهیزات سیسکو

دو اصطلاح CPU Punt و Process Switching گاهی به‌اشتباه به‌جای یکدیگر استفاده می‌شوند، درحالی‌که مفهوم یکسانی ندارند. CPU Punt به انتقال بسته از مسیر سخت‌افزاری به CPU اشاره دارد؛ اما Process Switching روشی برای پردازش و تصمیم‌گیری درباره ارسال بسته در نرم‌افزار است.

در معماری‌های قدیمی‌تر سیسکو، Process Switching نقش پررنگ‌تری در Forwarding داشت. در مقابل، سوئیچ‌های مدرن عمدتاً از ASIC و مسیرهای سخت‌افزاری برای ارسال ترافیک استفاده می‌کنند.

بنابراین، هر بسته Punt شده الزاماً به روش Process Switching ارسال نمی‌شود. بعضی بسته‌ها فقط برای پردازش کنترلی به CPU تحویل داده می‌شوند و اصلاً قرار نیست مانند ترافیک عادی Forward شوند.

چگونه از افزایش غیرعادی ترافیک CPU جلوگیری کنیم؟

برای کاهش مشکلات ناشی از انتقال بیش‌ازحد بسته‌ها به CPU در سوئیچ سیسکو، بهتر است چند اقدام عملی انجام شود. ابتدا مصرف CPU را در ساعات مختلف بررسی کنید تا الگوی عادی فعالیت دستگاه مشخص شود. سپس آمار Punt و Drop را در زمان وقوع مشکل با شرایط عادی مقایسه کنید.

در مرحله بعد، وضعیت پروتکل‌های کنترلی، تعداد درخواست‌های ARP، ترافیک مدیریتی و احتمال وجود Loop در شبکه را بررسی کنید. فعال‌سازی قابلیت‌هایی مانند Storm Control، استفاده صحیح از CoPP، محدودسازی دسترسی مدیریتی و به‌روزرسانی نرم‌افزار دستگاه نیز می‌توانند در شرایط مناسب مفید باشند.

نکته مهم این است که قبل از اعمال هرگونه محدودیت، باید علت اصلی افزایش ترافیک شناسایی شود. صرفاً کاهش نرخ بسته‌های ورودی به CPU بدون بررسی دلیل آن‌ها ممکن است مشکل اصلی را پنهان کند.

جمع‌بندی

انتقال بعضی بسته‌ها به CPU در سوئیچ سیسکو یک رفتار طبیعی و ضروری برای اجرای وظایف مدیریتی، پردازش پروتکل‌های کنترلی و رسیدگی به برخی شرایط استثنایی شبکه است.

در حالت عادی، بیشتر ترافیک توسط ASIC پردازش می‌شود و CPU فقط بسته‌هایی را دریافت می‌کند که به رسیدگی خاص نیاز دارند. بااین‌حال، افزایش غیرعادی ترافیک Punt می‌تواند باعث مصرف بالای CPU و اختلال در عملکرد Control Plane شود.

برای عیب‌یابی صحیح، باید علاوه بر بررسی CPU Utilization، آمار Punt، وضعیت صف‌های پردازشی و سیاست‌های CoPP نیز بررسی شوند. شناخت این فرایند به مدیران شبکه کمک می‌کند مشکلات عملکردی سوئیچ‌های Cisco Catalyst را دقیق‌تر شناسایی کنند و بدون ایجاد تغییرات غیرضروری، پایداری شبکه را افزایش دهند.