Deploy host networking with Network ATC

This article guides you through the requirements, best practices, and deployment of Network ATC. Network ATC simplifies the deployment and network configuration management for Windows Server and Azure Local clusters. Network ATC provides an intent-based approach to host network deployment. By specifying one or more intents (management, compute, or storage) for a network adapter, you can automate the deployment of the intended configuration. For more information on Network ATC, including an overview and definitions, see Network ATC overview.

If you have feedback or encounter any issues, review the requirements and best practices section, check the Network ATC event log, and work with your Microsoft support team.

Prerequisites

Complete the following prerequisites for using Network ATC:

• All servers in the cluster must be running Windows Server 2025 or later for Windows Server, and version 2311.2 or later for Azure Local environments.

• Must use physical hosts that are certified for Windows Server or Azure Local. For hardware certified for Secured-core server, see Windows Server Catalog. For validated nodes or higher for Azure Local, see Azure Local catalog.

• Adapters in the same Network ATC intent must be symmetric (of the same make, model, speed, and configuration) and available on each cluster node.

  • Asymmetric adapters lead to a failure in deploying any intent. Network ATC automatically confirms adapter symmetry for all nodes in the cluster before deploying an intent.

  • For more information on adapter symmetry, see Switch Embedded Teaming (SET).

• Each physical adapter specified in an intent must use the same name on all nodes in the cluster.

• Ensure each network adapter has an "Up" status, as verified by the PowerShell Get-NetAdapter cmdlet.

• Each node must have the following Windows Server features installed:

  • Network ATC
  • Hyper-V
  • Failover Clustering
  • Data Center Bridging

  Here's an example of installing the required features via PowerShell:

  Install-WindowsFeature -Name NetworkATC, Hyper-V, 'Failover-Clustering', 'Data-Center-Bridging' -IncludeManagementTools
  

• Insert each adapter in the same PCI slots in each host. This practice leads to ease in automated naming conventions by imaging systems.

• Configure the physical network (switches) before Network ATC including VLANs, MTU, and DCB configuration. For more information, please see Physical Network Requirements.

Common Network ATC commands

To identify the available Network ATC commands, run the Get-Command -ModuleName NetworkATC cmdlet in PowerShell. Ensure PowerShell is run as an administrator.

The Remove-NetIntent cmdlet removes an intent from the local node or cluster. This command doesn't destroy the invoked configuration.

Example intents

Network ATC modifies how you deploy host networking, not what you deploy. You can deploy multiple scenarios so long as each scenario is a supported scenario from Microsoft. Here are some examples of common deployment options, and the PowerShell commands needed. These scenarios aren't the only combinations available but they should give you an idea of the possibilities.

For simplicity we only demonstrate two physical adapters per SET team, however it's possible to add more. For more information, please see Plan Host Networking.

Fully converged intent

For this intent, compute, storage, and management networks are deployed and managed across all cluster nodes.

Add-NetIntent -Name ConvergedIntent -Management -Compute -Storage -AdapterName pNIC01, pNIC02

Converged compute and storage intent; separate management intent

Two intents are managed across cluster nodes. Management uses pNIC01, and pNIC02; Compute and storage are on different adapters.

Add-NetIntent -Name Mgmt -Management -AdapterName pNIC01, pNIC02
Add-NetIntent -Name Compute_Storage -Compute -Storage -AdapterName pNIC03, pNIC04

Fully disaggregated intent

For this intent, compute, storage, and management networks are all managed on different adapters across all cluster nodes.

Add-NetIntent -Name Mgmt -Management -AdapterName pNIC01, pNIC02
Add-NetIntent -Name Compute -Compute -AdapterName pNIC03, pNIC04
Add-NetIntent -Name Storage -Storage -AdapterName pNIC05, pNIC06

Storage-only intent

For this intent, only storage is managed. Network ATC doesn't manage the Management and compute adapters.

Add-NetIntent -Name Storage -Storage -AdapterName pNIC05, pNIC06

Compute and management intent

For this intent, compute and management networks are managed, but not storage.

Add-NetIntent -Name Management_Compute -Management -Compute -AdapterName pNIC01, pNIC02

Multiple compute (switch) intents

For this intent, multiple compute switches are managed.

Add-NetIntent -Name Compute1 -Compute -AdapterName pNIC03, pNIC04
Add-NetIntent -Name Compute2 -Compute -AdapterName pNIC05, pNIC06

Default Network ATC values

Network ATC uses a set of default values to simplify the deployment and management of host networking. These defaults are applied when you create intents or modify network settings. Understanding these defaults can help you manage your network configuration effectively.

Default values

This section describes other default values configured by Network ATC.

Default VLANs

