Cisco NX-OS – آشنایی با سیسکو NX-OS

از IOS یک‌تکه تا سیستم‌عامل دیتاسنتر

اگر سال‌ها با سوئیچ کاتالیست و روتر ISR زندگی کرده‌اید، اولین باری که پشت Nexus می‌نشینید یک حس آشنا و یک حس غریب با هم می‌آید. CLI هنوز بوی سیسکو می‌دهد، ولی دستور feature ، فایل سیستم bootflash: ، و آپگرید با install all دیگر همان IOS کلاسیک نیست. این مطلب همان Cisco NX-OS – آشنایی با سیسکو NX-OS است: اول سیر سیستم‌عامل‌های سیسکو و اینکه هر کدام مال کدام جعبه است، بعد شیرجه تخصصی داخل معماری ماژولار NX-OS ، نسخه‌ها، مدل نصب ایمیج، شباهت و تفاوت سطح دستور با IOS ، و مثال واقعی از رک دیتاسنتر.

در ایران هنوز خیلی‌ها «IOS» را اسم عام همه سیسکو می‌دانند. روی کاغذ غلط نیست که همه خانواده سیسکو‌اند؛ در عمل اگر روی Nexus 9000 دنبال ip routing کلاسیک بگردید یا روی Catalyst 9200 دنبال feature bgp ، هر دو را اشتباه گرفته‌اید. مسیر درست این است که اول خانواده OS را بشناسید، بعد برای دیتاسنتر عمیق شوید داخل NX-OS. برای لایه Access پردیس همان سویچ سیسکو سری ۹۲۰۰ با IOS XE است؛ برای هسته شاسی‌دار پردیس سویچ سیسکو سری ۹۶۰۰ ؛ برای leaf/spine دیتاسنتر داستان Nexus و NX-OS است.

سیر سیستم‌عامل‌های سیسکو؛ هر OS مال کدام تجهیز است

سیسکو یک OS واحد برای همه دنیا نساخت. از تلفن خانگی تا هسته اپراتور، نیاز HA ، مقیاس، و مدل برنامه‌نویسی فرق می‌کرد. خلاصه خانواده‌ها از روی پلتفرم رسمی سیسکو:

سیستم‌عامل	ماهیت	تجهیزات شاخص	کاربرد اصلی
Cisco IOS (کلاسیک / monolithic)	یک ایمیج یک‌تکه؛ control و data روی یک جعبه، ری‌استارت پروسس محدود	سوئیچ‌های قدیمی کاتالیست (۲۹۶۰، ۳۵۶۰، ۳۷۵۰، ۴۵۰۰، ۶۵۰۰ در نسل‌های IOS)، روترهای ISR نسل قدیم، بسیاری از پلتفرم‌های campus قبل از XE	LAN/WAN سازمانی کلاسیک؛ هنوز در رک ایران زنده است
Cisco IOS XE	IOS روی Linux؛ پروسس‌ها ماژولارتر، مدل Install/Bundle، API و Continer قابلیت	Catalyst 9000 (۹۲۰۰/۹۳۰۰/۹۴۰۰/۹۵۰۰/۹۶۰۰)، ISR 1000/4000 ، ASR 1000 ، Catalyst 9800 WLC ، بسیاری از Edge های SD-WAN	پردیس، شعبه، WAN مدرن سازمانی
Cisco IOS XR	ماژولار carrier-grade؛ جداسازی قوی، commit کانفیگ، مقیاس اپراتور	ASR 9000 ، NCS ، CRS (نسل‌ها)، روترهای هسته Service Provider	هسته و لبه اپراتور؛ نه سوئیچ Access اداری
Cisco NX-OS	OS دیتاسنتر مبتنی بر Linux؛ پروسس ایزوله، feature on-demand ، HA سطح سرویس	Nexus 3000 / 5000 / 6000 / 7000 / 9000 ، MDS (خانواده SAN با NX-OS مشتق)	دیتاسنتر، leaf/spine ، DCI ، SAN/LAN همگرا در پلتفرم‌های مربوط
ASA OS / FTD	فایروال و تهدید	ASA سخت‌افزاری، Firepower / Secure Firewall	امنیت لبه و دیتاسنتر؛ CLI جدا از NX-OS
AireOS / IOS XE Wireless	کنترلر وایرلس	WLC های AireOS قدیمی، Catalyst 9800	وایرلس سازمانی؛ در مطلب اکوسیستم وایرلس سیسکو
ACI fabric OS (روی Nexus 9000 در ACI mode)	همان خانواده سخت‌افزار Nexus با ایمیج/مود ACI تحت کنترل APIC	Nexus 9000 leaf/spine در فابریک ACI	دیتاسنتر policy-driven ؛ در مطلب سیسکو SDN

