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

Entrambi sono commerciali e carrier-grade, entrambi eseguono gli stessi standard ed entrambi arrivano con SLA e un'organizzazione di supporto globale. In ogni caso un router è fatto di quattro livelli. Ciò che cambia è chi fornisce ciascun livello e se è possibile cambiarne uno senza cambiare gli altri.

IP InfusionApprovvigionati separatamente, consegnati come un unico sistema
HardwareEdgecore, UfiSpace, Celestica
NOSOcNOS-SP or OcNOS-DC
CLIUna sola CLI per 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 or NX-OS
CLICLI diverse per linea: IOS-XR (SP), NX-OS (DC)
OtticheCisco
SupportoCisco TAC

Un unico fornitore per ogni livello, con consegna e rinnovo sotto un unico contratto.

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 e Cloud Scale, oltre a merchant silicon Broadcom in linee come NCS 5700 e Nexus 9500 R-Series.
Sistema operativoOcNOS-SP per il routing service provider, OcNOS-DC per il data center.IOS-XR per SP e core, NX-OS per il data center, IOS-XE per l'enterprise.
LicenzeConcesso in licenza separatamente dall'hardware. Perpetua e a termine, con livelli di funzionalità sbloccati tramite aggiornamento software.Smart Licensing Using Policy, in abbonamento e a termine. Alcune linee mantengono opzioni perpetue.
SourcingHardware e software si acquistano separatamente, così le piattaforme possono essere messe in concorrenza tra diversi ODM.Hardware, software e supporto provengono da Cisco.
ProtocolsBGP, OSPF, IS-IS, MPLS, SR-MPLS, SRv6, EVPN-VXLAN, RSVP-TE, IEEE 1588v2. Dettaglio per singola piattaforma nella Feature Matrix.Suite basata su standard comparabile su IOS-XR e NX-OS.
OttichePluggable multi-vendor con interoperabilità comprovata, inclusi i coerenti 400G ZR e ZR+.Cisco optics.
GestioneCLI transazionale conforme agli standard di settore con commit esplicito. NETCONF, OpenConfig, gNMI/gRPC, YANG, RESTCONF, Ansible, IP Maestro EMS.CLI IOS-XR e NX-OS. Telemetria model-driven di Cisco e stack di automazione Cisco.
SupportoUn contratto di supporto e un percorso RMA da IP Infusion, per software e hardware.TAC single-vendor per hardware e software.

Quale si adatta alla sua rete

I set di protocolli si sovrappongono ampiamente, perciò la decisione si riduce quasi sempre a come si vuole acquistare e gestire la rete.

Scelga IP Infusion quando desidera
  • Licenze di Sua proprietà. Opzioni perpetue e a termine, licenziate separatamente dall'hardware, così le funzionalità su cui fa affidamento restano un costo di sua proprietà anziché un costo da rinegoziare a ogni rinnovo.
  • Hardware da mettere in concorrenza. La stessa immagine 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. Un team IP Infusion reattivo segue sia il software sia l'hardware, con un unico contratto e un solo percorso RMA, così un problema non rimbalza tra i fornitori.
Scelga Cisco quando desidera
  • Un unico vendor per hardware, software e supporto, con un solo rapporto TAC.
  • Operatività già standardizzata su IOS-XR o NX-OS, con tooling, automazione e processi Cisco che intende mantenere.
  • Funzionalità che vivono specificamente nello stack Cisco, come un modello di policy APIC o un comportamento del silicio proprietario Cisco da cui dipende il suo design.

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

OcNOS offre la stessa riga di comando conforme agli standard di settore e lo stesso modello operativo su tre ruoli che Cisco gestisce con due sistemi operativi distinti. Il routing per service provider, la fabric EVPN-VXLAN del data center e lo spine AI-fabric RoCEv2 si configurano e si gestiscono allo stesso modo, sia nell'edizione OcNOS-SP sia nell'edizione OcNOS-DC.

Routing per service provider

OcNOS-SP supporta BGP, IS-IS, OSPF, SR-MPLS, SRv6 ed EVPN-MPLS con timing IEEE 1588v2 sulle piattaforme Broadcom Qumran e Jericho. Su Cisco questo ruolo funziona con IOS-XR.

fabric di data center

