EVPN-VXLAN · BGP Leaf-Spine · Open Hardware · 24/7 SLA

Cloud-Scale-Rechenzentrums-Fabric auf offener Hardware.

Skalierbare Leaf-Spine-Rechenzentrums-Fabric mit EVPN-VXLAN-Overlays und mandantenfähiger Workload-Isolation. BGP-ECMP auf jeder Ebene, auf validierter offener Hardware zu einem Bruchteil der Kosten proprietärer Lösungen.

Protokolle:
EVPN-VXLAN BGP Wide ECMP VXLAN PFC / DCB BFD OpenConfig gNMI gRPC Streaming-Telemetrie NETCONF / YANG Advanced Load Balancing Multisite Stitching IP Storage / NVMEoF Drittanbieter-Optiken Modellbasiertes OS
Non-Blocking
Wide-ECMP-Fabric-Architekturen
EVPN
RFC 7432 / 8365 · Multi-Homing
17
Validierte DC-Plattformen
24/7
Carrier-Grade-SLA weltweit
Das Problem

Proprietäre Switches bestimmen dauerhaft Ihren Hardware-Refresh-Zyklus.

Mit jedem Cisco- oder Arista-Switch zahlt der Kunde sowohl eine Hardware-Marge als auch eine Software-Lizenz an denselben Hersteller, ohne die Möglichkeit, beides voneinander zu trennen. OcNOS-DC läuft auf denselben Broadcom-ASICs zu ODM-Preisen.

EVPN-VXLAN-Leaf-Spine mit BGP-Underlay Anycast-Gateway ARP-Suppression EVPN Multi-Homing: produktionsbereit, ab Day 1, auf Open Hardware.

Referenzarchitektur

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

eBGP-Unnumbered-Underlay auf jedem Leaf-Spine-Link. VXLAN-VTEP auf jedem Leaf. Das Anycast-Gateway eliminiert die First-Hop-Routing-Latenz. ZTP provisioniert jeden neuen Switch beim Bootvorgang.

EVPN-VXLAN Leaf-Spine DC-Fabric mit Border Leaf EVPN-VXLAN-Rechenzentrums-Fabric mit zwei Spines und zwei Leaves. Server der Tenants A und B werden per ESI-LAG an VTEP-Leaves mit OcNOS-DC angebunden, mit Type-2- und Type-5-EVPN-Routen sowie Anycast-Gateway. Zwei Spines reflektieren die EVPN-Routen über eBGP ECMP mit jeweils 25,6 Tbps. Ein Border-Leaf mit 400G-Uplinks stellt die externe WAN-Anbindung und das EVPN-Gateway bereit. Server Tenant A ESI-LAG AA Server Tenant B ESI-LAG AA Server Tenant A Anycast-GW Leaf-01 OcNOS-DC VTEP · Anycast-Gateway Type-2 + Type-5 eBGP AS 65001 EVPN-VXLAN VTEP Leaf-02 OcNOS-DC eBGP AS 65002 EVPN-VXLAN VTEP eBGP ECMP Spine-01 OcNOS-DC 25.6 Tbps · RR EVPN Route Reflector eBGP AS 65100 Spine-02 OcNOS-DC 25.6 Tbps · RR EVPN Route Reflector eBGP AS 65101 Border Leaf OcNOS-DC Type-5 · RPKI 400G-Uplinks EVPN GATEWAY WAN / inet OcNOS-DC – DC FABRIC – EVPN-VXLAN · BGP LEAF-SPINE · ANYCAST GW · MULTI-TENANT
OcNOS-DC Leaf (VTEP)
OcNOS-DC Spine (RR)
OcNOS-DC Border Leaf
Extern / WAN

Fahren Sie über die Knoten, um Details zu Funktionen und Plattformen zu sehen · Vollständige HCL: 40+ validierte Plattformen unter ipinfusion.com/hcl

600+Betreiber-Deployments
60+Länder
26Jahre im Networking
Technische Architektur

EVPN-VXLAN richtig umgesetzt, automatisiert ab Tag 0.