نکته تاریخی مهم: IOS کلاسیک «monolithic» بود؛ یعنی بخش بزرگی از نرم‌افزار در یک فضای حافظه با هم زندگی می‌کرد. کرش یک بخش می‌توانست کل جعبه را پایین بیاورد. IOS XE و NX-OS و IOS XR هر کدام به روش خود از این مدل فاصله گرفتند. NX-OS از روز اول برای دیتاسنتر طراحی شد: ترافیک east-west زیاد، نیاز به آپگرید بدون قطع کامل، و جدا کردن سرویس‌ها طوری که BGP بمیرد ولی فورواردینگ روی خط کارت زنده بماند.

NX-OS چیست و برای چه ساخته شد

NX-OS سیستم‌عامل سوئیچ‌های خانواده Nexus است. سیسکو در Fundamentals رسمی Nexus 9000 می‌گوید NX-OS با محصولات IOS-variant سیسکو و با هر OS شبکه‌ای که استاندارد IEEE/RFC را رعایت کند، interoperable است. یک جمله کلیدی همان سند: The Cisco NX-OS software consists of one NXOS software image — روی نسل ۹۰۰۰ ایمیج واحد nxos.*.bin است، نه دو فایل جداگانه kickstart/system نسل‌های قدیمی‌تر.

هدف طراحی: دیتاسنتر. توپولوژی دو طبقه spine/leaf ، مقیاس ۱۰/۲۵/۴۰/۱۰۰ گیگ و بالاتر، قابلیت‌هایی مثل vPC ، VXLAN EVPN ، segment routing در نسخه‌های جدید، و برنامه‌پذیری با NX-API ، Python ، Bash و Guest Shell. اگر دفتر بیست‌نفره دارید، Nexus اشتباه خرید است؛ اگر اتاق سرور با چند قفس سرور و نیاز east-west دارید، NX-OS همان زبانی است که باید بلد باشید.

معماری NX-OS ؛ ماژولار، Linux ، پروسس ایزوله

قلب تفاوت NX-OS با IOS کلاسیک همین‌جاست. طبق مستند DevNet Open NX-OS Modular Architecture و اسلایدهای رسمی Cisco Live (BRKDCN-2958):

• کرنل Linux چندوظیفه‌ای با Completely Fair Scheduler
• پروتکل‌های روتینگ و سوئیچینگ، امنیت، مدیریت، و حتی بسیاری از درایورها در user space جدا از کرنل
• هر سرویس در فضای حافظه محافظت‌شده؛ کرش BGP کل سوئیچ را نمی‌کشد
• امکان process restart بدون reload کامل؛ حتی restart bgp از CLI
• زیرساخت مشترک: Sysmgr ، PSS (Persistent Storage Service) برای چک‌پوینت state ، و MTS برای پیام بین پروسس‌ها

سیسکو در Fundamentals 10.6 می‌گوید پروسس‌های ماژولار on-demand ساخته می‌شوند؛ فقط وقتی feature را enable کنید منابع می‌گیرند. scheduler بلادرنگ برای توابع حیاتی اولویت می‌گذارد. کارهای سنگین مثل برنامه‌ریزی جدول سخت‌افزار به پردازنده‌های روی ماژول داده می‌شود. این همان جمله‌ای است که در فیلد معنی‌اش این است: روی Nexus ، فیچر خاموش یعنی پروسس و حافظه کمتر؛ روی IOS کلاسیک خیلی وقت‌ها همه‌چیز از اول داخل ایمیج بیدار بود.

سطوح ری‌استارت سرویس را از BRK رسمی این‌طور خلاصه کنید:

