OcNOS-DC · EVPN-VXLAN · 按租户 VRF

每个租户都在同一个共享 GPU fabric 上保持隔离。

多租户数据中心 fabric 使每个租户在共享交换机与 GPU pod 上保持隔离,各自拥有独立的 VRF 和 VXLAN VNIs。当租户需要共享业务时,基于 VXLAN-EVPN 的 VRF 间路由泄露仅开放您允许的前缀。 IP Infusion 将其作为一个系统交付:经过验证的开放交换机,运行 OcNOS-DC, supported under one contract.

实证

一个经过验证的系统,内置隔离。

IP Infusion 在 18 款开放数据中心平台上验证完整交换机,预装 OcNOS-DC,并由一份合同提供支持。按租户隔离是该系统经过验证的能力,已在 OcNOS 功能矩阵中列出,而非需要您自行组装的附加组件。

18 款经过验证的数据中心平台

每个 leaf、spine 和 border 交换机都 按 ASIC 步进版本完成实验室认证 ,预装 OcNOS-DC,因此您设计的 fabric 就是最终交付的 fabric。

功能矩阵中的按租户 VRF 与 VNI

按租户 VRF、二层与三层 VNI、anycast 网关以及 VRF 间路由泄露均已 对应到支持它们的平台 。

一个系统,一份支持合同

一个团队负责 软件、交换机与 RMA,同时您仍可按各自独立的周期更新硬件与 OcNOS-DC。

系统背后的实践记录。 IP Infusion 交付生产级网络系统 自 1999 年起,OcNOS 运行于 60+ 个国家的 600+ 家运营商的生产网络中,因此多租户 fabric 作为拥有长期现网记录的完整系统交付。

隔离模型

选择一个租户,查看其通道点亮。

三个租户共享相同的 leaf 与 GPU pod。选择其中一个,可查看其 VRF、二层与三层 VNI,以及通往共享业务的唯一路由泄露路径。

多租户 EVPN-VXLAN 数据中心 fabric:三个租户共享相同的开放 leaf 交换机与 GPU pod,各自位于自己的 VRF 中并拥有自己的二层与三层 VNI,另有一条 VRF 间路由泄露路径,仅在两个租户之间传递允许的共享业务前缀。
多租户 fabric:三个租户共享相同的开放 leaf 与 GPU pod,各自隔离在自己的 VRF 与 VNI 中,并有一条受控的 VRF 间路由泄露路径通往共享业务。
fabric 内部

四项机制让租户彼此隔离。

每个租户都位于自己的 VRF 与 VNI 中,因此其流量与其他所有租户分别封装与路由。 分布式任播网关 为每个租户在任一 leaf 上提供相同网关,EVPN 多归属则在链路或 leaf 故障时保持租户连接。

VRF

每个租户一张私有路由表

为每个租户分配独立的 VRF,使其路由表与共享 fabric 上的其他租户保持分离。隔离是默认状态,访问其他租户需要您明确配置路由泄露。

VXLAN

每个租户封装在自己的 VNI 上

每个租户以自己的标识符穿越 fabric: 二层 VNI 承载其桥接流量, 三层 VNI 承载其路由流量,使用用于 EVPN IRB 的前缀路由,因此在共享交换机上没有两个租户共用同一封装。

Anycast 网关

每台 leaf 上相同的网关

每个 leaf 都呈现 相同的网关 IP 与 MAC (针对租户子网),因此工作负载与其网关始终只有一跳之隔,在 leaf 或 pod 之间迁移时保持默认路由。

ESI-LAG

leaf 故障时租户保持在线

面向 VXLAN 的二层 EVPN 多归属 通过 Ethernet Segment 以 active-active 模式将租户连接到两台或更多 leaf,使两条链路都转发流量,leaf 故障对该租户透明。

这建立在基础 EVPN-VXLAN leaf-spine fabric 之上。请参阅 数据中心 fabric 页面 ,了解 leaf、spine 与 underlay 如何协同 →

差异化优势

