When BGP Stops Being Boss: VNRA and Propagated Routes in Azure

Thu, 09 Jul 2026 00:00:00 +1000

BGP has a habit of making engineers feel safe.

If the gateway is up and the prefix is propagated, the instinct is to relax. Azure learned the route, the subnet can see it, and the packet should follow accordingly. In a standard hybrid mental model, that feels reasonable.

VNRA is where that comfort starts to fall apart.

This is the key point for this post:

A propagated BGP route can remain visible in Azure without remaining authoritative for forwarding once VNRA governs the packet path.

That is not just a troubleshooting nuance. It changes how you judge hybrid determinism, what evidence you trust during incidents, and whether a route table is telling you the thing you think it is.

The Mental Model

The common assumption is straightforward:

If a subnet has a propagated route from a VPN Gateway or ExpressRoute gateway, that route is the authority for forwarding unless something more specific overrides it.

That model works well enough until VNRA enters the picture. Then the mistake is not that Azure stops learning the route. The mistake is assuming that learning, visibility, and forwarding authority are still the same thing.

They are not.

Once VNRA participates in the routing outcome, a propagated route may still be present while no longer being the deciding authority for how traffic is actually delivered.

That is the mental shift:

BGP propagation tells Azure a prefix is reachable
VNRA can change whether that propagated route remains authoritative for forwarding
Effective routing evidence is no longer the same thing as forwarding truth

If you miss that distinction, hybrid routing starts to look deterministic on paper and conditional in production.

How It Really Works

This series is deliberately data plane first, so the question here is not “did Azure learn the route?” but “what governs forwarding once both gateway propagation and VNRA are involved?”

Propagation and authority are not the same thing

A route propagated from a gateway into a subnet tells you Azure has imported reachability information for that prefix. That is a control-plane fact.

The mistake is treating that fact as conclusive proof that the propagated route still governs forwarding for that subnet.

With VNRA in play, that is no longer a safe assumption.

A visible route with VirtualNetworkGateway as its source can still exist while VNRA is the stronger determinant of the realised path. Put bluntly:

Visibility of a propagated route does not guarantee authority over forwarding.

That is the actual fault line in hybrid designs using VNRA.

VNRA changes route authority, not just packet inspection

It is tempting to talk about VNRA as though it merely influences where packets are observed or inspected. That framing is too weak.

The important change is that VNRA can alter which route source remains authoritative in practice for a given path. Once that happens, the gateway-learned route is still part of the routing picture, but it is no longer the decisive actor engineers often assume it to be.

That is why hybrid issues in VNRA-connected designs can look contradictory:

the prefix is present
the gateway is healthy
the effective route table looks fine
traffic behaviour still does not align with a gateway-authoritative path

That is not necessarily a gateway problem. It is often a route authority problem.

The practical boundary is where forwarding stops obeying propagation

A useful way to reason about this is to stop asking whether BGP propagation exists and start asking where it remains authoritative.

Once VNRA governs the packet path for a subnet or transit flow, propagated routes may still be true in the sense that Azure has learned them, but they stop being authoritative in the way architects and operators usually care about: they no longer guarantee the forwarding outcome.

That is the decision boundary that matters.

If VNRA governs the path, the propagated route becomes evidence of learned reachability, not proof that the gateway still governs forwarding behaviour.

A Concrete Hybrid Scenario

Consider a spoke workload subnet in a hybrid environment.

The subnet receives propagated on-premises prefixes from a hub-connected ExpressRoute or VPN gateway. A VM in that subnet shows the expected private prefixes in its effective routes, sourced from VirtualNetworkGateway.

An engineer checks the route table and concludes the hybrid path is behaving as designed.

That conclusion may be wrong.

If VNRA governs forwarding for that subnet’s traffic, then the visible gateway-propagated route is no longer enough to prove that the gateway remains the authority over delivery. The route is present, but the packet path is now being decided elsewhere.

That is the trap.

flowchart LR A[Spoke workload subnet] B[Effective route shows on-prem prefix
Source: VirtualNetworkGateway] C[VNRA governs forwarding path] D[Observed traffic does not behave as though gateway propagation is authoritative] E[Operator assumes gateway path is still decisive] A --> B B --> E A --> C C --> D

The point of this flow is simple: route visibility and forwarding authority can diverge once VNRA is in the path.

Real-World Impact

This is where the article either matters or it does not.

Hybrid determinism is weaker than the route table suggests

A lot of Azure hybrid designs quietly assume that propagated gateway routes provide stable authority across workload subnets. VNRA weakens that assumption.

If the design depends on “the subnet can see the propagated route, therefore that route governs forwarding”, the design is less deterministic than it looks.

How would this change something you design, deploy, or operate?