OcNOS-DC realizza una leaf-spine BGP-EVPN-VXLAN con le primitive overlay standard su hardware Broadcom Trident e Tomahawk. Su Cisco questo ruolo funziona con NX-OS.

fabric AI

OcNOS-DC aggiunge il queueing lossless RoCEv2 sugli spine Broadcom Tomahawk-5 800G per le fabric di cluster GPU. Su Cisco questo ruolo funziona su Nexus (NX-OS) o Cisco 8000 (IOS-XR).

La stessa riga di comando e gli stessi schemi di configurazione valgono per tutti e tre i ruoli con IP Infusion. Su Cisco, il routing per service provider e di core funziona con IOS-XR mentre il data center funziona con NX-OS, ciascuno con la propria riga di comando e il proprio modello di configurazione, per cui un team che passa da un ruolo all'altro lavora con una sintassi e un modello operativo differenti.

Piattaforma per piattaforma: router service provider

Rows are matched on role, port profile and capacity, not SKU for SKU. Ogni riga abbina una piattaforma Cisco al suo equivalente IP Infusion, con il profilo delle porte, il confronto di capacità e il verdetto. Quando una singola piattaforma non raggiunge la capacità, la riga lo segnala e indica la combinazione che vi riesce.

Ruolo, porte e capacità coincidono Stessa classe di capacità Revisione progettuale
Piattaforma Cisco Equivalente IP Infusion Porte Capacità Corrispondenza Note
Cisco NCS 540Access / aggregation · IOS-XR S9510-28DC / AS7535-28XBOcNOS-SP 24×10G + 8×25G + 2×100G → 24×25G + 2×100G + 2×400G ~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 / 5700Aggregation / 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à Scala di routing, profondità di buffer e mix di porte vengono confrontati per ciascun deployment.
Cisco 8000 (8201 / 8202)Core / peering · IOS-XR · Cisco Silicon One Q100 S9610-36DOcNOS-SP 12×100G + 24×400G → 36×400G 10.8T → 14.4T Different silicon Le architetture del silicio sono diverse, perciò profondità di buffer, scala FIB/RIB e profondità dello stack di label vengono confrontate per ciascun deployment anziché date per scontate.
Cisco ASR 9902 / 9903PE / BNG edge · IOS-XR S9600-56DX / AS9947-36XKBOcNOS-SP 48×100G + 8×400G By configuration BNG da confermare I workload avanzati di subscriber management vengono inquadrati come una design review anziché come una sostituzione da datasheet.

Piattaforma per piattaforma: switch di data center

La stessa immagine OcNOS-DC, la stessa fabric EVPN-VXLAN basata su standard, su hardware aperto Broadcom Trident e Tomahawk.

Piattaforma Cisco Equivalente IP Infusion Porte Capacità Corrispondenza Note
Cisco Nexus 93180YC-FX25G leaf · NX-OS · Cloud Scale AS7326-56XOcNOS-DC 48×25G + 6×100G → 48×25G + 8×100G 1.8T → 2.0T (unidirezionale) Corrispondenza porta per porta BGP-EVPN-VXLAN, MAC-VRF e le primitive di overlay standard sono supportati nativamente.
Cisco Nexus 9336C-FX2100G leaf / spine · NX-OS · Cloud Scale AS7726-32X / S9110-32XOcNOS-DC 36×100G → 32×100G 3.6T → 3.2T (unidirezionale) Same 100G class Dove invece si preferiscono uplink 400G, la riga AS9716-32D qui sotto è il punto di partenza migliore.
Cisco Nexus 9332D-GX2B400G leaf / spine · NX-OS · Cloud Scale AS9716-32D / AS9736-64DOcNOS-DC 32×400G → 32 o 64×400G 12.8T → 12.8 or 25.6T Stessa classe 400G Entrambi supportano BGP-EVPN-VXLAN con le primitive di overlay standard.
Cisco 800G spine51.2T tier · Cisco Silicon One G200 AIS800-64D / S9321-64EOcNOS-DC 64×800G → 64×800G 51.2T → 51.2T Silicio di vendor diverso Il queueing lossless RoCEv2 per l'AI fabric è disponibile sulle piattaforme Tomahawk-5.
Cisco Nexus 9500 R-SeriesDeep-buffer spine · NX-OS · Broadcom ASICs S9610-36D / AS9947-36XKBOcNOS-SP 36×400G / 24×100G + 12×400G Per chassis → 14.4T / 7.2T Il deep buffer risiede in SP Sul fronte IP Infusion, le piattaforme con buffer nell'ordine dei GB sono i router Jericho2c+ (16 GB sull'S9610-36D, 8 GB HBM sull'AS9947-36XKB), che eseguono OcNOS-SP. Un ruolo di aggregazione deep-buffer viene quindi inquadrato come un design della famiglia SP anziché come una sostituzione uno-a-uno di uno switch DC.
Cisco ACI / APICController-based DC fabric Leaf-spine EVPN-VXLANOcNOS-DC — Per design della fabric Revisione progettuale Il controller APIC e il suo modello di policy non si trasferiscono uno-a-uno, quindi una migrazione viene inquadrata come una design review anziché come una sostituzione.

