Verifying and Re-Enabling RDMA after driver updates

Question

Verifying and Re-Enabling RDMA after driver updates

INT66 Risla 40

Hi team

After updating physical NIC drivers on an S2D host, the RDMA settings on the adapters get reset and storage resync traffic drops back to TCP speeds. For example, after installing a new Mellanox/NVIDIA ConnectX‑5 firmware package, the host suddenly stops advertising RDMA over SMB Direct. How can I properly verify the RDMA capabilities on each adapter and re‑enable them, and could an engineer help confirm the correct steps to avoid future RDMA fallback ?

0 comments

Answer accepted by question author

HLBui 11,820 Independent Advisor

Hi INT66 Risla

When you update NIC or firmware on an S2D host, it’s pretty normal for RDMA settings to get wiped and for SMB Direct to fall back to plain TCP. The quickest way to check what’s going on is to run Get-NetAdapterRdma and Get-NetAdapterNetworkDirect to see whether the adapters are still advertising RDMA. If they show up as disabled, just re‑enable them with Enable-NetAdapterRdma and restart the SMB service so the stack picks up the new capabilities. I also recommend checking Get-SmbMultichannelConnection afterward to confirm RDMA paths are actually being used again. In environments with Mellanox/ConnectX firmware, this reset happens more often than people expect, so having a quick validation checklist really helps.

If everything is okay, don't forget to share your experience with the issue by "Accept answer". If you need more information, feel free to leave a message. We are happy to help!

INT66 Risla 40 Reputation points

2026-09-11T15:21:46.64+00:00

Hi HLBui

One more question, is there any way to prevent this issue in the future ?
HLBui 11,820 Reputation points Independent Advisor

2026-09-12T04:01:26.66+00:00

Hi INT66 Risla

Thanks for your good question. There are a few ways to reduce the chance of RDMA settings getting wiped out after future driver or firmware updates. One best practice is to always export your NIC configuration before applying updates Get-NetAdapterAdvancedProperty and Get-NetAdapterRdma outputs can be saved so you’ve got a baseline to re‑apply quickly. Another tip is to stage updates in a maintenance window and validate RDMA immediately after the reboot, rather than assuming it’s still active. For Mellanox/ConnectX adapters, make sure you’re using the vendor’s recommended firmware/driver pairing, since mismatched versions are a common cause of RDMA fallback. Some teams also script a post‑update check that automatically re‑enables RDMA if it’s disabled, which saves a lot of manual effort. And finally, documenting a repeatable checklist for your cluster engineers will help ensure consistency across hosts.

1 additional answer

Your answer

INT66 Risla 40 Reputation points

2026-09-11T15:21:46.64+00:00

Hi HLBui

One more question, is there any way to prevent this issue in the future ?
HLBui 11,820 Reputation points Independent Advisor

2026-09-12T04:01:26.66+00:00

Hi INT66 Risla

Thanks for your good question. There are a few ways to reduce the chance of RDMA settings getting wiped out after future driver or firmware updates. One best practice is to always export your NIC configuration before applying updates Get-NetAdapterAdvancedProperty and Get-NetAdapterRdma outputs can be saved so you’ve got a baseline to re‑apply quickly. Another tip is to stage updates in a maintenance window and validate RDMA immediately after the reboot, rather than assuming it’s still active. For Mellanox/ConnectX adapters, make sure you’re using the vendor’s recommended firmware/driver pairing, since mismatched versions are a common cause of RDMA fallback. Some teams also script a post‑update check that automatically re‑enables RDMA if it’s disabled, which saves a lot of manual effort. And finally, documenting a repeatable checklist for your cluster engineers will help ensure consistency across hosts.

Answer 1

Use this verification and recovery flow after NIC driver or firmware updates on an S2D host.

Verify whether SMB still sees the adapters as RDMA-capable.

On the server, run:

Get-SmbServerNetworkInterface

On a client, run:

Get-SmbClientNetworkInterface

These commands are the documented way to verify that the network adapter is RDMA-capable for SMB Direct.

If an adapter no longer shows RDMA capability, re-enable RDMA on that interface.

For a specific adapter:

Enable-NetAdapterRDMA <name>

If RDMA was disabled globally, re-enable it for all interfaces:

Set-NetOffloadGlobalSetting -NetworkDirect Enabled

RDMA must be enabled on both the client and the server before SMB Direct can use it again.

Confirm SMB Direct itself is enabled.

Check the feature state:

Get-WindowsOptionalFeature -Online -FeatureName SMBDirect

If needed, enable it:

Enable-WindowsOptionalFeature -Online -FeatureName SMBDirect

If SMB Multichannel was also disabled during troubleshooting, re-enable it.

Server side:

Set-SmbServerConfiguration -EnableMultiChannel $true

Client side:

Set-SmbClientConfiguration -EnableMultiChannel $true

Validate that SMB Direct is actually being used again.

Run a large file copy and compare behavior with RDMA disabled versus enabled. To avoid misleading results from cache effects:

copy more data than memory can hold
perform the copy twice and time the second run
restart both server and client before each test

During testing, Performance Monitor can confirm RDMA traffic:

open perfmon
go to Monitoring Tools > Performance Monitor
add counters from SMB Direct Connection
add Bytes RDMA Read/sec and Bytes RDMA Written/sec

If the adapter still does not appear as RDMA-capable after the update, check firmware and driver level.

A documented cause is older or incorrect network adapter drivers or firmware not correctly identifying the adapter as RDMA-capable. In that case, update the network adapter firmware and driver from the manufacturer.

If Event ID 30818 appears and SMB falls back to TCP on Windows Server 2012 R2, install update 2919355.

That specific issue is documented for certain RDMA-capable adapters on Windows Server 2012 R2 and causes RDMA connections to fail back to TCP.

To reduce future RDMA fallback after driver maintenance:

verify RDMA capability with Get-SmbServerNetworkInterface immediately after every NIC driver or firmware update
verify SMB Direct is enabled with Get-WindowsOptionalFeature -Online -FeatureName SMBDirect
re-enable RDMA per adapter with Enable-NetAdapterRDMA <name> if the update reset adapter settings
update NIC firmware and drivers from the hardware vendor when SMB no longer reports the adapter as RDMA-capable

References: