IP Infusion vs Cisco Nexus, NCS e 8000: un confronto tecnico

Piattaforma per piattaforma, silicio per silicio: come i router e gli switch di IP Infusion si collocano rispetto a Cisco Nexus, NCS, alla serie Cisco 8000 e ad ACI, e che cosa cambia in termini di licenze, CLI e operatività in caso di migrazione.

Come sono costruiti i due approcci

Un router o uno switch è costruito con gli stessi livelli in entrambi i casi. Ciò che cambia è chi fornisce ciascun livello. Con IP Infusion ogni livello viene acquistato separatamente e il risultato viene consegnato come un unico sistema.

IP InfusionApprovvigionati separatamente, consegnati come un unico sistema
HardwareEdgecore, UfiSpace, Celestica
NOSOcNOS-SP o OcNOS-DC
CLIUn'unica CLI standard di settore su SP, DC e AI fabric
OttichePiù fornitori, inclusi 400G ZR e ZR+
SupportoIP Infusion: un contratto di supporto e un percorso RMA

Fornitori diversi per ogni livello, con qualifica congiunta di IP Infusion e consegna come un unico prodotto, con un contratto di supporto e un percorso RMA.

CiscoApprovvigionati e consegnati come un unico stack
HardwareCisco
NOSCisco IOS-XR o NX-OS
CLIIOS-XR CLI on NCS and Cisco 8000, NX-OS CLI on Nexus
OtticheCisco
SupportoCisco TAC

Cisco fornisce l'hardware, il sistema operativo di rete, le ottiche e il supporto.

In sintesi

DimensioneIP Infusion (OcNOS)Cisco (IOS-XR / NX-OS)
Che cosa si acquistaIl router o lo switch finito: hardware aperto, OcNOS, ottica e supporto come un unico sistema. Oppure OcNOS da solo, per l'hardware che utilizza già.Il router o lo switch finito: hardware Cisco, il NOS e il supporto da un unico vendor.
HardwarePiattaforme aperte di Edgecore, UfiSpace e Celestica. Un unico modello operativo OcNOS su tutte.Sistemi a marchio Cisco.
SilicioMerchant silicon Broadcom: Qumran e Jericho per il routing, Trident e Tomahawk per lo switching.Cisco Silicon One nei Cisco 8000 e nel Nexus 9364E-SG2, Cloud Scale nei Nexus 9300-FX2 e FX3. Cisco indica ASIC della famiglia Jericho per i router fissi NCS 5500 e NCS 5700.
Sistema operativoOcNOS-SP per il routing dei service provider, OcNOS-DC per il data center, ciascuno venduto in edizioni.IOS-XR sui router NCS e Cisco 8000, NX-OS sugli switch Nexus.
LicenzeConcesso in licenza separatamente dall'hardware, per edizione, con una licenza d'uso perpetua.IOS-XR: un Flexible Consumption Model con sottoscrizioni a termine e Smart Licensing, oppure un modello perpetuo sui Cisco 8000, NCS 540 e NCS 560.
ApprovvigionamentoHardware e software si acquistano separatamente, così le piattaforme possono essere messe in concorrenza tra diversi ODM.Hardware, software e supporto provengono da Cisco.
ProtocolliBGP, OSPF, IS-IS, MPLS, SR-MPLS, EVPN-VXLAN, RSVP-TE, IEEE 1588v2. Supporto iniziale per SRv6 su router selezionati, con altri in sviluppo. Dettaglio per piattaforma nella Feature Matrix.Per piattaforma, nei data sheet Cisco.
OttichePluggable multi-vendor con interoperabilità comprovata, inclusa l'ottica coerente 400G ZR e ZR+ sulle piattaforme supportate.Ottiche Cisco, elencate per piattaforma.
GestioneCLI transazionale standard di settore con commit esplicito. NETCONF, OpenConfig, gNMI, YANG, Ansible, IP Maestro EMS.Interfacce a riga di comando di IOS-XR e NX-OS.
SupportoPer un OcNOS System, un contratto di supporto e un percorso RMA da IP Infusion coprono software e hardware. Per l'hardware che comprate voi stessi, il produttore supporta l'hardware.Cisco TAC per hardware e software.

