کنترل‌پلین و دیتاپلین سیسکو

سه پلین، از CPU سوئیچ دسترسی تا QFP و سوپروایزر

اگر روی 2960 یا 3750 یک بار CPU به سقف رسیده و هم‌زمان درخت STP به‌هم ریخته، یا روی Catalyst 9300 پینگ به خود سوئیچ می‌پرد ولی ترافیک کاربران هنوز رد می‌شود، همان جایی است که باید سه پلین را از هم جدا ببینید. جعبه سیسکو یک مغز و یک جاده است. مغز تصمیم می‌گیرد. جاده فریم را رد می‌کند. اگر این دو را یکی حساب کنید، هم عیب‌یابی‌تان غلط می‌شود و هم کانفیگ محافظتی‌تان یا بی‌اثر است یا خودِ شبکه را می‌کُشد.

این مطلب همان کنترل‌پلین و دیتاپلین سیسکو است، به‌علاوه پلین سومی که اغلب داخل دومی قایم می‌شود: منیجمنت‌پلین. از تعریف رسمی NX-OS و Catalyst 9000 شروع می‌کنیم، یک بسته را سه بار از یک سوئیچ رد می‌کنیم، CEF و FIB و adjacency را باز می‌کنیم، بعد تفاوت IOS کلاسیک، IOS XE روی Catalyst 9000 و ASR 1000، NX-OS، IOS XR، ASA و وایرلس را می‌گوییم. CoPP، سقف حدود ۱۹ هزار بسته در ثانیه روی CPU خانواده Catalyst 9000، و دستورهایی که واقعاً مسیر punt را نشان می‌دهند وسط همین مسیرند؛ نه ضمیمه آخر.

روی کاغذ هر شاسی «سه صفحه» دارد. در عمل اسم‌ها بین پلتفرم‌ها یکی نیست. مستند عیب‌یابی Catalyst 9000 کلمه Control Plane را برای هر چیزی که به CPU می‌رسد به کار می‌برد، از BPDU تا SSH. راهنمای CoPP نکسوس همان ترافیک را به control و management شکافته است. اگر این اختلاف را ندانید، یک policy را از روی یک PDF به پلتفرم دیگر کپی می‌کنید و فردا OSPF فلپ می‌شود.

سه پلین دقیقاً چه هستند

راهنمای امنیت NX-OS، از جمله نسخه 10.6، سه جزء را این‌طور از هم جدا می‌کند. این تعریف را معیار می‌گیریم، چون از بقیه صریح‌تر است:

• Data plane همه ترافیک داده را جابه‌جا می‌کند. کار پایه دستگاه این است که بسته را از یک اینترفیس به اینترفیس دیگر بفرستد. بسته‌ای که مال خود سوئیچ نیست transit نام دارد و دیتاپلین آن را برمی‌دارد.
• Control plane ترافیک پروتکل مسیریابی را هندل می‌کند. BGP و OSPF بسته کنترلی بین دستگاه‌ها می‌فرستند. این بسته‌ها به آدرس خود روتر می‌رسند.
• Management plane اجزای مدیریت دستگاه را اجرا می‌کند؛ CLI و SNMP در خود مستند سیسکو مثال زده شده‌اند.

دیتاپلین همان forwarding plane است. کنترل‌پلین تصمیم می‌سازد و آن تصمیم را به جدول فوروارد می‌ریزد. منیجمنت‌پلین دستگاه را اداره می‌کند: شما SSH می‌زنید، سرور مانیتورینگ SNMP می‌خواند، یا اسکریپت NETCONF کانفیگ را هل می‌دهد. هیچ‌کدام از این سه، «جایگزین» دیگری نیست. اگر دیتاپلین سالم باشد و کنترل‌پلین مرده باشد، ترافیک موجود تا زمان انقضای adjacency و تایمر پروتکل رد می‌شود و بعد سیاه‌چاله می‌شود. اگر کنترل‌پلین زنده باشد و دیتاپلین اشباع شده باشد، همسایه OSPF up است ولی کاربر صف را حس می‌کند.

مرز خاکستری است و سیسکو هم این را پنهان نمی‌کند. یک فریم تا وقتی مقصدش میزبان آن‌طرف سوئیچ است دیتاپلین است. همان فریم اگر آدرس مقصدش SVI خود سوئیچ باشد، برای دستگاه است و باید به CPU برود. بسته OSPF hello بین دو روتر، از دید کابل «دیتا» است (یک IP روی سیم)، از دید روتر «کنترل» است. SSH هم روی سیم یک TCP معمولی است و از دید NX-OS مال منیجمنت‌پلین است، ولی روی Catalyst 9000 داخل همان لوله‌ای می‌افتد که سیسکو به آن punt به control plane می‌گوید.

یک بسته، سه سرنوشت

یک Catalyst را تصور کنید با SVI به آدرس 10.10.10.1، یک PC روی 10.10.10.10، و uplink به سمت روتر شعبه. سه آزمایش کافی است تا هر سه پلین را با دست خودتان ببینید.

1. PC به سرور آن‌طرف uplink. سوئیچ MAC یا مسیر را در سخت‌افزار پیدا می‌کند و فریم را از پورت خروجی می‌فرستد. show processes cpu تکان نمی‌خورد. این دیتاپلین است.
2. PC به 10.10.10.1 پینگ می‌کند. مقصد خود دستگاه است. بسته punt می‌شود. اگر هزار نفر هم‌زمان به SVI پینگ کنند، CPU بالا می‌رود در حالی که عبور کاربران هنوز ممکن است سالم باشد. این for-us است؛ نه transit.
3. شما به 10.10.10.1 روی SSH می‌روید. باز هم به CPU می‌رسد، ولی کارش اداره دستگاه است نه ساخت جدول مسیریابی. اگر این جلسه را روی همان VLAN کاربران آورده باشید، طوفانی که آزمایش دوم راه انداخت SSH را هم از شما می‌گیرد.