نوع	رفتار	مثال ذهنی
Stateful + PSS	state را از PSS برمی‌گرداند	سرویس مدیریتی داخلی
Stateful + Graceful Restart	state را از همسایه‌ها/سرویس‌های دیگر می‌گیرد	پروتکل‌های روتینگ با NSF/GR
Stateless	شروع از صفر	سرویسی که state پایدار ندارد

High Availability ؛ SSO ، ISSU ، NSF

روی شاسی‌های دو سوپروایزر (مثل Nexus 7000 و بعضی مدل‌های 9500)، NX-OS از Stateful Switchover (SSO) استفاده می‌کند: Active و Standby هم‌گام‌اند. خط کارت‌ها با NSF می‌توانند فورواردینگ را نگه دارند تا control plane جابه‌جا شود. تریگر سوئیچ‌اور: سیاست HA (مثلاً چندبار کرش یک کامپوننت)، دستور دستی، یا مسیر ISSU.

ISSU یا In-Service Software Upgrade یعنی آپگرید نرم‌افزار با کمترین قطع data plane. فرمان رایج روی Nexus 9000:

Nexus# install all nxos bootflash:nxos.9.2.3.bin

سیسکو در راهنمای آپگرید صریح می‌گوید install all روش توصیه‌شده است چون سازگاری کانفیگ و BIOS را چک می‌کند؛ فقط عوض کردن boot variable و reload این چک‌ها را دور می‌زند و توصیه نمی‌شود. روی سوئیچ‌های تک‌سوپروایزر، ISSU محدودتر است و بعضی مسیرها disruptive می‌مانند؛ قبل از برنامه downtime جدول پشتیبانی ISSU همان نسخه را از سایت سیسکو بخوانید.

پلتفرم‌ها و use case های NX-OS

خانواده	نقش رایج	نکته
Nexus 9000 (۹۳۰۰ fixed ، ۹۵۰۰ modular)	Leaf / Spine ، ToR ، ACI leaf/spine	جریان اصلی امروز؛ یک ایمیج nxos برای ۹۰۰۰ و بسیاری ۳۰۰۰
Nexus 3000	ToR کم‌تأخیر، تجارت/ HPC در سناریوهای خاص	ایمیج مشترک با مسیر ۹۰۰۰ در بسیاری نسخه‌ها
Nexus 7000 / 7700	هسته شاسی‌دار نسل قبل دیتاسنتر، VDC	هنوز در رک‌های ایران هست؛ kickstart+system در نسل‌های قدیمی
Nexus 5000 / 6000	Access/Aggregation و FCoE در نسل‌های میانی	بسیاری EOL؛ دانش‌شان برای نگهداری هنوز لازم است
MDS 9000 (NX-OS SAN)	Fabric سوئیچ Fibre Channel	خانواده دستور نزدیک، دامنه SAN جدا

VDC (Virtual Device Context) روی Nexus 7000 یعنی چند «سوئیچ منطقی» روی یک شاسی با control plane جدا. برای ادمین شبکه شبیه چند دستگاه است؛ برای سخت‌افزار یک کرنل مشترک. روی ۹۰۰۰ مسیر اصلی مجازی‌سازی شبکه بیشتر VXLAN / VRF / tenant است تا VDC کلاسیک ۷۰۰۰.

vPC (Virtual Port-Channel) یکی از فیچرهای بولد NX-OS است: دو سوئیچ upstream از دید سرور مثل یک Port-Channel واحد دیده می‌شوند، بدون STP blocking کلاسیک روی آن لینک‌ها. در ایران روی ToR و Aggregation دیتاسنتر تقریباً استاندارد شده است. اشتباه رایج: vPC را با StackWise کاتالیست یکی دانستن؛ مدل کنترل و failure domain فرق دارد.

نسخه‌های NX-OS ؛ از ۷k تا ۱۰.x

