OcNOS-DC · EVPN-VXLAN · VRF pro Mandant

Jeder Mandant isoliert auf einer gemeinsamen GPU-Fabric.

Eine mandantenfähige Rechenzentrums-Fabric hält jeden Mandanten auf gemeinsam genutzten Switches und GPU-Pods isoliert, jeden in seiner eigenen VRF und VXLAN VNIs. Wo Mandanten einen gemeinsamen Dienst benötigen, öffnet Inter-VRF-Route-Leaking über VXLAN-EVPN nur die Präfixe, die Sie erlauben. IP Infusion liefert sie als ein System: validierte offene Switches mit OcNOS-DC, supported under one contract.

Das Isolationsmodell ansehen OcNOS-DC-Datenblatt

Ein validiertes System, Isolation integriert.

IP Infusion validiert den kompletten Switch auf 18 offenen Rechenzentrumsplattformen, installiert OcNOS-DC vor und unterstützt ihn unter einem Vertrag. Isolation pro Mandant ist eine validierte Fähigkeit dieses Systems, abgebildet in der OcNOS Feature Matrix, und kein Add-on, das Sie selbst zusammenbauen.

18 validierte Rechenzentrumsplattformen

Jeder Leaf, jeder Spine und jeder Border-Switch ist pro ASIC-Stepping im Labor qualifiziert mit vorinstalliertem OcNOS-DC, sodass die Fabric, die Sie entwerfen, die Fabric ist, die geliefert wird.

Hardwareliste ansehen →

VRF und VNI pro Mandant in der Matrix

VRF pro Mandant, die Layer-2- und Layer-3-VNIs, das Anycast-Gateway und Inter-VRF-Route-Leaking sind jeweils den Plattformen zugeordnet, die sie unterstützen.

Feature-Matrix prüfen →

Ein System, ein Supportvertrag

Ein Team verantwortet Software, Switch und RMA, und Sie erneuern Hardware und OcNOS-DC weiterhin in unabhängigen Zyklen.

OcNOS-DC ansehen →

Eine Erfolgsbilanz hinter dem System. IP Infusion liefert Netzwerksysteme für den Produktivbetrieb seit 1999, und OcNOS läuft in Produktivnetzen bei über 600 Betreibern in mehr als 60 Ländern, sodass die Multi-Tenant-Fabric als komplettes System mit langer Praxiserfahrung kommt.

Wählen Sie einen Mandanten und sehen Sie, wie seine Spur aufleuchtet.

Drei Mandanten teilen dieselben Leaves und GPU-Pods. Wählen Sie einen aus, um seine VRF, seine Layer-2- und Layer-3-VNIs und den einen Route-Leak-Pfad zu sehen, der einen gemeinsamen Dienst erreicht.

Multi-Tenant-EVPN-VXLAN-Rechenzentrums-Fabric: Drei Mandanten teilen dieselben offenen Leaf-Switches und GPU-Pods, jeder in seiner eigenen VRF mit eigenen Layer-2- und Layer-3-VNIs, mit einem einzigen Inter-VRF-Route-Leak-Pfad, der nur die erlaubten Präfixe des gemeinsamen Dienstes zwischen zwei Mandanten durchlässt.
Multi-Tenant-Fabric: Drei Mandanten teilen dieselben offenen Leaves und GPU-Pods, jeder isoliert in eigener VRF und eigenen VNIs, mit einem kontrollierten Inter-VRF-Route-Leak-Pfad zu einem gemeinsamen Dienst.

Vier Dinge halten Mandanten getrennt.

Jeder Mandant lebt in seiner eigenen VRF und seinen eigenen VNIs, sodass sein Traffic getrennt von jedem anderen Mandanten gekapselt und geroutet wird. Ein verteiltes Anycast-Gateway gibt jedem Mandanten an jedem Leaf dasselbe Gateway, und EVPN-Multihoming hält einen Mandanten verbunden, wenn ein Link oder Leaf ausfällt.

VRF

Eine private Routing-Tabelle pro Mandant

Sie geben jedem Mandanten seine eigene VRF, sodass seine Routing-Tabelle von jedem anderen Mandanten auf der gemeinsamen Fabric getrennt bleibt. Isolation ist der Standard, und um einen anderen Mandanten zu erreichen, braucht es ein explizites Route Leak, das Sie konfigurieren.

EVPN-VXLAN →
VXLAN

Jeder Mandant gekapselt auf eigenen VNIs

