When Routes Disagree: VNRA Precedence and Conflict Resolution in Azure

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

If you have ever looked at an Azure effective route table and thought, that should not be the route that wins, this is the part that matters.

Route precedence in Azure is often explained as if each routing feature gets a turn at being authoritative. System routes do the baseline work, BGP propagated routes inject dynamic reachability, User Defined Routes (UDRs) override intent, and VNRA somehow arrives as a new control point that sits above the rest.

That framing is convenient. It is also what causes people to misread packet paths.

The stronger and more useful position is this:

VNRA is not a separate precedence domain. It changes routing outcomes inside Azure’s existing route selection logic, and the only version that matters is the effective route behaviour seen by the workload NIC.

That changes something you design and operate straight away. You stop asking whether VNRA “wins” against UDRs, BGP, or system routes as if it were a fourth referee. Instead, you ask what prefixes are present, which route source owns the winning prefix, and what next hop is actually selected for the packet.

That is the difference between platform intent and data-plane truth.

The Mental Model

The common assumption is that Azure routing is layered by feature:

system routes are default behaviour
propagated routes add learned reachability
UDRs override platform defaults
VNRA adds a new routing authority on top

That model breaks because Azure does not forward packets based on feature hierarchy. It forwards packets based on the effective route selected for a destination from the source NIC.

VNRA matters, but not because it suspends the normal rules. It matters because it affects the set of candidate routes and next-hop outcomes that Azure can realise. Once those candidates exist, Azure still resolves forwarding the same way it always has:

longest prefix match first
route source precedence only when prefixes are equal
the selected route becomes the packet path

So the mental shift is simple:

VNRA should be treated as a routing outcome modifier visible through effective route behaviour, not as a separate precedence domain.

If you treat it as a special layer above the rest, you will keep looking for feature interactions when the real answer is usually just prefix specificity plus route source precedence.

How It Really Works

Azure route selection is less mysterious when you strip it back to packet behaviour.

For any destination, Azure evaluates the effective route set applied to the source interface. The decision process is straightforward:

Find all matching routes for the destination IP
Select the most specific prefix
If multiple routes have the same prefix length, apply route source precedence
Use the winning route’s next hop

That means the first real question is never which routing feature is in charge. It is:

Which route actually wins for this prefix on this NIC?

That sounds obvious, but it gets lost quickly once VNRA enters the conversation. Engineers start attributing precedence to the feature rather than to the route that became effective.

A data-plane view of route selection

flowchart TD A[Packet arrives at source NIC] --> B[Match destination against effective routes] B --> C{Matching routes exist?} C -->|No| D[No explicit match beyond platform defaults] C -->|Yes| E[Select longest prefix match] E --> F{Equal prefix candidates remain?} F -->|No| G[Use selected next hop] F -->|Yes| H[Apply route source precedence] H --> I[Install winning route as forwarding decision] I --> G

The key point is deliberately plain: VNRA does not replace this logic. It shows up through it.

Route Source Conflicts in Practice

The route sources involved are not new, even if the design looks new.

System routes

System routes are Azure’s built-in opinion about reachability. They remain valid until something more specific exists, or an equal-prefix route with higher precedence takes their place.

The mistake is to treat them as irrelevant once you start using VNRA. They are still part of the candidate set, and they still win whenever nothing more specific or higher-precedence applies.

Propagated routes

BGP propagated routes can override system routes for the same prefix. They do not override a more specific route from another source, and they do not outrank a UDR for an equal prefix.

This is where people often start blaming VNRA for inconsistency when the real cause is simpler: a propagated route exists for a narrower prefix than the summarised path they expected to carry appliance-bound traffic.

UDRs

UDRs are still the clearest way to impose routing intent for a specific prefix. For equal prefixes, a UDR takes precedence over propagated and system routes.

That does not make UDRs universally dominant. A broad UDR only controls traffic where no more specific route exists. If you define a default route or a large summary and then allow narrower prefixes to appear from another source, Azure will choose the narrower route every time.

That is not an exception. That is the design consequence of using broad routing intent.

Where VNRA fits

This is the line to stay disciplined on:

VNRA does not appear as a separate route-precedence layer that overrides Azure routing rules. Its impact is expressed through the effective routes and next-hop decisions Azure realises.

So when engineers say “VNRA overrode my route”, what they usually mean is one of four things:

a more specific route existed than the one they expected to drive traffic through the appliance
an equal-prefix route with higher precedence was effective
the route they expected was configured, but not the route selected
they were reasoning from design intent, not from the effective route table on the workload NIC

That is not semantics. It is the operational difference between understanding Azure routing and narrating it.

What Actually Creates Ambiguity

Here is the harder opinion this topic needs.

VNRA does not introduce routing ambiguity. Overlapping prefixes and poor route intent do. VNRA just makes that ambiguity harder to ignore.