It means you should stop treating propagated BGP visibility as proof of packet path in VNRA-connected hybrid environments. For design reviews, that changes what evidence is acceptable. For operations, it changes what counts as validation.

Effective routes become evidence, not authority

This is the stronger operational opinion the article needs to make explicit:

In VNRA-affected hybrid paths, effective routes are useful evidence of learned reachability, but they are no longer authoritative proof of forwarding behaviour.

That is not because effective routes are wrong. It is because they answer a narrower question than many engineers use them for.

They can tell you Azure learned the prefix.

They cannot, on their own, prove that the gateway-learned route still governs the realised path once VNRA has altered route authority for forwarding.

Incident triage needs a different first question

Without VNRA, it is reasonable to begin with:

did the gateway lose the route?
did BGP stop propagating the prefix?
is the effective route missing?

With VNRA in the picture, the earlier question is often:

Does the propagated route still have forwarding authority for this subnet, or is VNRA now the governing path decision?

That is a materially better triage question because it separates control-plane health from forwarding truth.

Subnet-level behaviour matters more than VNet-level assumptions

One of the quieter risks here is over-generalising from a broad topology statement like “the VNet has the propagated route”.

That is too coarse.

In VNRA-influenced environments, the question is whether a particular subnet and path still behave as though the gateway-propagated route is authoritative. If not, route visibility at a wider scope is operationally misleading.

Implementation Example

This series excludes deployment guidance, but an operational article still needs a concrete artefact.

A common starting point is to inspect effective routes on a workload NIC.

Azure CLI: inspect effective routes

1
2
3
4


az network nic show-effective-route-table \
 --resource-group rg-spoke-prod \
 --name nic-app-01 \
 --output table

Example output:

1
2
3
4
5
6


Source State Address Prefix Next Hop Type
--------------------- ------- ------------------ ---------------------
Default Active 10.20.0.0/16 VnetLocal
VirtualNetworkGateway Active 172.16.0.0/12 VirtualNetworkGateway
VirtualNetworkGateway Active 192.168.100.0/24 VirtualNetworkGateway
Default Active 0.0.0.0/0 Internet

The operational mistake is to stop here and conclude:

“The on-prem route is present, so the gateway still governs forwarding.”

That conclusion is not justified in a VNRA scenario.

A better interpretation is:

Azure has learned the route
the subnet can see the propagated prefix
you still have not proved that the propagated route remains authoritative for forwarding

That distinction changes your next action. You move from route inspection to path validation.

In practice, that means validating observed behaviour with whichever telemetry is available in your environment, such as:

flow observations on the forwarding path
packet capture on test workloads
appliance-side session or forwarding logs
bidirectional connectivity tests between Azure and on-premises endpoints

The exact tool is less important than the principle: if forwarding behaviour and effective routes disagree, trust the forwarding outcome.

Gotchas & Edge Cases

A healthy gateway does not prove authoritative forwarding

Engineers often stop investigating once they confirm the gateway is up and prefixes are propagated. In a VNRA design, that only proves the control plane still knows the route. It does not prove the gateway remains the decisive authority for delivery.

Route visibility can create false certainty

The more “correct” the effective route table looks, the easier it is to over-trust it. That is exactly why this class of issue survives design reviews and slows incident response.

Hybrid asymmetry becomes easier to misunderstand

If teams assume a visible propagated route still governs both directions of traffic, they can misread asymmetric behaviour as a gateway fault or application issue when the underlying problem is that forwarding authority has shifted.

Prefix learning and forwarding authority can diverge cleanly

This is worth stating plainly: a propagated route does not need to disappear for its practical authority to be reduced. Azure can still learn the prefix while VNRA governs the realised packet path.

Best Practices

Treat propagated routes as learned reachability, not guaranteed authority

In VNRA-connected hybrid designs, a propagated route should be treated as evidence that Azure knows the prefix exists, not proof that the gateway still governs packet forwarding for that path.

Validate routing at the subnet-path level

Do not validate “hybrid routing” as a broad topology property. Validate whether a given subnet’s traffic to a given prefix still behaves according to the route authority you expect.

Update your runbooks to separate control-plane and forwarding checks

Runbooks should explicitly distinguish between:

route learned
route visible
route authoritative for forwarding

Those are no longer interchangeable conditions.

Use effective routes as a clue, not a verdict

Effective routes are still useful. They are just not the final word in VNRA scenarios.

🍺

Brewed Insight: A visible VirtualNetworkGateway route can tell you Azure learned the prefix. It cannot, by itself, tell you the gateway still governs delivery once VNRA is shaping the path. In hybrid Azure, that is the difference between a route table that looks right and a system that actually behaves right.

VPN Gateway on Brewed in the Cloud by Chris Hailes