Jeder Mandant durchquert die Fabric mit eigenen Kennungen: eine Layer-2-VNI trägt seinen gebridgten Traffic und eine Layer-3-VNI trägt seinen gerouteten Traffic, mit der Prefix-Route für EVPN IRB, sodass keine zwei Mandanten auf den gemeinsamen Switches dieselbe Kapselung teilen.

VXLAN →
Anycast-GW

Dasselbe Gateway auf jedem Leaf

Jeder Leaf präsentiert das dieselbe Gateway-IP und MAC für das Subnetz eines Mandanten, sodass ein Workload immer einen Hop von seinem Gateway entfernt ist und seine Default-Route behält, wenn er zwischen Leaves oder Pods wechselt.

Anycast-Gateway →
ESI-LAG

Ein Mandant bleibt aktiv, wenn ein Leaf ausfällt

Layer-2-EVPN-Multihoming für VXLAN bindet einen Mandanten im Active-Active-Modus über ein Ethernet-Segment an zwei oder mehr Leaves an, sodass beide Links weiterleiten und ein Leaf-Ausfall für diesen Mandanten transparent ist.

EVPN-Multihoming →

Dies baut auf der grundlegenden EVPN-VXLAN-Leaf-Spine-Fabric auf. Auf der Seite zur Rechenzentrums-Fabric sehen Sie, wie Leaves, Spines und Underlay zusammenspielen →

Einen Dienst zwischen Mandanten teilen, ganz bewusst.

Isolation ist der Standard, daher erreicht kein Mandant einen anderen, sofern Sie es nicht erlauben. Inter-VRF-Route-Leaking über VXLAN-EVPN lässt nur die spezifischen Präfixe zwischen zwei Mandanten-VRFs durch, die Sie erlauben, sodass ein gemeinsamer Dienst wie Storage oder ein Management-Netz erreichbar ist, während der Rest jedes Mandanten privat bleibt.

Nur die Präfixe leaken, die Sie benennen

Mit Inter-VRF-Route-Leaking für benutzerdefinierte VRFs kündigen Sie eine benannte Präfixmenge von einer Mandanten-VRF in eine andere an, sodass nur dieser Dienst erreichbar ist und jeder Pfad zwischen Mandanten einer ist, den Sie konfiguriert haben.

Dies läuft über das VXLAN-EVPN-Overlay selbst, sodass das Leak innerhalb des bestehenden Overlays bleibt.

EVPN-VXLAN →

Storage und gemeinsame Dienste

Platzieren Sie einen gemeinsamen Dienst wie Storage oder ein Management-Netz in einer eigenen VRF und leaken Sie seine Präfixe nur in die Mandanten, die ihn erreichen dürfen, sodass die Mandanten den Dienst teilen, ohne einander zu erreichen.

Dieselben offenen Switches betreiben auch den verlustfreien RoCEv2-Funktionssatz für GPU-Traffic; die Details stehen auf der AI-Fabric-Seite.

AI-Fabric →

Entwickelt für Neocloud- und souveräne Betreiber.

Neocloud- und souveräne Betreiber betreiben viele Mandanten auf gemeinsamer GPU- und Compute-Hardware und wollen jeden Mandanten isoliert und ihre Beschaffung unabhängig von einem einzelnen Lieferanten. Eine offene Multi-Tenant-Fabric bietet beides: Isolation pro Mandant auf Merchant-Silicon-Switches von mehr als einem Anbieter, geliefert und unterstützt als ein System.

Offene Multi-Vendor-Hardware

Die Fabric läuft auf offenen Merchant-Silicon-Switches von mehr als einem Hardwareanbieter, sodass Ihre Beschaffung nicht an einen einzelnen Lieferanten gebunden ist.

Ein verantwortlicher Anbieter für das gesamte System

IP Infusion validiert und unterstützt Switch, OcNOS-DC und RMA als ein System, sodass ein Anbieter für die integrierte Fabric verantwortlich ist.

Erneuerung in unabhängigen Zyklen

Sie erneuern Switch und OcNOS-DC in unabhängigen Zyklen, sodass Hardware-Refresh und Software-Upgrade getrennte Entscheidungen sind.

Beschaffung ohne proprietären Lock-in

Da die Hardware offen und die Software darauf portierbar ist, vermeiden Sie proprietären Lock-in und behalten dennoch eine einzige Supportbeziehung.

Für die Multi-Tenant-Fabric validierte Switches.

IP Infusion liefert die Fabric auf 18 validierte Rechenzentrumsplattformen von Edgecore und UfiSpace, jeweils pro Plattform im Labor qualifiziert, mit vorinstalliertem OcNOS-DC. Leaves binden Mandanten an und hosten das Anycast-Gateway, Spines tragen das Underlay, und ein Border-Switch übergibt Mandantenpräfixe nach außen.