Come leggere queste voci. Le righe sono abbinate per ruolo, profilo di porte e capacità. La capacità è indicata in una sola direzione su entrambi i fronti: Cisco pubblica la capacità di switching Nexus in forma bidirezionale, perciò qui quei valori sono dimezzati per il confronto con i valori unidirezionali pubblicati da Edgecore e UfiSpace. Il silicio è indicato solo dove è il vendor a indicarlo; Cisco non pubblica l'ASIC di forwarding dell'NCS 540 e descrive la Nexus 9500 R-Series come ASIC Broadcom senza nominare il componente. Nessuno SKU viene presentato come sostituzione uno-a-uno garantita, e la piattaforma giusta per la sua rete dipende comunque dal mix di porte, dalla scala e dal set di funzionalità. Le specifiche riflettono le informazioni pubblicamente documentate a luglio 2026.

Le piattaforme che IP Infusion fornisce per questi ruoli

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

S9510-28DC UfiSpace open switch
S9510-28DC accesso SP / cell-site UfiSpace · Qumran-2A Vedi il datasheet →
S9600-64X UfiSpace open switch
S9600-64X Aggregazione SP UfiSpace · Qumran-2C Vedi il datasheet →
S9610-36D UfiSpace open switch
S9610-36D Core compatto SP UfiSpace · Jericho-2C+ Vedi il datasheet →
AS7326-56X Edgecore open switch
AS7326-56X DC leaf (25G) Edgecore · Trident-3 Vedi il datasheet →
AS9736-64D Edgecore open switch
AS9736-64D DC spine (400G) Edgecore · Tomahawk-4 Vedi il datasheet →
AIS800-64D Edgecore open switch
AIS800-64D DC / AI spine (800G) Edgecore · Tomahawk-5 Vedi il datasheet →

Esplori l'intero set validato: Hardware compatibility list.

Dove IP Infusion sostituisce bene Cisco

Aggregazione metro & edge per service provider

SR-MPLS, EVPN-MPLS e timing IEEE 1588v2 di Classe C su piattaforme Broadcom Qumran e Jericho, a copertura dei ruoli di accesso e aggregazione svolti da Cisco NCS 540 e NCS 5500.

leaf-spine EVPN-VXLAN di data center

Una fabric BGP-EVPN-VXLAN su hardware aperto Trident e Tomahawk, con le primitive di overlay standard (MAC-VRF, rotte di tipo 2 e tipo 5) e senza dipendenza da un controller centrale.

spine di data center 400G e 800G

Spine ad alto radix su Broadcom Tomahawk-4 (400G) e Tomahawk-5 (800G), con queueing lossless RoCEv2 per l'AI fabric.

IPoDWDM e DCI coerente 400G

Pluggable coerenti OpenZR+ 400G gestiti direttamente da OcNOS-SP: DCI senza transponder su hardware aperto, con interoperabilità dell'ottica multi-vendor comprovata.

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:

