OcNOS-DC · EVPN-VXLAN · Per-tenant VRF

Every tenant isolated on one shared GPU fabric.

A multi-tenant data center fabric keeps every tenant isolated on shared switches and GPU pods, each in its own VRF and VXLAN VNIs. Where tenants need a shared service, inter-VRF route leaking over VXLAN-EVPN opens only the prefixes you permit. IP Infusion delivers it as one system: validated open switches running OcNOS-DC, supported under one contract.

See the isolation model OcNOS-DC データシート
実績

One validated system, isolation built in.

IP Infusion validates the complete switch on 17 open data center platforms, pre-loads OcNOS-DC, and supports it under one contract. Per-tenant isolation is a validated capability of that system, mapped in the OcNOS feature matrix, not an add-on you assemble yourself.

検証済みハードウェア

検証済みデータセンタープラットフォーム17機種

各リーフ、スパイン、ボーダースイッチは lab-qualified per ASIC stepping with OcNOS-DC pre-loaded, so the fabric you design is the fabric that ships.

See the hardware list →
Feature depth

Per-tenant VRF and VNI in the matrix

Per-tenant VRF, the Layer 2 and Layer 3 VNIs, the anycast gateway, and inter-VRF route leaking are each mapped to the platforms that support them.

Check the feature matrix →
One contract

One system, one support contract

1つのチームが担うのは software, switch, and RMA, and you still refresh the hardware and OcNOS-DC on independent cycles.

See OcNOS-DC →

A track record behind the system. IP Infusion has shipped production networking systems for 27 years, and OcNOS runs in production networks with 600+ operators across 60+ countries, so the multi-tenant fabric arrives as a complete system with a long field record.

The isolation model

Pick a tenant and watch its lane light up.

Three tenants share the same leaves and GPU pods. Select one to see its VRF, its Layer 2 and Layer 3 VNIs, and the one route-leak path that reaches a shared service.

Multi-tenant EVPN-VXLAN data center fabric: three tenants sharing the same open leaf switches and GPU pods, each in its own VRF with its own Layer 2 and Layer 3 VNIs, with a single inter-VRF route-leak path passing only the permitted shared-service prefixes between two tenants.
Multi-tenant fabric: three tenants share the same open leaves and GPU pods, each isolated in its own VRF and VNIs, with one controlled inter-VRF route-leak path to a shared service.
Fabric の内部

Four things keep tenants apart.

Each tenant lives in its own VRF and its own VNIs, so its traffic is encapsulated and routed separately from every other tenant. A distributed anycast gateway gives each tenant the same gateway on any leaf, and EVPN multihoming keeps a tenant connected when a link or leaf fails.

VRF

A private routing table per tenant

You give each tenant its own VRF, so its routing table stays separate from every other tenant on the shared fabric. Isolation is the default, and reaching another tenant takes an explicit route leak you configure.

EVPN-VXLAN →
VXLAN

Every tenant encapsulated on its own VNIs

Each tenant crosses the fabric on its own identifiers: a Layer 2 VNI carries its bridged traffic and a Layer 3 VNI carries its routed traffic, using the prefix route for EVPN IRB, so no two tenants share an encapsulation on the shared switches.

VXLAN →
Anycast GW

The same gateway on every leaf

各リーフは次を提示 same gateway IP and MAC for a tenant's subnet, so a workload is always one hop from its gateway and keeps its default route when it moves between leaves or pods.

Anycast gateway →
ESI-LAG

A tenant stays up when a leaf fails

VXLAN 向け Layer 2 EVPN マルチホーミング attaches a tenant to two or more leaves in active-active mode over an Ethernet Segment, so both links forward and a leaf failure is transparent to that tenant.

EVPN multihoming →

This builds on the base EVPN-VXLAN leaf-spine fabric. See the data center fabric page for how the leaves, spines, and underlay fit together →

The differentiator

Share a service between tenants, on purpose.

Isolation is the default, so no tenant reaches another unless you allow it. Inter-VRF route leaking over VXLAN-EVPN passes only the specific prefixes you permit between two tenant VRFs, so a shared service such as storage or a management network is reachable while the rest of each tenant stays private.