Validierte Rechenzentrums-Switches nach Rolle in der Mandanten-Fabric. Zuletzt geprüft: Juli 2026.
Rolle Validierter Switch Silicon und Kapazität Warum er zur Rolle passt
Leaf: Mandantenanbindung und VTEP Edgecore AS9726-32DB / UfiSpace S9300-32D Broadcom Trident 4, 12.8 Tbps, 400G Wo Mandanten angebunden werden: der VTEP, VRF und VNIs pro Mandant, das verteilte Anycast-Gateway und EVPN-Multihoming.
Spine: Underlay und Route Reflection Edgecore AS9736-64D Broadcom Tomahawk 4, 25.6 Tbps, 400G Trägt das Underlay jedes Mandanten mit Overlay-ECMP und EVPN-Route-Reflection; er hält keine Tunnel-Endpunkte, sodass der gesamte Zustand pro Mandant auf den Leaves bleibt.
Spine / Super-Spine (800G) Edgecore AIS800-64D / UfiSpace S9321-64E Broadcom Tomahawk 5, 51.2 Tbps, 800G 800G-Scale-out für die größten gemeinsamen Fabrics. Der AIS800-64D verwendet QSFP-DD800-Optiken.
Border: externe Übergabe der Mandantenpräfixe UfiSpace S9321-64EO Broadcom Tomahawk 5, 51.2 Tbps, 800G OSFP Übergibt die Präfixe jedes Mandanten nach außen und schaltet eine Interconnect-Wellenlänge direkt mit kohärenten ZR+-Pluggables auf.
100G-Leaf / ToR Edgecore AS7726-32X / UfiSpace S9110-32X Broadcom Trident 3, 3.2 Tbps, 100G Mandantenanbindung auf Access-Ebene für 25G- und 100G-Server- und Pod-Racks.

18 validierte Rechenzentrumsplattformen. Alle validierten Plattformen finden Sie in der Hardware-Kompatibilitätsliste, und ordnen Sie Features der Hardware zu in der Feature-Matrix.

Welcher Switch für welche Mandantenrolle

  • Leaf, Mandantenanbindung. Setzen Sie mandantenseitige Leaves auf 400G Trident 4 für VTEP, VRF und VNIs pro Mandant, das Anycast-Gateway und EVPN-Multihoming, oder auf einen 100G Trident 3 Leaf für 25G- und 100G-Racks.
  • Spine, Underlay und Route Reflection. Setzen Sie Spines auf 400G Tomahawk 4 oder auf 800G Tomahawk 5, wenn die gemeinsame Fabric breiter skaliert, und fügen Sie Spines hinzu, statt die Leaves anzufassen.
  • Border, externe Übergabe. Nutzen Sie den S9321-64EO, um die Präfixe jedes Mandanten nach außen zu übergeben und, wenn ein Mandant mehrere Standorte umfasst, die Interconnect-Wellenlänge direkt aufzuschalten.
  • Ein Vertrag. IP Infusion validiert und unterstützt jede Rolle als ein System, und Switch und OcNOS-DC werden in unabhängigen Zyklen erneuert.

Solution Brief und Datenblatt.

Der EVPN-VXLAN-Fabric-Brief und das OcNOS-DC-Datenblatt zum Teilen mit Ihrem Team. Kurzes Formular, und das PDF wird sofort heruntergeladen.

Solution Brief

EVPN-VXLAN-Data-Center-Fabric

Wie die Fabric Mandanten isoliert hält: VRF pro Mandant, Layer-2- und Layer-3-VNIs und das kontrollierte Inter-VRF-Leak auf offenen Switches.

Brief anfordern
Datenblatt

OcNOS-DC-Datenblatt

Der OcNOS-DC-Überblick: der Fabric-Funktionsumfang, die validierte Rechenzentrums-Hardware und der Betrieb, in einem PDF.

Datenblatt abrufen

Fragen zur Mandantenisolation.