That matters because a lot of post-deployment confusion gets framed as platform inconsistency when it is really unresolved routing intent:

broad appliance steering is expected to cover everything
narrower prefixes are introduced later by propagation or platform behaviour
traffic follows the narrower route
the team concludes VNRA is unpredictable

But the route selection was predictable. The design was not precise enough.

If you want deterministic packet paths, your prefixes need to be deterministic. VNRA cannot rescue vague routing intent.

Real-World Impact

This changes how you assess routing risk.

Reliability

A route conflict does not need to cause packet loss to be a problem. If traffic takes a path other than the one assumed by the design, reliability becomes conditional. The system may work until a dependency expects inspection, symmetry, or path locality that is no longer true.

Security

If your security model depends on traffic traversing an appliance path, broad route intent is not enough. Any more specific competing route can bypass that path without creating a visible outage.

That means inspection assumptions are only as strong as your prefix discipline.

Scalability

The larger the environment, the more likely it is that summarised intent and specific reachability will collide. VNRA does not make large environments harder to reason about by itself. It exposes where the routing model was already under-specified.

Operational clarity

The practical question remains:

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

It means you validate routing by effective outcome, not by feature configuration. And it means broad steering constructs should be treated as coarse guidance unless you have actively controlled competing specific prefixes.

Implementation Example

This post is not a deployment guide, but precedence claims need a concrete artefact. The right artefact here is the effective route table, because that is where Azure shows the realised forwarding candidates.

Azure CLI: inspect effective routes on a NIC

1
2
3
4


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

For this topic, the fields that matter are:

destination prefix
route source
next hop type
next hop IP, where applicable

If your routing argument is not visible there, it is not yet a data-plane argument.

Example conflict

Assume the effective route table contains the following entries:

Source	Prefix	Next Hop Type	Next Hop
Default	10.20.0.0/16	Virtual network	-
VirtualNetworkGateway	10.20.10.0/24	Virtual network gateway	-
User	10.20.0.0/16	Virtual appliance	10.0.1.4
User	0.0.0.0/0	Virtual appliance	10.0.1.4

Now apply packet logic.

Traffic to 10.20.10.7 follows the /24 propagated route because it is the most specific match
Traffic to 10.20.50.9 follows the /16 UDR because it is an equal-prefix conflict with the system route and the UDR has higher precedence
Traffic to 8.8.8.8 follows the 0.0.0.0/0 UDR unless a more specific route exists

None of those outcomes require a special VNRA rule. They only require Azure to apply normal route selection.

Deterministic vs Non-Deterministic Outcomes

This distinction needs to be blunt.

Azure route selection is deterministic once the effective route set is realised. The non-determinism people experience is usually in route convergence, propagation timing, or control-plane state visibility not in the precedence engine itself.

That is an important separation.

If the same NIC has the same effective routes and the same destination, Azure should produce the same forwarding decision. If the observed behaviour changes over time, the first suspicion should be changing route state, not changing precedence logic.

In VNRA discussions, that matters because people often attribute temporary inconsistency to the feature when they are really observing asynchronous route realisation.

That does not make the problem trivial. It just means the problem is different.

Gotchas & Edge Cases

Broad appliance steering does not guarantee universal appliance transit

A default route or summary route pointing to an appliance only governs traffic where no narrower match exists. If you need deterministic inspection for a destination set, summarised intent alone is weak control.

Route presence is not route selection

A route being present in the effective route table does not mean it is the route used for your destination. It only means it is a candidate.

Equal-prefix reasoning is often skipped too early

Engineers jump to route source precedence before checking whether the conflicting routes even have equal prefixes. Most disputes disappear once you compare prefix length honestly.

VNRA can be blamed for decisions it did not make

If the winning path is the result of a more specific propagated route or an equal-prefix UDR, the routing logic is doing exactly what Azure normally does. VNRA may be involved in the design, but not in the precedence mechanism.

Best Practices

Design routing intent at the prefix level

Do not ask whether VNRA should “take precedence”. Ask which exact prefixes must be controlled, and what other sources may advertise or inject overlapping routes.

Treat broad routes as coarse policy, not hard enforcement

A summary or default route gives directional intent. It does not prove exclusive path ownership.

Validate from the workload NIC

Configured route tables tell you what you meant. Effective routes tell you what Azure is prepared to do. For conflict resolution, only the latter settles the question.

Call overlapping prefixes what they are

If two routing sources are competing for the same traffic set because the prefix model is sloppy, that is not platform complexity. It is unresolved design intent.

🍺

Brewed Insight: Most “VNRA routing surprises” are not VNRA surprises at all. They are ordinary Azure route selection rules exposing a design that relied on broad intent where specific control was required.

Virtual Network Routing Appliance on Brewed in the Cloud by Chris Hailes