The controlled leak

Leak only the prefixes you name

With inter-VRF route leaking for user-defined VRFs, you advertise a named set of prefixes from one tenant VRF into another, so only that service is reachable and every path between tenants is one you configured.

This runs over the VXLAN-EVPN overlay itself, which not every multi-tenant design supports.

EVPN-VXLAN →
Shared services

Storage and shared services

Place a shared service such as storage or a management network in its own VRF, and leak its prefixes only into the tenants allowed to reach it, so the tenants share the service without reaching each other.

The same open switches also run the lossless RoCEv2 set for GPU traffic, with the depth on the AI fabric page.

AI Fabric →
Why open

Built for neocloud and sovereign operators.

Neocloud and sovereign operators run many tenants on shared GPU and compute hardware, and they want each tenant isolated and their procurement free of a single supplier. An open multi-tenant fabric gives them both: per-tenant isolation on merchant-silicon switches from more than one vendor, delivered and supported as one system.

Sourcing

Multi-vendor open hardware

The fabric runs on open merchant-silicon switches from more than one hardware vendor, so your procurement is not tied to a single supplier.

Accountability

One accountable vendor for the whole system

IP Infusion validates and supports the switch, OcNOS-DC, and RMA as one system, so one vendor is accountable for the integrated fabric.

Lifecycle

Refresh on independent cycles

You refresh the switch and OcNOS-DC on independent cycles, so a hardware refresh and a software upgrade are separate decisions.

Procurement

Procurement without proprietary lock-in

Because the hardware is open and the software is portable across it, you avoid proprietary lock-in while keeping one support relationship.

プラットフォーム

Switches validated for the multi-tenant fabric.

IP Infusion は次の基盤でファブリックを提供します: 検証済みデータセンタープラットフォーム17機種 from Edgecore and UfiSpace, each lab-qualified per ASIC stepping with OcNOS-DC pre-loaded. Leaves attach tenants and host the anycast gateway, spines carry the underlay, and a border switch hands off tenant prefixes externally.

Validated data center switches by tenant-fabric role. Last verified: Jul 2026.
役割 Validated switch シリコンと容量 そのロールに適合する理由
Leaf: tenant attach and VTEP Edgecore AS9726-32DB／UfiSpace S9300-32D Broadcom Trident 4、12.8 Tbps、400G Where tenants attach: the VTEP, per-tenant VRF and VNIs, the distributed anycast gateway, and EVPN multihoming.
Spine: underlay and route reflection Edgecore AS9736-64D Broadcom Tomahawk 4、25.6 Tbps、400G Carries every tenant's underlay with overlay ECMP and EVPN route reflection; it holds no tunnel endpoints, so all per-tenant state stays on the leaves.
スパイン ／ スーパースパイン（800G） Edgecore AIS800-64D／UfiSpace S9321-64E Broadcom Tomahawk 5、51.2 Tbps、800G 800G scale-out for the largest shared fabrics. The AIS800-64D uses QSFP-DD800 optics.
Border: external tenant-prefix handoff UfiSpace S9321-64EO Broadcom Tomahawk 5, 51.2 Tbps, 800G plus ZR+ Hands off each tenant's prefixes externally and lights an interconnect wavelength directly with integrated ZR+ coherent optics.
100G leaf ／ ToR Edgecore AS7726-32X／UfiSpace S9110-32X Broadcom Trident 3、3.2 Tbps、100G Access-tier tenant attach for 25G and 100G server and pod racks.

17 validated data center platforms. See every validated platform in the hardware compatibility list, and match features to hardware in the フィーチャーマトリクス.

Which switch for which tenant role

  • Leaf, tenant attach. Put tenant-facing leaves on 400G Trident 4 for the VTEP, per-tenant VRF and VNIs, the anycast gateway, and EVPN multihoming, or on a 100G Trident 3 leaf for 25G and 100G racks.
  • Spine, underlay and route reflection. Put spines on 400G Tomahawk 4, or on 800G Tomahawk 5 when the shared fabric scales wider, and add spines rather than touching the leaves.
  • Border, external handoff. Use the S9321-64EO to hand off each tenant's prefixes externally and, where a tenant spans sites, to light the interconnect wavelength directly.
  • One contract. IP Infusion はすべてのロールを一つのシステムとして検証・サポートし、スイッチと OcNOS-DC は独立したサイクルで更新されます。
