Azure Local Storage Vlan

Question

Azure Local Storage Vlan

Handian Sudianto 7,471

I have 2 node Azure Local with below topology for storage. Port4 connected to Port4 and Port5 connected to Port5

User's image

If i execute Get-NetIntent i got below detail.

With below detail can i know Port4 is map to vlan 711 and Port5 to vlan 712?

User's image

0 comments

1 answer

Your answer

Answer 1

Rukshan edirisinghe 910

Hi @Handian Sudianto

Yes, your reading is correct. The mapping is by order: Network ATC assigns the StorageVLANs to the adapters in the same order they're listed in the intent, so with {Port4, Port5} and {711, 712}, Port4 gets 711 and Port5 gets 712. The docs describe exactly this, the NICs in a storage intent get configured to use VLANs 711, 712 and so on respectively, and ATC applies it uniformly across all nodes.

That uniformity is what makes your switchless cabling work: Port4 on both nodes sits on VLAN 711 with one subnet, Port5 on both sits on 712 with the other, so each direct cable pair forms its own storage network. With defaults that's 10.71.1.0/24 for network 1 (VLAN 711) and 10.71.2.0/24 for network 2 (VLAN 712).

You don't have to infer it though, verify it on the adapters directly:

Get-NetAdapterAdvancedProperty -Name Port4,Port5 -DisplayName "VLAN ID" -CimSession (Get-ClusterNode).Name
Get-NetIPAddress -InterfaceAlias Port4,Port5 | Select InterfaceAlias,IPAddress
Get-NetIntentStatus -Name storage

The first shows the VLAN actually applied on each pNIC, the second confirms it (Port4 in 10.71.1.x, Port5 in 10.71.2.x if defaults), and the last confirms the intent provisioned on both nodes. If this were a converged intent with a vSwitch, you'd check the vSMB vNICs with Get-VMNetworkAdapterIsolation -ManagementOS instead, but for a storage-only intent the VLAN sits on the physical NIC.

And since you're switchless, those VLANs live only between the nodes, nothing to configure on any switch.

References: https://learn.microsoft.com/en-us/windows-server/networking/network-atc/network-atc https://learn.microsoft.com/en-us/azure/azure-local/plan/two-node-switchless-single-switch

Handian Sudianto 7,471 Reputation points

2026-09-20T14:35:09.8666667+00:00

hi @Rukshan edirisinghe

With that condition then all must connect to same port, example port4 to port4 and port5 to port5. How if the cable connection is like below picture where port3 connected to port4 and port6 connected to port5 (blue line and ignore all otehr lines)
Rukshan edirisinghe 910 Reputation points

2026-09-20T16:41:33.05+00:00

Good follow-up, and yes, you've spotted the rule correctly: same port name to same port name. Here's why.

Network ATC keys everything off the adapter name and applies the config uniformly across all nodes. So Port4 gets VLAN 711 and subnet 1 on every node, Port5 gets 712 and subnet 2 on every node. A direct cable only works when both ends sit on the same VLAN and subnet, which only happens when both ends have the same name.

Your blue-line example breaks in two ways. First, Port3 and Port6 aren't in your intent at all ({Port4, Port5}), so ATC gives them nothing, no VLAN, no storage IP. Second, even if you added them, ATC can't configure Port3 as network 1 on one node while Port4 is network 1 on the other, because the config follows the name, not the cable. So that cabling gives you links where one end is on 711/10.71.1.x and the other end is on 712/10.71.2.x or unconfigured, and no storage traffic flows. Deployment validation for switchless will also flag it.

If the crossed cabling is physically unavoidable, there's a clean fix: rename the adapters so both ends of each cable share a name. For example, rename node2's Port3 and node3's Port4 both to SMB1, and node2's Port6 and node3's Port5 both to SMB2 (Rename-NetAdapter), then create the intent on SMB1, SMB2. ATC only cares that the names match across nodes, not which physical port they sit on.

But if you can just move the cables, do that instead. Port-to-same-port is the documented reference pattern and saves the next engineer a lot of confusion.
Handian Sudianto 7,471 Reputation points

2026-09-21T02:50:27.73+00:00

hi @Rukshan edirisinghe the issue is when i scaleout by adding one more node then i confuse for the cable conenction. For 3 node or more there must be a cross connection, example from port4 node1 to port3 node3.

Also when i add the new node then i found the network atc only configure for port3 and port4. Should i make a new sotage intent for Azure Local-1?
Rukshan edirisinghe 910 Reputation points

2026-09-21T03:45:11.46+00:00
Hi @Handian Sudianto

This follow-up changes the picture, so let me be straight with you.

First, the direct answer: no, don't create a new storage intent. Intents are cluster-scoped, one storage intent for the whole cluster, applied to every node by adapter name. Per-node intents aren't how ATC works. The reason only some ports got configured on the new node is that the intent only touches adapters named exactly Port4 and Port5.

But here's the bigger issue: adding a node to a switchless cluster isn't a supported operation. The docs say it plainly, scale-out operations aren't supported on switchless storage deployments, and to add a node you redeploy the cluster, because the storage cabling and storage networks have to be reconfigured. So no amount of intent tweaking on the live cluster gets you to a supported 3-node state.

You're also right about the cabling, and this is exactly why scale-out is blocked: at 3 nodes you need a full mesh (every node cabled to both peers), so the clean same-port-to-same-port rule from your 2-node setup can't hold anymore. And a 3-node switchless mesh has different ATC requirements entirely: a single VLAN for all storage subnets, StorageAutoIP set to false with per-link IPs you specify yourself, and deployment only via ARM template, not the portal. Your current 2-node intent (auto IP, 711/712 per adapter) can't express that topology.

So your two real options:

Stay switchless at 3 nodes: cable the full mesh, then redeploy the instance using the 3-node switchless ARM template pattern. Plan a maintenance window, this is a redeployment, not an in-place change.

If you expect to grow beyond this, put storage on physical switches instead. Switchless caps at 4 nodes hard and never scales out, while switched storage supports up to 16 nodes and proper scale-out.

If this helped, please click Accept Answer so others hitting the same wall can find it.

References: https://learn.microsoft.com/en-us/azure/azure-local/plan/three-node-switchless-two-switches-two-links https://learn.microsoft.com/en-us/azure/azure-local/plan/cloud-deployment-network-considerations
Handian Sudianto 7,471 Reputation points

2026-09-21T03:55:16.53+00:00

hi @Rukshan edirisinghe

Previously i can build 3 node with switchless configuration, but this mean we can't scaleout from 2 to 3 node?
The only way we must reconfig from strach using 3 nodes?