دیتاپلین: از process switching تا CEF

هر بسته transit یک سؤال دارد: از کدام اینترفیس بیرون برود و هدر لایه دو خروجی‌اش چه باشد. سیسکو این سؤال را در طول سال‌ها سه جور جواب داده. اسم هر سه را هنوز در خروجی دستورها می‌بینید، حتی اگر روی IOS XE امروز فقط سومی زنده باشد.

Process switching

هر بسته را خود پروسه IP روی CPU برمی‌دارد، در RIB دنبال longest-match می‌گردد، و می‌فرستد. این کندترین حالت است و برای نرخ بالا ساخته نشده. اگر کسی روی روتر قدیمی no ip cef گذاشته باشد، یا ویژگی‌ای روشن باشد که بسته را از مسیر سخت‌افزار بیرون بکشد (مثل log روی هر hit یک ACL شلوغ)، عملاً به همین دنیا برمی‌گردید. علامت میدانی‌اش ساده است: با چند جریان همزمان، CPU فرآیند IP Input بالا می‌رود و تأخیر کاربران با بار خود روتر بالا و پایین می‌شود.

Fast switching

نسل وسط. بسته اول process می‌شد و نتیجه در route cache می‌نشست؛ بسته‌های بعدی همان مقصد در سطح interrupt فوروارد می‌شدند. مشکلش demand cache بود: میلیون مقصد مختلف یعنی cache که هیچ‌وقت گرم نمی‌ماند. CEF آمد که این را حل کند. روی پلتفرم‌های IOS XE امروزی این حالت مدل عملیاتی شما نیست؛ اگر در متن قدیمی آموزشی می‌بینیدش، تاریخ است نه دستور امروز.

CEF

Cisco Express Forwarding جدول فوروارد را از قبل می‌سازد، نه بعد از دیدن بسته اول. دو ساختار دارد. FIB نسخه بهینه RIB برای جست‌وجوی پیشوند است. Adjacency table می‌گوید برای رسیدن به hop بعدی، هدر لایه دو چیست: MAC مقصد، اینترفیس خروجی، و اگر لازم باشد VLAN tag. پروتکل مسیریابی RIB را عوض می‌کند؛ CEF از RIB مشتق می‌شود و روی سخت‌افزار، همان FIB به ASIC یا QFP برنامه می‌شود. به همین دلیل همسایه OSPF که فلپ می‌کند، برای چند لحظه هم کنترل‌پلین را مشغول می‌کند و هم برنامه‌ریزی مجدد دیتاپلین را.

مستند «Understand Express Forwarding» سیسکو همین را خلاصه می‌کند: CEF جایگزین مدل route-cache است، FIB و adjacency را جدا نگه می‌دارد، و روی پلتفرم مدرن این جدول‌ها با سخت‌افزار فوروارد همگام می‌شوند. CEF به‌صورت پیش‌فرض روشن است. خاموش کردنش راه‌حل عیب‌یابی نیست؛ راه ساختن قطعی است.

دستورهایی که این جدول را روی IOS و IOS XE نشان می‌دهند:

show ip cef 10.10.20.10
show adjacency
show ip interface GigabitEthernet0/0/1 | include CEF

اگر کنار یک پیشوند glean ماندگار ببینید، یا میزبان جواب ARP نمی‌دهد یا چیزی در مسیر ARP را می‌خورد. اگر همه چیز punt شده، CEF برای آن ترافیک کنار رفته و CPU دارد کار ASIC را می‌کند. این را با «شبکه کند است» یکی نکنید؛ اول بگویید کندی مال عبور است یا مال خود جعبه.

کنترل‌پلین: پروتکلی که اگر دیر شود شبکه را می‌خواباند

کنترل‌پلین بسته transit را فوروارد نمی‌کند. توپولوژی را نگه می‌دارد. OSPF hello اگر سه بار پشت سر هم نرسد، adjacency می‌خوابد و FIB خالی از مسیرهایی می‌شود که از آن همسایه آمده بودند. BPDU اگر روی 2960 دیر به CPU برسد، پورت می‌تواند از blocking دربیاید و حلقه بسازد. LACP اگر timeout شود، EtherChannel نصف می‌شود. این‌ها همه «چند بسته در ثانیه»‌اند، ولی مهلت‌شان کوتاه است.

لایه دو را دست‌کم نگیرید. روی سوئیچ دسترسی، سنگین‌ترین کنترل‌پلین اغلب اصلاً BGP نیست. STP، CDP، LLDP، LACP، UDLD، VTP و DTP روی Catalyst 9000 همگی در صف WK_CPU_Q_L2_CONTROL می‌نشینند. یک حلقه لایه دو، یا یک IP phone که CDP را سیل می‌کند، همان صفی را پر می‌کند که BPDU لازم دارد. روتر شعبه داستان دیگری دارد: آنجا OSPF و BGP و HSRP صف routing را پر می‌کنند.

مستند عیب‌یابی کنترل‌پلین Catalyst 9000 چند علت punt را با شماره نشان می‌دهد. این‌ها را حفظ کنید، چون خروجی show platform software fed switch active punt cause summary همین اسم‌ها را می‌دهد:

