EVPN-VXLAN · BGP Leaf-Spine · Hardware aperto

Fabric per data center cloud-scale, su hardware aperto.

Data center fabric leaf-spine scale-out con overlay EVPN-VXLAN e isolamento dei workload multi-tenant. BGP ECMP a ogni livello, su hardware aperto validato a una frazione del costo proprietario.

Protocolli:
EVPN-VXLAN BGP Wide ECMP VXLAN PFC / DCB BFD OpenConfig Telemetria streaming gNMI gRPC NETCONF / YANG Bilanciamento del carico avanzato Multisite Stitching Storage IP / NVMEoF Ottiche di terze parti OS model-based
Non-blocking
Architetture di fabric Wide-ECMP
EVPN
RFC 7432 / 8365 · Multi-Homing
17
Piattaforme DC validate
Singolo
Contratto di supporto, SW + HW
Il problema

Gli switch proprietari controllano permanentemente il vostro ciclo di refresh hardware.

Per ogni switch Cisco o Arista acquistato si paga sia un margine hardware sia una licenza software allo stesso fornitore, senza alcuna possibilità di separare i due. OcNOS-DC gira sugli stessi ASIC Broadcom a prezzi ODM.

Leaf-spine EVPN-VXLAN con Underlay BGP gateway anycast Soppressione ARP EVPN multi-homing: pronto per la produzione, dal Day 1, su hardware aperto.

Architettura di riferimento

Leaf-Spine EVPN-VXLAN: RFC 7938 + RFC 8365

Underlay eBGP unnumbered su ogni link leaf-spine. VTEP VXLAN su ogni leaf. Il gateway anycast elimina la latenza di routing del primo hop. ZTP esegue il provisioning di ogni nuovo switch all'avvio.

Topologia DC fabric: leaf-spine EVPN-VXLAN con leaf VTEP, uplink eBGP ECMP e un border leaf per la connettività esterna e la route reflection EVPN
DC Fabric: leaf-spine EVPN-VXLAN con leaf VTEP, eBGP ECMP e un border leaf per la connettività esterna.
600+Deployment operatore
60+Paesi
26Anni nel networking
Architettura tecnica

EVPN-VXLAN fatto bene, automatizzato dal giorno 0.

La maggior parte dei deployment di fabric da data center si basa ancora su provisioning CLI manuale che richiede giorni per rack. OcNOS-DC combina l'intero set di funzionalità EVPN-VXLAN con ZTP, telemetria gNMI in streaming e automazione Ansible, dal solo switch a leaf in produzione in pochi minuti.

EVPN Type-2 + Type-5 con Symmetric IRB

Le rotte Type-2 annunciano MAC e IP insieme così ogni leaf conosce ogni host senza flooding. Le rotte Type-5 distribuiscono i prefissi IP per il routing inter-tenant ed esterno. L'IRB simmetrico fornisce forwarding L3 sia sui VTEP di ingresso sia su quelli di uscita: percorso ottimale, nessun hairpin.

EVPN multi-homing: active-active, senza MLAG

Server in dual-homing verso due switch leaf tramite ESI-LAG. Entrambi i collegamenti instradano traffico simultaneamente, mentre EVPN gestisce la sincronizzazione MAC/IP tra i VTEP. Nessun dominio MLAG proprietario, nessun peer-link, nessun rischio di split-brain.

Anycast Gateway distribuito + ARP Suppression

Ogni leaf switch condivide lo stesso IP e MAC di gateway per ciascuna subnet tenant, senza tromboning del traffico attraverso un gateway centrale. La ARP suppression fa sì che i leaf switch rispondano localmente alle ARP dal database EVPN anziché effettuare il flooding, riducendo il broadcast dell'80–90% su larga scala.

ZTP + gNMI: zero-touch dal rack all'esercizio

Un nuovo switch OcNOS-DC si avvia, il DHCP provisiona la configurazione EVPN completa via ZTP, e la telemetria gNMI on-change inizia a essere in streaming in pochi minuti. Nessun cavo console, nessuna configurazione eBGP manuale. Ansible e Terraform gestiscono i cambiamenti Day-2 in modo idempotente sull'intero fabric.

