Azure Route Server: validate a BGP advertisement before production propagation

A network team must advertise a new prefix from a virtual appliance to Azure Route Server. The change looks local: add one BGP route, confirm its preference, then run an application test. In practice, that route can propagate to several VNets, win over a less specific path, move return traffic, and send flows through an appliance that has neither the expected policy nor sufficient capacity.

This runbook covers a planned change in an Azure hub connected to spokes and an external network. Its purpose is to prove what will be learned, propagated and actually selected before expanding the advertisement. The outcome is an explicit decision to retain the prefix, repair the BGP origin, withdraw it or block the change.

Bound the change to one prefix and peer

Write the routing contract first. “Add the new site network” is too vague to distinguish an intended advertisement from a route leak.

change:
route_server: ars-hub-prod-weu
peer: nva-hub-a
peer_asn: approved-nva-asn
canary_prefix: 10.84.240.0/28
final_prefix: 10.84.0.0/16
maintenance_window_utc: 2026-08-02T20:00:00Z/2026-08-02T21:00:00Z

expected_path:
forward: app-spoke -> hub -> nva-hub-a -> external-network
return: external-network -> nva-hub-a -> hub -> app-spoke

evidence:
- peer_state_before_after
- learned_and_advertised_routes_before_after
- effective_routes_on_canary_workload
- nva_and_firewall_logs_for_one_flow
- application_probe_and_latency_baseline
- withdrawal_owner_and_deadline

The canary prefix must target a test destination with no irreversible business effect. It must not overlap existing address space or become an undocumented backup route.

Capture the routing state before the change

A Connected BGP session does not prove that the correct route is learned or propagated to the right place. Capture the peer, the routes learned from it and the routes Azure advertises back.

RG="rg-network-prod"
ROUTE_SERVER="ars-hub-prod-weu"
PEER="nva-hub-a"

az network routeserver peering show --resource-group "$RG" --routeserver "$ROUTE_SERVER" --name "$PEER" --output json

az network routeserver peering list-learned-routes --resource-group "$RG" --routeserver "$ROUTE_SERVER" --name "$PEER" --output table

az network routeserver peering list-advertised-routes --resource-group "$RG" --routeserver "$ROUTE_SERVER" --name "$PEER" --output table

Also preserve the appliance BGP configuration, allowed prefixes and last IaC commit. Route Server carries received routing information; prefix control still belongs at the origin, on the appliance and in the change process.

Find collisions and competing paths

Before advertising, search for the exact prefix, its parents and its subnets in UDRs, routes learned from other peers and VNet address spaces. A more specific route can win even when its BGP path looks less attractive.

Block the change when
The prefix overlaps a VNet, subnet or existing UDR
Another peer already advertises the prefix or a sub-prefix
The return path is undocumented
The appliance does not filter out-of-scope routes
Advertisement withdrawal requires an untested operation

Continue only when
The prefix owner is identified
The next hop and return path are approved
The canary has no irreversible business effect
Metrics and logs are available during the window
A named operator can execute the withdrawal

Private Endpoint is not the focus. If one exists in an affected spoke, only verify that the new prefix does not capture its address or DNS path; a BGP advertisement cannot repair inconsistent private resolution.

Advertise the canary, then inspect the selected route

Enable only the canary prefix from the appliance. After convergence, verify that it appears in the routes learned from that peer. Then inspect the effective routes of one test NIC in every spoke that is actually in scope.

RG="rg-network-prod"
ROUTE_SERVER="ars-hub-prod-weu"
PEER="nva-hub-a"
WORKLOAD_RG="rg-app-prod"
WORKLOAD_NIC="nic-app-canary-01"

az network routeserver peering list-learned-routes --resource-group "$RG" --routeserver "$ROUTE_SERVER" --name "$PEER" --output table

az network nic show-effective-route-table --resource-group "$WORKLOAD_RG" --name "$WORKLOAD_NIC" --output table

A learned route and an effective route answer different questions. The first confirms the BGP exchange. The second shows what a specific workload can select after system routes, UDRs and propagated routes are combined.

If the prefix is absent, do not expand the advertisement. Check the peer, ASN, neighbor address, appliance filters and session stability. If it appears with an unexpected next hop, withdraw it before any application test.

Prove both the forward and return paths

Send one timestamped test flow to a destination inside the canary prefix. Correlate evidence at the source, appliance, optional firewall and destination. A successful ping is insufficient when production uses TCP, TLS or another stateful protocol.

probe:
source: app-canary / 10.42.12.18
destination: service-canary / 10.84.240.4
protocol: tcp
port: 443
correlation_id: bgp-canary-20260802-01

success:
- effective route uses the approved next hop
- nva observes request and response
- destination observes the expected source identity
- tls and application response are valid
- latency and loss stay within the baseline
- adjacent prefixes keep their previous routes

stop:
- return traffic bypasses the nva
- an unrelated spoke learns the canary unexpectedly
- session flaps or route count changes outside the contract
- firewall denies appear on adjacent flows
- application probe becomes intermittent

Check the return route from the external network to the source address. A correct forward route with a direct return creates asymmetry that stateful devices can reject. The existing UDR asymmetry article is then a useful companion, but the immediate rollback remains withdrawal of the canary prefix.

Expand or withdraw using a written gate

Advertise the final prefix only after the canary remains stable across several probes and all affected spokes are checked. Repeat the snapshots after expansion; do not infer final propagation from the /28 alone.

Retain and expand
The canary is learned from the expected peer
In-scope workloads select the approved next hop
Return traffic crosses the same inspection domain
No adjacent prefix changed its effective route
Application probes remain within baseline

Withdraw the advertisement
Prefix or next hop is unexpected
Propagation reaches an out-of-scope spoke
Return traffic bypasses the appliance
The BGP session becomes unstable
Logs or effective routes cannot support a decision

Repair before retrying
Prefix filter is too broad on the appliance
Address overlap or competing sub-prefix exists
A UDR forces a different path in one direction
Next-hop capacity or policy is insufficient

Rollback starts by withdrawing the advertisement at its source, then confirming its disappearance from learned and effective routes. Do not delete the Route Server peer to remove one prefix: that would unnecessarily affect every other route exchanged with that neighbor.

Close only after proven stability or disappearance

After withdrawal, observe convergence instead of waiting for an arbitrary delay. The prefix must disappear from learned routes, effective routes and downstream devices. Replay the probe through the last known path and confirm no temporary route remains outside IaC.

After validation, record the final prefix, origin peer, expected spokes, return path and filter owner. That evidence becomes the baseline for the next change or incident.

Conclusion

An Azure BGP advertisement is validated neither by a connected session nor by one line visible in Route Server. It is validated when the intended prefix is learned from the correct peer, selected by in-scope workloads, observed in both directions and absent from unrelated scopes.

The production decision then has four outcomes: expand after the canary, repair the origin, withdraw the advertisement or block for lack of evidence. A good rollback removes one prefix at its source and verifies its disappearance; it does not tear down the entire peering to recover a stable network.