Die meisten Data-Center-Fabric-Deployments stützen sich nach wie vor auf manuelles CLI-Provisioning, das pro Rack Tage in Anspruch nimmt. OcNOS-DC kombiniert den vollständigen EVPN-VXLAN-Funktionsumfang mit ZTP, gNMI-Streaming-Telemetrie und Ansible-Automatisierung, vom nackten Switch zum produktiven Leaf in wenigen Minuten.

EVPN Type-2 + Type-5 mit Symmetric IRB

Type-2-Routen kündigen MAC und IP gemeinsam an: jeder Leaf-Switch kennt jeden Host ohne Flooding. Type-5-Routen verteilen IP-Präfixe für Inter-Tenant- und External-Routing. Symmetrisches IRB liefert L3-Forwarding sowohl auf Ingress- als auch auf Egress-VTEPs: optimaler Pfad, kein Hairpin.

EVPN-Multi-Homing: Active-Active, ohne MLAG

Server mit Dual-Homing an zwei Leaf-Switches über ESI-LAG. Beide Links übertragen Datenverkehr gleichzeitig, während EVPN die MAC/IP-Synchronisation zwischen den VTEPs übernimmt. Keine proprietäre MLAG-Domäne, kein Peer-Link, kein Split-Brain-Risiko.

Verteiltes Anycast Gateway + ARP-Suppression

Jeder Leaf-Switch teilt sich dieselbe Gateway-IP und MAC für jedes Tenant-Subnetz, ohne Traffic-Tromboning durch ein zentrales Gateway. ARP-Suppression bedeutet, dass Leaf-Switches ARP lokal aus der EVPN-Datenbank beantworten, statt zu fluten, und reduziert so Broadcast bei Skalierung um 80 bis 90 %.

ZTP + gNMI: Zero-Touch vom Rack bis zum Produktivbetrieb

Ein neuer OcNOS-DC-Switch bootet, DHCP provisioniert die vollständige EVPN-Konfiguration über ZTP, und die gNMI-On-Change-Telemetrie beginnt innerhalb von Minuten zu streamen. Kein Konsolenkabel, keine manuelle eBGP-Konfiguration. Ansible und Terraform übernehmen Day-2-Änderungen idempotent über das gesamte Fabric.

ansible: EVPN-VXLAN-Fabric ausrollen LIVE
$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, ESI-Peer
ok: [border-01] · Type-5, RPKI aktiv
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 Routen: 14
✓ Fabric gesund. 0 Drops. ECMP ausbalanciert

Qualifizierte DC-Fabric-Plattformen

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+ qualifizierte Plattformen Vollständige HCL →

Offen vs. proprietär

Dieselben ASICs. Ein Bruchteil der Kosten.

Die Data-Center-Switches von Arista, Cisco und Juniper basieren auf Broadcom-Tomahawk- und Trident-ASICs: demselben Silizium, das auch in der ODM-Hardware von Edgecore und UfiSpace steckt. Der Aufpreis entfällt allein auf die Marke, den Vendor Lock-in und die Marge des Herstellers.

❌ Proprietär (Arista / Cisco / Juniper)

Hardware und NOS gebündelt. der ASIC ist nicht ohne die daran gebundene Softwarelizenz erhältlich.

MLAG für Server-Dual-Homing erfordert ein proprietäres Peer-Link-Protokoll und einen dedizierten Keepalive-Link je Switch-Paar.

Automatisierung über herstellerspezifische EAPI, NX-API oder Junos PyEZ: nicht portierbar zwischen Plattformen oder Lieferanten.

Getrennte Support-Verträge für Hardware und Software: mehrere TAC-Warteschlangen für denselben Netzwerkvorfall.

Vollständiger Austausch alle 3–5 Jahre, sobald der Hersteller die Plattform abkündigt — unabhängig davon, ob die Hardware ausgefallen ist.

✓ OcNOS-DC auf Open Hardware

Hardware von Edgecore oder UfiSpace. OcNOS-DC von IP Infusion. Separate Verträge, oder gebündelt über eine einzige Turnkey-SKU.