Network ATC uses the following VLANs by default for adapters with the storage intent type. If the adapters are connected to a physical switch, these VLANs must be allowed on the physical network. If the adapters are switchless, no other configuration is required.

Consider the following command:

Add-NetIntent -Name MyIntent -Storage -AdapterName pNIC01, pNIC02, pNIC03, pNIC04

The physical NIC (or virtual NIC if necessary) is configured to use VLANs 711, 712, 713, and 714 respectively.

Automatic storage IP addressing

Network ATC automatically configures valid IP Addresses for adapters with the storage intent type. Network ATC performs this configuration in a uniform manner across all nodes in your cluster and verifies that the address chosen isn't already in use on the network.

The default IP Address for each adapter on each node in the storage intent is set up as follows:

To override Automatic Storage IP Addressing, create a storage override and pass the override when creating an intent:

$StorageOverride = New-NetIntentStorageOverrides
$StorageOverride.EnableAutomaticIPGeneration = $false

Add-NetIntent -Name MyIntent -Storage -Compute -AdapterName 'pNIC01', 'pNIC02' -StorageOverrides $StorageOverride

Cluster network settings

Network ATC configures a set of Cluster Network Features by default. The defaults are listed as follows:

Default Data Center Bridging (DCB) configuration

Network ATC establishes the following priorities and bandwidth reservations. This configuration should also be configured on the physical network.

Common Error Messages

With the new event logs, there are some simplistic troubleshooting methods to identify intent deployment failures. This section outlines some of the common fixes when an issue is encountered. The following errors are from the output of the Get-NetIntentStatus cmdlet.

Error: AdapterBindingConflict

Scenario 1: An adapter is bound to an existing vSwitch that conflicts with the new vSwitch that is being deployed by Network ATC.

Solution: Remove the conflicting vSwitch, then Set-NetIntentRetryState

Scenario 2: An adapter is bound to the component, but not necessarily a vSwitch.

Solution: Disable the vms_pp component (unbind the adapter from the vSwitch) then run Set-NetIntentRetryState.

Error: ConflictingTrafficClass

This issue occurs because a traffic class is already configured. Network ATC is attempting to deploy traffic classes that conflict with this preconfigured traffic class. For example, you might have deployed a traffic class called SMB when Network ATC tries to deploy a similar traffic class with a different name.

Solution:

Clear the existing DCB configuration on the system then run Set-NetIntentRetryState

Get-NetQosTrafficClass | Remove-NetQosTrafficClass
Get-NetQosPolicy | Remove-NetQosPolicy -Confirm:$false
Get-NetQosFlowControl | Disable-NetQosFlowControl

Error: Network Symmetry Check Failure

You might encounter a situation where functionally symmetric adapters have different component ID strings. It might occur if a substring is added to an adapter's component ID during an upgrade or when combining OCP and PCI NICs within the same intent. To work around this issue, you can disable the component ID based symmetry check by setting the NicSymmetryCheckEnabled registry key to 0. This setting allows Network ATC to proceed with the deployment without checking for symmetry based on component IDs. You should only use this workaround if you're certain that the adapters are functionally symmetric.

Stop-Service -Name NetworkATC
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NetworkATC' -Name "NicSymmetryCheckEnabled" -Value 0 -PropertyType DWord
Start-Service -Name NetworkATC

After you disable the component ID based symmetry check, you can continue with the intent deployment.

Error: RDMANotOperational

You might see this message:

1. If the network adapter uses an inbox driver. Inbox drivers aren't supported and must be updated.

   Solution: Upgrade the driver for the adapter.

2. If SR-IOV is disabled in the BIOS.

   Solution: Enable SR-IOV for the adapter in the system BIOS

3. If RDMA is disabled in the BIOS

   Solution: Enable RDMA for the adapter in the system BIOS

Error: InvalidIsolationID

This message occurs when you use RoCE RDMA and override the default VLAN with an invalid value. Meaning the value you chose can't be used with that protocol. For example, RoCE RDMA requires a nonzero VLAN so that Priority Flow Control (PFC) markings can be added to the frame. A VLAN value between 1 - 4094 must be used. Network ATC doesn't override the value you specified without administrator intervention for several reasons. To resolve this issue:

1. Choose iWARP as the RDMA (NetworkDirect) protocol

   Solution: If supported by the adapter, Network ATC automatically chooses iWARP as its RDMA protocol that might use a VLAN ID of 0. Remove the override that enforces RoCE as the chosen protocol.

2. Use the default VLANs

   Solution: We highly recommend using the Network ATC Default VLANs

3. Use a valid VLAN

   When specifying a VLAN, use the -StorageVLANs parameter and specify comma separated values between 1 - 4094.

Next steps

• Manage your Network ATC deployment. See Manage Network ATC.
• Learn more about Stretched clusters.