Validating and Re-Enabling NVGRE/VXLAN offloading in SDN workloads

Question

Validating and Re-Enabling NVGRE/VXLAN offloading in SDN workloads

Lin Dan 40

Hi all

When running SDN workloads that rely on NVGRE or VXLAN encapsulation, administrators often encounter severe spikes in CPU utilization on host nodes. This issue typically arises because the physical NICs fail to properly execute Task Offload for encapsulated packets, forcing the CPU to handle the additional processing overhead. As a result, the efficiency of packet forwarding and overall system performance can degrade significantly, especially under heavy traffic conditions.

In one scenario, a data center observed that during peak traffic hours, CPU usage on host servers surged to nearly 90%, even though network throughput remained moderate. This was traced back to the NICs not offloading encapsulated traffic, leaving the CPU to perform repetitive checksum and segmentation tasks. In another case, a cloud environment running multiple tenant networks experienced latency spikes and packet drops because VXLAN offloading was disabled at the NIC driver level, preventing hardware acceleration from functioning as intended.

How can we validate whether NVGRE/VXLAN offloading is currently active on the NICs, and what steps should be taken to re-enable or properly configure offloading so that encapsulated traffic benefits from hardware acceleration rather than overwhelming the CPU ?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello @Lin Dan

Yes, Windows provides native PowerShell cmdlets to verify and configure encapsulated packet task offload for NVGRE and VXLAN.

First, check which NICs support it and whether it's enabled:

Get-NetAdapterEncapsulatedPacketTaskOffload -Name "*"

To show only adapters where encapsulated offload is enabled:

Get-NetAdapterEncapsulatedPacketTaskOffload -Name "*" |
    Where-Object { $_.Enabled }

Microsoft confirms that encapsulated packet task offload allows capable NICs to perform operations such as LSO and VMQ against the inner headers of encapsulated traffic, reducing CPU processing.

Get-NetAdapterEncapsulatedPacketTaskOffload documentation

If the NIC/driver supports the required encapsulation but it's disabled, enable it explicitly:

Enable-NetAdapterEncapsulatedPacketTaskOffload `
    -Name "Ethernet" `
    -EncapsulationType VXLAN

or for NVGRE:

Enable-NetAdapterEncapsulatedPacketTaskOffload `
    -Name "Ethernet" `
    -EncapsulationType NVGRE

Microsoft documents both VXLAN and NVGRE as supported values. Note that enabling the setting normally restarts the network adapter, so this should be performed during an appropriate maintenance window on production hosts.

You can also configure VXLAN specifically with:

Set-NetAdapterEncapsulatedPacketTaskOffload `
    -Name "Ethernet" `
    -VxlanEncapsulatedPacketTaskOffloadEnabled $true

I would also verify the underlying NIC offloads:

Get-NetAdapterLso -Name "*"
Get-NetAdapterVmq -Name "*"
Get-NetAdapterRss -Name "*"
Get-NetAdapterAdvancedProperty -Name "*"

If Get-NetAdapterEncapsulatedPacketTaskOffload doesn't report the physical NIC, don't try to force-enable it. That generally means the NIC/driver isn't advertising the required capability. Check the NIC vendor's current Windows Server driver/firmware and confirm that the specific adapter supports VXLAN/NVGRE hardware offload.

After enabling it, compare host CPU utilization and network performance under the same workload. If CPU remains high, check whether LSO/VMQ/RSS are also correctly configured and whether the NIC driver/firmware supports the encapsulation type actually being used by the SDN deployment.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.