Cosa cambia con IP Infusion

IP Infusion cambia il modo in cui la rete viene acquistata e supportata. Il passaggio da Cisco è pianificato in tre fasi.

Cosa vi offre IP Infusion
  • Licenze per edizione. OcNOS è concesso in licenza separatamente dall'hardware, in edizioni, con una licenza d'uso perpetua.
  • Hardware da mettere in concorrenza. OcNOS gira su piattaforme in merchant silicon di Edgecore, UfiSpace e Celestica, così il box può essere messo a gara senza cambiare il sistema operativo di rete.
  • Livelli che restano separabili. Hardware, software e ottica si acquistano ciascuno per i propri meriti, così un cambio di fornitore su uno non impone un cambio sugli altri.
  • Ottica multi-vendor. Pluggable con interoperabilità comprovata da più fornitori, inclusi i coerenti 400G ZR e ZR+ per IPoDWDM e DCI.
  • Supporto da un unico team. Per un OcNOS System, IP Infusion supporta sia il software sia l'hardware, con un unico contratto e un unico percorso RMA. Per l'hardware che comprate voi stessi, il produttore supporta l'hardware.
Cosa comporta il passaggio
  • Valutazione. La configurazione IOS-XR o NX-OS attuale, il mix di porte e l'uso delle funzioni vengono verificati rispetto alla Feature Matrix e alla Hardware Compatibility List.
  • Traduzione. La sintassi dei comandi OcNOS differisce da quella di IOS-XR e NX-OS, quindi la configurazione viene mappata e rivista anziché copiata riga per riga.
  • Revisione del progetto per ACI. Il modello di policy APIC non si trasferisce uno a uno su una fabric BGP-EVPN-VXLAN, quindi una fabric ACI viene riprogettata anziché sostituita.

Un unico modello operativo per service provider, data center e AI fabric

OcNOS offre la stessa riga di comando standard di settore e lo stesso modello operativo nel routing service provider, nella fabric EVPN-VXLAN del data center e nello spine della AI fabric con RoCEv2, nelle famiglie OcNOS-SP e OcNOS-DC. Cisco esegue questi ruoli su due sistemi operativi, IOS-XR e NX-OS.

Routing per service provider

OcNOS-SP offre BGP, IS-IS, OSPF, SR-MPLS ed EVPN-MPLS con sincronizzazione IEEE 1588v2 su piattaforme Broadcom Qumran e Jericho. Su Cisco questo ruolo è svolto da IOS-XR.

fabric di data center

OcNOS-DC esegue un leaf-spine BGP-EVPN-VXLAN con le primitive di overlay standard, su leaf Broadcom Trident-3 e spine Tomahawk. Su Cisco questo ruolo è svolto da NX-OS.

fabric AI

OcNOS-DC aggiunge PFC ed ECN per il traffico RoCEv2 lossless su spine Broadcom Tomahawk-5 a 800G per le fabric di cluster GPU. Il Cisco 800G Nexus 9364E-SG2 esegue NX-OS.

Con IP Infusion la stessa riga di comando e gli stessi schemi di configurazione si applicano a tutti e tre i ruoli. Su Cisco, il routing service provider e di core è svolto da IOS-XR e il data center da NX-OS, ciascuno con la propria riga di comando.

Piattaforma per piattaforma: router service provider

Le righe sono abbinate per ruolo, profilo di porte e capacità, non SKU per SKU. Ogni riga abbina una piattaforma Cisco al suo equivalente IP Infusion, il profilo di porte, il confronto di capacità e il livello di corrispondenza. Dove una piattaforma non raggiunge la capacità, la riga lo indica e nomina la combinazione che la raggiunge.

