Zatwierdzony przez Cisco system SONiC tworzy nową opcję systemu operacyjnego dla wybranych wdrożeń Cisco Nexus 9000. Jest on przeznaczony dla organizacji, które potrzebują natywnych dla systemu Linux operacji, automatyzacji i skalowalnej sieci w środowiskach webowych, sztucznej inteligencji, neocloud i centrów danych o wysokiej gęstości. Kluczowa decyzja nie polega jedynie na tym, czy sprzęt ma porty 100G czy 400G. Projekt musi również potwierdzić dokładną kwalifikację sprzętu, wersję oprogramowania, wymagane funkcje i model długoterminowego wsparcia.
- Dlaczego klasyfikacja Cloud Scale nie jest wystarczająca
- Wybór modelu operacyjnego dla projektu
- Kontrole sprzętu, oprogramowania, optyki i wsparcia
- Planowanie konfiguracji, architektury i walidacji
- Założenia, które mogą stwarzać ryzyko wdrożenia
- Odpowiedzi na często zadawane pytania dotyczące Cisco Nexus SONiC
- Praktyczna zasada kwalifikacji SONiC
Co Cisco potwierdziło w sprawie SONiC na Nexusie 9000
Ogłoszenie firmy Cisco z października 2026 r. potwierdziło, że SONiC jest opcją dla wdrożeń otwartych sieci, które wymagają operacji opartych na systemie Linux, automatyzacji i architektury skalowalnej.
Ogłoszony zakres koncentruje się na wdrożeniach o wysokiej gęstości 100G i 400G typu „leaf-spine” z wykorzystaniem przełączników Cisco Nexus 9000 z krzemem Cloud Scale. Cisco opisuje również przypadki użycia w środowiskach korporacyjnych, internetowych, sztucznej inteligencji i neocloud.
- Sieci centrów danych o wysokiej gęstości 100G i 400G
- Środowiska Leaf-Spine na skalę przedsiębiorstwa i sieci
- Obciążenia sztucznej inteligencji i centrów danych o wysokiej przepustowości
- Wstępnie skompilowane i zabezpieczone oprogramowanie SONiC
- Wsparcie Cisco w zakresie sprzętu, NOS, SAI, FRR i skompilowanego stosu SONiC
Różni się to od instalacji obrazu SONiC społecznościowego na kompatybilnym przełączniku. SONiC zatwierdzony przez Cisco odnosi się do zdefiniowanego pakietu oprogramowania i modelu wsparcia. Dokładny sprzęt i kwalifikacja wersji nadal muszą zostać sprawdzone dla każdego projektu.
Aby zapoznać się z oryginalnym ogłoszeniem, zobacz oficjalny artykuł firmy Cisco na stronie SONiC zatwierdzony przez Cisco na N9000.
Czy N9K-C93180YC-FX3 obsługuje SONiC?
Praktyczna odpowiedź brzmi: przed zakupem lub migracją należy potwierdzić obsługę technologii SONiC.
N9K-C93180YC-FX3 to przełącznik Cisco Cloud Scale Nexus 9000 przeznaczony do wdrożeń w centrach danych o dużej gęstości. Jego opublikowana konfiguracja sprzętowa obejmuje:
- 48 portów 1/10/25G SFP28
- 6 portów QSFP28 40/100G
- Przepustowość przełączania 3.6 Tbps
- Wydajność przekazywania 1.2 Bpps
Te specyfikacje czynią platformę odpowiednią do planowania rozwiązań Leaf-Spine 100G i 400G. Klasyfikacja rodziny produktów nie jest jednak tym samym, co kwalifikacja systemu operacyjnego.
Karta katalogowa Cisco N9300-FX3 potwierdza informacje dotyczące działania NX-OS i ACI, ale nie gwarantuje, że każdy model FX3 jest obsługiwany przez SONiC zatwierdzony przez Cisco. Dokładny identyfikator PID i docelową wersję SONiC należy zatem sprawdzić w odpowiedniej dokumentacji pomocy technicznej Cisco.
Oficjalna Karta danych Cisco N9300-FX3 powinna być używana do weryfikacji sprzętu, ale nie powinna być traktowana jako kompletna macierz kwalifikacji SONiC.
Jeśli oceniasz ten model pod kątem SONiC, podaj dokładny PID, wersję docelową, plan portu, modele optyczne, wymagane funkcje i wymagania dotyczące wsparcia, zanim poprosisz o potwierdzenie.
SONiC kontra NX-OS kontra ACI
Wybór SONiC powinien być dokonywany na podstawie modelu operacyjnego i obciążenia, a nie tylko prędkości portu czy przepustowości przełączania. Przegląd modelu operacyjnego Cisco Nexus 9000 stanowi przydatny punkt wyjścia do zrozumienia istniejących opcji NX-OS i ACI.
| Option | Najlepiej dopasowana | Główna uwaga |
|---|---|---|
| NX-OS | Tradycyjne centra danych Nexus, VXLAN EVPN i istniejące zespoły operacyjne Cisco | Zwykle wiąże się z mniejszą liczbą zmian operacyjnych, gdy środowisko już korzysta z NX-OS |
| ACI | Struktury oparte na zasadach zarządzane za pośrednictwem APIC lub Nexus Dashboard | Wymaga modelu infrastruktury ACI i scentralizowanej architektury zasad |
| Zweryfikowany SONiC | Środowiska automatyzacji w skali sieci Web, AI, neocloud i Linux | Wymaga innego systemu operacyjnego (NOS), łańcucha narzędzi i operacyjnego przepływu pracy |
Kiedy NX-OS jest lepszym wyborem
NX-OS jest zazwyczaj najbardziej praktycznym wyborem, gdy organizacja już korzysta z przepływów pracy Nexus CLI i NX-API, projektów VXLAN EVPN, wdrożeń dual-leaf opartych na vPC, monitorowania specyficznego dla Cisco i ustalonych procedur Cisco TAC.
W takich środowiskach przejście na SONiC może wprowadzić więcej zmian operacyjnych niż oczekiwano. Porty fizyczne mogą pozostać takie same, ale model konfiguracji, telemetria, narzędzia automatyzacji, proces rozwiązywania problemów i przepływ pracy wsparcia mogą ulec zmianie.
Kiedy ACI jest lepszym wyborem
Technologia ACI jest bardziej odpowiednia, gdy projekt wymaga scentralizowanego zarządzania polityką, operacji opartych na strukturze APIC, polityki sieciowej zorientowanej na aplikacje oraz zintegrowanego zarządzania dzierżawcami, VRF i punktami końcowymi.
SONiC nie oferuje bezpośredniego zamiennika modelu polityki ACI. Migrację z ACI do SONiC należy zatem traktować jako przeprojektowanie architektury, a nie wymianę oprogramowania.
Kiedy SONiC może być lepszym wyborem
Zatwierdzone przez Cisco rozwiązanie SONiC może okazać się lepszym rozwiązaniem, gdy organizacja dysponuje zespołami inżynierów sieciowych pracującymi na systemie Linux, modelem wdrażania nastawionym na automatyzację, rozbudowaną infrastrukturą Leaf-Spine lub AI, ujednoliconymi procesami konfiguracji oraz wymaga otwartych interfejsów sieciowych.
Kompromisem jest to, że zespół inżynierów musi potwierdzić obsługę funkcji, narzędzia wdrożeniowe, monitorowanie i procedury eskalacji przed zaangażowaniem się w platformę.
Co należy sprawdzić przed zakupem
Zapytanie ofertowe powinno zawierać nie tylko stwierdzenie „Cisco Nexus 9000 z SONiC”, ale także listę kontrolną kwalifikacji sprzętu i oprogramowania.
Kwalifikacja sprzętu i układów ASIC
- Dokładny identyfikator PID Cisco i wersja sprzętu, jeśli ma to zastosowanie
- ASIC lub rodzina układów krzemowych
- Typ portu i możliwość rozdzielenia portu
- Obsługiwane tryby 100G i 400G
- Zachowanie bufora i funkcje zarządzania przeciążeniem
- Kierunek przepływu powietrza i konfiguracja zasilania
NOS i kwalifikacja funkcji
Sprawdź, czy docelowa wersja SONiC obsługuje funkcje wymagane przez projekt:
- BGP
- EVPN i VXLAN
- MLAG lub wybrany projekt z podwójnym przełącznikiem
- PFC i ECN
- Funkcje związane z RoCE
- QoS i planowanie kolejek
- Wyjście z portu
- Dane telemetryczne i strumieniowe
- Interfejsy automatyzacji
- Procedury aktualizacji i przywracania
Nie należy zakładać, że funkcja dostępna w systemie NX-OS jest implementowana, konfigurowana lub obsługiwana w ten sam sposób w systemie SONiC.
Optyka, okablowanie i wsparcie
Sprawdź modele transceiverów 100G i 400G, zgodność z DAC i AOC, obsługę kabli rozdzielających, typ światłowodu, wymagania FEC, widoczność DOM i współdziałanie z podłączonym serwerem lub przełącznikiem.
Wniosek o pomoc techniczną powinien również określać obraz SONiC, obsługiwany identyfikator sprzętu, kombinację wersji, zakres działania Cisco TAC, dostęp do aktualizacji oprogramowania, zakres wymiany sprzętu oraz granice eskalacji pomiędzy Cisco, dostawcą systemu NOS i integratorem.
Wyślij dokładny PID, wersję docelową, plan portu, optykę i wymagane funkcje.
Planowanie migracji z NX-OS lub ACI
Migracji do SONiC nie należy traktować jako zwykłej aktualizacji obrazu oprogramowania.
NX-OS do SONiC
Przełącznik Nexus może zachować te same porty fizyczne i okablowanie, ale może zaistnieć konieczność przeprojektowania następujących elementów:
- Konfiguracja interfejsu
- Definicje VLAN i VRF
- Konfiguracja BGP i EVPN
- Konstrukcja MLAG lub dual-homing
- Zasady QoS i buforowania
- Monitorowanie i telemetria
- Zarządzanie automatyzacją i konfiguracją
- Procedury tworzenia kopii zapasowych i przywracania
Istniejącą konfigurację NX-OS należy wykorzystać jako źródło informacji projektowych. Nie należy zakładać, że da się ją bezpośrednio zaimportować do SONiC.
ACI do SONiC
Migracja ACI jest zazwyczaj bardziej znacząca, ponieważ ACI korzysta z modelu polityki i struktury zarządzanego przez APIC. Zespół ds. migracji może być zmuszony do przeprojektowania dzierżawców, sieci VRF, domen mostowych, grup punktów końcowych, kontraktów, routingu zewnętrznego i monitorowania operacyjnego.
Jeśli wdrożenie wykorzystuje dwa przełączniki Nexus, należy sprawdzić istniejące Wskazówki dotyczące konfiguracji i rozwiązywania problemów z komputerem vPC N9K-C93180YC-FX3 w ramach oceny stanu obecnego. Nie potwierdza to zgodności funkcji SONiC, ale pomaga zidentyfikować istniejące wymagania dotyczące redundancji i obsługi awarii.
Zalecana sekwencja walidacji
- Potwierdź dokładny PID sprzętu i docelową wersję SONiC.
- Sprawdź wymagane funkcje w odpowiedniej dokumentacji pomocy technicznej Cisco.
- Zbuduj małe laboratorium wykorzystując zamierzoną optykę i okablowanie.
- Przetestuj płaszczyznę sterowania i płaszczyznę danych osobno.
- Sprawdź poprawność przełączania awaryjnego, konwergencji routingu, QoS i telemetrii.
- Potwierdź monitorowanie i automatyzację przepływów pracy.
- Przywrócenie dokumentu do poprzedniej wersji systemu operacyjnego lub projektu.
- Uzyskaj ostateczne potwierdzenie wsparcia przed wdrożeniem produkcyjnym.
Do celów instalacji fizycznej, przepływu powietrza, zasilania i początkowej kontroli rozmieszczenia należy użyć Instrukcja instalacji i konfiguracji N9K-C93180YC-FX3 wraz z odpowiednią dokumentacją sprzętową Cisco.
Typowe błędy w zamówieniach publicznych
Kilka założeń może później stwarzać problemy:
- Zakładając, że każdy Cloud Scale N9000 obsługuje SONiC
- Traktowanie obrazu SONiC społecznościowego jako równoważnego z obrazem SONiC zatwierdzonym przez Cisco
- Zakładając, że konfigurację NX-OS można skopiować bezpośrednio do SONiC
- Wybór optyki wyłącznie na podstawie prędkości i typu złącza
- Ignorowanie wymagań FEC, wyłamania lub pasa
- Potwierdzenie obsługi sprzętu bez potwierdzenia wydania oprogramowania
- Porównywanie wyłącznie ceny przełącznika, ignorując obsługę NOS i prace migracyjne
- Traktowanie migracji ACI-do-SONiC jako prostej zmiany systemu operacyjnego
Ryzyko to jest łatwiejsze do kontrolowania, gdy PID sprzętu, obraz oprogramowania, wymagania funkcjonalne, optyka i model wsparcia są analizowane łącznie.
Najczęściej zadawane pytania
Ostateczne jedzenie na wynos
Zatwierdzone przez Cisco rozwiązanie SONiC tworzy nową opcję systemu operacyjnego dla wybranych wdrożeń Nexus 9000 Cloud Scale, w szczególności w środowiskach o dużej gęstości 100G/400G leaf-spine, AI, web-scale i neocloud.
Ważna zasada zamówień jest prosta: nie traktuj „Skala w chmurze” jako automatycznego dowodu kwalifikacji SONiC. Przed zamówieniem lub zaplanowaniem migracji sprawdź dokładny identyfikator PID urządzenia N9000, wersję oprogramowania, wymagania funkcjonalne, optykę i zakres wsparcia Cisco.
W przypadku modelu takiego jak N9K-C93180YC-FX3 kolejnym krokiem jest przesłanie dokładnych informacji o sprzęcie i wdrożeniu w celu przeprowadzenia kontroli zgodności konkretnego modelu.