شماره‌گذاری NX-OS در طول زمان چند نسل داشته است. روی Nexus 7000 مسیر ۷.x کلاسیک بود. روی Nexus 9000 ابتدا شاخه‌های 6.1(2)I و 7.0(3)I آمدند، بعد ۹.x و امروز ۱۰.x (مثلاً 10.4 ، 10.5 ، 10.6 در Fundamentals جاری). برای انتخاب نسخه همیشه Nexus Switch Platform Support Matrix و Release Notes همان PID را چک کنید؛ یک ایمیج روی همه SKU های ۹۰۰۰ لزوماً یکسان رفتار نمی‌کند.

از 9.2(1) به بعد سیسکو Optionality آورد: بسته‌های RPM برای فیچرهای اختیاری. از حدود 10.1 ، ابزار پکیج از YUM به DNF رفت. این یعنی آپگرید دیگر فقط «یک bin بزرگ» نیست؛ می‌توانید بعضی فیچرها را بدون تعویض کل ایمیج مدیریت کنید — با قواعد و محدودیت‌هایی که در راهنمای آپگرید نوشته شده است.

نصب و بوت ایمیج روی دستگاه؛ kickstart ، unified ، base/full

این بخش را با حوصله بخوانید چون سه مفهوم را بازار قاطی می‌کند.

۱) مدل کلاسیک Nexus: kickstart + system

روی نسل‌های قدیمی‌تر (به‌ویژه 7000 و بعضی 5k/6k)، دو فایل می‌دیدید: kickstart (هسته/بوت اولیه) و system (بقیه NX-OS). boot variable ها جدا ست می‌شدند. آپگرید یعنی هر دو را هم‌خوان نگه دارید.

۲) مدل مدرن Nexus 9000: یک فایل nxos.bin

امروز روی ۹۰۰۰ سیسکو می‌گوید نرم‌افزار از یک NXOS image تشکیل شده است. کپی به bootflash ، بعد:

install all nxos bootflash:nxos.10.x.y.bin

یا در سناریوهای خاص تنظیم boot و reload — با آگاهی از اینکه install all امن‌تر است.

۳) Base mode در برابر Full mode (Optionality)

از 9.2(1) می‌توانید NX-OS را در دو حالت بوت کنید (سند Optionality رسمی Nexus 9000):

حالت	چه چیزی داخل است	کاربرد
Full NX-OS mode (پیش‌فرض)	تقریباً همه feature RPM ها هنگام بوت	رفتار آشنای نسخه‌های قبل؛ اکثر سایت‌ها همین را می‌خواهند
Base NX-OS mode	L2/L3 پایه؛ روتینگ داینامیک (BGP، OSPF، EIGRP، ISIS، RIP) و خیلی فیچرهای اختیاری نیستند مگر RPM نصب کنید	تصویر سبک‌تر، کنترل بیشتر روی سطح حمله و حجم

جابه‌جایی با دستورهایی مثل install reset nxos full / مسیر base در VSH انجام می‌شود و معمولاً reload و پاک شدن بخشی از وضعیت را به دنبال دارد؛ قبل از اجرا سند همان نسخه را خط‌به‌خط بخوانید. فشرده‌سازی ایمیج (compact image) هم در همان راهنمای آپگرید برای صرفه‌جویی فضای bootflash آمده است.

۴) Install mode و Bundle mode ؛ این مال IOS XE است

خیلی‌ها Bundle/Install را به NX-OS نسبت می‌دهند. در مستندات رسمی سیسکو، Bundle mode و Install mode اصطلاح Catalyst / IOS XE است:

IOS XE	معنی
Bundle mode	بوت مستقیم از فایل .bin ؛ پکیج‌ها در RAM باز می‌شوند؛ حافظه بیشتر
Install mode (توصیه‌شده)	استخراج به .pkg ها و بوت از packages.conf ؛ RAM کمتر، SMU و قابلیت‌های مدرن

سیسکو حتی اعلام کرده Bundle mode بعد از شاخه‌های جدید IOS XE کنار گذاشته می‌شود. روی Nexus ، معادل ذهنی «یک bin در برابر بسته‌های ماژولار» بیشتر همان unified nxos.bin + RPM optionality است، نه packages.conf کاتالیست. اگر ۹۲۰۰ دارید Install/Bundle بخوانید؛ اگر N9K دارید install all و base/full.

۵) NX-OS mode در برابر ACI mode