دو کلمه را سیسکو در همان سند تعریف کرده و ارزش دارد عین معنایشان بماند. Punt یعنی بسته کنترلی که دیتاپلین گرفته و به CPU فرستاده. Inject یعنی بسته‌ای که CPU ساخته (hello، پاسخ SNMP، پاسخ ping) و به دیتاپلین داده تا از اینترفیس خارج شود. مسیر برگشت را فراموش نکنید. اگر inject عقب بیفتد، شما hello می‌فرستید دیر، حتی اگر همسایه سالم باشد.

منیجمنت‌پلین: همان CPU، ولی قرار نیست از VLAN کاربران بیاید

راهنمای IOS XR منیجمنت‌پلین را مسیر منطقی ترافیکی می‌داند که به اداره خود پلتفرم مربوط است، و پروتکل‌هایش را اسم می‌برد: SNMP، Telnet، HTTP، HTTPS و SSH. NX-OS هم CLI و SNMP را در همین پلین گذاشته. یعنی از نظر معماری، SSH «یک جور OSPF» نیست. از نظر سخت‌افزار ارزان‌تر، هر دو اغلب از یک CPU سردرمی‌آورند. این اختلاف را در طراحی آدرس مدیریت حل می‌کنید، نه در اسم‌گذاری اسلاید.

دو جور اینترفیس مدیریت داریم و XR برای هر دو اسم رسمی دارد:

• Out-of-band. اینترفیسی که برای ترافیک مدیریت کنار گذاشته شده. روی نکسوس معمولاً mgmt0 است، روی ASR 1000 پورت مدیریت RP، روی خیلی از Catalystها پورت GigabitEthernet0/0 که وارد VLAN کاربران نمی‌شود. طوفان دیتاپلین به این سیم راه ندارد، به شرطی که واقعاً به یک سوئیچ مدیریت جدا رفته باشد نه به همان access.
• In-band. همان SVI یا اینترفیس مسیریابی که هم دیتا را عبور می‌دهد هم SSH را تمام می‌کند. XR به آن shared management interface می‌گوید. راحت است و تا روز حادثه هم کار می‌کند. روز حادثه دقیقاً وقتی به SSH نیاز دارید، in-band همان لوله‌ای است که پر شده.

پروتکل‌های جدیدتر هم همین پلین‌اند، حتی اگر در PDF سال ۲۰۱۰ نباشند: NETCONF، RESTCONF، gNMI و telemetry مدل‌محور. همه به CPU یا به یک پروسه مدیریتی روی لینوکس IOS XE می‌رسند. تفاوت‌شان با SNMP این است که حجم پاسخ و فرکانس‌شان می‌تواند بیشتر باشد. یک subscription درشت telemetry روی جعبه کوچک شعبه همان اثری را دارد که polling یک‌ثانیه‌ای SNMP روی 3750 داشت.

روی IOS XR ویژگی Management Plane Protection از نسخه 3.7.2 هست و پیش‌فرض خاموش است. تا وقتی روشن نشده، پروتکل مدیریتی که فعال باشد از همه اینترفیس‌ها قابل‌دسترسی است. با اولین اینترفیس in-band یا out-of-band که زیر MPP می‌گذارید، ویژگی روشن می‌شود و اینترفیس‌های دیگر آن ترافیک را دور می‌ریزند. پروتکل‌هایی که MPP محدود می‌کند، طبق راهنمای ASR 9000: SSH، SNMP (همه نسخه‌ها)، Telnet، TFTP، HTTP و HTTPS. MPP خودش سرویس را روشن نمی‌کند؛ فقط مشخص می‌کند سرویسِ روشن‌شده از کدام در وارد شود. جلسه SSH که قبل از تغییر کانفیگ باز بوده هم قطع نمی‌شود. و شمارنده بسته‌های دورریخته را نگه نمی‌دارد؛ اگر بعد از MPP دیگر به روتر نمی‌رسید، دنبال drop counter داخل خود MPP نگردید.

لوله باریک بین دیتاپلین و CPU

عدد مهم این معماری را مستند عیب‌یابی Catalyst 9000 رکورد کرده: خانواده Catalyst 9000 در مجموع حدود ۱۹٬۰۰۰ بسته در ثانیه را به CPU می‌رساند. بالاتر از این سقف، ترافیک punt بدون وزن‌دهی policed می‌شود. مقایسه کنید با دیتاپلین همان کلاس سوئیچ که صدها گیگابیت را در ASIC رد می‌کند. نسبت، تعارف نیست. CPU برای پروتکل ساخته شده، نه برای اینکه جای ASIC را بگیرد.

پس «CPU چهل درصد است» به‌تنهایی جمله مفیدی نیست. باید بپرسید کدام CPU. روی IOS XE دو عدد دارید:

• show processes cpu sorted بار دیمون IOS است؛ همان IOSd که روی لینوکس IOS XE نشسته و پروتکل و CLI را اجرا می‌کند.
• show platform software status control-processor brief بار خود پردازنده کنترل (لینوکس میزبان) را نشان می‌دهد. ممکن است IOSd خلوت باشد و پروسه دیگری روی لینوکس صندوق را پر کرده باشد.
• روی ASR 1000 و ISR 4000، show platform hardware qfp active datapath utilization summary بار دیتاپلین QFP است. این یکی اگر بالا باشد، کاربران کندی عبور را حس می‌کنند حتی اگر CLI هنوز روان باشد.

روی سوئیچ قدیمی‌تر مثل 2960، این تفکیک را به این تمیزی ندارید. یک CPU هم فریم استثنا را می‌بیند هم SNMP را. آنجا بالا رفتن CPU تقریباً همیشه یعنی کنترل و مدیریت با هم در خطرند، و علامت کلاسیکش این است که کنسول تکه‌تکه جواب می‌دهد و پینگ به خود سوئیچ loss دارد، در حالی که کاربران آن‌طرف هنوز رد می‌شوند؛ تا لحظه‌ای که BPDU هم drop شود. از آن لحظه به بعد دیتاپلین هم دیگر قابل‌اعتماد نیست، چون توپولوژی لایه دو خراب شده.

