Azure Virtual Network Routing Appliance: When Packet Truth Moves Away from the Edge

Tue, 30 Jun 2026 00:00:00 +1000

In plain Azure networking, plenty of engineers get away with a simple habit: check the effective routes on the NIC, sanity-check the subnet, and infer the packet path from there.

Most of the time, that shortcut is good enough.

VNRA is where it starts to break.

Not because Azure suddenly becomes opaque, and not because route evaluation stops mattering. The change is more useful than that. Once VNRA is introduced, the packet path is no longer best understood from the edge inward. The centre of gravity moves. Forwarding intent becomes more centralised, and attachment-level effective routes become a local view of a broader forwarding design.

That is the shift this post is about.

The Mental Model

The common assumption is straightforward:

If I can see the effective routes on the NIC or subnet, I can explain how the packet will move.

That assumption holds often enough in Azure to become muscle memory. It is also exactly the habit VNRA exposes.

The better mental model is this:

VNRA does not replace Azure routing. It recentres forwarding intent around a shared routing control point, which means NIC- and subnet-level effective routes are no longer the authoritative explanation of end-to-end packet behaviour.

That is an important distinction.

This is not about obscurity. Azure has not become mysterious. System routes still exist. User-defined routes (UDRs) still matter. Route precedence still matters. Longest prefix match still matters.

What changes is where packet truth lives.

Before VNRA, many engineers reason from the edge inward:

inspect the source attachment
read the effective routes
infer the path

With VNRA in the design, that shortcut becomes unreliable. You now need to reason from the forwarding design outward:

understand the role of the shared routing control point
then interpret local effective routes in that context

That is a design shift, an operations shift, and a troubleshooting shift.

How It Really Works

VNRA does not turn Azure into a traditional routed fabric with a core router that owns the whole network. Azure still owns the underlying virtual network fabric. The platform still provides system behaviour. Effective routes still express local route-selection context.

What changes is that forwarding expectations increasingly need to be interpreted relative to VNRA’s role in the path.

That makes VNRA less like a simple next-hop override and more like the logical centre of forwarding intent.

Before VNRA

In a conventional Azure design, an engineer might look at the source NIC, inspect its effective routes, and treat that as a near-final explanation of packet behaviour.

That is not perfectly complete, but it is often operationally serviceable.

A familiar mental flow looks like this:

flowchart LR A[Source NIC] --> B[Effective route evaluation] B --> C[Winning route selected] C --> D[Azure native forwarding path] D --> E[Destination]

After VNRA

With VNRA present, the route evaluation at the source still matters, but it no longer tells the whole story on its own. The winning route needs to be interpreted in the context of a forwarding design whose centre now sits at the routing appliance.

flowchart TB subgraph SpokeA[Spoke A] A1[Source workload] A2[Source NIC effective routes] end subgraph Hub[Shared routing domain] H1[VNRA as forwarding control point] end subgraph SpokeB[Spoke B] B1[Destination workload] end A1 --> A2 A2 --> H1 H1 --> B1

The point is not that Azure stops selecting routes at the source. It does not.

The point is that the source attachment no longer gives you a sufficient explanation of the full packet path. It gives you a local route-selection view inside a forwarding design that now has a more central control point.

A Concrete Scenario: Spoke-to-Spoke Traffic

This is where the old instinct starts to fail.

Assume you have:

a workload in Spoke A
a workload in Spoke B
VNRA positioned in the shared routing domain
traffic between the spokes expected to follow that central forwarding design

An engineer checks the effective routes on the source NIC in Spoke A and sees the expected destination prefix. That is useful, but it only answers part of the question.

It tells you:

what route-selection context exists at the source attachment
which route is likely to win locally

It does not, by itself, prove that the end-to-end packet path is correctly understood purely from that edge view.

That is the mistake to avoid.

In a VNRA-centred design, the source NIC route table is no longer the best place to infer the whole story. The authoritative interpretation now sits with the shared forwarding design that the appliance represents.

So the practical shift is this:

pre-VNRA habit: read the packet path from the source edge
VNRA-aware habit: read the packet path from the forwarding centre, then use edge effective routes to validate local context

That is a very different troubleshooting posture.

What Changes in Effective Routes

This is where precision matters.

The change is not that effective routes become wrong.

The change is not that Azure starts hiding route information.

The change is this:

Effective routes remain useful for understanding local route-selection context, but they are no longer sufficient on their own to explain end-to-end packet behaviour once VNRA becomes the logical centre of forwarding intent.

That is a narrower and more defensible claim.

What still holds

Longest prefix match still applies.
Route precedence still applies.
UDRs still influence forwarding intent.
System routes still exist.
Propagated routes still matter where applicable.

What changes operationally

A familiar-looking effective route table can create false confidence.
Local route correctness does not guarantee correct packet-path interpretation.
The packet path can no longer be safely inferred from attachment-level visibility alone.
Route inspection becomes one step in analysis, not the final answer.

That is the real impact.

Azure Default Routing Behaviour Does Not Disappear