ansible: deploy del fabric EVPN-VXLAN
$ansible-playbook -i dc-inventory deploy-evpn.yml
ok: [spine-01] · EVPN RR, AS 65100
ok: [spine-02] · EVPN RR, AS 65101
ok: [leaf-01] · VTEP 10.0.0.1, VNIs up
ok: [leaf-02] . VTEP 10.0.0.2, peer ESI
ok: [border-01] · Type-5, RPKI attivo
PLAY RECAP
5 devices changed=5 failed=0 unreachable=0
$gnmic sub --path /network-instances/ \
--mode ON_CHANGE
VNI 10010 up MACs: 248 ARPs: 248
VNI 10020 up MACs: 192 ARPs: 192
VNI 50010 up route: 14
✓ fabric integra. 0 drop. ECMP bilanciato

Piattaforme DC fabric qualificate

AS9736-64D
Edgecore – Spine
25.6 TbpsTH4
AIS800-64D
Edgecore – Spine
51,2 TbpsTH5
AS9726-32DB
Edgecore – Leaf
12.8 TbpsTD4
S9300-32D
UfiSpace – Leaf
12.8 TbpsTD4

40+ piattaforme qualificate HCL completa →

Aperto vs proprietario

Gli stessi ASIC. Una frazione del costo.

Gli switch da data center di Arista, Cisco e Juniper utilizzano ASIC Broadcom Tomahawk e Trident: lo stesso silicio presente nell'hardware ODM di Edgecore e UfiSpace. Il sovrapprezzo paga unicamente il marchio, il vendor lock-in e il margine del fornitore.

❌ Proprietario (Arista / Cisco / Juniper)

Hardware e NOS in bundle. non è possibile acquistare l'ASIC senza la licenza software associata.

MLAG per il dual-homing server richiede un protocollo peer-link proprietario e un link keepalive dedicato per ogni coppia di switch.

L'automazione utilizza EAPI, NX-API o Junos PyEZ specifici del fornitore: non portabili tra piattaforme o fornitori.

Contratti di supporto hardware e software separati: più code TAC per lo stesso problema di rete.

Sostituzione integrale ogni 3–5 anni quando il fornitore dichiara la piattaforma a fine vita, indipendentemente da eventuali guasti hardware.

✓ OcNOS-DC su hardware aperto

Hardware di Edgecore o UfiSpace. OcNOS-DC di IP Infusion. Contratti separati, oppure abbinati tramite un unico SKU.

EVPN Multi-Homing (ESI-LAG) offre nativamente il dual-homing server active-active: senza peer-link, senza protocolli proprietari.

NETCONF/YANG 1.1, OpenConfig, gNMI, Ansible, Terraform: standard aperti che funzionano su OcNOS-DC e su qualsiasi altro NOS conforme agli standard.

Un unico contratto di supporto IP Infusion copre il TAC software e il coordinamento RMA hardware a livello globale — una sola chiamata, una sola coda.

OcNOS-DC è software. aggiornate il NOS indipendentemente dall'hardware. Estendete la vita della piattaforma oltre le scadenze EOL del fornitore.

Scenari di deployment

Dove OcNOS DC Fabric è in esercizio oggi.

CASO D'USO 01

Fabric DC multi-tenant enterprise

I data center enterprise che ospitano più unità di business o clienti su infrastruttura condivisa necessitano di un'isolazione tenant forte senza sacrificare le prestazioni est-ovest. OcNOS-DC fornisce isolamento per-VRF tramite VNI L3, gateway anycast per routing intra-fabric ottimale e suppression ARP per contenere il broadcast su larga scala, il tutto su hardware aperto.

CASO D'USO 02

Fabric cloud provider / hyperscale

Cloud provider e hyperscaler richiedono operazioni automation-first in cui ogni switch viene provisionato in modo identico da un template, mai manualmente. Il design ZTP, NETCONF/YANG e Ansible-native di OcNOS-DC porta nuova capacità in esercizio in minuti, non giorni. Il supporto Docker e Kubernetes in OcNOS 7.0 consente agli operatori di eseguire agenti di monitoring on-switch insieme al NOS.

CASO D'USO 03

Fabric ibrido IA + uso generale

Molti data center eseguono sia pod di calcolo GPU sia workload convenzionali. OcNOS-DC gestisce entrambi in un'unica istanza NOS: fabric EVPN-VXLAN multi-tenant per i workload convenzionali e l'intero stack DCB RoCEv2 lossless (PFC, ECN, DLB) per i pod GPU. Nessun NOS separato per la sezione IA. Per il livello di interconnessione DC-to-DC, vedere la Soluzione IPoDWDM.

Inizia

