Azure Route Server : valider une annonce BGP avant sa propagation en production

Une équipe réseau doit annoncer un nouveau préfixe depuis une appliance virtuelle vers Azure Route Server. Le changement paraît local : une route BGP de plus, une préférence connue, puis un test applicatif. En réalité, la route peut être propagée vers plusieurs VNets, gagner face à une route moins spécifique, déplacer le chemin retour et faire passer des flux dans une appliance qui n’a ni la policy ni la capacité attendues.

Ce runbook traite un changement planifié dans un hub Azure connecté à des spokes et à un réseau externe. Son objectif est de prouver ce qui sera appris, propagé et réellement sélectionné avant d’élargir l’annonce. La sortie attendue est une décision explicite : conserver le préfixe, corriger l’origine BGP, retirer l’annonce ou bloquer le changement.

Borner le changement à un préfixe et un pair

Commencez par écrire le contrat de routage. « Ajouter le réseau du nouveau site » n’est pas assez précis pour distinguer une annonce attendue d’une fuite de routes.

change:
route_server: ars-hub-prod-weu
peer: nva-hub-a
peer_asn: asn-nva-approuve
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: spoke-app -> hub -> nva-hub-a -> reseau-externe
return: reseau-externe -> nva-hub-a -> hub -> spoke-app

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

Le préfixe canary doit cibler une destination test sans trafic métier irréversible. Il ne doit pas recouvrir un espace déjà utilisé ni devenir une route de secours implicite.

Capturer la table avant le changement

Une session BGP Connected ne prouve pas que la bonne route est apprise ni qu’elle est propagée au bon endroit. Capturez le pair, les routes apprises depuis ce pair et celles qu’Azure lui annonce.

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

Conservez aussi la configuration BGP de l’appliance, les préfixes autorisés et le dernier commit IaC. Route Server transporte l’information reçue ; la maîtrise des préfixes autorisés reste un contrôle à poser sur l’origine, l’appliance et le processus de changement.

Rechercher collisions et chemins concurrents

Avant d’annoncer, recherchez le préfixe exact, ses parents et ses sous-réseaux dans les UDR, les routes apprises par les autres pairs et les espaces d’adressage des VNets. Une route plus spécifique peut gagner même si son chemin BGP semble moins favorable.

Bloquer le changement si
Le prefixe chevauche un VNet, un subnet ou une route UDR existante
Un autre pair annonce deja le prefixe ou un sous-prefixe
Le chemin retour n'est pas documente
L'appliance ne filtre pas les routes hors perimetre
Le retrait de l'annonce exige une operation non testee

Continuer seulement si
Le proprietaire du prefixe est identifie
Le next hop et le chemin retour sont approuves
Le canary est sans effet metier irreversible
Les metriques et logs sont disponibles pendant la fenetre
Le retrait est executable par un operateur nomme

Private Endpoint n’est pas le sujet central. S’il existe dans un spoke concerné, vérifiez seulement que le nouveau préfixe ne capture pas son adresse ou le chemin vers son DNS ; l’annonce BGP ne corrige pas une résolution privée incohérente.

Annoncer le canary, puis vérifier la route sélectionnée

Activez d’abord le seul préfixe canary depuis l’appliance. Après convergence, vérifiez qu’il apparaît dans les routes apprises du pair. Contrôlez ensuite les routes effectives d’une NIC de test dans chaque spoke réellement concerné.

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

La présence dans la table apprise et la présence dans une table effective répondent à deux questions différentes. La première confirme l’échange BGP. La seconde montre ce qu’un workload donné peut réellement sélectionner après combinaison des routes système, UDR et routes propagées.

Si le préfixe n’apparaît pas, n’élargissez pas l’annonce. Vérifiez le pair, l’ASN, l’adresse du voisin, les filtres de l’appliance et la stabilité de la session. S’il apparaît avec un next hop inattendu, retirez-le avant tout test applicatif.

Prouver le chemin aller et le chemin retour

Envoyez un seul flux de test horodaté vers une destination du préfixe canary. Corrélez la source, l’appliance, le firewall éventuel et la destination. Un ping réussi ne suffit pas si la production utilise TCP, TLS ou un protocole dont l’état traverse l’appliance.

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

Vérifiez le retour depuis le réseau externe vers l’adresse source. Une route aller correcte avec un retour direct crée un chemin asymétrique que les équipements stateful peuvent refuser. L’article existant sur le diagnostic UDR devient alors le complément utile, mais le rollback immédiat reste le retrait du préfixe canary.

Étendre ou retirer avec un critère écrit

N’annoncez le préfixe final qu’après stabilité du canary sur plusieurs probes et contrôle des spokes concernés. Répétez les snapshots après extension ; ne déduisez pas la propagation finale à partir du seul /28.

Conserver et etendre
Le canary est appris par le pair attendu
Les workloads vises selectionnent le next hop approuve
Le chemin retour traverse le meme domaine d'inspection
Aucun prefixe adjacent n'a change de route effective
Les probes applicatives restent dans la baseline

Retirer l'annonce
Le prefixe ou le next hop est inattendu
La propagation atteint un spoke hors perimetre
Le retour contourne l'appliance
La session BGP devient instable
Les logs ou routes effectives ne permettent pas de conclure

Corriger avant nouvelle tentative
Filtrage de prefixe trop large sur l'appliance
Chevauchement d'adressage ou sous-prefixe concurrent
UDR qui force un autre chemin dans un seul sens
Capacite ou policy insuffisante sur le next hop

Le rollback consiste d’abord à retirer l’annonce à sa source, puis à vérifier sa disparition des routes apprises et des routes effectives. Ne supprimez pas le peer Route Server pour retirer un seul préfixe : cela élargirait inutilement l’impact aux autres routes du voisin.

Clore seulement après disparition ou stabilité prouvée

Après retrait, attendez la convergence observée plutôt qu’un délai arbitraire. Le préfixe doit avoir disparu de la table apprise, des routes effectives et des équipements aval. Rejouez la probe via le dernier chemin connu et confirmez qu’aucune route temporaire ne subsiste hors de l’IaC.

Après validation, enregistrez le préfixe final, le pair d’origine, les spokes où il est attendu, le chemin retour et le propriétaire du filtre. Ce dossier devient la baseline du prochain incident ou changement.

Conclusion

Une annonce BGP Azure n’est validée ni par une session connectée ni par une ligne visible dans Route Server. Elle est validée quand le préfixe attendu est appris du bon pair, sélectionné par les workloads visés, observé dans les deux sens et absent des périmètres non concernés.

La décision de production tient alors en quatre options : étendre après canary, corriger l’origine, retirer l’annonce ou bloquer faute de preuve. Le bon rollback retire un préfixe à sa source et contrôle sa disparition ; il ne démonte pas tout le peering pour retrouver un réseau stable.