همان سخت‌افزار Nexus 9000 می‌تواند در مود NX-OS (CLI کلاسیک دیتاسنتر / VXLAN) یا مود ACI (تحت APIC) کار کند. تبدیل مود یک عملیات برنامه‌ریزی‌شده است و کانفیگ و ایمیج را عوض می‌کند؛ سوئیچ ACI را با ذهنیت «یک Nexus معمولی با VLAN» اداره نکنید.

شباهت NX-OS با IOS

سیسکو عمداً منحنی یادگیری را برای مهندس IOS نرم کرده است:

• حالت‌های EXEC و Configuration و Interface آشناست
• show ، configure terminal ، interface Ethernet1/1 ، no form
• ایده ACL ، VRF ، OSPF/BGP ، Port-Channel
• قابلیت abbreviation و کمک ?

اگر CCNA روی کاتالیست خوانده‌اید، روز اول Nexus گم نمی‌شوید؛ روز سوم است که فرق‌ها درد می‌گیرد.

تفاوت‌ها حتی در سطح دستور

موضوع	IOS / IOS XE تقریبی	NX-OS
فعال‌سازی فیچر	اغلب از اول در ایمیج هست	باید feature … بزنید وگرنه دستورش نیست
نام اینترفیس	GigabitEthernet1/0/1	Ethernet1/1 ، Ethernet1/49 ، port-channel
ذخیره	write memory / copy run start	copy running-config startup-config ؛ عادت‌ها فرق جزئی دارند
فایل سیستم	flash:	bootflash: ، volatile: ، slot0 در پلتفرم‌ها
آپگرید	boot system / install add (XE)	install all nxos …
روتینگ	router ospf 1	بعد از feature ospf ؛ context و دستورات show غنی‌تر برای DC
لایه ۲ پیشرفته DC	StackWise / VSS در کاتالیست	vPC ، FabricPath (قدیمی)، VXLAN
شل لینوکس	Guest Shell در XE	Bash / Guest Shell با RBAC ؛ دسترسی کنترل‌شده به Linux زیرین
API	NETCONF/RESTCONF روی XE	NX-API (JSON/XML روی HTTP(S)) ، علاوه بر مدل‌های جدیدتر
حذف کانفیگ خطرناک	ممکن است بخشی از سرویس بماند	خاموش کردن feature می‌تواند کانفیگ مرتبط را پاک کند؛ قبلش بکاپ

مثال واقعی دستور — بدون feature ، BGP اصلاً وارد کانفیگ نمی‌شود:

N9K(config)# feature bgp
N9K(config)# router bgp 65000
N9K(config-router)# neighbor 192.0.2.2 remote-as 65000
N9K(config-router)# restart bgp 65000

همان restart bgp روی IOS کلاسیک معنی NX-OS را ندارد؛ اینجا پروسس ایزوله را هدف می‌گیرد. روی DevNet نمونه kill پروسس BGP از Bash و برگشت خودکار Sysmgr هم مستند شده است.

مثال vPC (ساده شده):

feature vpc
feature lacp
vpc domain 10
  peer-keepalive destination 10.10.10.2 source 10.10.10.1
interface port-channel10
  vpc peer-link
interface Ethernet1/1
  channel-group 10 mode active

مثال VXLAN — فقط اسکلت ذهنی برای برگ/اسپاین؛ جزئیات nve و BGP EVPN را از کانفیگ گاید همان نسخه بخوانید، چون syntax بین ۹.x و ۱۰.x جابه‌جا شده است.

فیچرهای بولد NX-OS که باید بلد باشید

feature enable مدل: امنیت و منابع را کنترل می‌کند. فیچر خاموش یعنی سطح حمله و پیچیدگی کمتر.

vPC: چندمسیری فعال به سرور/سوئیچ پایین بدون تک‌نقطه شکست کلاسیک STP روی آن لینک.

POAP (PowerOn Auto Provisioning): سوئیچ نو از DHCP/TFTP اسکریپت می‌گیرد و day-0 می‌شود؛ برای ردیف ToR در دیتاسنتر بزرگ حیاتی است. در Fundamentals 10.6 فصل جدا دارد.

