Windows Cluster Vlan issue in one server out of 5 node.

Yashpal Bhandari/IEX/Information Technology 0 Reputation points
2026-09-25T01:13:34.0333333+00:00

We have a 5-node Windows Server 2022 Datacenter cluster setup, and a virtual switch has been created on all servers. We have three different network ranges (VLANs) configured.

On four servers, all VLANs are working without any issues. However, on one server, only two out of the three VLANs are working properly, while the third VLAN is not functioning.

Because of this issue, we are unable to move VMs that are connected to the affected network segment.

Interestingly, when we assign an IP address directly to the network adapter associated with the suspected VLAN, the network works correctly.

Could you please help identify the possible cause of this issue and suggest how it can be resolved?

Windows for business | Windows Server | Storage high availability | Virtualization and Hyper-V
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Steven Nguyen (WICLOUD CORPORATION) 415 Reputation points Microsoft External Staff Moderator
    2026-09-25T01:46:25.1166667+00:00

    Hi Yashpal Bhandari,

    Since the VLAN works when an IP address is assigned directly to the physical network adapter, the physical switch configuration is likely correct and the VLAN traffic is reaching the host. This suggests that the issue may be occurring somewhere between the Hyper-V virtual switch and the physical adapter stack on this particular node.

    A few things I would check on the affected server:

    1. Verify the switch port configuration for all team members

    If the virtual switch is using Switch Embedded Teaming (SET) or an LBFO team, make sure every physical switch port connected to this host is configured identically. I've seen situations where one uplink was missing a VLAN from its allowed trunk list. In that case, traffic can work intermittently or fail completely depending on which uplink is being used.

    2. Compare NIC drivers and firmware with a working node

    Since the other four cluster nodes are functioning correctly, compare the NIC driver and firmware versions on the affected server against one of the healthy nodes. Differences in drivers or firmware can sometimes cause VLAN-tagged traffic to behave unexpectedly even when host-level connectivity appears normal.

    3. Test with VMQ and hardware offloads disabled

    VMQ and certain NIC offload features have occasionally been involved in networking issues affecting virtual machines. As a test, try temporarily disabling VMQ on the physical adapters backing the virtual switch:

    Disable-NetAdapterVmq -Name "<PhysicalAdapterName>"

    If connectivity starts working afterward, it will point toward a driver, firmware, or hardware offload issue.

    4. Compare Hyper-V virtual switch settings

    It may also be worth comparing the virtual switch configuration on the affected node with one of the working servers:

    Get-VMSwitch | Format-List *

    Also verify that the VM connected to the affected network is configured for the correct VLAN:

    Get-VMNetworkAdapterVlan -VMName "<AffectedVM>"

    Finally, check whether any third-party virtual switch extensions or filter drivers are installed on this host but not on the others, as they can sometimes interfere with VLAN-tagged traffic.

    Given that all other cluster nodes are working and the VLAN can be reached directly from the host, I would focus first on the physical uplink configuration for all team members and then compare the NIC driver/firmware versions against a known good node. Those are the most likely places where I would expect to find a difference.

    If this helps resolve your problem, please consider hitting "Accept Answer" so other users facing this failure can easily find the solution!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-09-25T01:13:56.1733333+00:00

    A likely cause is an inconsistent VLAN configuration on that one host rather than a VM or cluster-wide problem.

    The strongest clues are:

    1. Four nodes work with the same design.
    2. One node fails on only one VLAN.
    3. The network works when an IP is assigned directly to the adapter.
    4. VM movement fails for workloads connected to that network.

    That pattern points to a host-specific networking mismatch such as:

    • The switchport or trunk on that server not advertising the same VLAN set as the other four hosts.
    • A misconfigured or inconsistent VLAN on the host for the adapters participating in the same intent.
    • A cluster network on that host not being available for the operation.
    • Adapter binding/order issues on the affected node.

    Use this troubleshooting path:

    1. Verify cluster network availability on the affected host. Run PowerShell as administrator: 
         Get-ClusterNetwork
   Get-ClusterNetworkInterface | ft NodeName, NetworkName, State
      Confirm the affected network is present and usable on the problem node. If the interface for that VLAN shows a failed or unavailable state, the cluster cannot use it for VM movement.
    2. Check that cluster communication is allowed on that network. For the affected cluster network, make sure Allow cluster network communication on this network is enabled. If the cluster marks that network unavailable, live migration or VM movement can fail with "A cluster Network isn't available for this operation."
    3. Compare VLAN consistency across all five hosts. The problem is likely that the switchports connected to the affected host are not advertising the same VLANs as the other nodes. Microsoft guidance for Network HUD calls out misconfigured or inconsistent VLANs as a cause of VM connectivity loss and storage isolation failure. The VLAN set must be consistent:
      • across adapters in the same host intent
      • across the same intent on all hosts in the cluster
      • for all workload VLANs required by the VMs
    4. Validate the host network configuration. Run the Validate a Configuration Wizard in Failover Cluster Manager and review the Network section for warnings and errors. This helps identify whether the adapter is reachable, properly configured, and participating correctly in cluster communication.
    5. Check adapter binding order on the affected node. On the problem server:
      • Open Start → Run → ncpa.cpl
      • Open Advanced Settings
      • Review Adapters and Bindings Network adapters used for client communication should be at the top of the binding order. Incorrect priority can affect outbound connectivity on multi-homed cluster nodes.
    6. Confirm the same virtual switch exists on all nodes. For VM mobility, the VM must have the same virtual switch on all nodes. If the switch exists but the underlying VLAN path is different on one host, VMs attached to that VLAN can fail after migration.
    7. If Network ATC is in use, check intent status. 
         Get-NetIntentStatus
      This helps detect host-level inconsistencies. Microsoft documentation also notes that VLANs for storage and management can be explicitly set when creating intents, and inconsistent adapter presence or configuration is reported by status checks.

    What the direct-IP test means: If assigning an IP directly to the adapter makes the network work, the physical path is likely functional. That shifts focus to the virtual switch/VLAN presentation on that host, or to cluster recognition of that network, rather than a total cable/NIC failure.

    Most likely resolution:

    • Make the VLAN configuration on the affected host match the other four hosts exactly.
    • Verify the physical switchport/trunk for that server allows the same VLANs.
    • Confirm the cluster network for that VLAN is available and enabled for cluster communication.
    • Confirm adapter binding order and virtual switch consistency.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.