Ruolo, porte e capacità coincidono Stessa classe di capacità Revisione progettuale
Piattaforma Cisco Equivalente IP Infusion Porte Capacità Corrispondenza Note
Cisco NCS 540 (N540-24Z8Q2C)Accesso / aggregazione · IOS-XR S9510-28DC / AS7535-28XBOcNOS-SP 24×10G + 8×25G + 2×100G → 24×25G + 2×100G + 2×400G Totale porte 640G → 800G Corrispondenza di ruolo e capacità Cisco non pubblica l'ASIC di forwarding dell'NCS 540, perciò questa riga è abbinata per ruolo, profilo di porte e capacità anziché per silicio.
Cisco NCS 5500 / 5700Aggregazione / provider edge · IOS-XR S9600-64X / 56DX / AS9947-36XKBOcNOS-SP 24×100G + 6×400G → 48×100G + 8×400G 3.6T-4.8T → 4.8T-7.2T Stessa classe di capacità Per un NCS-57B1 da 6×400G + 24×100G, la forma di porte più vicina è l'S9600-56DX con 8×400G + 48×100G. Route scale and port mix are compared per deployment.
Cisco 8201-32FHCore / peering · Cisco 8000 · Cisco Silicon One S9610-36DOcNOS-SP 32×400G → 36×400G 12.8T → 14.4T Silicio diverso Le architetture di silicon sono diverse, quindi la scala FIB/RIB e la profondità dello stack di etichette vengono confrontate per ciascun deployment anziché date per scontate.

Piattaforma per piattaforma: switch di data center

OcNOS-DC su hardware aperto Broadcom: leaf EVPN-VXLAN su Trident-3, spine IP su Tomahawk.

Piattaforma Cisco Equivalente IP Infusion Porte Capacità Corrispondenza Note
Cisco Nexus 93180YC-FX3Leaf 25G · NX-OS · Cloud Scale AS7326-56XOcNOS-DC 48×25G + 6×100G → 48×25G + 8×100G 1.8T → 2.0T (unidirezionale) Corrispondenza porta per porta Sono supportati BGP-EVPN-VXLAN, MAC-VRF e le primitive di overlay standard.
Cisco Nexus 9336C-FX2Leaf / spine 100G · NX-OS · Cloud Scale AS7726-32X / S9110-32XOcNOS-DC 36×100G → 32×100G 3.6T → 3.2T (unidirezionale) Stessa classe 100G Quattro porte 100G in meno rispetto al 9336C-FX2, quindi per una fabric ampia il numero di porte va verificato rispetto al design.
Cisco Nexus 9332D-GX2B400G leaf / spine · NX-OS AS9716-32D / AS9736-64DOcNOS-DC 32×400G → 32 o 64×400G 12.8T → 12.8 o 25.6T Stessa classe 400G La Feature Matrix elenca EVPN-VXLAN sulle piattaforme Trident-3, non su queste piattaforme Tomahawk, quindi si adattano al ruolo di spine IP di una fabric EVPN-VXLAN.
Cisco Nexus 9364E-SG2800G spine · NX-OS · Cisco Silicon One G200 AIS800-64D / S9321-64EOcNOS-DC 64×800G → 64×800G 51.2T → 51.2T Silicio di vendor diverso 64×800G su entrambi i lati, su silicon di vendor diversi. Le piattaforme Tomahawk-5 supportano PFC, ECN ed ECN dinamico per il traffico della AI fabric RoCEv2.
Cisco ACI / APICFabric DC basata su controller Leaf-spine EVPN-VXLANOcNOS-DC n/a Per design della fabric Revisione progettuale Entrambi usano VXLAN nella fabric. ACI lo abbina a IS-IS, COOP e al modello di policy APIC, quindi il passaggio è definito come una revisione del progetto anziché come una sostituzione.

