If you've been keeping an eye on Azure Networking, you’ve likely seen the global preview of route maps for Azure Route Server (ARS). While route maps might sound like a straightforward enhancement, applying them to ARS actually introduces deep architectural shifts that can disrupt some existing advanced network setups.

In this post, we'll explore why route maps for ARS are more than just a feature, what makes them challenging in complex topologies like the square hub design, and how to mitigate issues with BGP peerings across VNets and hubs. Whether you operate multi-hub architectures, utilize NVAs extensively, or rely on VNet-to-VNet IPsec connections, you’ll want to understand these implications before enabling route maps in production.

We’ll walk through the core challenges, outline the architecture impact, and share practical workarounds to help your Azure networking stay robust and scalable.

Architecture Overview

Here is a conceptual view of the major components discussed, showing data flow between hubs, NVAs, and Azure Route Server instances:

┌──────────────────────────────┐
│        On-Premises           │
├──────────────────────────────┤
│ • VNet-to-VNet IPsec         │
│ • VPN Gateways               │
└─────────────↓────────────────┘
              ↓
┌──────────────────────────────┐
│     Azure Virtual Hubs       │
├──────────────────────────────┤
│ • Azure Route Server (ARS)  │
│ • NVAs with BGP Peering     │
│ • Virtual Network Gateways  │
└───────┬─────────┬────────────┘
        ↓         ↓
┌──────────────────────────────┐
│        Inter-Hub Links       │
├──────────────────────────────┤
│ • Hub-to-Hub VNet Peering   │
│ • Cross-Hub BGP Peering via │
│   NVAs                      │
└──────────────────────────────┘

This diagram reflects the “square design” scenario that exercises advanced routing challenges such as hub-to-hub connectivity, multi-region resiliency, and dynamic route failover without asymmetric routing.

Illustrative square hub design with route server and NVAs managing routing via BGP, from Cloudtrooper.

Key Technical Observations

• Route Maps Trigger a Major ARS Software Upgrade — Enabling route maps does much more than adding filtering capabilities; it fundamentally changes ARS’s internal data model by introducing “connections” similar to those in Virtual WAN.

• Breaking Backwards Compatibility with VNet-to-VNet Connections — ARS’s new connection model is aligned to VWAN, which lacks support for VNet-to-VNet connections. This causes BGP route propagation issues when such connections are in use, as ARS cannot classify the BGP peer as a valid connection.

• Requirement for Connections in BGP Peer Configuration — When NVAs are peered from a different VNet, ARS requires explicit VNet connections. The inability to model cross-hub VNet connections where “Allow Gateway Transit” or “Use Remote Gateways” cannot be enabled causes failures in ARS BGP neighborships.

• Hub-to-Hub NVAs Challenges — Scenarios involving BGP peerings across hubs (like dual-hub or transit architectures) are not natively supported under ARS route map architecture. VWAN handles these natively, but ARS expects a simpler hub-spoke model.

• Route Engineering Workaround via NVAs — To restore cross-hub reachability without UDRs, direct BGP peering between NVAs themselves (bypassing ARS peering across hubs) is a viable workaround, provided routes are manipulated for AS path and next-hop to prevent loops and route rejection.

• Asymmetric Routing Risks Mitigated Through Careful Next-Hop Control — Without adjusting next-hop in BGP advertisements between NVAs, routing loops or blackholes could occur. Setting the next hop correctly ensures stable forwarding.

How It Works: Deep Dive into ARS Route Maps Impact

The ARS Connection Model and Its Implications

Originally, Azure Route Server was a straightforward BGP route reflector without the richer “connection” abstraction present in Virtual WAN. In VWAN, everything is a connection — VNets, ExpressRoute, VPN, sites — each modeled explicitly.

Route maps in VWAN applied at the connection level. To port this feature to ARS, the concept of connections had to be introduced in ARS’s data model. This forced a software rewrite/upgraded ARS instances, changing route processing fundamentally.

Consequently:

• Every BGP peering must belong to a well-defined connection.
• Scenarios that don’t align with VWAN connection types (e.g., VNet-to-VNet IPsec tunnels, or NVAs bridging hubs) break or stop receiving routes.
• ARS no longer emits errors in some failure cases, making troubleshooting harder.

BGP Peering Changes for NVAs in Different VNets