NX-API و Bash: اتوماسیون بدون انتظار Expect روی CLI فقط. برای تیمی که Ansible می‌زند، Nexus معمولاً خوش‌دست‌تر از کاتالیست قدیمی است.

Ethanalyzer / SPAN / EEM / GOLD: عیب‌یابی داخل جعبه؛ Ethanalyzer عملاً Wireshark روی control plane سوئیچ است.

Rollback و checkpoint: قبل از تغییر بزرگ، نقطه بازگشت بسازید؛ در دیتاسنتر دست‌کاری بدون rollback یعنی شجاعت بی‌مورد.

SMU / Patch: پچ بدون رفتن به نسخه بعدی؛ برای باگ عملیاتی یا امنیتی انتخابی.

مثال‌های واقعی از فیلد

۱) ToR برای چند قفس سرور: دو Nexus 9300 با vPC به سرورها، uplink به spine. OS: NX-OS full mode. کانفیگ روزمره: VLAN/VXLAN ، HSRP یا anycast GW ، ACL ، monitoring. اینجا Catalyst 9200 PoE جای ToR ۱۰/۲۵گیگ را نمی‌گیرد.

۲) هسته قدیمی با Nexus 7010: هنوز در بعضی سازمان‌ها VDC جدا برای Production و DMZ روی یک شاسی است. آپگرید kickstart/system و ISSU دو سوپروایزر را باید مثل جراحی برنامه‌ریزی کرد.

۳) مهاجرت به ACI: همان leaf سخت‌افزاری، مود ACI، مغز APIC. تیم دیگر CLI leaf را «مال خود» نمی‌داند؛ سیاست از EPG/Contract می‌آید. اگر فقط NX-OS بلد باشید و وارد ACI شوید، باید مدل ذهنی را عوض کنید نه فقط دستور.

۴) اشتباه رایج: کپی ACL و HSRP از کانفیگ 3750 به Nexus بدون feature و بدون درک اینکه اینترفیس‌ها routed یا switched‌اند. نتیجه: دستور قبول نمی‌شود یا رفتار لایه ۲/۳ قاطی می‌شود.

NX-OS را کِی انتخاب کنیم؛ کِی نه

انتخاب کنید اگر: دیتاسنتر یا اتاق سرور جدی دارید، east-west زیاد است، به vPC/VXLAN/اسکیل ۱۰گیگ+ نیاز دارید، یا مسیر ACI در نقشه است.

انتخاب نکنید اگر: فقط Access اداری و PoE و وایرلس می‌خواهید — همان Catalyst + IOS XE. اگر تیم فقط IOS پردیس بلداست و یک Nexus تنها بدون طراحی leaf/spine می‌خرید، پیچیدگی بدون فایده می‌خرید.

منابع مطالعاتی رسمی

• Nexus 9000 NX-OS Fundamentals — Overview
• Open NX-OS Modular Architecture (DevNet)
• Optionality in NX-OS Software (base/full ، RPM)
• Cisco Live BRKDCN-2958 — NX-OS HA (PDF)
• Nexus 7000 HA Overview
• برای Bundle/Install روی کاتالیست: Upgrade Guide for Catalyst 9000
• مسیر مهارت اتوماسیون شبکه در عصر تازه مدارک سیسکو

جمع‌بندی آشنایی با سیسکو NX-OS

Cisco NX-OS سیستم‌عامل دیتاسنتر سیسکو است؛ نه جایگزین IOS XE روی کاتالیست پردیس، نه IOS XR اپراتور. از IOS monolithic فاصله گرفته: Linux ، پروسس ایزوله، feature on-demand ، PSS/MTS ، ISSU و SSO. روی ۹۰۰۰ ایمیج واحد nxos.bin و آپگرید با install all ؛ از 9.2 به بعد base/full و RPM. Install/Bundle را با کاتالیست قاطی نکنید. اگر CLI کاتالیست بلداید، نصف راه را آمده‌اید؛ نصف دیگر feature ، vPC ، VXLAN و عادت bootflash است. برای کار عملی بعد از تئوری، دسته آموزش کانفیگ و پیاده‌سازی و مطالب SDN و سوئیچ‌های ۹۰۰۰ روی شاکه همان مسیر رک است.