Azure Accelerated Networking overview

Azure Accelerated Networking significantly improves virtual machine networking performance by reducing latency and CPU utilization. This article describes the benefits, constraints, and supported configurations of Accelerated Networking. Accelerated Networking enables single root I/O virtualization (SR-IOV) on supported virtual machine (VM) types, greatly improving networking performance. This high-performance data path bypasses the host, which reduces latency, jitter, and CPU utilization for the most demanding network workloads.

The following diagram illustrates how two VMs communicate with and without Accelerated Networking.

Open diagram: Screenshot that shows communication between Azure VMs with and without Accelerated Networking.

Without Accelerated Networking, all networking traffic in and out of the VM traverses the host and the virtual switch. The virtual switch provides all policy enforcement to network traffic. Policies include network security groups, access control lists, isolation, and other network virtualized services.

With Accelerated Networking, network traffic that arrives at the VM's network interface (NIC) is forwarded directly to the VM. Accelerated Networking offloads all network policies that the virtual switch applied, and it applies them in hardware. Because hardware applies policies, the NIC can forward network traffic directly to the VM. The NIC bypasses the host and the virtual switch, while it maintains all the policies that it applied in the host.

Benefits

Accelerated Networking has the following benefits:

Lower latency and higher packets per second. Removing the virtual switch from the data path eliminates the time that packets spend in the host for policy processing. It also increases the number of packets that the VM can process.
Reduced jitter. Processing time for virtual switches depends on the amount of policy to apply and the workload of the CPU that does the processing. Offloading policy enforcement to the hardware removes that variability by delivering packets directly to the VM. Offloading also removes the host-to-VM communication, all software interrupts, and all context switches.
Decreased CPU utilization. Bypassing the virtual switch in the host leads to less CPU utilization for processing network traffic.

Limitations and constraints

The benefits of Accelerated Networking apply only to the VM that enables it.
For best results, enable Accelerated Networking on at least two VMs in the same Azure virtual network. This feature has minimal effect on latency when you communicate across virtual networks or connect on-premises.
You can't enable Accelerated Networking on a running VM. You can enable Accelerated Networking on a supported VM only when the VM is stopped and deallocated.
You can't deploy virtual machines (classic) with Accelerated Networking through Azure Resource Manager.
The Azure platform doesn't update the Mellanox NIC or MANA drivers in the VM. For VMs running Linux and FreeBSD, you should stay current with the latest kernel updates offered by the distribution. For VMs running Windows, apply updated drivers from the NVIDIA support page if you encounter any issues with the driver delivered with the Marketplace image or applied to a custom image. The latest MANA drivers can be found at the documentation page for MANA on Windows

Supported regions

Accelerated Networking is available in all global Azure regions and the Azure Government Cloud.

Supported operating systems

Windows

The following versions of Windows support Accelerated Networking for all interfaces:

Product
Windows 11
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows Server 2025

Linux

For virtual machines (VMs) with the Microsoft Mana Adapter:

Distribution	Kernel Series	Min Version
AlmaLinux 9.6	5.14	kernel-5.14.0-570.52.1.el9_6
AlmaLinux 10.0	6.12	kernel-6.12.0-108.el10
Azure Linux 3	6.6	ANY
Azure Linux 4	6.18	ANY
Debian 12 "Bookworm"	6.12	6.12.21
Debian 13 "Trixie"	6.12	6.12.21
Oracle Linux (Red Hat kernel) 9.x	5.14	kernel-5.14.0-570.52.1.el9_6
Oracle Linux (Red Hat kernel) 10.x	6.12	kernel-6.12.0-108.el10
Oracle Linux UEK R7	UEK 7	Not listed above
Oracle Linux UEK R8	UEK 8/U1 (6.12.0-100.28.2)	UEK8/U1
Rocky Linux 9.6	5.14	kernel-5.14.0-570.52.1.el9_6
Rocky Linux 10.0	6.12	kernel-6.12.0-108.el10
Red Hat Enterprise Linux 9.6	5.14	kernel-5.14.0-570.52.1.el9_6
Red Hat Enterprise Linux 10.0	6.12	kernel-6.12.0-108.el10
SUSE Linux Enterprise Server 15 SP5	5.14	5.14.21-150500.55.121.2
SUSE Linux Enterprise Server 15 SP6	6.4	6.4.0-150600.23.73.1
SUSE Linux Enterprise Server 15 SP7	6.4	6.4.0-150700.53.16.1
SUSE Linux Enterprise Server 16	6.12	6.12.0-160000.5.1
Ubuntu 22.04 LTS	5.15	5.15.0-1096.105
Ubuntu 24.04 LTS	6.8	6.8.0-1041.47

For users of non endorsed Linux distributions or utilizing custom kernels, we recommend the Linux Kernel 6.14 or later found at kernel.org

Note

MANA’s newer features are actively evolving, and Linux vendors work with Microsoft to bring upstream updates into their kernels. Update frequency varies by distribution, but newer releases generally include the latest improvements.

The preceding table lists the minimum recommended kernel versions for MANA support.

For virtual machines (VMs) with Mellanox Adapters