有意地在租户之间共享业务。

隔离是默认状态,除非您允许,否则任何租户都无法访问其他租户。 基于 VXLAN-EVPN 的 VRF 间路由泄露 仅在两个租户 VRF 之间传递您允许的特定前缀,因此存储或管理网络等共享业务可被访问,而每个租户的其余部分保持私有。

只泄露您指定的前缀

借助用户定义 VRF 的 VRF 间路由泄露,可以将指定的一组前缀从一个租户 VRF 通告到另一个,因此只有该业务可达,租户之间的每条路径都经过明确配置。

这一过程直接运行于 VXLAN-EVPN overlay 之上,使泄露保持在现有 overlay 之内。

存储与共享业务

将共享业务,例如 存储或管理网络 ,放入其独立 VRF,并仅将其前缀泄露给允许访问的租户,使租户共享该业务而不会互相访问。

同样的开放交换机也为 GPU 流量运行无损 RoCEv2 功能集,详情请见 AI fabric 页面。

为何选择开放

为 neocloud 与主权运营方打造。

neocloud 与主权运营方在共享的 GPU 与计算硬件上运行众多租户,他们希望每个租户彼此隔离,并且采购不依赖单一供应商。 开放多租户 fabric 可同时满足这两点:在来自多家厂商的通用芯片交换机上实现按租户隔离,并作为一个系统交付和支持。

多厂商开放硬件

fabric 运行于 来自多家硬件厂商的开放通用芯片交换机,因此您的采购不受单一供应商约束。

由一家厂商对整个系统负责

IP Infusion 将 交换机、OcNOS-DC 与 RMA 作为一个系统进行验证与支持,因此由一家厂商对集成 fabric 负责。

按独立周期更新

您可以 按独立周期更新交换机与 OcNOS-DC,因此硬件更新与软件升级是两个独立的决策。

采购不受专有锁定

由于硬件是开放的,软件可在其上移植,您可以 避免专有锁定 ,同时保持单一支持关系。

平台

经过验证、适用于多租户 fabric 的交换机。

IP Infusion 交付 fabric,运行于 18 款经过验证的数据中心平台 ,来自 Edgecore 与 UfiSpace,每款均按平台完成实验室认证并预装 OcNOS-DC。leaf 接入租户并承载 anycast 网关,spine 承载 underlay,border 交换机则向外交接租户前缀。

按租户 fabric 角色划分的经过验证的数据中心交换机。最后核实:2026 年 7 月。
角色 经过验证的交换机 芯片与容量 它为何契合该角色
Leaf:租户接入与 VTEP Edgecore AS9726-32DB / UfiSpace S9300-32D Broadcom Trident 4,12.8 Tbps,400G 租户接入位置:VTEP、按租户 VRF 与 VNI、分布式 anycast 网关以及 EVPN 多归属。
Spine:underlay 与路由反射 Edgecore AS9736-64D Broadcom Tomahawk 4,25.6 Tbps,400G 通过 overlay ECMP 与 EVPN 路由反射承载每个租户的 underlay;它不承载任何隧道端点,因此所有按租户的状态都保留在 leaf 上。
脊 / 超级脊(800G) Edgecore AIS800-64D / UfiSpace S9321-64E Broadcom Tomahawk 5,51.2 Tbps,800G 为最大规模的共享 fabric 提供 800G 横向扩展。AIS800-64D 使用 QSFP-DD800 光模块。
Border:对外交接租户前缀 UfiSpace S9321-64EO Broadcom Tomahawk 5,51.2 Tbps,800G 加 ZR+ 向外交接每个租户的前缀,并直接通过 ZR+ 相干可插拔光模块点亮互联波长。
100G 叶交换机 / ToR Edgecore AS7726-32X / UfiSpace S9110-32X Broadcom Trident 3,3.2 Tbps,100G 用于 25G 与 100G 服务器及 pod 机架的接入层租户接入。

18 款经过验证的数据中心平台。所有经过验证的平台请参阅 硬件兼容性列表,并将功能与硬件相匹配,请见 功能矩阵.

