روتر یا سوئیچ لایه ۳ شما فقط ترافیک دیگران را عبور نمیدهد؛ خودش هم «میزبان» است: BGP و OSPF با آن حرف میزنند، شما با SSH به آن وصل میشوید، SNMP و NTP از آن جواب میگیرند. همه این بستهها به CPU دستگاه میرسند، و CPU برخلاف ASIC سختافزاری ظرفیت محدودی دارد. کافی است یک کاربر بدخواه یا یک ویروس با یک ابزار ساده سیل بستههای UDP به سمت IP روتر بفرستد تا CPU صددرصد شود، همسایههای مسیریابی بیفتند و کل شبکه از اینترنت جدا شود.
راهحل سیسکو برای این مشکل Control Plane Policing یا CoPP است: یک سیاست QoS که جلوی ورودی CPU مینشیند، ترافیک را دستهبندی میکند و برای هر دسته سقف میگذارد؛ تا پروتکلهای حیاتی همیشه جا داشته باشند و ترافیک مزاحم پیش از رسیدن به CPU دور ریخته شود. در این مطلب مفهوم Planeها، طراحی درست کلاسها، کانفیگ کامل روی روترهای IOS و IOS XE ، رفتار متفاوت CoPP روی سوئیچهای Catalyst 9000 ، روش آزمایش و اشتباههای رایج را مرور میکنیم.

CoPP در یک نگاه
| هدف | حفاظت از CPU دستگاه در برابر DoS و تضمین جا برای پروتکلهای حیاتی |
| ابزار | Modular QoS CLI (MQC) : class-map ، policy-map و police |
| محل اعمال | روی اینترفیس منطقی control-plane در جهت ورودی |
| روترهای IOS / IOS XE | سیاست را خودتان طراحی و اعمال میکنید |
| Catalyst 9000 | سیاست ثابت system-cpp-policy از پیش نصب شده؛ فقط نرخها قابل تنظیماند |
| Nexus (NX-OS) | پروفایل CoPP (مثل strict) در اولین بوت اعمال میشود |
فهرست مطالب
سه Plane در هر دستگاه شبکه
سیسکو در راهنمای Hardening دستگاهها، کارکرد هر روتر و سوئیچ را به سه بخش (Plane) تقسیم میکند. CoPP مخصوص دومی است:
| Plane | چه ترافیکی | کجا پردازش میشود | ابزار حفاظت |
|---|---|---|---|
| Data Plane | ترافیک کاربران که از دستگاه عبور میکند | ASIC و سختافزار (یا CEF) | ACL ، uRPF ، QoS |
| Control Plane | پروتکلهای مسیریابی و کنترلی: BGP ، OSPF ، EIGRP ، HSRP ، ARP ، STP | CPU | CoPP ، احراز هویت پروتکلها |
| Management Plane | SSH ، SNMP ، NTP ، Syslog ، TACACS+ | CPU | ACL روی VTY ، AAA ، CoPP |
ترافیک Data Plane در حالت عادی اصلاً به CPU نمیرسد. اما بستههایی که مقصدشان خود دستگاه است، بستههای با TTL منقضی، ARP ، و بستههایی که سختافزار نمیتواند پردازش کند (Punt) همه به CPU میروند. همین مسیر همان نقطه آسیبپذیری است.
یک آزمایش ساده: CPU یک روتر چطور از پا درمیآید
ما در آزمایشگاه روی یک روتر Cisco 2811 با یک ابزار تست شبکه در دسترس، بستههای UDP کوچک به سمت IP خود روتر فرستادیم. با حدود ۲۸ مگابیت ترافیک، CPU روتر کاملاً اشباع و دستگاه از دسترس خارج شد. هر چه بستهها کوچکتر و تعدادشان بیشتر باشد، بار روی CPU سنگینتر است، چون CPU به ازای هر بسته کار میکند نه به ازای هر بایت.