リソース

Solution brief and datasheet.

The EVPN-VXLAN fabric brief and the OcNOS-DC datasheet to share with your team. Quick form, and the PDF downloads immediately.

ソリューションブリーフ

EVPN-VXLAN データセンターファブリック

How the fabric keeps tenants isolated: per-tenant VRF, Layer 2 and Layer 3 VNIs, and the controlled inter-VRF leak on open switches.

概要資料を入手
データシート

OcNOS-DC データシート

OcNOS-DC の概要：ファブリックの機能セット、検証済みのデータセンターハードウェア、運用を 1 つの PDF で。

データシートを入手
評価の前に

Questions about tenant isolation.

Each tenant runs in its own VRF and its own set of VXLAN network identifiers. A Layer 2 VNI carries a tenant's bridged traffic and a Layer 3 VNI carries its routed traffic inside that tenant's VRF, so traffic is encapsulated and routed per tenant and one tenant cannot see another on the shared switches and GPU pods. Each tenant reaches the same gateway on any leaf through a distributed anycast gateway. Isolation is the default: two tenants reach each other only where you allow it. IP Infusion delivers this as one system, with the switch, OcNOS-DC, and one support contract.
Use inter-VRF route leaking when two tenants need a common resource such as a storage network, a management network, or a shared inference service. It passes only the selected IP prefixes from one tenant VRF into another, so that one service becomes reachable while the rest of each tenant stays private. On this fabric the leak runs over the VXLAN-EVPN overlay itself and carries only the prefixes you name, so sharing is always explicit and scoped to what you permit.
A VLAN alone leaves tenants sharing one IP routing domain, because it separates traffic only at Layer 2 within a single routing table. A per-tenant VRF closes that gap: each tenant gets its own routing table, and its own Layer 2 and Layer 3 VNIs carry it across the fabric, so tenants are separated in both bridging and routing. That is why a VRF-and-VNI model isolates tenants end to end on a shared fabric where VLANs alone would not, and why reaching another tenant requires an explicit inter-VRF route leak.
Yes. You place the shared service in its own VRF and use inter-VRF route leaking to advertise only that service's prefixes into the tenant VRFs allowed to reach it, so each tenant reaches the shared service while the tenants never reach each other. Every path between VRFs is one you configured on purpose, and because the leak carries only the prefixes you name, the shared storage or management network is reachable while the rest of each tenant stays isolated.
A workload is always one hop from its gateway no matter which leaf it lands behind, because the fabric runs a distributed anycast gateway and every leaf presents the same gateway IP and MAC for a tenant's subnet. The workload keeps its default route when it moves between leaves or pods. Because the gateway is distributed across the leaves rather than pinned to one switch, a tenant's routing does not depend on where its servers or GPU pods physically attach.
Yes. Neocloud and sovereign operators run many tenants on shared GPU and compute hardware and need each tenant isolated, which is exactly what per-tenant VRF and VNI isolation provides. The fabric runs on open merchant-silicon switches from more than one hardware vendor, so procurement is not tied to a single supplier, and the switch and OcNOS-DC refresh on independent cycles. IP Infusion delivers and supports the complete system under one contract, so one vendor is accountable for the integrated fabric.
ファブリックを評価

Design your multi-tenant fabric.

See how IP Infusion delivers the multi-tenant fabric as one system, or contact us to map your tenants, shared services, and platforms to the right validated switches.

See OcNOS-DC お問い合わせ How to buy
ブログより

ブログの関連記事

EVPN-VXLAN Leaf-SpineファブリックにおけるオーバーレイECMP、Part 1

How EVPN-VXLAN overlay ECMP load-balances tenant traffic across a Clos leaf-spine fabric

記事を読む →

EVPN-VXLAN Leaf-SpineファブリックにおけるオーバーレイECMP、Part 2

The second part of the EVPN-VXLAN overlay ECMP walk-through for the shared fabric

記事を読む →
すべてのブログ記事 →