MadeoHa sostituito switch Cisco Nexus 3048 e Catalyst 3750. Ha scelto OcNOS per l'interconnessione data center EVPN-VXLAN, il peering di transito BGP completo e la flessibilità sull'ottica, su una CLI che il team conosceva già. Dojo NetworksHa sostituito gli apparati di trasporto Cisco tra le sedi. Ha citato l'ampiezza funzionale su hardware eterogeneo e tempi di consegna passati da anni a giorni, mantenendo l'interoperabilità con il parco Cisco, Juniper e Ruckus installato. Premium Choice BroadbandHa sostituito un router di core Cisco ormai datato con OcNOS-SP su UfiSpace. Ha citato la disponibilità immediata degli apparati di upgrade, la robustezza del software e il prezzo. Hall AG (Citynet)Ha sostituito il proprio backbone Cisco con OcNOS su Edgecore. Ha citato la parità funzionale con le alternative valutate, la disponibilità a magazzino, il prezzo e una CLI standard di settore che ha semplificato il cutover.

Un percorso di migrazione a fasi

Settimana 1

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 4

Pilota e parità

Esegua un pilot dual-homed, verifichi la parità di protocollo e timing, traduca le route-policy e la configurazione EVPN, e trasmetta la telemetria OpenConfig al suo collector esistente.

Settimana 12

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.

Dove si colloca IP Infusion

Cisco è un incumbent maturo, con un portafoglio profondo e un'organizzazione di supporto all'altezza. IP Infusion compete sull'approvvigionamento: hardware in merchant silicon che può mettere in concorrenza tra diversi ODM, software licenziato separatamente dal box e disponibile in forma perpetua e ottica di più fornitori, il tutto consegnato come router o switch finito e validato sulla HCL. Quando il requisito è il set di protocolli basato su standard, è questo lo scambio che vale la pena quotare.

Matrice funzionalitàSupporto per funzionalità e per piattaforma Hardware compatibility listPiattaforme aperte elencate nell'HCL OcNOS-SPRouting service provider OcNOS-DCfabric di data center open networkingIl panorama dei fornitori OcNOS vs SONiCConfronta anche OcNOS vs JuniperConfronta anche
Esplora OcNOS Contattaci

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 relativi nomi di prodotto sono marchi di Broadcom Inc. Tutti gli altri marchi sono di proprietà dei rispettivi titolari. IP Infusion non è affiliata a, approvata da o sponsorizzata da Cisco Systems. I confronti riflettono le specifiche documentate pubblicamente a luglio 2026 e sono forniti a soli fini di valutazione.

FAQ

Domande frequenti