روترهای جدید قویترند، اما قاعده عوض نشده است: ظرفیت CPU برای بستههای «به مقصد خود دستگاه» همیشه چند مرتبه کمتر از ظرفیت فورواردینگ سختافزاری است.
طراحی درست کلاسها
اشتباه رایج این است که یک کلاس برای «همه UDP» بسازیم و نرخش را خیلی پایین بگذاریم. این کار NTP ، SNMP ، DNS ، RADIUS و حتی بعضی پروتکلهای مسیریابی را هم خفه میکند. روش درست این است که ترافیک را بر اساس اهمیت دستهبندی کنیم، از مهمترین تا بیارزش:
| کلاس | نمونه ترافیک | سیاست پیشنهادی |
|---|---|---|
| Undesirable | پورتهایی که هرگز نباید به روتر برسند (Telnet از اینترنت ، SQL Slammer 1434 ، …) | drop کامل |
| Critical / Routing | BGP ، OSPF ، EIGRP ، HSRP ، BFD | نرخ بالا؛ ترجیحاً فقط مانیتور (exceed هم transmit) |
| Management | SSH از شبکه مدیریت، SNMP ، NTP ، TACACS+ ، RADIUS | نرخ متوسط |
| Normal / ICMP | ping ، traceroute ، unreachable | نرخ کم |
| class-default | هر چیز دیگری که به CPU میرسد | نرخ کم و drop مازاد |
exceed-action transmit بگذارید و فقط شمارندهها را ببینید. بعد از یکی دو هفته که الگوی واقعی ترافیک را شناختید، نرخها را تنظیم و drop را فعال کنید. CoPP با نرخ اشتباه، خودش یک DoS است.کانفیگ کامل روی روترهای IOS و IOS XE
این نمونه برای یک روتر مرزی با BGP به ISP و مدیریت از شبکه 10.10.99.0/24 است. آدرسها و نرخها را با شبکه خودتان تطبیق دهید.
! ---------- 1) ACLs ---------- ip access-list extended COPP-UNDESIRABLE permit udp any any eq 1434 permit tcp any any eq telnet ip access-list extended COPP-ROUTING permit tcp host 203.0.113.1 any eq bgp permit tcp host 203.0.113.1 eq bgp any permit ospf any any permit udp any any eq 3784 ip access-list extended COPP-MGMT permit tcp 10.10.99.0 0.0.0.255 any eq 22 permit udp host 10.10.99.5 any eq snmp permit udp any eq ntp any eq ntp permit tcp host 10.10.99.50 eq tacacs any ip access-list extended COPP-ICMP permit icmp any any echo permit icmp any any echo-reply permit icmp any any ttl-exceeded permit icmp any any unreachable permit icmp any any packet-too-big ! ! ---------- 2) Classes ---------- class-map match-all COPP-UNDESIRABLE match access-group name COPP-UNDESIRABLE class-map match-all COPP-ROUTING match access-group name COPP-ROUTING class-map match-all COPP-MGMT match access-group name COPP-MGMT class-map match-all COPP-ICMP match access-group name COPP-ICMP ! ! ---------- 3) Policy ---------- policy-map COPP-POLICY class COPP-UNDESIRABLE drop class COPP-ROUTING police 2000000 conform-action transmit exceed-action transmit class COPP-MGMT police 1000000 conform-action transmit exceed-action drop class COPP-ICMP police 128000 conform-action transmit exceed-action drop class class-default police 256000 conform-action transmit exceed-action drop ! ! ---------- 4) Apply ---------- control-plane service-policy input COPP-POLICY
نکتههای این کانفیگ:
- ترتیب کلاسها مهم است؛ بسته در اولین کلاسی که match شود میماند. کلاس Undesirable اول است تا بستههای مزاحم زودتر دور ریخته شوند.
- کلاس Routing عمداً
exceed-action transmitدارد؛ هرگز نمیخواهیم همسایه BGP بهخاطر CoPP بیفتد، فقط میخواهیم مصرفش را ببینیم. - پورت 3784 برای BFD است؛ اگر BFD ندارید حذفش کنید.
- قبل از اعمال روی دستگاه عملیاتی، کانفیگ را روی یک دستگاه آزمایشی تست کنید و یک نشست کنسول باز داشته باشید.
Control Plane Protection (CPPr)
روی روترهای IOS میتوانید control plane را به زیرمسیرهای دقیقتر هم تقسیم کنید: control-plane host (ترافیکی که مقصدش خود روتر است)، control-plane transit و control-plane cef-exception. روی زیرمسیر host ، علاوه بر policing ، سیاستهای port-filter (بستن پورتهای TCP/UDP بسته روی خود روتر) و queue-threshold هم ممکن است:
class-map type port-filter match-all PF-CLOSED match closed-ports policy-map type port-filter PF-POLICY class PF-CLOSED drop control-plane host service-policy type port-filter input PF-POLICY
این سیاست هر بستهای را که به پورت بستهای روی خود روتر برسد، پیش از پردازش در CPU دور میریزد. نتیجه را با show control-plane host open-ports و شمارندهها را با show control-plane host counters ببینید.
CoPP روی سوئیچهای Catalyst 9000
روی خانواده Catalyst 9000 ، CoPP فرق مهمی دارد. طبق راهنمای رسمی CoPP برای Catalyst 9300:
- در اولین روشن شدن، سوئیچ سیاستی به نام
system-cpp-policyمیسازد و روی control-plane نصب میکند، با کلاسهایی که هر کدام به یک صف CPU نگاشت شدهاند. - فقط همین سیاست روی control-plane مجاز است و قابل حذف یا جایگزینی نیست؛ فقط در جهت ورودی.
- تنها action مجاز police است و نرخ فقط بهصورت بسته در ثانیه (pps) تعریف میشود و به نزدیکترین مضرب ۲۰۰ گرد میشود.
- با
cpp system-defaultهمه نرخها به مقدار پیشفرض سیسکو برمیگردند.
C9300# show policy-map control-plane C9300# show platform hardware fed switch active qos queue stats internal cpu policer C9300(config)# policy-map system-cpp-policy C9300(config-pmap)# class system-cpp-police-routing-control C9300(config-pmap-c)# police rate 6000 pps
در عمل روی سوئیچهای کاتالیست بهندرت نیاز به تغییر نرخها دارید؛ کار شما بیشتر خواندن شمارندههاست تا بفهمید کدام صف CPU زیر فشار است. روی سوئیچهای Nexus هم NX-OS در اولین بوت یک پروفایل CoPP اعمال میکند؛ توضیح آن را در مطلب آشنایی با سیسکو NX-OS ببینید.
بررسی و عیبیابی
| دستور | کاربرد |
|---|---|
show policy-map control-plane |
شمارنده conform و exceed هر کلاس؛ مهمترین دستور |
show processes cpu sorted |
مصرف CPU و پروسسهای پرمصرف |
show processes cpu history |
نمودار مصرف CPU در ۶۰ ثانیه، ۶۰ دقیقه و ۷۲ ساعت |
show control-plane host counters |
شمارندههای CPPr روی مسیر host |
show ip bgp summary و show ip ospf neighbor |
اطمینان از اینکه همسایهها بعد از اعمال CoPP پایدارند |
اشتباههای رایج
- یک کلاس برای همه UDP: NTP ، SNMP ، DNS و RADIUS هم UDP هستند و با آن خفه میشوند.
- drop در کلاس Routing: در اوج ترافیک یا بعد از قطع و وصل لینک، BGP با تعداد زیادی بسته بهروزرسانی میکند و همسایه میافتد.
- فراموش کردن ARP: روی روترها ARP در class-default میافتد؛ نرخ class-default را آنقدر پایین نگذارید که ARP در LANهای بزرگ drop شود.
- تست نکردن SSH از شبکه مدیریت: پیش از بستن نشست، از یک پنجره جدید وصل شوید.
پرسشهای متداول
CoPP جای فایروال یا ACL ورودی را میگیرد؟
نه. ACL زیرساخت (iACL) روی اینترفیس ورودی جلوی بستههای ناخواسته را زودتر میگیرد؛ CoPP لایه دوم دفاع درست جلوی CPU است. هر دو را با هم استفاده کنید.
CoPP روی ترافیک عبوری کاربران اثر دارد؟
نه. فقط روی بستههایی اثر دارد که به CPU میرسند.
روی سوئیچ کاتالیست 9000 میتوانم سیاست خودم را بنویسم؟
نه؛ فقط نرخ کلاسهای سیاست ثابت system-cpp-policy قابل تغییر است.
منابع رسمی
- Cisco Guide to Harden Cisco IOS Devices
- Security Configuration Guide, IOS XE 17.9 (Catalyst 9300) – Configuring Control Plane Policing
مطالب مرتبط: ایمنسازی روتر سیسکو ، سیسکو uRPF و BOGON و راه رهایی از آن.
مشاوره با AKA NET
برای طراحی CoPP ، Hardening روترهای مرزی و بررسی دلیل بالا رفتن CPU دستگاههای سیسکو با آکانت (AKA NET) تماس بگیرید.
تلفن: 09121308444 | ایمیل: aka@aka.ir | aka.ir
بازتاب: Control Plane و حفاظت از منابع روتر | مرکز آموزش یوسرور - هاست اشتراکی - سرور مجای با کیفیت
دمت گرم