CoPP همان نگهبان دم در CPU است

Control Plane Policing یک policy از جنس QoS است که روی مسیر punt/inject می‌نشیند، نه روی پورت کاربر. راهنمای IOS XE این مسیر را punt/inject interface می‌نامد: از دیتاپلین به RP در جهت ورودی، و از RP به دیتاپلین در جهت خروجی. قانون QoS بعد از آن اعمال می‌شود که مشخص شده مقصد بسته خود کنترل‌پلین است. مثال خود سیسکو: محدود کردن TCP SYN به سمت کنترل‌پلین، مثلاً به یک مگابیت بر ثانیه، قبل از اینکه CPU درگیر handshake شود.

نسخه قدیمی‌تر IOS (مستند 15M&T) این ایده را به Control Plane Protection گسترش داده و زیر اینترفیس aggregate سه زیرصف ساخته:

• Host: ترافیکی که مقصدش یکی از آدرس‌های خود روتر است. SSH، SNMP، BGP، OSPF، EIGRP. بیشتر حفاظت اینجاست.
• Transit: بسته‌ای که مال روتر نیست ولی نرم‌افزاری سوئیچ می‌شود؛ مثل بعضی تونل‌هایی که روی CPU تمام می‌شوند.
• CEF-exception: چیزی که FIB به فرآیند برگردانده، یا درایور اینترفیس مستقیم در صف ورودی کنترل‌پلین گذاشته. ARP، keepalive لایه دو، و ترافیک غیر IP میزبان اینجاست. پس ARP را در کلاس host IP جست‌وجو نکنید؛ سیسکو صریحاً گفته ARP و CDP آنجا نیستند.

CoPP عصای جادویی نیست. اگر نرخ کلاس routing را زیادی پایین بیاورید، خود OSPF را drop می‌کنید و فکر می‌کنید «حمله دفع شد». اگر نرخ را بردارید، سیل تا CPU می‌رود. مستند Catalyst 9300 (IOS XE 16.6) هشدار می‌دهد که policer کلاس سیستمی را خاموش نکنید؛ حتی اگر خاموش کنید، بعد از بوت بعدی سیستم برای سالم بالا آمدن دوباره نرخ پیش‌فرض را برمی‌گرداند. تغییر نرخ نسبت به پیش‌فرض، طبق سند جدیدتر همان خانواده، حساسیت به اثر جانبی را بالا می‌برد. اول drop counter را بخوانید، بعد نرخ را دست بزنید.

همان سه پلین، شاسی‌های مختلف

معماری منطقی یکی است. جایی که بسته transit واقعاً لمس می‌شود فرق می‌کند. این جدول را موقع خرید یا موقع خواندن show processes cpu کنار دستتان بگذارید.

اگر قبلاً آشنایی با سیسکو NX-OS را خوانده‌اید، سوپروایزر در برابر لاین‌کارت همان شکاف کنترل و داده است. سیسکو SDN این شکاف را از داخل یک جعبه به بیرون می‌برد: کنترلر تصمیم می‌گیرد، تجهیزات فوروارد می‌کنند. در پردیس، مطلب سیسکو LISP چیست کنترل‌پلین فابریک است و آشنایی با سیسکو VXLAN دیتاپلین همان فابریک. آن دو مقاله را با این یکی قاطی نکنید: آنجا «پلین» مال overlay است، اینجا مال خود جعبه.

Catalyst 9000: FED، IOSd و سی‌ودو صف

سند عیب‌یابی سیسکو برای این خانواده چهار اسم را تعریف می‌کند که بدون آن‌ها خروجی دستورها معماست.

• FED (Forwarding Engine Driver) قلب سوئیچ است و سخت‌افزار را برنامه می‌ریزد. بسته transit را FED و ASIC تمام می‌کنند.
• IOSd دیمون IOS روی هسته لینوکس است. پروتکل و بخش زیادی از CLI اینجاست.
• PDS (Packet Delivery System) مکانیزم رساندن بسته بین زیرسیستم‌هاست؛ از جمله از FED به IOSd و برعکس.
• LSMPI اینترفیس حافظه مشترک لینوکس برای مسیر punt است.

CoPP روی 9000 سی‌ودو policer سخت‌افزاری برای سی‌ودو صف دارد. صف‌ها سیستمی‌اند و شما صف تازه نمی‌سازید. نرخ policer قابل‌تغییر است، ولی تنها policy که اجازه دارد روی control-plane بنشیند همان system-cpp-policy است. در راهنمای 16.6 حتی گفته شده هفده کلاس سیستمی را نمی‌شود پاک کرد، و نرخ کلاس سیستمی فقط بر حسب pps است نه بیت بر ثانیه. show running-config کلاس‌هایی را که روی مقدار پیش‌فرض مانده‌اند نشان نمی‌دهد. برای دیدن واقعیت:

show policy-map control-plane
show policy-map system-cpp-policy
show platform hardware fed switch active qos queue stats internal cpu policer
show platform software fed switch active punt cause summary
show platform software fed switch active punt cpuq all

نقشه کلاس به صف، از همان سند (نام کلاس را بدون فاصله تایپ کنید؛ در PDF رسمی بعضی نام‌ها وسط خط شکسته‌اند):