哪种交换机适用于哪种租户角色

  • Leaf,租户接入。 将接入租户的 leaf 部署在 400G Trident 4 上,用于 VTEP、按租户 VRF 与 VNI、anycast 网关以及 EVPN 多归属;对于 25G 与 100G 机架,可使用 100G Trident 3 leaf。
  • Spine,underlay 与路由反射。 将 spine 部署在 400G Tomahawk 4 上,当共享 fabric 需要更大规模时部署在 800G Tomahawk 5 上,并通过增加 spine 而非改动 leaf 来扩展。
  • Border,对外交接。 使用 S9321-64EO 向外交接每个租户的前缀,并在租户跨站点时直接点亮互联波长。
  • 一份合同。 IP Infusion 将每个角色作为一个系统进行验证和支持,交换机和 OcNOS-DC 按独立周期更新。
在评估之前

关于租户隔离的问题。

每个租户运行在自己的 VRF 与自己的一组 VXLAN 网络标识符中。二层 VNI 承载租户的桥接流量,三层 VNI 在该租户的 VRF 内承载其路由流量,因此流量按租户封装与路由,在共享交换机与 GPU pod 上一个租户无法看到另一个租户。每个租户通过分布式 anycast 网关在任一 leaf 上访问相同的网关。隔离是默认状态:两个租户只有在您允许的位置才能互相访问。IP Infusion 将其作为一个系统交付,包括交换机、OcNOS-DC 与一份支持合同。
当两个租户需要共同资源(例如存储网络、管理网络或共享推理服务)时,使用 VRF 间路由泄露。它仅将选定的 IP 前缀从一个租户 VRF 传递到另一个,使该业务可达,而每个租户的其余部分保持私有。在此 fabric 上,泄露直接运行于 VXLAN-EVPN overlay 之上,且只承载您指定的前缀,因此共享始终是明确的,并限定在您允许的范围内。
仅使用 VLAN 时,租户仍共享同一个 IP 路由域,因为 VLAN 只在单一路由表内于二层分隔流量。按租户 VRF 弥补了这一缺口:每个租户拥有自己的路由表,并由自己的二层与三层 VNI 承载其穿越 fabric,因此租户在桥接与路由两方面都相互分离。这就是 VRF 与 VNI 模型能在共享 fabric 上端到端隔离租户、而仅靠 VLAN 做不到的原因,也是访问其他租户需要明确的 VRF 间路由泄露的原因。
可以。您将共享业务放入其独立 VRF,并使用 VRF 间路由泄露,仅将该业务的前缀通告到允许访问它的租户 VRF 中,因此每个租户都能访问共享业务,而租户之间始终无法互相访问。VRF 之间的每条路径都是您有意配置的;由于泄露只承载您指定的前缀,共享存储或管理网络可被访问,而每个租户的其余部分保持隔离。
无论工作负载位于哪台 leaf 之后,它与网关始终只有一跳之隔,因为 fabric 运行分布式 anycast 网关,每台 leaf 都为租户子网提供相同的网关 IP 与 MAC。工作负载在 leaf 或 pod 之间迁移时保持默认路由。由于网关分布在各台 leaf 上,而非固定在某一台交换机上,租户的路由不取决于其服务器或 GPU pod 的物理接入位置。
适合。neocloud 与主权运营方在共享的 GPU 与计算硬件上运行众多租户,需要每个租户彼此隔离,而这正是按租户 VRF 与 VNI 隔离所提供的能力。fabric 运行于来自多家硬件厂商的开放通用芯片交换机,因此采购不受单一供应商约束,交换机与 OcNOS-DC 按独立周期更新。IP Infusion 交付完整系统并由一份合同提供支持,因此由一家厂商对集成 fabric 负责。
评估该 fabric

设计您的多租户 fabric。

了解 IP Infusion 如何将多租户 fabric 作为一个系统交付,或联系我们,将您的租户、共享业务与平台对应到合适的经过验证的交换机。