Costruite la vostra fabric leaf-spine su hardware aperto.

Scarica gratis la VM OcNOS-DC e convalida oggi le configurazioni EVPN-VXLAN — senza hardware — oppure prenota una demo.

Domande tecniche frequenti

DC fabric con OcNOS-DC

Cos'è EVPN-VXLAN e come lo implementa OcNOS-DC?
EVPN-VXLAN è lo standard industriale per gli overlay di fabric da data center multi-tenant. OcNOS-DC implementa EVPN secondo RFC 8365 con incapsulamento VXLAN: rotte Type-2 per l'annuncio MAC/IP, rotte Type-5 per la distribuzione dei prefissi IP e Integrated Routing and Bridging (IRB) sia simmetrico che asimmetrico. Gli switch leaf operano come VXLAN Tunnel Endpoint (VTEP) con gateway anycast distribuito per un routing intra-fabric ottimale. La suppression ARP riduce il traffico broadcast su larga scala. L'underlay BGP segue l'architettura per data center descritta in RFC 7938 con interfacce eBGP unnumbered su ogni link leaf-spine.
OcNOS-DC può sostituire Arista EOS o Cisco NX-OS nel mio data center?
Sì. OcNOS-DC offre parità funzionale per i deployment EVPN-VXLAN leaf-spine standard. È in esercizio sugli stessi ASIC Broadcom Tomahawk e Trident utilizzati negli apparati Arista e Cisco, ma su piattaforme ODM aperte di Edgecore, UfiSpace e Celestica. I clienti ottengono tipicamente risparmi CapEx sostanziali sull'hardware rispetto ai sistemi proprietari. IP Infusion fornisce un unico contratto di supporto che copre sia il software OcNOS-DC sia il coordinamento RMA hardware, semplicità operativa equivalente a un deployment proprietario, senza il vendor lock-in.
Cos'è l'EVPN Multi-Homing e OcNOS-DC lo supporta?
EVPN multi-homing (ESI-LAG) consente a un server o a un dispositivo di rete di collegarsi contemporaneamente a due o più switch leaf in configurazione active-active o active-standby, senza richiedere un dominio MLAG tradizionale. OcNOS-DC supporta EVPN multi-homing (active-active) basato su Ethernet Segment Identifier (ESI), fornendo ridondanza e distribuzione ottimale del traffico senza la complessità operativa dei protocolli MLAG proprietari.
Come gestisce OcNOS-DC l'isolamento multi-tenant in un DC fabric?
L'isolamento multi-tenant è implementato tramite VXLAN Network Identifier (VNI). OcNOS-DC supporta sia VNI Layer 2 per domini tenant bridgiati sia VNI Layer 3 per traffico inter-tenant routato tramite IRB simmetrico. Ogni VRF tenant è isolata a livello di data plane. EVPN E-Tree (Scenario 1) fornisce ulteriore isolamento leaf-to-leaf all'interno di un tenant per i casi d'uso che richiedono il controllo del traffico spoke-to-spoke. La validazione BGP RPKI mette in sicurezza il control plane di routing al bordo del fabric.
OcNOS-DC supporta lo Zero Touch Provisioning per implementazioni leaf-spine?
Sì. OcNOS-DC supporta lo ZTP basato su DHCP sia su IPv4 che su IPv6. Un nuovo switch leaf si avvia, richiede la configurazione tramite l'opzione DHCP 67, e OcNOS-DC scarica e applica automaticamente l'intera configurazione, incluse sessioni eBGP, address family EVPN, mapping VNI e profili DCBX. Combinato con IP Maestro per la gestione del lifecycle e la telemetria gNMI in streaming, OcNOS-DC abilita operazioni completamente automatizzate dal Day 0 al Day 2 senza interventi manuali sulla CLI.
Quali strumenti di automazione supporta OcNOS-DC per la gestione del DC fabric?
OcNOS-DC è progettato per operazioni automation-first: modelli NETCONF/YANG 1.1 e OpenConfig per configurazione model-driven, gNMI con telemetria in streaming dial-in e dial-out per osservabilità in tempo reale, playbook Ansible per deployment fabric-wide idempotenti, un provider Terraform per workflow infrastructure-as-code e sFlow per il campionamento del traffico. Il supporto Docker e Kubernetes in OcNOS 7.0 consente agli agenti di monitoring di terze parti di operare direttamente sulla CPU dello switch, eliminando la necessità di un'infrastruttura di collector separata.