صف ۹ و ۱۰ مال وایرلس توکار است: CAPWAP کنترل روی UDP 5246 و CAPWAP داده روی UDP 5247. اگر eWLC روشن باشد و APها بی‌قرار، این دو صف را ببینید قبل از اینکه سراغ OSPF بروید. در یک خروجی نمونه خود سیسکو روی Catalyst 9600، کلاس system-cpp-police-ios-routing با نرخ ۱۷۰۰۰ pps نشان داده شده. این عدد را به 9300 تعمیم ندهید. سند می‌گوید مقدار دقیق بین اعضا و نسل‌های خانواده فرق می‌کند. منبع حقیقت، خروجی همان سوئیچ است.

دو سناریویی که سیسکو از فیلد آورده و ما هم زیاد می‌بینیم: پینگ به IP محلی که گاه‌وبی‌گاه drop می‌شود، و ICMP redirect زیاد که DHCP را هم کند می‌کند. redirect یعنی روتر یا SVI دارد به میزبان می‌گوید «از در دیگری برو». اگر این پیام‌ها سیل شود، صف ICMP پر می‌شود و کشف آدرس و DHCP که همسایه همان CPU هستند عقب می‌افتند. درمانش معمولاً بستن redirect روی SVI است (no ip redirects)، نه بالا بردن کورکورانه policer.

ASR 1000: سه برد، دو کانال

راهنمای عملیات ASR 1000 کنترل‌پلین را این‌طور چیده. سه قطعه اصلی:

• RP پردازنده همه‌منظوره است. پروتکل مسیریابی، CLI، اینترفیس مدیریت، نگهداری کد، لاگ، و مدیریت شاسی. بسته‌های کنترلی شبکه و پروتکل‌هایی را هم که ESP پشتیبانی نمی‌کند همین‌جا پردازش می‌شوند.
• ESP پردازنده فوروارد است. فایروال، ACL، رمزنگاری و QoS مسیر داده اینجاست. داخل ESP، QFP (QuantumFlow Processor) بسته‌ها را پردازش می‌کند. همه ترافیک عادی از ESP فعال رد می‌شود. اگر ESP مشکل پیدا کند، فوروارد می‌ایستد؛ حتی اگر RP هنوز به کنسول جواب بدهد.
• SIP برد اینترفیس است و SPAها را به RP و ESP وصل می‌کند.

کنترل توزیع شده است، به این معنا که RP و FECP (پردازنده کنترل موتور فوروارد) و IOCP (پردازنده کنترل ورودی/خروجی) هر کدام پردازنده خودشان را دارند. RP این مجموعه را با یک گیگابیت اترنت خارج از باند داخلی به نام EOBC هماهنگ می‌کند. سلامت قطعات روی I2C دیده می‌شود. مسیر داده روی midplane لینک‌های سریال ESI است که RP و SIP و ESP آماده را به ESP فعال وصل می‌کند. پس روی این شاسی «کنترل‌پلین» فقط یک پروسه IOS نیست؛ یک شبکه کوچک داخل جعبه است. اگر EOBC ناسالم باشد، قطعه از نظر RP گم می‌شود در حالی که کابل مشتری سالم است.

راهنمای عملیات ASR 1000، Figure 5-1: RP، ESP، QFP، SIP و لینک‌های EOBC و ESI روی midplane

همان راهنما، Figure 5-2: IOS روی هسته لینوکس RP، و QFP Client روی Embedded Services Processor

در شکل رسمی، هر دو بلوک RP و هر دو ESP با برچسب active کشیده شده‌اند. متن همان راهنما صریح‌تر است: یک RP و یک ESP فعال‌اند و جفت آماده را sync می‌کنند. برچسب شکل را با وضعیت زمان اجرا یکی نگیرید.

در همان راهنما، IOS روی RP مثل یک ماشین مجازی زیر هسته لینوکس است و به سخت‌افزار مستقیم دست نمی‌زند. برای سیستم با یک پروسه IOS، حدود ۴۵ درصد حافظه RP یک‌بار به IOS داده می‌شود؛ اگر IOS افزونه (active/standby) داشته باشید، سهم هر کدام حدود ۲۰ درصد است. این عدد مال راهنمای عملیات ASR 1000 است، نه یک قانون برای 9300.

نتیجه عملی: موقع حادثه روی ASR دو نمودار جدا بکشید. اگر QFP پر است، کاربر کندی عبور می‌بیند. اگر CPU روتر RP پر است، ممکن است BGP کند شود در حالی که جریان‌های از قبل برقرار هنوز از ESP رد می‌شوند. جابه‌جایی به ESP آماده، حالت فوروارد را با خود می‌برد؛ به همین دلیل standby باید sync باشد. این را با 2960 مقایسه نکنید. آنجا یک CPU است و «گراف جدا» وجود ندارد.

NX-OS: سوپروایزر را ارزان فرض نکنید

روی نکسوس، سوپروایزر هم کنترل‌پلین را دارد هم منیجمنت‌پلین را. دیتاپلین روی موتور فوروارد است. راهنمای NX-OS صریح می‌گوید اختلال سوپروایزر یعنی قطعی جدی: از دست رفتن keepalive و update مسیریابی، flap مسیر، کند شدن CLI، و پر شدن صف‌ها. مثال حمله‌ای که خود سند می‌زند ICMP echo، IP fragment و TCP SYN flood است. لازم نیست حمله باشد. یک اسکن آسیب‌پذیری از داخل دیتاسنتر، یا یک SNMP walk سنگین، همان الگو را می‌سازد.

از اولین بوت، اگر setup را رد کنید یا گزینه‌ای انتخاب نکنید، سیاست copp-system-p-policy-strict نصب می‌شود. چهار سطح در setup هست به‌علاوه skip که سیسکو توصیه‌اش نمی‌کند:

