DCBX/LLDP Configuration Issue on Mellanox ConnectX-5 for Azure Local Deployment

Infrastructure & Networking Software And Drivers WinOF Driver
1

We are configuring Mellanox ConnectX-5 EN adapters (MCX512A-ACU_Ax_Bx, device ID mt4119) for Azure Local RDMA compliance. The goal is to enable LLDP and IEEE DCBX negotiation for PFC/ETS using Mellanox firmware and Windows QoS.

Steps Taken:

  1. Updated NIC firmware and Mellanox WinOF2 drivers.

  2. Used mlxconfig.exe to enable LLDP and IEEE DCBX:

    PowerShell

    .\mlxconfig.exe -d mt4119_pciconf0 set LLDP_NB_DCBX_P1=1 LLDP_NB_RX_MODE_P1=ALL LLDP_NB_TX_MODE_P1=ALL DCBX_IEEE_P1=1 DCBX_CEE_P1=0 LLDP_NB_DCBX_P2=1 LLDP_NB_RX_MODE_P2=ALL LLDP_NB_TX_MODE_P2=ALL DCBX_IEEE_P2=1 DCBX_CEE_P2=0

    Verified via mlxconfig query that LLDP/DCBX settings are active.
    LLDP_NB_DCBX_P1 True(1)
    LLDP_NB_RX_MODE_P1 ALL(2)
    LLDP_NB_TX_MODE_P1 ALL(2)
    LLDP_NB_DCBX_P2 True(1)
    LLDP_NB_RX_MODE_P2 ALL(2)
    LLDP_NB_TX_MODE_P2 ALL(2)
    DCBX_IEEE_P1 True(1)
    DCBX_CEE_P1 True(1)
    DCBX_WILLING_P1 True(1)
    DCBX_IEEE_P2 True(1)
    DCBX_CEE_P2 True(1)
    DCBX_WILLING_P2 True(1)

  3. Changed DcbxMode in Windows NIC advanced properties:

    • Initially set to Firmware in Charge (NIC negotiates with switch).

    • Changed netadapteradvancedproperties to Host in Charge for OS-level DCBX control

      Verified via Get-NetAdapterAdvancedProperty that mode changed successfully.

  4. Windows QoS was configured via network intents and verified.

    Observed Issues:

  • When Firmware in Charge is active:

    • Get-NetAdapterQos shows DcbxSupport:IEEE.

        • Switch (Cisco Nexus 9k) IEEE is detected with show lldp dcbx interface E1/X

        • LLDP/DCBX TLVs appear inconsistent with Windows QoS settings.

  • When Host in Charge is active:

    • Get-NetAdapterQos shows DcbxSupport: None instead of IEEE.

    • DCBX negotiation does not appear operational from Windows or Nexus perspective.

  • RDMA (Get-NetAdapterRdma) is enabled, but PFC/ETS negotiation is unsuccessful on Nexus side.

  • Need clarification on:

    • Correct mode for Azure Local (Firmware vs Host in Charge).

    • Why switch detects CIN when NIC is configured for IEEE.

    • Why Windows reports DcbxSupport: None in Host in Charge mode.

Environment Details:

  • NIC: Mellanox ConnectX-5 EN (MCX512A-ACU_Ax_Bx)

  • Driver: 25.10.26965.0

  • OS: Windows Server 2025

  • Switch: Cisco Nexus 9k - NXOS: version 10.4(5)

  • Azure Local deployment scenario (SMB Direct RDMA required)

Expected Outcome:

  • NIC and switch negotiate IEEE DCBX successfully.

  • Windows reports DcbxSupport: IEEE when Host in Charge is selected.

  • RDMA and QoS settings align with Azure Local requirements (PFC on priority 3, ETS configured).

2

Hi,

Azure Local requires Host in Charge on the ConnectX‑5, with DCBX handled by NIC firmware while Windows only manages QoS policy. Because of this design, Get‑NetAdapterQos shows DcbxSupport: None even though IEEE DCBX is still negotiating with the Nexus switch. To avoid CIN behavior, disable CEE/CIN in the NIC ( DCBX_CEE=0 ) and run pure IEEE DCBX, then verify on the Nexus that PFC is enabled only on priority 3 and ETS bandwidth shares match your Azure Local intent.

If there are any additional issues, please open a case with Enterprise Support and it will be handled based on entitlement.

Thanks,

Jonathan.

3

Hi Jonathan,

I appreciate the information. I changed the NIC settings to the following and rebooted the host:
LLDP_NB_DCBX_P1 True(1)
LLDP_NB_RX_MODE_P1 ALL(2)
LLDP_NB_TX_MODE_P1 ALL(2)
LLDP_NB_DCBX_P2 True(1)
LLDP_NB_RX_MODE_P2 ALL(2)
LLDP_NB_TX_MODE_P2 ALL(2)
DCBX_IEEE_P1 True(1)
DCBX_CEE_P1 False(0)
DCBX_WILLING_P1 True(1)
DCBX_IEEE_P2 True(1)
DCBX_CEE_P2 False(0)
DCBX_WILLING_P2 True(1)

Unfortunately, I still get no DCBX negotiations with the switch. PFC and ETS on the switch are applied directly to the interface(s) and match exactly the qos settings on host. Am I missing anything else?