EVPN Multi-Homing (ESI-LAG) bietet nativ Active-Active-Dual-Homing für Server: ohne Peer-Link, ohne proprietäres Protokoll.

NETCONF/YANG 1.1, OpenConfig, gNMI, Ansible, Terraform: offene Standards, die auf OcNOS-DC und jedem anderen standardkonformen NOS funktionieren.

Ein einziger IP-Infusion-Supportvertrag deckt Software-TAC und Hardware-RMA-Koordination weltweit ab, rund um die Uhr: ein Anruf, eine Warteschlange.

OcNOS-DC ist Software. aktualisieren Sie das NOS unabhängig von der Hardware. Verlängern Sie die Lebensdauer der Plattform über die EOL-Termine des Herstellers hinaus.

Einsatzszenarien

Wo OcNOS DC Fabric heute im Einsatz ist.

ANWENDUNGSFALL 01

Enterprise-Multi-Tenant-DC-Fabric

Enterprise-Rechenzentren, die mehrere Geschäftsbereiche oder Kunden auf gemeinsamer Infrastruktur betreiben, benötigen eine starke Tenant-Isolation ohne Einbußen bei der Ost-West-Performance. OcNOS-DC liefert VRF-spezifische Isolation über L3-VNIs, Anycast-Gateway für optimales Intra-Fabric-Routing und ARP-Suppression zur Begrenzung des Broadcast-Verkehrs im großen Maßstab, durchgängig auf offener Hardware.

ANWENDUNGSFALL 02

Cloud-Provider-/Hyperscale-Fabric

Cloud-Provider und Hyperscaler benötigen einen Automation-first-Betrieb, in dem jeder Switch identisch aus einem Template provisioniert wird — niemals manuell. Das ZTP-, NETCONF/YANG- und Ansible-native Design von OcNOS-DC bedeutet, dass neue Kapazität in Minuten statt Tagen produktiv ist. Die Docker- und Kubernetes-Unterstützung in OcNOS 7.0 erlaubt es Netzbetreibern, On-Switch-Monitoring-Agents neben dem NOS auszuführen.

ANWENDUNGSFALL 03

Hybrides KI- und Allzweck-Fabric

Viele Rechenzentren betreiben sowohl GPU-Compute-Pods als auch klassische Workloads. OcNOS-DC bedient beide in einer einzigen NOS-Instanz: EVPN-VXLAN-Multi-Tenant-Fabric für die klassischen Workloads und den vollständigen verlustfreien RoCEv2-DCB-Stack (PFC, ECN, DLB) für die GPU-Pods. Keine separate NOS-Instanz für den KI-Bereich. Für die DC-zu-DC-Interconnect-Ebene siehe die IPoDWDM-Lösung.

Loslegen

Bauen Sie Ihre Leaf-Spine-Fabric auf offener Hardware.

Sprechen Sie mit einem IPI-DC-Networking-Spezialisten oder laden Sie die kostenlose OcNOS-DC-VM herunter und validieren Sie noch heute EVPN-VXLAN-Konfigurationen: ohne Hardware.

Häufige technische Fragen

DC Fabric mit OcNOS-DC

Was ist EVPN-VXLAN und wie setzt OcNOS-DC es um?
EVPN-VXLAN ist der Industriestandard für Multi-Tenant-Data-Center-Fabric-Overlays. OcNOS-DC implementiert EVPN nach RFC 8365 mit VXLAN-Kapselung: Type-2-Routen für die MAC/IP-Ankündigung, Type-5-Routen für die Verteilung von IP-Präfixen sowie sowohl symmetrisches als auch asymmetrisches Integrated Routing and Bridging (IRB). Leaf-Switches fungieren als VXLAN Tunnel Endpoints (VTEPs) mit verteilter Anycast-Gateway-Funktion für optimales Intra-Fabric-Routing. ARP-Suppression reduziert den Broadcast-Verkehr im großen Maßstab. Der BGP-Underlay folgt der Data-Center-Architektur nach RFC 7938 mit eBGP-unnumbered-Interfaces auf jedem Leaf-Spine-Link.
Kann OcNOS-DC Arista EOS oder Cisco NX-OS im eigenen Data Center ersetzen?
Ja. OcNOS-DC bietet Funktionsparität für klassische EVPN-VXLAN-Leaf-Spine-Deployments. Es läuft auf denselben Broadcom-Tomahawk- und -Trident-ASICs, die in Arista- und Cisco-Hardware verbaut sind, jedoch auf offenen ODM-Plattformen von Edgecore, UfiSpace und Celestica. Kunden erzielen damit typischerweise substanzielle Hardware-CapEx-Einsparungen gegenüber proprietären Systemen. IP Infusion bietet einen einheitlichen Support-Vertrag, der OcNOS-DC-Software und die Hardware-RMA-Koordination abdeckt, vergleichbar mit der operativen Einfachheit einer proprietären Lösung, jedoch ohne Vendor-Lock-in.
Was ist EVPN Multi-Homing und unterstützt OcNOS-DC es?
EVPN Multi-Homing (ESI-LAG) ermöglicht es einem Server oder Netzgerät, sich gleichzeitig mit zwei oder mehr Leaf-Switches in einer Active-Active- oder Active-Standby-Konfiguration zu verbinden — ohne eine klassische MLAG-Domäne. OcNOS-DC unterstützt EVPN Multi-Homing (Active-Active) auf Basis von Ethernet Segment Identifiers (ESI) und liefert Redundanz und optimale Verkehrsverteilung ohne die operative Komplexität proprietärer MLAG-Protokolle.
Wie realisiert OcNOS-DC die Mandantentrennung in einem DC Fabric?
Multi-Tenant-Isolation wird über VXLAN Network Identifiers (VNIs) realisiert. OcNOS-DC unterstützt sowohl Layer-2-VNIs für gebridgte Tenant-Domänen als auch Layer-3-VNIs für geroutete Inter-Tenant-Kommunikation über symmetrisches IRB. Jede Tenant-VRF ist auf der Data Plane isoliert. EVPN E-Tree (Szenario 1) bietet zusätzliche Leaf-zu-Leaf-Isolation innerhalb eines Tenants für Anwendungsfälle, die Spoke-zu-Spoke-Verkehrskontrolle erfordern. BGP-RPKI-Validierung sichert die Routing-Control-Plane an der Fabric-Edge.
Unterstützt OcNOS-DC Zero Touch Provisioning für Leaf-Spine-Deployments?
Ja. OcNOS-DC unterstützt DHCP-basiertes ZTP über IPv4 und IPv6. Ein neuer Leaf-Switch bootet, fordert seine Konfiguration über DHCP-Option 67 an, und OcNOS-DC lädt und übernimmt die vollständige Konfiguration automatisch, einschließlich eBGP-Sessions, EVPN-Address-Families, VNI-Mappings und DCBX-Profilen. In Verbindung mit IP Maestro für das Lifecycle-Management und gNMI-Streaming-Telemetrie ermöglicht OcNOS-DC einen vollautomatischen Betrieb von Day 0 bis Day 2, ohne manuelle CLI-Eingriffe.
Welche Automatisierungstools unterstützt OcNOS-DC für das DC-Fabric-Management?
OcNOS-DC ist auf einen Automation-first-Betrieb ausgelegt: NETCONF/YANG 1.1 und OpenConfig-Modelle für modellgetriebene Konfiguration, gNMI mit Dial-in- und Dial-out-Streaming-Telemetrie für Echtzeit-Sichtbarkeit, Ansible-Playbooks für idempotente fabric-weite Deployments, ein Terraform-Provider für Infrastructure-as-Code-Workflows sowie sFlow für Traffic-Sampling. Die Docker- und Kubernetes-Unterstützung in OcNOS 7.0 erlaubt es, Monitoring-Agents von Drittanbietern direkt auf der Switch-CPU laufen zu lassen — separate Collector-Infrastruktur entfällt.