یک استثنای عملیاتی: با POAP، strict خودش اعمال نمی‌شود و باید CoPP را خودتان بگذارید. ارتقای NX-OS هم کلاس‌های جدید پروتکل را خودبه‌خود به policy قدیمی شما تزریق نمی‌کند؛ یا setup یا copp profile لازم است. policy پیش‌فرض با upgrade عوض نمی‌شود. این را موقع برنامه‌ریزی ارتقای نکسوس در پنجره شبانه یادتان باشد، وگرنه پروتکل تازه‌ای که IOS منتظر محافظتش بوده بدون کلاس می‌ماند.

show copp status
show policy-map interface control-plane
show copp profile strict
copp profile moderate

copp profile را وسط تولید، بدون خواندن drop counter، عوض نکنید. اول ببینید کدام کلاس drop دارد. اگر کلاس BGP drop می‌دهد و همسایه فلپ می‌کند، مشکل «کمبود پهنای باند اینترفیس» نیست.

IOS XR: FIB روی لاین‌کارت، MPP روی در مدیریت

در IOS XR، RIB بهترین مسیر را انتخاب می‌کند و آن را برای ساخت FIB به لاین‌کارت می‌فرستد. راهنمای سری 8000 می‌گوید خود پروسه RIB جدول FIB را نمی‌سازد؛ مسیرهای برگزیده را از راه Bulk Content Downloader به پروسه FIB هر لاین‌کارت می‌دهد و FIB آنجا ساخته می‌شود. پس کنترل‌پلین روی RP تصمیم می‌گیرد و دیتاپلین روی لاین‌کارت اجرا می‌کند. اگر یک لاین‌کارت FIB کهنه داشته باشد و بقیه تازه، سیاه‌چاله را فقط روی پورت‌های همان کارت می‌بینید. این علامت را با «OSPF کلاً down است» عوضی نگیرید.

بسته به سمت خود روتر، قبل از اینکه CPU را غرق کند، از LPTS (Local Packet Transport Services) رد می‌شود. LPTS در عمل CoPP دنیای XR است: برای هر جریان کنترلی یک سقف محلی دارد. نقطه شروع دیدن policerها:

show lpts pifib hardware police location 0/RP0/CPU0

محل دقیق location را از show platform همان شاسی بردارید. RP و لاین‌کارت اینترفیس ورودی یکی نیستند.

MPP لایه بعدی است و فقط در مدیریت را محدود می‌کند. نمونه، مطابق گام‌های راهنمای ASR 9000، برای اینکه SSH فقط از یک اینترفیس و فقط از یک محدوده منبع پذیرفته شود:

configure
control-plane
 management-plane
  inband
   interface GigabitEthernet0/0/0/0
    allow SSH peer
     address ipv4 192.0.2.0/24
commit
show mgmt-plane inband

پورت اترنت خود RP به‌صورت پیش‌فرض out-of-band حساب می‌شود و می‌شود زیر MPP گذاشتش. اگر MPP را روشن کنید و اینترفیس in-band کاربران را در فهرست نیاورید، SSH از همان VLAN دیتا دیگر داخل نمی‌شود. این رفتار درست است؛ غافلگیرکننده هم هست اگر نیمه شب از خانه به آدرس in-band وصل می‌شوید. قبل از commit، یک جلسه روی پورت out-of-band باز نگه دارید.

XR یک تفاوت عملیاتی دیگر هم دارد که مال پلین مدیریت است نه مال فوروارد: کانفیگ با commit وارد می‌شود و پروسه‌ها از هم جدا هستند. خراب شدن یک پروتکل، کل IOS را با خودش نمی‌برد آن‌طور که روی IOS یکپارچه قدیمی ممکن بود. این جداسازی همان دلیلی است که برای اینترنت و لبه اپراتور XR را برمی‌دارند، نه به‌خاطر اینکه «دستورهایش قشنگ‌تر است».

فایروال و وایرلس؛ کلمه‌ها را قاطی نکنید

روی ASA و FTD دو مسیر آشنا داریم. Through-the-box دیتاپلین فایروال است: بسته‌ای که از یک اینترفیس وارد می‌شود و از اینترفیس دیگر باید خارج شود، با قاعده دسترسی، NAT و inspection. To-the-box بسته‌ای است که مقصدش خود فایروال است: SSH مدیریتی، BGP اگر روی ASA باشد، ترافیک failover. ACL معمولی اینترفیس، to-the-box را آن‌طور که انتظار دارید فیلتر نمی‌کند. برای آن، ACL را با کلمه control-plane به اینترفیس می‌چسبانند:

access-list CP-IN extended permit tcp 192.0.2.0 255.255.255.0 interface outside eq ssh
access-group CP-IN in interface outside control-plane

اگر این تفاوت را ندانید، ACL را روی outside سخت می‌کنید و فکر می‌کنید مدیریت بسته شده، در حالی که SSH به خود ASA هنوز از جای دیگری جواب می‌دهد. یا برعکس، یک permit اضافه برای تست می‌گذارید و در مدیریت را روی اینترنت باز می‌گذارید.

در وایرلس یک جفت کلمه دیگر هست که نباید با پلین جعبه عوض شود. بین AP و WLC، CAPWAP control روی UDP 5246 است و CAPWAP data روی UDP 5247. آن شکاف، مال تونل اکسس‌پوینت است. خود WLC یا سوئیچی که eWLC دارد باز هم CPU و ASIC خودش را دارد، و همان صف‌های ۹ و ۱۰ روی Catalyst 9000 دقیقاً همین دو پورت را به CPU می‌برند. FlexConnect هم داستان سوم است: فوروارد محلی AP یعنی دیتاپلین کاربر دیگر تا WLC نمی‌آید، ولی کنترل‌پلین AP همچنان به WLC وابسته است. اگر این سه لایه را یکی بگویید، موقع قطعی یا AP را ریبوت می‌کنید یا سوئیچ را، و هیچ‌کدام علت نیست.