Come leggere queste voci. Le righe sono abbinate per ruolo, profilo di porte e capacità. La capacità è espressa nello stesso modo su entrambi i lati: dove Cisco pubblica la capacità di switching dei Nexus in forma bidirezionale, il valore qui è dimezzato per confrontarlo con i valori unidirezionali pubblicati da Edgecore e UfiSpace. Il silicon è indicato solo dove lo indica il vendor; Cisco non pubblica l'ASIC di forwarding dell'NCS 540 né del Nexus 9332D-GX2B. Nessuno SKU è presentato come sostituto uno a uno garantito, e la piattaforma giusta per la vostra rete dipende ancora dal suo mix di porte, dalla scala e dal set di funzioni. Le specifiche riflettono le informazioni documentate pubblicamente a ottobre 2026.

Fonti Cisco per i dati di questa pagina:

Le piattaforme che IP Infusion fornisce per questi ruoli

Un insieme rappresentativo per i ruoli qui sopra. Aprite una scheda qualsiasi per il datasheet della piattaforma:

Consultate l'elenco completo delle piattaforme qualificate nella Hardware Compatibility List.

Ruoli coperti da IP Infusion

Aggregazione metro & edge per service provider

SR-MPLS, EVPN-MPLS e sincronizzazione G.8273.2 Class C su piattaforme Broadcom Qumran e Jericho, per i ruoli di accesso e aggregazione svolti dai Cisco NCS 540 e NCS 5500.

leaf-spine EVPN-VXLAN di data center

Una fabric BGP-EVPN-VXLAN con leaf Trident-3 e spine IP Tomahawk, le primitive di overlay standard (MAC-VRF, rotte type-2 e type-5) e nessun controller centrale.

spine di data center 400G e 800G

Spine ad alta densità di porte su Broadcom Tomahawk-4 (400G) e Tomahawk-5 (800G), con PFC ed ECN per il traffico lossless della AI fabric RoCEv2.

IPoDWDM e DCI coerente 400G

Pluggable coerenti 400G ZR e OpenZR+ su router OcNOS-SP supportati, con interoperabilità comprovata con ottiche di più vendor, per il DCI senza transponder separati.

Gli operatori che hanno fatto il passo

Storie cliente pubblicate in cui gli apparati Cisco sono stati sostituiti, con la motivazione indicata da ciascun operatore:

Un percorso di migrazione a fasi

Valutazione e laboratorio

Rilevate la configurazione IOS-XR / NX-OS attuale, la combinazione di porte e l'utilizzo delle funzionalità; mappate le piattaforme sulle classi indicate sopra e selezionate le edizioni di OcNOS e l'hardware della HCL.

Settimana 1

Pilota e parità

Eseguite un pilot dual-homed, verificate la parità di protocollo e timing, traducete le route-policy e la configurazione EVPN, e trasmettete la telemetria OpenConfig al vostro collector esistente.

Settimana 4

Cutover progressivo

Effettuate il cutover regione per regione, con un chiaro percorso di rollback, mantenendo per tutto il processo lo stesso data plane basato su standard e lo stesso modello operativo.

Settimana 12

Dove si colloca IP Infusion

IP Infusion compete sul modo in cui la rete viene acquistata: hardware con merchant silicon che può essere messo a gara tra più ODM, OcNOS concesso in licenza per edizione separatamente dal box con una licenza d'uso perpetua e ottiche di più di un fornitore, consegnato come router o switch completo qualificato nella HCL.

Cisco, IOS-XR, IOS-XE, NX-OS, Silicon One, Nexus, Catalyst, NCS, Cisco 8000, ACI e APIC sono marchi di Cisco Systems, Inc. Broadcom e i nomi dei suoi prodotti sono marchi di Broadcom Inc. Tutti gli altri marchi sono di proprietà dei rispettivi titolari. IP Infusion non è affiliata a Cisco Systems, né da essa approvata o sponsorizzata. I confronti riflettono le specifiche documentate pubblicamente a ottobre 2026 e sono forniti solo a scopo di valutazione.