When adding a BGP peer in Azure Portal for ARS with route maps enabled, a new “VNet Connection” field appears. Peers in the same VNet get auto-associated and the dropdown is greyed out. For peers in different VNets, a valid VNet connection must exist.

However, hub-to-hub VNet peerings usually cannot enable “Allow Gateway Transit” or “Use Remote Gateways,” which the ARS expects for the connection to exist. This breaks the model and disables the expected route propagation.

Hub-to-Hub Cross-Peering Workaround

Bypassing ARS limitations involves creating direct BGP peerings between NVAs deployed in each hub, effectively stitching routes with manual control:

[ARS1] ←→ [NVA1] ←→ [NVA2] ←→ [ARS2]

This approach requires NVAs to:

• Strip the AS path number 65515 before advertising to avoid BGP route rejection.
• Advertise routes learned from the other hub using the other NVA as the next hop, preventing routing loops within the subnet.

This design yields dynamic, failover-capable cross-hub routing without relying on static UDRs or encapsulation overlays.

Example Effective Route Table on NVA2’s NIC

Source                 State    Address Prefix    Next Hop Type          Next Hop IP
---------------------  -------  ----------------  ---------------------  -------------------
Default                Active   10.20.0.0/16      VnetLocal
Default                Active   10.21.0.0/24      VNetPeering

VirtualNetworkGateway  Active   10.11.0.0/24      VirtualNetworkGateway  10.10.1.4

VirtualNetworkGateway  Active   10.20.0.0/15      VirtualNetworkGateway  10.20.1.4
...

Traffic flows dynamically between spokes over both NVAs, respecting BGP routes without overlay technology or static routes.

Traceroute output demonstrating cross-hub NVA traffic flow — source: Cloudtrooper.

Quick Tips & Tricks

1. Evaluate Your Topology Before Enabling Route Maps
   Complex hubs using VNet-to-VNet IPsec or cross-hub BGP peers may break. Test thoroughly in non-production environments.

2. Map Every BGP Peer to a Valid Connection
   Ensure that all BGP peers have associated VNet connections that support “Allow Gateway Transit” and “Use Remote Gateways” options. If not possible, expect issues.

3. Use NVAs for Cross-Hub BGP Peering
   To achieve dynamic hub-to-hub routing where ARS route maps fail, create BGP peerings directly between NVAs with route rewriting for AS path and next hop.

4. Leverage Overlay Protocols as a Last Resort
   If you prefer to avoid complex route engineering between NVAs, encapsulation overlays like IPsec or VXLAN remain valid workarounds for multi-hub scenarios.

5. Monitor BGP Sessions Closely After Enabling Route Maps
   Lack of explicit error signaling in ARS route map upgrades means silent route loss can occur. Enable logging and monitor routes proactively.

6. Stay Updated on Azure Route Server Roadmap
   The introduction of connections and route maps marks a platform evolution. Track Microsoft releases for improvements and fixes to these advanced use cases.

Conclusion

Azure Route Server route maps introduce more than route filtering capabilities—they rewrite how ARS models network topology internally, aligning it with Virtual WAN's connection model. For many, this brings powerful new controls. For advanced architectures—especially those involving VNet-to-VNet IPsec, cross-hub NVAs, or multi-hub peering—the changes can cause route propagation failures and complex troubleshooting.

While Microsoft is still evolving ARS, it’s critical to assess your deployment before enabling route maps and understand the new connection abstractions. The workaround of direct NVA-to-NVA BGP peering with careful route manipulation unlocks dynamic, resilient cross-hub routing without losing ARS benefits.

Route maps are a step forward, but for now, they require careful planning when integrating with existing advanced networking designs. Cloud network architects should expect more evolutions and should test extensively to maintain stability.

References

1. Azure Route Server route maps overview (Microsoft Docs) — Official documentation on route maps feature.
2. Simon Painter’s blog post on Azure Route Server route maps — One of the earliest analyses of the feature.
3. Azure ExpressRoute Local — Azure ExpressRoute SKU relevant for multi-region network architectures.
4. Dual-Homed Network ExpressRoute integration — Details on advanced multi-hub connectivity patterns.
5. Azure Route Server: to encap or not to encap, that is the question – Cloudtrooper — Prior deep dive on overlay workarounds.
6. Azure VMware Solution example architectures — Real-world scenario with NVAs and complex BGP peering.

Content courtesy of Cloudtrooper.net

---