نمونه کانفیگ، هر کدام فقط روی پلتفرم خودش

بدترین عادت این موضوع، کپی کردن یک CoPP از وبلاگ IOS 12.4 روی Catalyst 9300 است. 9300 آن policy را قبول نمی‌کند، یا اگر جایی قبول کند رفتار سیستم را خراب می‌کند. نمونه‌ها را جدا نگه دارید.

IOS و IOS XE کلاسیک، جایی که policy دست خودتان است

روی روتری که control-plane را با MQC آزاد می‌گذارد (نسل ISR قدیمی و برخی IOS XEها، نه سوئیچ 9000)، شکل کار این است. اعداد آزمایشگاهی‌اند؛ قبل از تولید، نرخ را با show policy-map control-plane و تایمر واقعی OSPF میزان کنید.

ip access-list extended COPP-ICMP
 permit icmp any any echo
ip access-list extended COPP-OSPF
 permit ospf any any
class-map match-all CM-ICMP
 match access-group name COPP-ICMP
class-map match-all CM-OSPF
 match access-group name COPP-OSPF
policy-map COPP-IN
 class CM-OSPF
  police rate 100 pps conform-action transmit exceed-action transmit
 class CM-ICMP
  police rate 50 pps conform-action transmit exceed-action drop
 class class-default
  police rate 200 pps conform-action transmit exceed-action drop
control-plane
 service-policy input COPP-IN

کلاس OSPF در این نمونه حتی در صورت عبور از نرخ، transmit می‌ماند تا آزمایش را خراب نکنید. در تولید برای ICMP به سمت خود روتر drop معنی دارد؛ برای hello معمولاً نه، مگر نرخ را با حاشیه زیاد بالاتر از ترافیک سالم پروتکل گذاشته باشید. جهت را هم فراموش نکنید: این policy ورودیِ مسیر punt است.

Catalyst 9000: سیاست سیستمی را عوض نکنید، نرخ را اگر لازم شد دست بزنید

policy را خودتان service-policy نکنید. اگر بعد از خواندن drop counter واقعاً باید نرخ یک کلاس سیستمی را جابه‌جا کنید، شکل مجاز در راهنمای همین خانواده، police rate … pps زیر همان کلاس داخل system-cpp-policy است. و فردایش خروجی را با مقدار قبلی مقایسه کنید. اگر نمی‌دانید مقدار قبلی چه بوده، دست نزنید؛ show policy-map system-cpp-policy را ذخیره کنید.

بستن redirect، که اغلب از CoPP مؤثرتر است

interface Vlan10
 ip address 10.10.10.1 255.255.255.0
 no ip redirects
 no ip unreachables

no ip unreachables را کورکورانه روی هر جا نگذارید. بعضی عیب‌یابی‌ها به unreachable وابسته‌اند. روی SVI کاربران که مرتب میزبان بی‌مسیر دارد، خاموش کردنش CPU را از ساختن ICMP نجات می‌دهد. روی لبه اینترنت، قبلاً اثرش را روی PMTU بفهمید.

مدیریت را از VLAN کاربران جدا کنید

interface GigabitEthernet0/0
 vrf forwarding Mgmt-vrf
 ip address 192.0.2.10 255.255.255.0
no ip http server
no ip http secure-server
line vty 0 4
 transport input ssh
 access-class 10 in

روی خیلی از Catalyst 9000ها پورت مدیریت از قبل در VRF به نام Mgmt-vrf است. SSH به آن آدرس، از طوفان VLAN کاربران جداست به شرطی که کابلش به همان سوئیچ access کاربران نرفته باشد. access-class جایگزین CoPP نیست؛ فقط منبع مجاز را کوچک می‌کند. هر دو را با هم بخواهید.

عیب‌یابی: اول بگویید کدام پلین بیمار است

یک ترتیب که در رک وقت را تلف نمی‌کند:

1. یک پینگ transit واقعی بزنید، از میزبان پشت دستگاه به مقصدی که خود دستگاه نیست. اگر این سالم است و فقط پینگ به خود جعبه می‌پرد، دیتاپلین هنوز ایستاده و CPU یا CoPP درگیرند.
2. CPU را با دستور مناسب همان پلتفرم بخوانید. روی 9000 هر دو عدد IOSd و control-processor را. روی ASR، QFP را جدا.
3. علت punt را بشمارید، نه اینکه فقط درصد CPU را نگاه کنید. punt cause summary روی 9000 می‌گوید ARP است یا for-us یا L2 control.
4. drop مربوط به policer را بخوانید. drop در کلاس L2 همزمان با حلقه STP یک تشخیص است. drop در کلاس forus همزمان با مانیتورینگ یک تشخیص دیگر.
5. اگر فقط CLI کند است و فوروارد سالم، جلسه را ببرید روی out-of-band و بعد در in-band را محدود کنید. وسط طوفان از روی همان VLAN کاربران debug all نزنید. debug خودش کنترل‌پلین را می‌خورد.

دستور خطرناک را هم بگوییم تا کسی از روی این صفحه برنداردش. debug ip packet و debug all روی دستگاه تولید یعنی خودتان مسیر punt را سیل کنید. اگر لازم است یک بسته را ببینید، روی 9000 از EPC استفاده کنید که در همان سند سیسکو به‌عنوان علت punt هم دیده می‌شود؛ یعنی capture هم رایگان نیست و سهمی از CPU می‌گیرد. بازه و بافر را کوچک بگیرید و تمام که شد خاموش کنید.

آنچه در رک ایرانی همین شکاف را لو می‌دهد

