Back to Articles

When Azure Local's Reserved IP Ranges Collide With Your Network

A recovery path when your datacenter network overlaps with Microsoft's reserved ranges

By Pieter Teeling • Azure Local Deployment

Microsoft's documentation for Azure Local includes a strict requirement:

Two IP ranges must not be used anywhere in your Azure Local deployment:

10.96.0.0/12 — Reserved for Kubernetes services
10.244.0.0/16 — Reserved for Kubernetes pod networking

These ranges are reserved for internal Azure Local and AKS Arc components. If your existing datacenter network uses any part of these blocks — and many do — deployment can fail or behave unpredictably.

This is especially common with 10.244.0.0/16, which appears in many legacy Kubernetes clusters, lab environments, and inherited network designs.

Microsoft's guidance is simple: don't use these ranges.

But real customer networks are rarely simple.

Sometimes you inherit a network.
Sometimes you're mid‑migration.
Sometimes you discover the overlap only after Azure Local deployment has already begun.

Fortunately, there is a clean, repeatable workaround.

The Workaround: Deploy First, Then Re‑Create the Arc Resource Bridge

Azure Local enforces reserved‑range validation during deployment. But Arc Resource Bridge (ARB) — the component that hosts AKS on Azure Local — can be safely deleted and re‑created afterward.

This gives you a path forward:

Deploy Azure Local using the IPs you want, even if they overlap with Microsoft's reserved ranges.
Delete the automatically created AKS Arc instance.
Re‑create it manually with your own service CIDR, pod CIDR, and DNS service IP.

This allows you to avoid the reserved ranges and avoid redesigning your entire network.

Step 1 — Delete the Default AKS Arc Instance

Start by removing the Arc Resource Bridge that was automatically created during Azure Local setup.

Using the Azure CLI:

az aksarc delete --name <cluster-name> --resource-group <resource-group> --yes --no-wait

This operation will clean up the associated Kubernetes cluster and all its networking configurations.

Step 2 — Re‑Create AKS Arc With Your Own IP Ranges

Once removed, you can deploy a new AKS Arc instance with custom networking parameters:

az aksarc create \
    --resource-group <resource-group> \
    --name <cluster-name> \
    --custom-location <custom-location> \
    --vnet-ids <logical-network-id> \
    --service-cidr <your-service-cidr> \
    --dns-service-ip <your-dns-service-ip> \
    --pod-cidr <your-pod-cidr>

Example with custom ranges:

az aksarc create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --custom-location myCustomLocation \
    --vnet-ids myLogicalNetworkId \
    --service-cidr 172.20.0.0/16 \
    --dns-service-ip 172.20.0.10 \
    --pod-cidr 10.244.0.0/16

Replace the ranges with whatever fits your environment, as long as they don't collide with your existing infrastructure.

Important Notes

The DNS service IP must always end in .10 — The specific octet is non‑negotiable for AKS Arc.

The service CIDR and pod CIDR can be anything that fits your environment, as long as they don't overlap with the rest of your network.

This process modifies only the ARB/AKS layer — not your Azure Local deployment itself. Your VM hosts, storage, and fabric remain unchanged.

Why This Works

Azure Local enforces reserved ranges during deployment because ARB and AKS rely on them internally. But once the system is deployed, you can override the Kubernetes networking configuration by re‑creating the AKS Arc instance.

This gives customers with constrained or inherited networks a viable path forward without renumbering DNS servers, proxies, gateways, or entire IP blocks.

It's not documented. It's not obvious. But it's fully supported because you're using standard lifecycle operations.

When This Workaround Makes Sense

Use this approach when:

Your existing network uses 10.96.0.0/12 or 10.244.0.0/16.
You cannot renumber critical infrastructure.
You want to deploy Azure Local now, not after a long network redesign.
You need AKS Arc to run with custom service/pod CIDRs.

It's also a great recovery path when the initial deployment fails due to IP conflicts and you want to avoid tearing everything down.

The Bottom Line

Azure Local's reserved IP ranges are strict — but they don't have to be blockers.

By deploying first and re‑creating the Arc Resource Bridge with your own CIDRs, you can run Azure Local in networks that would otherwise be incompatible.

This is one of those real‑world hybrid‑cloud challenges that customers hit all the time. Now you've got a clean, repeatable way to handle it.

Teeling Cloud Courant

When Azure Local's Reserved IP Ranges Collide With Your Network