All Azure Endorsed Linux Distributions are supported, as long as the vendors don't mark them as end of life (EOL).

Supported VM instances

Most general-purpose and compute-optimized VM instance sizes with two or more vCPUs support Accelerated Networking. On instances that support hyperthreading, VM instances with four or more vCPUs support Accelerated Networking.

To check whether a VM size supports Accelerated Networking, see Sizes for virtual machines in Azure.

You can directly query the list of VM SKUs that support Accelerated Networking by using the Azure CLI az vm list-skus command:

az vm list-skus \
  --location westus \
  --all true \
  --resource-type virtualMachines \
  --query '[].{size:size, name:name, acceleratedNetworkingEnabled: capabilities[?name==`AcceleratedNetworkingEnabled`].value | [0]}' \
  --output table

Note

Although NC and NV sizes appear in the command output, those sizes don't support Accelerated Networking. Enabling Accelerated Networking on NC or NV VMs has no effect.

Custom VM images

If you use a custom image that supports Accelerated Networking, make sure you meet the following requirements.

Device and driver support

Any custom image supporting Accelerated Networking must include drivers that enable Single Root I/O Virtualization for the network interface cards (NIC) which are used on Azure platforms. This hardware list includes NVIDIA ConnectX-3, ConnectX-4 Lx, ConnectX-5 and the Microsoft Azure Network Adapter (MANA).

Dynamic binding and revocation of virtual function

Accelerated Networking requires guest OS images to properly handle the virtual function being removed or added dynamically. Scenarios such as host maintenance or live migration will result in dynamic revocation of the virtual function and restoration after the maintenance event. Additionally, applications must ensure that they bind to the synthetic device and not the virtual function in order to maintain network connectivity during these events.

For more information about application binding requirements, see How Accelerated Networking works in Linux and FreeBSD VMs.

Configure drivers to be unmanaged

Accelerated Networking requires configuring the SR-IOV drivers as unmanaged devices in your network settings. This requirement applies to the NVIDIA/Mellanox mlx4_core and mlx5_core drivers and to the MANA driver. Images using cloud-init version 23.2 or later automatically apply the correct network configuration to support Accelerated Networking during provisioning. Avoid concurrent network interface management tools (such as ifupdown and networkd) on custom images, and don't run dhcpclient directly on multiple interfaces.

Ensure azure-vm-utils version 0.6.0 or later is installed. Verify /usr/lib/udev/rules.d/10-azure-unmanaged-sriov.rules exists.
If it's not available for the distro, then use a custom udev rule in /etc/udev/rules.d/10-azure-unmanaged-sriov.rules with the content:

# Azure VMs with accelerated networking may have MANA, mlx4, or mlx5 SR-IOV devices which are transparently bonded to a synthetic
# hv_netvsc device.  Mark devices with the 0x800 bit set as unmanaged devices:
#   AZURE_UNMANAGED_SRIOV=1 for 01-azure-unmanaged-sriov.network
#   ID_NET_MANAGED_BY=unmanaged for systemd-networkd >= 255
#   NM_UNMANAGED=1 for NetworkManager
#
# ATTR{flags}=="0x?[89ABCDEF]??" checks the 0x800 bit.
SUBSYSTEM=="net", ACTION!="remove", DRIVERS=="mana|mlx4_core|mlx5_core", ATTR{flags}=="0x?[89ABCDEF]??", ENV{AZURE_UNMANAGED_SRIOV}="1", ENV{ID_NET_MANAGED_BY}="unmanaged", ENV{NM_UNMANAGED}="1"

# Azure VMs with accelerated networking may have MANA, mlx4, or mlx5 SR-IOV devices which are transparently bonded to a synthetic
# hv_netvsc device.  Mark devices with the 0x800 bit set as unmanaged devices:
#   AZURE_UNMANAGED_SRIOV=1 for 01-azure-unmanaged-sriov.network
#   ID_NET_MANAGED_BY=unmanaged for systemd-networkd >= 255
#   NM_UNMANAGED=1 for NetworkManager
#
# ATTR{flags}=="0x?[89ABCDEF]??" checks the 0x800 bit.
SUBSYSTEM=="net", ACTION!="remove", DRIVERS=="mana|mlx4_core|mlx5_core", ATTR{flags}=="0x?[89ABCDEF]??", ENV{AZURE_UNMANAGED_SRIOV}="1", ENV{ID_NET_MANAGED_BY}="unmanaged", ENV{NM_UNMANAGED}="1"

If using networkd <255, add the following to /usr/lib/systemd/network/01-azure-unmanaged-sriov.network

# Azure VMs with accelerated networking may have MANA, mlx4, or mlx5 SR-IOV
# devices which are transparently bonded to a synthetic hv_netvsc device.
# 10-azure-unmanaged-sriov.rules will mark these devices with
# AZURE_UNMANAGED_SRIOV=1 so this can configure the devices as unmanaged.
 
[Match]
Property=AZURE_UNMANAGED_SRIOV=1
 
[Link]
Unmanaged=yes

Network traffic uses the Accelerated Networking data path

For NVIDIA drivers: Verify that the packets are flowing over the VF interface

For MANA driver: Verify that the traffic is flowing through MANA