شبکه‌ای که هم 3750 دارد هم 9300، هم ISR قدیمی شعبه هم یک نکسوس در مرکز، سه نسل از این معماری را هم‌زمان زنده نگه داشته. سیاستی که روی 9300 پیش‌فرض است روی 3750 وجود ندارد. پس در طوفان، جعبه قدیمی‌تر اول بی‌صدا می‌میرد و جعبه جدیدتر فقط drop counter بالا می‌آورد و ظاهراً «سالم» است. گزارش کاربر برعکس این است: «سوئیچ جدید مشکل دارد» چون همان سالن را پوشش می‌دهد، در حالی که ریشه یک کابل برگشتی روی 3750 ته رک است.

مانیتورینگ را هم جدی بگیرید. سرور Zabbix یا PRTG که هر ده ثانیه SNMP اگرینترفیس‌های یک 2960 را می‌خواند، برای آن CPU عدد کوچکی نیست. اگر آدرس مدیریت همان VLAN کاربران باشد، روزی که یک کارت شبکه خراب broadcast کند هم مانیتورینگ را از دست می‌دهید هم SSH را. پورت management سوئیچ‌های جدید را به یک VLAN یا سوئیچ جدا ببرید، حتی اگر آن سوئیچ جدا یک 2960 قدیمی فقط برای مدیریت باشد. طنزش را می‌فهمیم؛ ولی همان 2960 اگر فقط ترافیک مدیریت ببیند زنده می‌ماند.

روی روتر شعبه که NAT و zone-based firewall و تونل همزمان دارد، بخشی از بسته‌ای که «باید سخت‌افزار باشد» به فرآیند برمی‌گردد. آنجا قبل از خرید پهنای باند بیشتر، show processes cpu و اگر IOS XE است نمودار QFP را ببینید. خیلی از شکایت‌های «اینترنت شعبه کند است» سقف دیتاپلین همان ISR است، نه صف OSPF. و خیلی از شکایت‌های «روتر هنگ کرد» در واقع SSH است که از پشت همان NAT به خود روتر hairpin می‌شود و صف for-us را پر می‌کند.

دوشنبه صبح چه کار کنیم

1. برای هر جعبه یک خط بنویسید: دیتاپلین کجاست، مدیریت از کدام آدرس است، out-of-band دارد یا نه. اگر مدیریت in-band روی VLAN کاربران است، همان اولین کار است نه خرید شاسی جدید.
2. یک بار در حالت سالم، show policy-map control-plane یا معادل NX-OS را ذخیره کنید. بدون خط پایه، drop فردا معنی ندارد.
3. روی 9000 به system-cpp-policy دست نزنید تا وقتی یک کلاس مشخص drop پایدار دارد و علتش را از punt cause می‌دانید.
4. روی نکسوس اگر کسی skip را انتخاب کرده، برگردید به strict و بعد اگر پروتکل خودتان drop می‌شود نرخ همان کلاس را باز کنید، نه اینکه CoPP را بردارید.
5. روی XR، MPP را وقتی روشن کنید که یک مسیر out-of-band واقعاً کار می‌کند. commit را با جلسه پشتیبان بزنید.
6. Redirect و ACL log را در فهرست بازبینی SVI کاربران بگذارید. این دو بیشتر از «حمله پیچیده» CPU را می‌خورند.
7. سقف را به همکاران مانیتورینگ بگویید: حدود ۱۹ هزار pps به CPU روی Catalyst 9000، و خیلی کمتر روی سوئیچ access قدیمی. polling را با این عدد طراحی کنید نه با تعداد پورت.

اگر این سه پلین را جدا ببینید، نصف تیکت‌های «سوئیچ کند است» همان روز بسته می‌شود: یا عبور کند است (دیتاپلین، صف اینترفیس، فیبر، duplex)، یا خود جعبه کند است (punt و CoPP)، یا فقط ابزار شما کند است (منیجمنت). قاطی کردنشان یعنی ریبوت بی‌دلیل، و ریبوت یعنی پاک شدن همان شمارنده‌ای که علت را می‌گفت.

پرسش‌های کوتاه

منابع رسمی

• Troubleshoot Control Plane Operations on Catalyst 9000 Switches؛ سقف حدود ۱۹٬۰۰۰ pps، FED و IOSd، صف‌ها و دستورهای punt
• Catalyst 9300, IOS XE 16.6 — Configuring Control Plane Policing
• Nexus 9000 NX-OS 10.6 — Configure Control Plane Policing
• IOS XE QoS — Control Plane Policing و اینترفیس punt/inject
• IOS 15M&T — Control Plane Protection، زیررابط host و transit و CEF-exception
• Understand Express Forwarding (CEF)
• ASR 1000 Operations — Monitoring the Control Plane؛ RP، ESP، EOBC و ESI
• ASR 9000 IOS XR — Implementing Management Plane Protection
• IOS XR 8000 — RIB و دانلود مسیر به FIB لاین‌کارت

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

آکانت (Akanet) با بیش از بیست سال سابقه در شبکه‌های سیسکو، کنار سازمان‌هایی است که هم‌زمان سوئیچ access قدیمی و شاسی جدید دارند و باید بدانند کندی مال ASIC است یا مال CPU. جدا کردن آدرس مدیریت، خواندن CoPP بدون کور کردن OSPF، و بستن مسیری که طوفان را به سوپروایزر می‌رساند کار همان رک است، نه جمع‌بندی یک اسلاید. اگر تیکت «سوئیچ کند است» هر ماه برمی‌گردد، از روی شمارنده punt می‌شود علت را جدا کرد.

09121308444

aka@aka.ir  |  aka.ir

وفقک الله