One easy mistake is to overstate what VNRA changes.

VNRA does not mean Azure abandons its default routing model. The platform is still doing what the platform does. Azure has not become a blank underlay underneath your appliance.

That matters because this is not an article arguing that VNRA replaces Azure routing.

It is arguing something more specific:

VNRA changes the operational locus of truth for packet-path interpretation.

That is why engineers get caught.

They compare route objects before and after VNRA, see something broadly familiar, and conclude the forwarding story is still edge-readable in the same way. It often is not.

The route constructs may still look recognisable. The packet-path explanation is what changes.

Why Next-Hop Thinking Is Not Enough

A lot of Azure route interpretation compresses two ideas into one:

which route wins
what packet path that creates

Without VNRA, that shortcut often survives.

With VNRA, it becomes much less safe.

The route winner at the source attachment still matters, but the realised forwarding expectation now needs to be interpreted relative to the appliance-centred design. If you skip that second step, you can end up with a route table that looks correct and an understanding of packet behaviour that is not.

That is why this topic matters in production.

Real-World Impact

So how would this change something you design, deploy, or operate?

It changes where you validate packet truth.

Design

When VNRA is in the forwarding design, you should stop validating routing solely from the edge.

Instead, design reviews need to ask:

what is the intended central forwarding path?
which flows depend on that shared routing control point?
do local effective routes support that intent, rather than supposedly define it?

That sounds subtle, but it changes how deterministic your design really is.

A route table can be technically correct and still be a poor explanation of the intended packet path.

Deployment

Successful deployment is no longer proven by:

a route object being present
an effective route appearing on a NIC
an appliance existing in the environment

Those are useful checks, not sufficient proof.

If VNRA is the centre of forwarding intent, deployment validation has to confirm that the intended traffic classes actually align with that central design. Otherwise you have validated configuration artefacts, not forwarding behaviour.

Operations

This is where the change becomes most visible.

Your runbooks need to separate two different questions:

Is local route selection at the attachment point correct?
Is the packet path behaving according to the VNRA-centred forwarding design?

Those are not the same question.

Without that distinction, teams end up diagnosing packet-path issues as though they were route-precedence issues, or vice versa.

That is how incident response gets slower and less accurate.

Implementation Example: Effective Routes as Local Evidence

The Azure CLI still gives you a useful first view.

1
2
3


az network nic show-effective-route-table \
 --resource-group rg-network-prod \
 --name spokea-app01-nic

That output tells you the local route-selection context for that NIC.

It does not by itself prove the full end-to-end path once VNRA is acting as the shared routing control point.

A VNRA-aware interpretation looks more like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Source NIC effective routes:
- 10.20.0.0/16 via VirtualNetwork
- 10.30.0.0/16 via UserDefinedRoute

What this tells you:
- The source attachment has a visible route-selection context.
- A specific route source is winning locally.

What this does not tell you on its own:
- That the full packet path is correctly understood purely from this edge view.
- That the observed forwarding behaviour aligns with the VNRA-centred design.

That is the practical shift. The command has not changed. The meaning you assign to its output has.

Gotchas and Edge Cases

Familiar route output creates false confidence

This is probably the biggest trap.

The effective route table can look entirely reasonable while still being an incomplete explanation of actual packet behaviour. Engineers trust familiar output quickly. VNRA punishes that habit.

Local route correctness and path correctness are different things

You can have a locally sensible route outcome and still misread the real packet path if you are treating the source attachment as the authoritative viewpoint.

That matters most when traffic between shared network domains is expected to conform to a centrally expressed forwarding design.

Comparing before and after route tables can mislead you

If your only test is “did the effective route entries visibly change?”, you may miss the actual shift.

VNRA is often less about inventing new-looking route artefacts and more about changing where the authoritative packet-path interpretation now sits.

Split responsibility makes diagnosis worse

If one team validates route objects and another validates appliance health, but neither owns packet-path interpretation end to end, VNRA will expose that gap quickly.

This is not a governance post, so I will leave it there. Operationally, though, the boundary matters.

Best Practices

1. Stop treating edge effective routes as the whole packet narrative

They are still useful. They are no longer authoritative on their own.

2. Model packet paths from the forwarding centre outward

If VNRA sits at the heart of forwarding intent, start there. Then use attachment-level route views to confirm local context.

3. Separate route correctness from forwarding correctness in your runbooks

Make this explicit. It will prevent a lot of bad diagnosis during incidents.

4. Challenge designs that rely on edge inference alone

If the only way to explain a path is by reading local route tables and hoping that tells the whole story, the design is probably under-validated.

5. Favour determinism over cleverness

A VNRA-centred design should make packet intent clearer, not turn troubleshooting into guesswork.

🍺

Brewed Insight: VNRA is not interesting because it adds another routing target. It is interesting because it moves packet truth away from the edge. Once forwarding intent is centralised, effective routes become local evidence, not the final explanation.

Effective Routes on Brewed in the Cloud by Chris Hailes