IP Infusion vende switch e router completi, o solo il software OcNOS?
Entrambi. L'offerta principale è il prodotto finito: un router o uno switch carrier-grade con OcNOS preinstallato su hardware aperto, più l'ottica e il contratto di supporto, consegnati come un unico sistema e validati sulla Hardware Compatibility List. Se utilizza già hardware aperto, può acquistare la sola licenza OcNOS per quell'hardware. Poiché hardware, software e ottica restano separabili, in seguito può cambiarne uno 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?
A livello di protocollo OcNOS-SP offre lo stack su cui le reti SP funzionano con Cisco IOS-XR: BGP, IS-IS, OSPF, MPLS, SR-MPLS, SRv6, RSVP-TE, L2VPN/L3VPN, QoS e timing IEEE 1588v2. Se una specifica piattaforma Cisco corrisponda uno-a-uno dipende dal mix di porte, dalla scala e dall'uso delle funzionalità, quindi una sostituzione in produzione viene validata con una valutazione ingegneristica di IP Infusion rispetto alla Feature Matrix e alla Hardware Compatibility List.
Qual è la differenza tra OcNOS e Cisco NX-OS nel data center?
Entrambi eseguono fabric leaf-spine EVPN-VXLAN con le stesse primitive di overlay. NX-OS gira su hardware Cisco Nexus; OcNOS-DC gira su piattaforme aperte Broadcom Trident e Tomahawk di diversi produttori. La differenza sta nel modello hardware, non nel design della fabric.
OcNOS funziona sullo stesso silicon di Cisco?
In parte sì, ed è proprio questo il punto. OcNOS si standardizza su merchant silicon Broadcom (Qumran, Jericho, Trident, Tomahawk). Cisco impiega i propri ASIC Silicon One e Cloud Scale in gran parte del portafoglio, ma commercializza anche merchant silicon Broadcom in linee come NCS 5700, dove Cisco dichiara un singolo ASIC Jericho 2 da 4.8 Tbps, e Nexus 9500 R-Series. È proprio questa base comune di merchant silicon a rendere praticabile un approvvigionamento hardware multi-fornitore.
Esiste un equivalente OcNOS del Cisco Nexus 9300?
Per il ruolo di leaf nel data center, OcNOS-DC gira su piattaforme di classe Broadcom Trident (per esempio uno switch Edgecore 48×25G con uplink 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 sulla Hardware Compatibility List.
OcNOS può sostituire una fabric EVPN-VXLAN di Cisco ACI?
Cisco ACI è una fabric basata su controller gestita dall'APIC. OcNOS-DC esegue un leaf-spine BGP-EVPN-VXLAN su hardware aperto con le stesse primitive di overlay e senza controller centrale. I due condividono il data plane VXLAN/EVPN, ma il modello di policy APIC non è un port di funzionalità uno-a-uno, quindi una migrazione viene inquadrata come una design review anziché come una sostituzione.
Qual è l'alternativa OcNOS alle serie Cisco 8000 o NCS per il core SP?
OcNOS-SP funziona su piattaforme compact-core aperte (per esempio le famiglie UfiSpace S9600 e S9610 su silicio Broadcom Qumran-2C e Jericho-2C+) per core e peering, e su router di accesso di classe Qumran per il ruolo NCS 540. Quando la piattaforma Cisco utilizza Silicon One, si tratta di una corrispondenza di classe di throughput su silicio differente; quando Cisco utilizza già Broadcom, si tratta della stessa generazione di silicio. Profondità di buffer, scala FIB/RIB e profondità dello stack di label vengono confrontate per ciascun deployment.
Come si mappano i comandi Cisco IOS-XR e NX-OS su OcNOS?
OcNOS utilizza una riga di comando conforme agli standard di settore, transazionale con commit esplicito e con un'ergonomia vicina a quella di IOS-XR, così che la maggior parte degli schemi di configurazione di BGP, IS-IS, OSPF, MPLS, interfacce ed EVPN si trasferisca in modo diretto. La sintassi esatta differisce in alcuni punti, perciò una migrazione si basa su una mappatura dei comandi e su una fase di traduzione revisionata, anziché su un porting 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 conforme agli standard di settore e lo stesso modello operativo per il routing per service provider su OcNOS-SP e per la fabric EVPN-VXLAN del data center e gli spine AI-fabric RoCEv2 su OcNOS-DC, quindi gli stessi schemi di configurazione e gli stessi strumenti valgono per tutti e tre i ruoli. Su Cisco questi ruoli si distribuiscono su due sistemi operativi, IOS-XR per il routing per service provider e di core e NX-OS per il data center, ciascuno con la propria riga di comando e il proprio modello di configurazione.
OcNOS è supportato come lo è Cisco?
Sì. OcNOS è un prodotto commerciale, con SLA e un'organizzazione di supporto globale alle spalle, non un progetto community. La differenza tra i due non sta nel supporto, ma nel modello 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 opera in reti di service provider e di data center in produzione in tutto il mondo, su un piano di controllo del routing con oltre due decenni di esperienza sul campo grazie alla sua eredità ZebOS. È un prodotto commerciale e supportato, con ingegneria, QA e processo di rilascio propri. Per una rete specifica il deployment viene validato rispetto alla Matrice funzionalità e alla Hardware compatibility list, così che l'idoneità ai Suoi ruoli, alla Sua scala e al Suo utilizzo delle funzionalità sia confermata prima del passaggio anziché data per scontata.
Perché sostituire i router proprietari con l'open networking?
Separa hardware, sistema operativo di rete e ottica, così ciascun elemento può essere approvvigionato per i propri meriti, e mantiene licenze software di proprietà anziché da rinegoziare al rinnovo. IP Infusion fornisce il risultato come sistema finito e validato, così questa libertà di approvvigionamento non si trasforma in un progetto di integrazione.
IP Infusion è un'alternativa anche a Juniper, Arista e Nokia oltre che a Cisco?
Sì. IP Infusion compete sul routing e sullo switching proprietari in generale. Le stesse piattaforme OcNOS che coprono i ruoli Cisco IOS-XR e NX-OS coprono anche le piattaforme Juniper Junos nelle reti service provider e data center. Per una visione Junos piattaforma per piattaforma, consulti il confronto con Juniper su /resources/ocnos-vs-juniper/.