Jeder Mandant läuft in seiner eigenen VRF und mit seinem eigenen Satz an VXLAN Network Identifiers. Eine Layer-2-VNI trägt den gebridgten Traffic eines Mandanten und eine Layer-3-VNI seinen gerouteten Traffic innerhalb der VRF dieses Mandanten, sodass Traffic pro Mandant gekapselt und geroutet wird und ein Mandant auf den gemeinsamen Switches und GPU-Pods keinen anderen sehen kann. Jeder Mandant erreicht über ein verteiltes Anycast-Gateway an jedem Leaf dasselbe Gateway. Isolation ist der Standard: Zwei Mandanten erreichen einander nur dort, wo Sie es erlauben. IP Infusion liefert dies als ein System, mit Switch, OcNOS-DC und einem Supportvertrag.
Setzen Sie Inter-VRF-Route-Leaking ein, wenn zwei Mandanten eine gemeinsame Ressource benötigen, etwa ein Storage-Netz, ein Management-Netz oder einen gemeinsamen Inferenzdienst. Es lässt nur die ausgewählten IP-Präfixe von einer Mandanten-VRF in eine andere durch, sodass dieser eine Dienst erreichbar wird, während der Rest jedes Mandanten privat bleibt. In dieser Fabric läuft das Leak über das VXLAN-EVPN-Overlay selbst und trägt nur die Präfixe, die Sie benennen, sodass eine gemeinsame Nutzung immer explizit und auf das Erlaubte begrenzt ist.
Ein VLAN allein lässt Mandanten eine gemeinsame IP-Routing-Domäne teilen, weil es Traffic nur auf Layer 2 innerhalb einer einzigen Routing-Tabelle trennt. Eine VRF pro Mandant schließt diese Lücke: Jeder Mandant erhält seine eigene Routing-Tabelle, und seine eigenen Layer-2- und Layer-3-VNIs tragen ihn über die Fabric, sodass Mandanten sowohl beim Bridging als auch beim Routing getrennt sind. Deshalb isoliert ein Modell aus VRF und VNI Mandanten auf einer gemeinsamen Fabric Ende-zu-Ende, wo VLANs allein es nicht würden, und deshalb erfordert das Erreichen eines anderen Mandanten ein explizites Inter-VRF-Route-Leak.
Ja. Sie platzieren den gemeinsamen Dienst in einer eigenen VRF und kündigen mit Inter-VRF-Route-Leaking nur die Präfixe dieses Dienstes in die Mandanten-VRFs an, die ihn erreichen dürfen, sodass jeder Mandant den gemeinsamen Dienst erreicht, die Mandanten einander aber nie. Jeder Pfad zwischen VRFs ist einer, den Sie bewusst konfiguriert haben, und da das Leak nur die von Ihnen benannten Präfixe trägt, ist das gemeinsame Storage- oder Management-Netz erreichbar, während der Rest jedes Mandanten isoliert bleibt.
Ein Workload ist immer einen Hop von seinem Gateway entfernt, egal hinter welchem Leaf er landet, weil die Fabric ein verteiltes Anycast-Gateway betreibt und jeder Leaf für das Subnetz eines Mandanten dieselbe Gateway-IP und MAC präsentiert. Der Workload behält seine Default-Route, wenn er zwischen Leaves oder Pods wechselt. Da das Gateway über die Leaves verteilt und nicht an einen Switch gebunden ist, hängt das Routing eines Mandanten nicht davon ab, wo seine Server oder GPU-Pods physisch angebunden sind.
Ja. Neocloud- und souveräne Betreiber betreiben viele Mandanten auf gemeinsamer GPU- und Compute-Hardware und müssen jeden Mandanten isolieren, genau das leistet die Isolation per VRF und VNI pro Mandant. Die Fabric läuft auf offenen Merchant-Silicon-Switches von mehr als einem Hardwareanbieter, sodass die Beschaffung nicht an einen einzelnen Lieferanten gebunden ist, und Switch und OcNOS-DC werden in unabhängigen Zyklen erneuert. IP Infusion liefert und unterstützt das komplette System unter einem Vertrag, sodass ein Anbieter für die integrierte Fabric verantwortlich ist.
Die Fabric evaluieren

Gestalten Sie Ihre Multi-Tenant-Fabric.

Sehen Sie, wie IP Infusion die Multi-Tenant-Fabric als ein System liefert, oder kontaktieren Sie uns, um Ihre Mandanten, gemeinsamen Dienste und Plattformen den passenden validierten Switches zuzuordnen.

OcNOS-DC ansehen Kontakt So kaufen Sie
Aus dem Blog

Passend aus dem Blog

Overlay-ECMP in einer EVPN-VXLAN-Leaf-Spine-Fabric, Teil 1

Wie Overlay-ECMP in EVPN-VXLAN den Mandanten-Traffic über eine Clos-Leaf-Spine-Fabric verteilt

Beitrag lesen →

Overlay-ECMP in einer EVPN-VXLAN-Leaf-Spine-Fabric, Teil 2

Der zweite Teil der Einführung in Overlay-ECMP mit EVPN-VXLAN für die gemeinsame Fabric

Beitrag lesen →
Alle Blog-Beiträge →