Azure Preview Lets Route Tables Disable VNet Peering Routes for NVA Traffic Steering

The listing itself says very little. The details below come from Microsoft's networking documentation and the Azure CLI project.

What the setting does​

The control is a route-table property called disablePeeringRoute. Microsoft's ARM/Bicep schema describes it as whether to disable routes learned by peering on the route table. "None" leaves peering routes enabled, and "All" disables all of them.

Microsoft's peering overview documents the preview under the name "disable peering route propagation". It is meant to help you steer traffic through a network virtual appliance (NVA), such as Azure Firewall, without keeping a separate user-defined route (UDR) for every peered virtual network. It suppresses the system-generated IPv4 and IPv6 peering routes for supported workloads on subnets associated with the route table, and it keeps the peering connection itself.

Why hub-and-spoke admins will care​

This is mainly about forcing traffic through a firewall. Azure picks routes by longest prefix match. A system peering route can be more specific than a summarized UDR. When that happens, Azure picks the peering route and traffic bypasses the NVA.

The usual workaround is to add a more specific UDR for each spoke. As you add spokes, those per-spoke overrides use up route-table capacity and need recurring configuration. Turning peering routes off on the route table removes the competing route, so your intended UDR can win.

Limits and caveats​

• It is not a kill switch for peering. The peering connection stays in place. Microsoft's peering guide treats access, forwarded traffic, gateway transit and remote-gateway use as separate settings. This new property is a different control and only affects peering-learned routes on the associated route table.
• It does not build the inspection path for you. Microsoft says that disabling peering route propagation doesn't create replacement routes or an inspection path. Configure the required UDRs and confirm the next hop works before you enable it.
• There is a same-VNet next hop requirement. During public preview, the Azure Firewall or NVA next hop must be in the same virtual network as the source workload's network interface. A next hop in a peered virtual network isn't supported. That excludes some common hub-and-spoke designs. Check your topology against it before testing.
• It is separate from BGP propagation. disableBgpRoutePropagation is a Boolean for routes learned by BGP, and disablePeeringRoute is its own property for peering routes.

Tooling and API versions​

The Azure CLI repository has a feature request, opened in March 2026, for this property. It says the Network resource provider added disablePeeringRoute in API version 2025-07-01. It proposed --disable-peering-route {None, All} for az network route-table create and update, and showing the property in show and list. The issue was closed as completed on April 23, 2026, linked to pull request #33231. That shows the CLI work was done. It doesn't tell you which released CLI build includes it.

The ARM/Bicep reference for API version 2025-09-01 lists the property under the route table's properties. Use a tool and API version that know about the property. Older ones may not.

A cautious test plan​

This is general good practice, not a Microsoft-prescribed procedure:

1. Capture the current route table and the effective routes on a representative NIC.
2. Make sure your UDRs and NVA next hop are in place and in the same VNet as the workload.
3. Set disablePeeringRoute to All on a test route table only.
4. Re-check the effective routes, then test both the traffic that should be allowed and the traffic that should be blocked.
5. To roll back, set the value back to None.

What isn't confirmed​

I could not retrieve the body of the Azure Updates entry. The sources reviewed don't establish which regions or clouds support the preview, whether the Azure portal exposes the setting, or what permissions are needed beyond normal route-table management. Treat those as open questions and check Microsoft's current documentation before planning a rollout.

Bottom line​

For network teams running large hub-and-spoke designs, this could replace a pile of per-spoke UDRs with one setting. The preview limits are real, though: it is non-production only, and the NVA next hop must be in the same VNet. It is worth a lab test, and not yet worth redesigning production routing around.