اگر سال‌ها با کاتالیست و ISR زندگی کرده‌اید، اولین باری که پشت یک Nexus می‌نشینید دو حس با هم می‌آید: یک حس آشنا و یک حس غریب. CLI هنوز بوی سیسکو می‌دهد، اما دستور feature ، فایل‌سیستم bootflash: ، VRF مدیریتی که از روز اول هست و آپگرید با install all دیگر همان IOS همیشگی نیست. اینجا با NX-OS سروکار دارید؛ سیستم‌عاملی که سیسکو از روز اول برای دیتاسنتر ساخت.
در ایران هنوز خیلی‌ها «IOS» را اسم عام همه سیسکوها می‌دانند. روی کاغذ غلط نیست، همه از یک خانواده‌اند. در عمل اگر روی Nexus 9000 دنبال رفتار IOS کلاسیک بگردید یا روی Catalyst 9200 دنبال feature bgp ، هر دو را اشتباه گرفته‌اید. راه درست این است که اول خانواده سیستم‌عامل‌ها را بشناسید، بعد برای دیتاسنتر عمیق شوید داخل NX-OS.
در این راهنما سیسکو NX-OS را از همه زاویه‌ها مرور می‌کنیم: جایگاهش کنار IOS ، IOS XE و IOS XR ، معماری ماژولار روی Linux ، HA و انواع ISSU ، پلتفرم‌های Nexus ، مدل نسخه‌ها و نسخه پیشنهادی امروز سیسکو، ایمیج و بوت، لایسنس، کانفیگ روز اول، تفاوت دستورها با IOS ، vPC به‌طور کامل، عملیات روزمره (checkpoint ، GIR ، SMU و آپگرید)، برنامه‌پذیری و NDFC ، عیب‌یابی و امنیت. همه اعداد و تصاویر از منابع رسمی سیسکو است: Configuration Guideها، راهنمای آپگرید، راهنمای لایسنس و اسلایدهای Cisco Live.
اگر دنبال لایه بعدی همین داستان هستید، مطلب آشنایی با سیسکو VXLAN را ببینید و برای تصویر بزرگ‌تر ACI و SDN سراغ سیسکو SDN بروید.
NX-OS در یک نگاه
| سازنده / خانواده | Cisco ؛ سیستم‌عامل دیتاسنتر برای Nexus و MDS |
| پایه | کرنل Linux ؛ سرویس‌های ماژولار و ایزوله در user space |
| ایمیج روی Nexus 9000 | یک فایل واحد (مثل nxos64-cs.10.5.5.M.bin) به‌جای kickstart + system |
| نسخه پیشنهادی سیسکو (ژوئن ۲۰۲۶) | 10.5(5)M برای سخت‌افزارهای پشتیبانی‌شده در 10.5 |
| فیچرهای شاخص | vPC ، VXLAN BGP EVPN ، ISSU ، GIR ، checkpoint/rollback ، NX-API |
| لایسنس | DCN Essentials / Advantage / Premier ؛ Smart Licensing Using Policy از 10.2(1)F |
| حالت‌های کاری Nexus 9000 | NX-OS mode (مستقل) یا ACI mode (تحت APIC) |
| مدیریت متمرکز | Nexus Dashboard Fabric Controller (NDFC ، جانشین DCNM) |
فهرست مطالب
- خانواده سیستم‌عامل‌های سیسکو
- NX-OS چیست و برای چه ساخته شد
- معماری NX-OS
- High Availability ؛ SSO ، NSF و ISSU
- پلتفرم‌ها: Nexus 9000 و نسل‌های قبل
- نسخه‌ها و نسخه پیشنهادی
- ایمیج، بوت، Base و Full
- لایسنس NX-OS
- کانفیگ روز اول
- NX-OS برای کسی که IOS بلد است
- vPC به‌طور کامل
- عملیات: checkpoint ، GIR ، SMU و آپگرید
- برنامه‌پذیری و مدیریت متمرکز
- ابزارهای عیب‌یابی
- امنیت و Hardening
- مثال‌های واقعی از فیلد
- NX-OS را کی انتخاب کنیم؟
- پرسش‌های متداول
خانواده سیستم‌عامل‌های سیسکو؛ هر OS مال کدام تجهیز است
سیسکو یک سیستم‌عامل واحد برای همه دنیا نساخت. از روتر شعبه تا هسته اپراتور، نیاز HA ، مقیاس و مدل برنامه‌نویسی فرق می‌کرد. سه خانواده اصلی امروز IOS XE ، NX-OS و IOS XR هستند و IOS کلاسیک هنوز در رک‌های قدیمی زنده است.
سه خانواده اصلی سیستم‌عامل سیسکو: IOS ، NX-OS و IOS XR
| سیستم‌عامل | ماهیت | تجهیزات شاخص | کاربرد اصلی |
|---|---|---|---|
| IOS کلاسیک | ایمیج یک‌تکه (monolithic)؛ کرش یک بخش می‌تواند کل دستگاه را پایین بیاورد | Catalyst 2960 ، 3560 ، 3750 ، 4500 و 6500 نسل قدیم ، ISR G1/G2 | LAN و WAN سازمانی قدیمی |
| IOS XE | IOS روی Linux ؛ پروسس‌ها ماژولارتر، Install mode ، NETCONF/RESTCONF | Catalyst 9000 ، ISR 1000/4000 ، ASR 1000 ، Catalyst 8000 ، WLC 9800 | پردیس، شعبه، WAN سازمانی |
| NX-OS | OS دیتاسنتر روی Linux ؛ سرویس ایزوله، feature on-demand ، HA سطح سرویس | Nexus 9000 ، 3000 ، 7000 ، 5000/6000 ؛ MDS 9000 برای SAN | دیتاسنتر، leaf/spine ، VXLAN ، DCI |
| IOS XR | سیستم‌عامل carrier-grade ؛ جداسازی قوی، مدل commit | ASR 9000 ، NCS ، 8000 Series | هسته و لبه اپراتور |
| ACI (روی Nexus 9000) | همان سخت‌افزار Nexus با ایمیج ACI تحت کنترل APIC | Nexus 9000 leaf/spine | دیتاسنتر policy-driven |
| ASA / FTD | سیستم‌عامل فایروال | ASA ، Secure Firewall | امنیت لبه و دیتاسنتر |
نکته تاریخی مهم: IOS کلاسیک یک‌تکه بود؛ بخش بزرگی از نرم‌افزار در یک فضای حافظه مشترک زندگی می‌کرد. IOS XE ، NX-OS و IOS XR هر کدام به روش خودشان از این مدل فاصله گرفتند. NX-OS از روز اول برای دیتاسنتر طراحی شد: ترافیک east-west سنگین، آپگرید بدون قطع کامل، و جدا کردن سرویس‌ها طوری که اگر BGP بمیرد، فورواردینگ روی سخت‌افزار زنده بماند.
NX-OS چیست و برای چه ساخته شد
NX-OS سیستم‌عامل سوئیچ‌های Nexus و (با شاخه مخصوص خودش) سوئیچ‌های SAN خانواده MDS است. سیسکو در راهنمای Fundamentals نسخه 10.6 می‌گوید NX-OS با محصولات خانواده IOS و هر سیستم‌عامل شبکه‌ای که استانداردهای IEEE و RFC را رعایت کند سازگار است، و روی Nexus 9000 «از یک ایمیج نرم‌افزاری NXOS» تشکیل شده است.
هدف طراحی دیتاسنتر است: توپولوژی دو طبقه spine/leaf ، پورت‌های ۱۰ ، ۲۵ ، ۱۰۰ ، ۴۰۰ و حالا ۸۰۰ گیگ، فیچرهایی مثل vPC ، VXLAN EVPN و Segment Routing ، و برنامه‌پذیری با NX-API ، Python ، Bash و gNMI. اگر دفتر بیست‌نفره دارید، Nexus خرید اشتباهی است. اگر اتاق سرور با چند رک و ترافیک east-west جدی دارید، NX-OS همان زبانی است که باید بلد باشید.
شکل رسمی سیسکو: معماری دو طبقه spine و leaf با سوئیچ‌های Nexus و NX-OS
معماری NX-OS ؛ ماژولار، Linux و سرویس‌های ایزوله
قلب تفاوت NX-OS با IOS کلاسیک همین‌جاست. طبق مستند DevNet با عنوان Open NX-OS Modular Architecture و اسلایدهای Cisco Live (BRKDCN-2958):
- پایه سیستم یک کرنل Linux چندوظیفه‌ای است.
- پروتکل‌های مسیریابی و سوئیچینگ، امنیت، مدیریت و حتی بخش زیادی از درایورها در user space و جدا از کرنل اجرا می‌شوند.
- هر سرویس فضای حافظه محافظت‌شده خودش را دارد؛ کرش BGP کل سوئیچ را پایین نمی‌آورد.
- سرویس‌ها می‌توانند بدون reload ری‌استارت شوند؛ حتی از CLI با
restart bgp 65000. - زیرساخت مشترک: Sysmgr (مدیر سرویس‌ها که پروسس کرش‌کرده را دوباره بالا می‌آورد)، PSS (Persistent Storage Service برای ذخیره state) و MTS (Message and Transaction Service برای پیام بین پروسس‌ها).
- پروسس‌ها on-demand هستند؛ تا فیچری را با
featureفعال نکنید، پروسس و حافظه‌ای مصرف نمی‌کند.
Cisco Live BRKDCN-2958: پروسس‌های ایزوله NX-OS روی کرنل Linux با PSS و Graceful Restart
معنی عملی این معماری در فیلد: روی Nexus فیچر خاموش یعنی پروسس کمتر، حافظه کمتر و سطح حمله کوچک‌تر. روی IOS کلاسیک بیشتر وقت‌ها همه‌چیز از اول داخل ایمیج بیدار بود.
| نوع ری‌استارت سرویس | رفتار | نمونه |
|---|---|---|
| Stateful با PSS | state را از PSS برمی‌گرداند و از همان نقطه ادامه می‌دهد | سرویس‌های مدیریتی و داخلی |
| Stateful با Graceful Restart | state را از همسایه‌ها یا سرویس‌های دیگر دوباره می‌سازد | OSPF ، BGP ، IS-IS با NSF/GR |
| Stateless | از صفر شروع می‌کند | سرویس‌هایی که state پایدار ندارند |
High Availability ؛ SSO ، NSF و ISSU
روی شاسی‌های دو سوپروایزری (Nexus 9500 ، 9800 و نسل قبل 7000)، NX-OS از Stateful Switchover (SSO) استفاده می‌کند: سوپروایزر Active و Standby همگام هستند و اگر Active از دست برود، Standby بدون reload کامل کنترل را می‌گیرد. کارت‌های خط با NSF فورواردینگ را در این فاصله ادامه می‌دهند و پروتکل‌های مسیریابی با Graceful Restart یا NSR از همسایه‌ها می‌خواهند مسیرها را نگه دارند.
Cisco Live BRKDCN-2958: نمای کلی High Availability در NX-OS
Cisco Live BRKDCN-2958: جابه‌جایی سوپروایزر Active و Standby با حفظ data plane
سوئیچ‌اور با سه چیز فعال می‌شود: سیاست HA (مثلاً چند کرش پشت‌سرهم یک سرویس)، دستور دستی مدیر شبکه، یا مسیر ISSU.
ISSU ؛ آپگرید بدون قطع ترافیک
ISSU یعنی آپگرید نرم‌افزار با کمترین اثر روی data plane. طبق راهنمای آپگرید Nexus 9000 نسخه 10.5 ، روی سوئیچ‌های تک‌سوپروایزری سه نوع آپگرید داریم:
| نوع | data plane | قطعی control plane | شرایط |
|---|---|---|---|
| Disruptive (پیش‌فرض) | قطع می‌شود | حدود ۱۲۰ ثانیه | همه پلتفرم‌ها |
| Non-Disruptive ISSU | بدون قطع | کمتر از ۱۲۰ ثانیه | با کلیدواژه non-disruptive ، طبق ISSU Matrix |
| Enhanced ISSU (LXC) | بدون قطع | کمتر از ۶ ثانیه | boot mode lxc + reload ، حداقل 16GB حافظه ؛ 9300-FX/FX2/FX3/GX و مدل‌های جدیدتر |
Cisco Live BRKDCN-2958: آپگرید نرم‌افزار با ISSU و دستور install all
boot mode lxc است و سوئیچی که نیست پشتیبانی نمی‌شود؛ دو عضو vPC را هم‌حالت نگه دارید. (۲) اگر boot poap enable در کانفیگ باشد، ISSU بلاک می‌شود. قبل از هر پنجره تغییرات، ISSU Support Matrix را برای مسیر دقیق نسخه‌ها چک کنید.پلتفرم‌ها: Nexus 9000 و نسل‌های قبل
امروز جریان اصلی NX-OS روی خانواده Nexus 9000 است. سیسکو در صفحه رسمی این خانواده، سری‌های زیر را معرفی می‌کند:
| سری | فرم‌فاکتور | سرعت پورت | نقش رایج |
|---|---|---|---|
| Nexus 9300 | ثابت (fixed) | 1G تا 800G | Leaf ، ToR ، Spine کوچک، Border |
| Nexus 9400 | ماژولار جمع‌وجور (4RU) | تا 400G | Spine و Aggregation با تراکم بالا |
| Nexus 9500 | شاسی ماژولار | 1G تا 400G | Spine ، هسته دیتاسنتر |
| Nexus 9800 | شاسی ماژولار با معماری توزیع‌شده | 400G و 800G | Spine بزرگ و هسته نسل جدید |
| Nexus 9100 / 9200 | ماژولار / ثابت | تا 800G | خانواده‌های جدید برای AI و ابر؛ پشتیبانی NX-OS را در Release Notes چک کنید |
| نسل قبلی | نقش | نکته امروز |
|---|---|---|
| Nexus 7000 / 7700 | هسته شاسی‌دار، VDC ، OTV | هنوز در رک‌های ایران هست؛ برای پروژه جدید پیشنهاد نمی‌شود |
| Nexus 5000 / 5600 / 6000 | Access و Aggregation ، FCoE ، FEX | بیشتر مدل‌ها End-of-Sale ؛ دانش‌شان برای نگهداری لازم است |
| Nexus 3000 | ToR کم‌تأخیر | در بسیاری از مدل‌ها هم‌ایمیج با Nexus 9000 |
| MDS 9000 | سوئیچ Fibre Channel | شاخه NX-OS مخصوص SAN ؛ دستورها نزدیک، دامنه جدا |
VDC (Virtual Device Context) روی Nexus 7000 چند «سوئیچ منطقی» با control plane جدا روی یک شاسی می‌ساخت. روی Nexus 9000 جداسازی بیشتر با VRF ، VXLAN و tenant انجام می‌شود تا VDC.
NX-OS mode در برابر ACI mode
همان سخت‌افزار Nexus 9000 می‌تواند در NX-OS mode (مستقل، با CLI کلاسیک، VXLAN EVPN و NDFC) یا در ACI mode (تحت کنترلر APIC و مدل policy) کار کند. تبدیل مود یعنی عوض کردن ایمیج و پاک شدن کانفیگ؛ یک عملیات برنامه‌ریزی‌شده است نه یک دستور ساده. سوئیچ ACI را با ذهنیت «یک Nexus معمولی با VLAN» اداره نکنید؛ آنجا سیاست از EPG و Contract می‌آید، نه از CLI هر leaf.
نسخه‌ها و نسخه پیشنهادی سیسکو
شماره‌گذاری NX-OS چند نسل عوض شده است: روی Nexus 7000 شاخه‌های 6.x ، 7.x و 8.x ؛ روی Nexus 9000 اول 6.1(2)I و 7.0(3)I ، بعد 9.2 و 9.3 ، و امروز 10.x. در شاخه 10 ، پسوند F یعنی Feature Release (فیچر جدید) و پسوند M یعنی Maintenance Release (پایداری و رفع باگ). برای شبکه عملیاتی دنبال نسخه M باشید.
طبق سند رسمی Recommended Releases (به‌روزشده در ۴ ژوئن ۲۰۲۶):
| سخت‌افزار | نسخه پیشنهادی سیسکو |
|---|---|
| سخت‌افزاری که 10.5(x) را پشتیبانی می‌کند | 10.5(5)M |
| سخت‌افزاری که 10.5 را نه ولی 10.4 را پشتیبانی می‌کند | 10.4(7)M |
| مدل‌های EX که از 10.4 پشتیبانی نمی‌شوند | 10.3(8)M |
| سخت‌افزار قدیمی که هنوز End-of-Support نشده | 9.3(16) |
ایمیج، بوت، Base و Full
این بخش را با حوصله بخوانید، چون سه مفهوم را بازار قاطی می‌کند.
۱) مدل کلاسیک: kickstart + system
روی نسل‌های قدیمی (Nexus 7000 و 5000/6000) دو فایل داشتیم: kickstart (کرنل و بوت اولیه) و system (بقیه NX-OS). boot variableها جدا تنظیم می‌شدند و در آپگرید باید هر دو هم‌نسخه می‌ماندند.
۲) مدل مدرن Nexus 9000: یک فایل
روی Nexus 9000 فقط یک ایمیج داریم. در شاخه 10.x نام فایل‌ها ۶۴ بیتی است؛ مثلاً nxos64-cs.10.5.5.M.bin برای پلتفرم‌های Cloud Scale. نام دقیق فایل هر مدل را از صفحه دانلود و Release Notes بگیرید.
۳) Base mode در برابر Full mode
از 9.2(1) سیسکو Optionality را آورد: فیچرهای اختیاری به‌شکل بسته RPM هستند و NX-OS می‌تواند در دو حالت بوت شود (سند Optionality):
| حالت | چه چیزی داخل است | کاربرد |
|---|---|---|
| Full mode (پیش‌فرض) | تقریباً همه RPMهای فیچر هنگام بوت | رفتار آشنا؛ بیشتر سایت‌ها همین را می‌خواهند |
| Base mode | L2/L3 پایه؛ مسیریابی داینامیک و خیلی از فیچرها فقط بعد از نصب RPM | ایمیج سبک‌تر و سطح حمله کمتر |
۴) Install mode و Bundle mode مال IOS XE است
خیلی‌ها Bundle و Install را به NX-OS نسبت می‌دهند. در مستندات سیسکو این دو اصطلاح Catalyst و IOS XE هستند: Bundle یعنی بوت مستقیم از .bin و Install یعنی بوت از packages.conf. روی Nexus معادل ذهنی‌اش همان «یک ایمیج واحد + RPMهای اختیاری» است. اگر Catalyst 9000 دارید Install/Bundle بخوانید؛ اگر Nexus 9000 دارید install all و Base/Full.
۵) EPLD
روی Nexus غیر از NX-OS ، ایمیج EPLD هم داریم که FPGAها و برنامه‌پذیرهای سخت‌افزاری را به‌روز می‌کند. آپگرید EPLD همیشه disruptive است و در Release Notes هر نسخه مشخص می‌شود که لازم است یا نه.
لایسنس NX-OS
طبق Cisco NX-OS Licensing Options Guide ، لایسنس Nexus 9000 سه سطح اصلی و چند add-on دارد:
| سطح | نوع خرید | فیچرهای شاخص |
|---|---|---|
| بدون لایسنس | — | مسیر استاتیک، SVI ، HSRP و سوئیچینگ پایه |
| DCN Essentials | اشتراکی | BGP ، OSPF ، EIGRP ، IS-IS ، PIM ، GRE ، VXLAN BGP EVPN ، EPBR/ITD/PBR ، NetFlow و sFlow |
| DCN Advantage | اشتراکی و دائمی | همه Essentials + VXLAN EVPN Multi-Site ، TRM ، SR-MPLS ، MPLS L3VPN ، SRv6 ، Dynamic Load Balancing |
| DCN Premier | اشتراکی | همه Essentials و Advantage به‌علاوه قابلیت‌های Day-2 Operations |
| Add-on امنیتی | جداگانه | MACsec و CloudSec |
| Add-on Storage | جداگانه | FCoE ، FC و NDFC SAN |
از NX-OS 10.2(1)F مدل Smart Licensing Using Policy آمده است. روی Nexus 9000 و 3000 لایسنس «honor-based» است: فیچر بدون لایسنس هم کار می‌کند، اما گزارش مصرف باید به CSSM برسد. روی کاغذ یعنی سوئیچ قفل نمی‌شود؛ در عمل یعنی در ممیزی و تمدید قرارداد باید حساب لایسنس‌ها تمیز باشد.
کانفیگ روز اول
سوئیچ نو را یا دستی و از کنسول بالا می‌آورید، یا با POAP (PowerOn Auto Provisioning) که سوئیچ در اولین بوت از DHCP آدرس و اسکریپت می‌گیرد و خودش را کانفیگ می‌کند؛ در ردیف‌های ToR دیتاسنتر بزرگ حیاتی است. نمونه زیر حداقل‌هایی است که ما روی هر Nexus جدید می‌گذاریم. نکته کلیدی: پورت mgmt0 از روز اول در VRF management است، پس هر سرویس مدیریتی باید use-vrf management داشته باشد.
configure terminal hostname N9K-LEAF-1 clock timezone IRST 3 30 ! Management VRF (mgmt0 is always in VRF "management") interface mgmt0 vrf member management ip address 192.168.100.11/24 vrf context management ip route 0.0.0.0/0 192.168.100.1 ! Access and services no feature telnet feature ssh ssh key rsa 2048 username netadmin password 0 <StrongPassword> role network-admin username noc password 0 <StrongPassword> role network-operator ip domain-name dc.local ntp server 192.168.100.5 use-vrf management logging server 192.168.100.6 6 use-vrf management logging timestamp milliseconds ! Only the features you need feature interface-vlan feature lacp feature vpc feature lldp copy running-config startup-config
| نقش RBAC پیش‌فرض | دسترسی |
|---|---|
| network-admin | دسترسی کامل خواندن و نوشتن |
| network-operator | فقط خواندن؛ مناسب NOC و مانیتورینگ |
| نقش سفارشی | با role name و rule برای محدود کردن دستورها، اینترفیس‌ها یا VRFها |
NX-OS برای کسی که IOS بلد است
سیسکو عمداً منحنی یادگیری را برای مهندس IOS نرم کرده است: حالت‌های EXEC ، config و interface ، دستورهای show ، configure terminal ، فرم no ، کوتاه‌نویسی و علامت سؤال همه آشنا هستند. اگر روی کاتالیست CCNA خوانده‌اید، روز اول Nexus گم نمی‌شوید؛ روز سوم است که تفاوت‌ها درد می‌گیرد.
| موضوع | IOS / IOS XE | NX-OS |
|---|---|---|
| فعال‌سازی فیچر | بیشتر فیچرها از اول فعال‌اند | باید feature ospf و مانند آن را بزنید، وگرنه دستورش وجود ندارد |
| خاموش کردن فیچر | کانفیگ معمولاً می‌ماند | no feature … همه کانفیگ آن فیچر را پاک می‌کند؛ قبلش checkpoint بگیرید |
| نام اینترفیس | GigabitEthernet1/0/1 |
Ethernet1/1 برای همه سرعت‌ها |
| پیش‌فرض پورت | switchport | روی بسیاری از مدل‌ها routed یا shutdown ؛ با show run all ببینید |
| مدیریت | معمولاً در global routing | mgmt0 در VRF management |
| آدرس IP | ip address 10.1.1.1 255.255.255.0 |
ip address 10.1.1.1/24 (ماسک هم پذیرفته می‌شود) |
| فایل‌سیستم | flash: |
bootflash: ، volatile: ، usb1: |
| ذخیره کانفیگ | write memory |
copy running-config startup-config |
| آپگرید | install add … activate commit (XE) |
install all nxos bootflash:… |
| دیدن کانفیگ یک بخش | show run | section ospf |
show running-config ospf |
| مقایسه کانفیگ | show archive config differences |
show running-config diff |
| خروجی ساختاریافته | محدود | show … | json و | xml |
| فیلتر خروجی | include ، begin |
grep ، egrep ، last ، count ، wc ، sort |
| مجازی‌سازی لایه ۲ | StackWise ، StackWise Virtual | vPC (دو کنترل‌پلن مستقل) |
| شل Linux | Guest Shell | Bash (feature bash-shell) و Guest Shell |
یک مثال واقعی: بدون feature ، BGP اصلاً وارد کانفیگ نمی‌شود.
N9K(config)# router bgp 65000
^
% Invalid command at '^' marker.
N9K(config)# feature bgp
N9K(config)# router bgp 65000
N9K(config-router)# neighbor 192.0.2.2 remote-as 65000
N9K# restart bgp 65000
همان restart bgp اینجا پروسس ایزوله BGP را ری‌استارت می‌کند، نه کل سوئیچ را.
vPC به‌طور کامل
vPC (Virtual Port-Channel) پرکاربردترین فیچر NX-OS در ایران است: دو سوئیچ Nexus از دید سرور یا سوئیچ پایین‌دستی مثل یک سوئیچ دیده می‌شوند و یک Port-Channel واحد با لینک‌هایی به هر دو ساخته می‌شود؛ هر دو لینک فعال، بدون blocking در STP. اشتباه رایج این است که vPC را با StackWise کاتالیست یکی بدانیم. در vPC هر سوئیچ control plane مستقل خودش را دارد و آپگرید یا خرابی یکی، دیگری را از کار نمی‌اندازد.
Cisco Live BRKDCN-2958: اصطلاحات vPC ؛ Domain ، Peer ، Peer-Link ، Keepalive ، Member و Orphan Port
| جزء | کار | نکته طراحی |
|---|---|---|
| vPC Domain | جفت سوئیچ‌های vPC با یک ID | ID در هر سایت یکتا باشد (در system MAC اثر دارد) |
| vPC Peer | هر یک از دو سوئیچ؛ یکی Primary و دیگری Secondary | با role priority مشخص کنید |
| Peer-Link | Port-Channel بین دو سوئیچ برای همگام‌سازی (CFS) و ترافیک اضطراری | حداقل دو لینک ۱۰G یا بیشتر روی دو ماژول/ASIC مختلف |
| Peer-Keepalive | لینک L3 جدا برای تشخیص زنده بودن peer | معمولاً از mgmt0 در VRF management ؛ هرگز از روی peer-link |
| vPC Member Port | پورت‌های Port-Channel متصل به سرور یا سوئیچ پایین | با vpc <id> ؛ LACP active |
| Orphan Port | پورتی که فقط به یکی از دو سوئیچ وصل است | در خرابی peer-link ممکن است ایزوله شود؛ تا حد ممکن نداشته باشید |
feature vpc feature lacp vpc domain 10 role priority 100 peer-keepalive destination 192.168.100.12 source 192.168.100.11 vrf management peer-switch peer-gateway auto-recovery delay restore 150 ip arp synchronize interface port-channel1 description vPC Peer-Link switchport mode trunk spanning-tree port type network vpc peer-link interface Ethernet1/53-54 description to N9K-LEAF-2 switchport mode trunk channel-group 1 mode active interface port-channel20 description ESXi-01 (vPC 20) switchport mode trunk switchport trunk allowed vlan 10,20,30 spanning-tree port type edge trunk vpc 20 interface Ethernet1/1 description ESXi-01 vmnic0 switchport mode trunk switchport trunk allowed vlan 10,20,30 channel-group 20 mode active
| دستور | چرا |
|---|---|
peer-switch |
هر دو سوئیچ با یک Bridge ID در STP ظاهر می‌شوند؛ همگرایی سریع‌تر هنگام خرابی |
peer-gateway |
هر سوئیچ بسته‌ای را که به MAC روتر peer فرستاده شده خودش route می‌کند؛ لازم برای برخی storage و load balancerها |
auto-recovery |
اگر فقط یکی از دو سوئیچ بعد از قطعی برق بالا بیاید، vPCها را بعد از timeout فعال می‌کند |
delay restore |
پس از reload ، vPCها را دیرتر بالا می‌آورد تا مسیریابی L3 آماده باشد |
ip arp synchronize |
جدول ARP بین دو peer همگام می‌شود؛ همگرایی سریع‌تر |
Cisco Live BRKDCN-2958: object tracking برای peer-link و uplinkها در vPC
show vpc consistency-parameters global و show vpc consistency-parameters vpc <id> را بگیرید. اگر هر دو peer-link و keepalive قطع شوند، هر دو سوئیچ خود را Primary می‌دانند (dual-active)؛ دلیل اینکه keepalive را هرگز از مسیر peer-link رد نمی‌کنیم همین است.عملیات: checkpoint ، GIR ، SMU و آپگرید
Checkpoint و Rollback
در دیتاسنتر دست‌کاری بدون نقطه بازگشت یعنی شجاعت بی‌مورد. NX-OS دستور داخلی برای این کار دارد:
checkpoint PRE-CHANGE description before-vpc-change show checkpoint summary ! ... apply changes ... show diff rollback-patch checkpoint PRE-CHANGE running-config rollback running-config checkpoint PRE-CHANGE
از نسخه‌های جدیدتر، configure replace bootflash:golden.cfg هم هست که کل کانفیگ را با یک فایل مرجع جایگزین می‌کند و فقط اختلاف‌ها را اعمال می‌کند.
Graceful Insertion and Removal (GIR)
GIR سوئیچ را پیش از تعمیر یا آپگرید «با احترام» از مسیر ترافیک بیرون می‌برد. طبق راهنمای System Management نسخه 10.6 ، در حالت maintenance همه پروتکل‌های کنترل‌پلن لایه ۳ از شبکه ایزوله می‌شوند (BGP با isolate ، OSPF با max-metric ، IS-IS با overload) و vPC خاموش می‌شود، در حالی که مسیرهای مستقیم دست نمی‌خورند. همسایه‌ها ترافیک را از مسیر دیگر می‌فرستند و بعد شما با خیال راحت کار می‌کنید.
Cisco Live BRKDCN-2958: خارج کردن سوئیچ از مسیر ترافیک با یک دستور و snapshot پیش از تغییر
N9K# snapshot create PRE-UPGRADE before-upgrade N9K(config)# system mode maintenance N9K# show system mode ! ... upgrade / fix hardware ... N9K(config)# no system mode maintenance N9K# show snapshots compare PRE-UPGRADE after_maintenance
Cisco Live BRKDCN-2958: برگشت به حالت normal ؛ پروتکل‌ها بعد از نصب مسیرها در سخت‌افزار اعلام می‌شوند
NX-OS هنگام ورود و خروج از maintenance به‌طور خودکار snapshot می‌گیرد (وضعیت اینترفیس‌ها، همسایه‌های BGP و OSPF ، vPC و …) تا بتوانید قبل و بعد را مقایسه کنید و مطمئن شوید همه‌چیز برگشته است.
Cisco Live BRKDCN-2958: snapshot خودکار و دستی برای مقایسه وضعیت قبل و بعد از تغییر
SMU ؛ پچ بدون رفتن به نسخه بعدی
SMU (Software Maintenance Update) یک پچ RPM برای یک باگ مشخص است؛ وقتی باگ عملیاتی یا امنیتی دارید و نمی‌خواهید کل نسخه را عوض کنید. چرخه‌اش add ، activate و commit است و با ISSU سازگار است.
Cisco Live BRKDCN-2958: چرخه SMU با install add ، activate ، commit ، deactivate و remove
install add bootflash:<smu-file>.rpm activate install commit show install active ! rollback of a patch: install deactivate <smu-package> install remove <smu-package>
آپگرید نرم‌افزار؛ مراحل ما
| گام | کار | دستور |
|---|---|---|
| ۱ | انتخاب نسخه از Recommended Release و ISSU Matrix | — |
| ۲ | بکاپ و checkpoint | copy running-config bootflash:pre-upg.cfg |
| ۳ | کپی ایمیج و چک هش | copy scp://… bootflash: vrf management و show file bootflash:… sha512sum |
| ۴ | دیدن اثر آپگرید | show install all impact nxos bootflash:… non-disruptive |
| ۵ | خارج کردن سوئیچ از مسیر (اختیاری ولی توصیه‌شده) | system mode maintenance |
| ۶ | آپگرید | install all nxos bootflash:… non-disruptive |
| ۷ | بررسی و برگرداندن به مسیر | show version ، show vpc ، no system mode maintenance |
| ۸ | تکرار برای vPC peer | یکی‌یکی، نه هم‌زمان |
install all روش توصیه‌شده است، چون سازگاری کانفیگ، BIOS و ماژول‌ها را قبل از آپگرید چک می‌کند. عوض کردن boot variable و reload این چک‌ها را دور می‌زند و برای downgrade اصلاً پشتیبانی نمی‌شود.برنامه‌پذیری و مدیریت متمرکز
یکی از دلایلی که تیم‌های اتوماسیون Nexus را دوست دارند همین بخش است. تقریباً هر چیزی در NX-OS یک API دارد.
| ابزار | فعال‌سازی | کاربرد |
|---|---|---|
| NX-API CLI / REST | feature nxapi |
اجرای دستور CLI و گرفتن خروجی JSON روی HTTPS ؛ ساده‌ترین راه برای اسکریپت |
| NETCONF / RESTCONF | feature netconf ، feature restconf |
کانفیگ مدل‌محور با YANG (مدل‌های Native و OpenConfig) |
| gNMI / gRPC | feature grpc |
Streaming Telemetry و کانفیگ با OpenConfig |
| Bash | feature bash-shell |
دسترسی کنترل‌شده به Linux زیرین با RBAC |
| Guest Shell | guestshell enable |
کانتینر Linux ایزوله برای اجرای Python و ابزارهای شخص ثالث |
| Python روی سوئیچ | داخلی | اسکریپت با ماژول cli ؛ همراه EEM برای واکنش خودکار |
| Ansible / Terraform | از بیرون | کالکشن cisco.nxos و providerهای NX-OS و NDFC |
N9K# show interface brief | json N9K# show ip route vrf all | json-pretty
Nexus Dashboard و NDFC
برای بیش از چند سوئیچ، کانفیگ دستی تک‌تک leafها خطای انسانی می‌سازد. Nexus Dashboard Fabric Controller (NDFC) ، جانشین DCNM ، فابریک VXLAN EVPN ، vPC و حتی SAN را با قالب‌های آماده می‌سازد و مدیریت می‌کند. روی همان پلتفرم Nexus Dashboard ، ماژول‌های Insights و Orchestrator برای تحلیل، پیش‌بینی اثر تغییر و مدیریت چند سایت هستند.
Cisco Live BRKDCN-2958: NDFC روی Nexus Dashboard برای ساخت و مدیریت فابریک
شکل رسمی سیسکو: نمونه توپولوژی شبکه دیتاسنتر مبتنی بر Nexus
ابزارهای عیب‌یابی
| ابزار / دستور | کاربرد |
|---|---|
show system resources ، show processes cpu sort |
مصرف CPU و حافظه و پروسس‌های پرمصرف |
show logging logfile | last 50 |
آخرین لاگ‌ها |
show interface counters errors |
CRC ، drop و خطاهای لینک |
ethanalyzer local interface inband display-filter "bgp" limit-captured-frames 50 |
Wireshark داخل سوئیچ برای ترافیک control plane |
| SPAN / ERSPAN | کپی ترافیک data plane به آنالایزر، حتی از راه دور روی GRE |
show policy-map interface control-plane |
بسته‌هایی که CoPP drop کرده؛ علت رایج «همسایه BGP می‌پرد» |
show vpc ، show vpc consistency-parameters global |
سلامت vPC |
show install all status |
وضعیت آپگرید در حال اجرا یا قبلی |
show cores ، show system reset-reason |
کرش پروسس و دلیل reload |
show tech-support details |
خروجی کامل برای TAC ؛ روی bootflash ذخیره کنید |
| EEM و GOLD | واکنش خودکار به رویداد و تست سلامت سخت‌افزار |
امنیت و Hardening
| موضوع | اقدام |
|---|---|
| سطح حمله | فقط فیچرهای لازم را فعال کنید؛ no feature telnet ، NX-API فقط روی HTTPS |
| دسترسی مدیریتی | مدیریت فقط از mgmt0 و VRF management ؛ ACL روی line vty |
| احراز هویت | AAA با TACACS+ یا RADIUS ؛ کاربر محلی فقط برای اضطرار؛ نقش‌های RBAC |
| CoPP | NX-OS در اولین بوت یک پروفایل CoPP (مثل strict) اعمال می‌کند؛ آن را حذف نکنید، فقط در صورت نیاز تنظیم کنید |
| پروتکل‌های مسیریابی | احراز هویت همسایه‌های OSPF و BGP ؛ maximum-prefix روی BGP |
| لایه ۲ | BPDU Guard روی پورت edge ، DHCP Snooping و Dynamic ARP Inspection در صورت نیاز |
| رمزنگاری لینک | MACsec (add-on امنیتی) روی لینک‌های بین سایت یا حساس |
| نرم‌افزار | ماندن روی نسخه M پیشنهادی و خواندن Security Advisoryهای سیسکو |
مثال‌های واقعی از فیلد
۱) ToR برای چند رک سرور: دو Nexus 9300 با vPC به سرورها و uplink به spine یا هسته. کانفیگ روزمره: VLAN یا VXLAN ، HSRP یا Anycast Gateway ، ACL و مانیتورینگ. اینجا Catalyst 9200 با PoE جای ToR ده یا بیست‌وپنج گیگ را نمی‌گیرد.
۲) هسته قدیمی با Nexus 7010: هنوز در بعضی سازمان‌ها VDC جدا برای Production و DMZ روی یک شاسی هست. آپگرید kickstart و system و ISSU دو سوپروایزر را باید مثل جراحی برنامه‌ریزی کرد؛ و وقتش است که برنامه مهاجرت به Nexus 9000 نوشته شود.
۳) مهاجرت به ACI: همان leaf سخت‌افزاری، مود ACI و مغز APIC. تیم دیگر CLI leaf را «مال خودش» نمی‌داند. اگر فقط NX-OS بلد باشید و وارد ACI شوید، باید مدل ذهنی را عوض کنید، نه فقط دستورها را.
۴) اشتباه رایج: کپی کردن ACL و HSRP از کانفیگ 3750 به Nexus بدون feature و بدون دقت به اینکه پورت‌ها routed هستند یا switched. نتیجه: دستور قبول نمی‌شود یا رفتار لایه ۲ و ۳ قاطی می‌شود.
۵) آپگرید هم‌زمان دو عضو vPC: برای «صرفه‌جویی در وقت» هر دو را با هم reload کرده‌اند و همه سرورها قطع شده‌اند. vPC را همیشه یکی‌یکی، با GIR و بعد از بررسی سلامت عضو اول آپگرید کنید.
NX-OS را کی انتخاب کنیم؟
| انتخاب کنید اگر | انتخاب نکنید اگر |
|---|---|
| دیتاسنتر یا اتاق سرور جدی با ترافیک east-west دارید | فقط Access اداری، PoE و وایرلس می‌خواهید؛ Catalyst + IOS XE کافی است |
| به vPC ، VXLAN EVPN یا پورت‌های ۲۵/۱۰۰/۴۰۰ گیگ نیاز دارید | یک Nexus تنها بدون طراحی leaf/spine و بدون تیم آشنا می‌خرید |
| اتوماسیون، API و Telemetry برایتان مهم است | نیاز اصلی‌تان StackWise ، PoE+ و امکانات پردیس است |
| مسیر ACI یا NDFC در نقشه راه است | بودجه لایسنس و پشتیبانی را در نظر نگرفته‌اید |
برای Access پردیس همان سوئیچ سیسکو سری ۹۲۰۰ ، برای هسته شاسی‌دار پردیس سوئیچ سیسکو سری ۹۶۰۰ و برای leaf دیتاسنتر سوئیچ سیسکو Nexus 93180 را ببینید.
پرسش‌های متداول
NX-OS همان IOS است با اسم دیگر؟
نه. CLI شبیه است، اما معماری (Linux ، سرویس ایزوله، feature on-demand)، مدل ایمیج و آپگرید، VRF مدیریتی و خیلی از فیچرها متفاوت است.
بعد از فعال کردن feature باید reload کنم؟
معمولاً نه؛ پروسس همان لحظه بالا می‌آید. استثناها بیشتر به TCAM Carving یا تغییر حالت بوت (مثل boot mode lxc) مربوط‌اند.
vPC بهتر است یا StackWise؟
برای دیتاسنتر vPC ، چون دو control plane مستقل دارد و آپگرید و خرابی یک عضو دیگری را نمی‌خواباند. StackWise و StackWise Virtual مخصوص Catalyst و پردیس هستند.
کدام نسخه NX-OS را نصب کنم؟
برای سخت‌افزارهایی که 10.5 را پشتیبانی می‌کنند، پیشنهاد فعلی سیسکو 10.5(5)M است. همیشه سند Recommended Releases را همان روز چک کنید.
بدون لایسنس چه کار می‌کند؟
سوئیچینگ پایه، SVI ، مسیر استاتیک و HSRP بدون لایسنس کار می‌کنند. OSPF ، BGP و VXLAN EVPN در DCN Essentials هستند؛ لایسنس honor-based است، اما باید گزارش مصرف داشته باشید.
منابع رسمی برای ادامه مطالعه
- Cisco Nexus 9000 NX-OS Fundamentals Configuration Guide 10.6(x) – Overview
- Open NX-OS Modular Architecture (Cisco DevNet)
- Cisco Nexus 9000 NX-OS Software Upgrade and Downgrade Guide 10.5(x)
- Optionality in Cisco NX-OS Software (Base / Full)
- Recommended Cisco NX-OS Releases for Cisco Nexus 9000 Series Switches
- Cisco Nexus 9000 and 3000 ISSU Support Matrix
- Cisco NX-OS Licensing Options Guide
- Cisco Nexus 9000 System Management Guide 10.6 – Graceful Insertion and Removal
- Cisco Nexus 7000 High Availability Overview
- Cisco Live BRKDCN-2958 – Data Center Operations, Maintenance and Migration Best Practices
- Upgrade Guide for Catalyst 9000 (Install / Bundle mode)
مسیر مهارت اتوماسیون شبکه را هم در مطلب عصر تازه مدارک سیسکو و آموزش‌های عملی را در دسته آموزش کانفیگ و پیاده‌سازی دنبال کنید.
مشاوره و پیاده‌سازی با آکانت
آکانت (Akanet) با بیش از بیست سال سابقه در شبکه‌های مبتنی بر سیسکو، کنار سازمان‌هایی ایستاده که دیتاسنتر Nexus ، vPC و فابریک VXLAN EVPN را طراحی، اجرا و نگهداری می‌کنند. انتخاب بین Nexus و Catalyst ، انتخاب نسخه و مسیر آپگرید، مهاجرت از Nexus 7000 و 5000 به Nexus 9000 ، اتوماسیون با NDFC و Ansible و عیب‌یابی سخت، کار روزمره ماست.
تلفن: 09121308444 | ایمیل: aka@aka.ir | aka.ir