From DPU to Fabric: Multi-Tenant Network Automation with NVIDIA NICo and Aviz ONES

Multi-tenant AI infrastructure spans two networking domains. The first is the GPU host and DPU layer, where tenant networking begins. The second is the data center fabric, where that tenant needs to reach storage, shared services, and external networks. Both domains must work from the same tenant information.

NVIDIA Infra Controller (NICo) and Aviz ONES handle this by splitting the work clearly. NICo manages GPU hosts and their BlueField-3 DPUs and sets the network identity for each tenant. ONES takes that identity and extends it across the AI fabric.

NICo: The Source of Truth for Tenant Identity

NICo works closest to the workload. When a GPU server is assigned to a tenant, NICo configures its BlueField-3 DPU with the details needed to identify and isolate that tenant:

  • VLAN
  • VNI
  • VTEP information

Since these values are created during host provisioning, NICo holds the authoritative tenant network identity. The fabric does not assign its own identifiers. It uses the ones NICo already assigned.

ONES: Extending That Identity Across the Fabric

Aviz ONES manages the network around the GPU hosts, including the north-south part of the AI fabric. In the reference architecture, this covers:

  • Front-end fabric (leaf/spine)
  • Border leaf switches
  • Aviz Service Gateway
  • Firewall connectivity
  • Storage leaf

ONES connects to NICo as an infrastructure provider, pulls each tenant’s networking attributes, and uses them to configure the fabric. It does not build a separate tenant model. It turns NICo’s tenant definition into the configuration the network needs.

How Tenant Traffic Moves Beyond the Host

The BlueField-3 DPU is the first enforcement point for tenant networking. Traffic then flows through the front-end leaf-spine fabric toward storage, external networks, or shared infrastructure.

The Aviz Gateway is where tenant overlay connectivity can terminate before reaching external networks. It can also handle:

  • Tenant-aware routing
  • NAT and firewall
  • Load balancer
  • External network connectivity

Firewall policy controls which external destinations or services each tenant can reach. ONES programs all of these using the tenant information from NICo.

The Reference Architecture

GPU servers with BlueField-3 DPUs sit at the base and are managed by NICo. The DPUs connect into the front-end leaf-spine network. From there, tenant traffic reaches the border leaf switches and the Aviz Gateway, which ONES manages. Storage is connected through a separate storage leaf network.

What matters most is that tenant network identity stays the same across both domains. A tenant created at the GPU layer keeps the same networking context as its traffic crosses the fabric.

The Workflow, Step by Step

  1. Build the AI fabric in ONES. This sets up the physical topology ONES will manage.
  2. Register NICo as a provider. ONES connects using the NICo controller address and provider credentials.
  3. Create the tenant. The operator assigns GPU servers, and NICo provisions networking on the related BlueField-3 DPUs.
  4. Retrieve the tenant’s network identity. NICo returns identifiers such as VLAN, VNI, and VTEP information.
  5. Extend the tenant across the fabric. ONES configures the border leafs, Aviz Service Gateway, firewall, and storage-facing network with those same values.

Why One Source of Truth Matters

If two systems track tenant networking separately, they can drift apart. For example:

  • NICo: Tenant A → VLAN 100 → VNI 10100
  • Fabric: Tenant A → VLAN 200 → VNI 20200

Each may be valid on its own, but together the system is no longer deterministic. The better approach is a single flow:

Tenant creation → NICo assigns network identity → ONES discovers it → ONES extends it across the fabric

Key Takeaway

This integration sets a clear control-plane ownership model. NICo manages GPU infrastructure and tenant networking at the BlueField-3 DPU. ONES consumes that tenant definition and extends it across the AI network fabric. Each controller stays in its own domain, and the tenant network model stays consistent end to end, without a second source of tenant network identity.

Comments

Post a Comment

Popular posts from this blog

Scaling Deep Network Observability for 5G: Reflections from a Real Deployment

Image
  I recently went through a detailed implementation showing how deep network observability enhances 5G mobile user experience while reducing operational complexity. What stood out was how grounded the deployment was in real traffic and production-scale constraints. Some practical observations: • Fragmented systems increase cost and operational overhead • Frequent infrastructure upgrades create instability and repair expenses • Optimised filtering significantly reduces DPI hardware requirements • Real-time KPI computation improves SLA monitoring and service assurance • Standardised data export through streaming pipelines simplifies integration One misconception addressed during the walkthrough was that deeper observability automatically means more hardware. In reality, efficient filtering and intelligent packet processing reduce hardware footprint while improving performance. My biggest takeaway is that scalable observability in 5G environments requires architectural efficiency,...
Read more

Evolving Packet Brokering for Modern Network Observability

Image
  I recently reviewed a technical overview describing how packet brokering platforms are evolving to support large-scale observability in modern data centers and service provider networks. The discussion focused on scalability, automated deployment, and operational efficiency. Some practical observations: • Network visibility platforms are expanding support for 400G switching hardware used in modern data center fabrics • GRE encapsulation enables mirrored traffic to move across Layer-3 networks while preserving packet metadata • Zero-Touch Provisioning simplifies onboarding for new or factory-reset switches • Packet brokers aggregate traffic from TAPs and SPAN ports and apply filtering and distribution policies • CLI improvements help operators manage large monitoring environments more efficiently One notable element was how GRE tunneling extends observability beyond Layer-2 boundaries. By encapsulating mirrored traffic into GRE tunnels, monitoring systems can receive full packet c...
Read more

How Network Copilot Uses Agentic AI to Correlate FortiGate and Splunk

Image
I recently went through a detailed implementation explaining how Network Copilot correlates FortiGate firewall telemetry with operational data indexed in Splunk . What stood out was how grounded the discussion was in real operational workflows rather than theoretical AI claims. Some practical observations: • Network and security logs are typically distributed across multiple platforms • Troubleshooting often requires manually correlating events between systems • Network Copilot ingests metrics, events, logs, and traces from firewall environments • Operators can interact with the system using natural language questions • Explainable root cause analysis improves operational confidence One misconception addressed during the walkthrough was that AI in operations means replacing engineers. In reality, the system augments teams by surfacing insights faster and correlating information across environments. Another interesting point was how the platform learns from real firewall deployments...
Read more