Domande frequenti

IP Infusion vende switch e router completi, o solo il software OcNOS?
Entrambi. L'offerta principale è il prodotto completo: un router o switch carrier-grade con OcNOS preinstallato su hardware aperto, più le ottiche e il contratto di supporto, consegnato come un unico sistema e qualificato nella Hardware Compatibility List. Se utilizzate già hardware aperto, potete acquistare la licenza di OcNOS separatamente per quell'hardware. Poiché hardware, software e ottiche restano separabili, potete cambiarne uno in seguito senza sostituire gli altri.
IP Infusion è un'alternativa a Cisco?
Sì. IP Infusion fornisce router e switch per gli stessi ruoli service provider e data center coperti da Cisco, costruiti su piattaforme aperte in merchant silicon Broadcom, con il sistema operativo di rete commerciale OcNOS, supporto del vendor e SLA. La differenza pratica sta nell'approvvigionamento: l'hardware viene messo in concorrenza tra diversi ODM e il software è licenziato separatamente da esso.
OcNOS può sostituire Cisco IOS-XR per il routing service provider?
OcNOS-SP offre BGP, IS-IS, OSPF, MPLS, SR-MPLS, RSVP-TE, L2VPN e L3VPN, QoS e sincronizzazione IEEE 1588v2, con supporto iniziale per SRv6 su router selezionati e altri in sviluppo. Se una specifica piattaforma Cisco corrisponda uno a uno dipende dal mix di porte, dalla scala e dall'uso delle funzioni, quindi un passaggio in produzione viene verificato in una valutazione di engineering IP Infusion rispetto alla Feature Matrix e alla Hardware Compatibility List.
Qual è la differenza tra OcNOS e Cisco NX-OS nel data center?
OcNOS-DC esegue fabric leaf-spine BGP-EVPN-VXLAN su piattaforme aperte Broadcom Trident e Tomahawk di più produttori. NX-OS gira su hardware Cisco Nexus. La differenza è il modello hardware: con OcNOS-DC lo switch può essere acquistato da più di un produttore senza cambiare il sistema operativo di rete.
OcNOS funziona sullo stesso silicon di Cisco?
In parte. OcNOS si basa su merchant silicon Broadcom (Qumran, Jericho, Trident, Tomahawk). Cisco usa i propri ASIC Silicon One nei Cisco 8000 e nel Nexus 9364E-SG2 e la tecnologia Cloud Scale nei Nexus 9300-FX2 e FX3, e indica ASIC della famiglia Jericho per i router fissi NCS 5500 e NCS 5700, tra cui un singolo ASIC Jericho 2 da 4.8 Tbps nell'NCS-57B1.
Esiste un equivalente OcNOS del Cisco Nexus 9300?
Per il ruolo di leaf del data center, OcNOS-DC gira su piattaforme Broadcom Trident-3 (ad esempio uno switch Edgecore 48×25G con uplink a 100G) con BGP-EVPN-VXLAN, MAC-VRF e le primitive di overlay standard. La corrispondenza esatta dipende dal profilo di porte e uplink, che la valutazione mappa rispetto alla Hardware Compatibility List.
OcNOS può sostituire una fabric EVPN-VXLAN di Cisco ACI?
Cisco ACI è una fabric basata su controller gestita dall'APIC, in cui tutto il traffico della fabric è trasportato come VXLAN, con IS-IS e COOP per il forwarding degli endpoint. OcNOS-DC esegue un leaf-spine BGP-EVPN-VXLAN su hardware aperto senza controller centrale. Entrambi usano VXLAN, ma il modello di policy APIC non corrisponde funzione per funzione, quindi il passaggio è definito come una revisione del progetto anziché come una sostituzione.
Qual è l'alternativa OcNOS alle serie Cisco 8000 o NCS per il core SP?
OcNOS-SP gira sulla famiglia UfiSpace S9600 (Broadcom Qumran-2C), sull'S9610-36D (Jericho2C+) e sull'Edgecore AS9947-36XKB (Jericho2C+) per aggregazione, core e peering, e su router Qumran-2A per il ruolo di accesso dell'NCS 540. Il silicon è diverso da Cisco Silicon One e dal Jericho 2 che Cisco indica per l'NCS-57B1, quindi scala FIB/RIB, profondità dello stack di etichette e mix di porte vengono confrontati per ciascun deployment.
Come si mappano i comandi Cisco IOS-XR e NX-OS su OcNOS?
OcNOS usa una riga di comando standard di settore di tipo transazionale, con commit e rollback espliciti. La sintassi dei comandi differisce da quella di IOS-XR e NX-OS, quindi una migrazione utilizza una mappatura dei comandi e una fase di traduzione rivista anziché una copia riga per riga.
Un solo team può gestire service provider, data center e AI fabric con IP Infusion?
Sì. OcNOS usa la stessa riga di comando standard di settore e lo stesso modello operativo nel routing service provider con OcNOS-SP e nella fabric EVPN-VXLAN del data center e negli spine della AI fabric RoCEv2 con OcNOS-DC, quindi gli stessi schemi di configurazione e gli stessi strumenti valgono per tutti e tre i ruoli. Su Cisco questi ruoli sono svolti da due sistemi operativi: IOS-XR sui router NCS e Cisco 8000, e NX-OS sugli switch Nexus.
OcNOS è supportato come lo è Cisco?
Sì. OcNOS è un prodotto commerciale con SLA e un'organizzazione di supporto globale alle spalle, non un progetto di community. Acquistando un OcNOS System, IP Infusion supporta software e hardware con un unico contratto e un unico percorso RMA. Per l'hardware che comprate voi stessi, IP Infusion supporta il software e il produttore dell'hardware supporta l'hardware.
Da quanto tempo IP Infusion sviluppa software per sistemi operativi di rete?
Dalla fine degli anni Novanta. OcNOS si basa su ZebOS, lo stack di routing embedded commerciale che IP Infusion sviluppa e distribuisce da oltre due decenni e che ha concesso in licenza come software di routing in tutto il settore del networking e della sicurezza. La sua discendenza di routing risale al progetto di routing Zebra, nato per iniziativa dei fondatori di IP Infusion. OcNOS-SP e OcNOS-DC sono i sistemi operativi carrier-grade costruiti su quella base di codice, per cui lo stack di protocolli che li sostiene porta con sé una lunga esperienza sul campo e non recente.
OcNOS è abbastanza collaudato per una rete di operatore o di data center in produzione?
Sì. OcNOS gira in reti di produzione di service provider e di data center in tutto il mondo, su un control plane di routing con oltre vent'anni di storia sul campo grazie alla sua eredità ZebOS. È un prodotto commerciale supportato, con un proprio processo di engineering, QA e rilascio. Per una rete specifica il deployment viene verificato rispetto alla Feature Matrix e alla Hardware Compatibility List, così la corrispondenza con i vostri ruoli, la scala e l'uso delle funzioni è confermata prima del cutover.
Perché sostituire i router proprietari con l'open networking?
Separa hardware, sistema operativo di rete e ottiche in modo che ciascuno possa essere acquistato in base ai propri meriti, con OcNOS concesso in licenza per edizione con una licenza d'uso perpetua. IP Infusion fornisce il risultato come sistema completo e qualificato, così la libertà di scelta non diventa un progetto di integrazione.
IP Infusion è anche un'alternativa a Juniper?
Sì. Le stesse piattaforme OcNOS che coprono i ruoli di Cisco IOS-XR e NX-OS coprono anche i ruoli di Junos nelle reti di service provider e di data center. Per una vista piattaforma per piattaforma, consultate il confronto con Juniper su /resources/ocnos-vs-juniper/.