7 — Azure ExpressRoute

Circuit privé dédié entre l'on-prem et Azure via un partenaire → ne traverse jamais internet. Bande passante élevée, latence prévisible, le choix des charges critiques.

A. Vue d'ensemble

ExpressRoute (ER) = circuit privé dédié entre l'on-prem et Azure via un partenaire (FAI / exchange provider). Ne traverse JAMAIS internet — c'est la grande différence avec S2S VPN.

A.1 Pourquoi ExpressRoute ?

• Bandwidth élevé : 50 Mbps → 100 Gbps (S2S VPN plafonné à 10 Gbps)
• Latence prévisible : circuit dédié, pas de variation internet
• Compliance "no internet" : banking, gov, healthcare (PHI, données sensibles)
• SLA 99.95% (vs 99.95% VPN AZ aussi, mais ER tient mieux dans la durée)
• Accès privé aux services publics MS (M365 etc.) via Microsoft peering

A.2 ExpressRoute vs S2S VPN — récap

A.3 Combo prod critique

ER primary + VPN S2S backup → 99.99% combiné. Pattern bancaire / fintech classique.

B. Architecture & Composants

B.1 Schéma global

ON-PREM                                        AZURE
┌──────────────────┐                          ┌──────────────────────┐
│ CE (Customer    │                          │ MSEE (Microsoft     │
│  Edge router)   │◄────── Partner Edge ─────►│  Enterprise Edge)   │
└──────────────────┘     (FAI ou Direct)      └──────────────────────┘
        │                                              │
        │                                              │
        ▼                                              ▼
┌──────────────────┐                          ┌──────────────────────┐
│ LAN on-prem      │      ExpressRoute        │ VNet Hub Azure       │
│ 10.1.0.0/16      │       Circuit            │ 10.10.0.0/16         │
│ 10.2.0.0/16      │                          │   ExpressRoute GW    │
└──────────────────┘                          │   dans GatewaySubnet │
                                              └──────────────────────┘
                                                       │
                                              Connection (lie ER GW à Circuit)

B.2 Composants

B.3 BGP est obligatoire

Contrairement à S2S VPN où BGP est optionnel, ExpressRoute exige BGP :

• ASN Microsoft (côté Azure) : 12076
• ASN customer (côté on-prem) : configurable (privé 64512-65534 ou public si tu as un AS)
• Les peering sessions BGP sont établies automatiquement entre CE et MSEE via le provider

C. Connectivity Models

C.1 Vue d'ensemble

C.2 ExpressRoute via Provider (Service Provider)

Modèle où la connexion passe par un carrier tiers ou un exchange provider. C'est le provider qui possède et opère l'infrastructure physique reliée au Microsoft Edge.

• Partner-managed : Equinix, Orange Business, AT&T, BT, NTT, Megaport, Coresite, etc.
• Le partner possède et opère l'infrastructure physique entre toi et MS edge
• Setup simplifié : tu lui donnes le Service Key du circuit, il configure
• Bandwidth : 50 Mbps à 10 Gbps
• Cas standard pour 80% des entreprises

C.3 ExpressRoute Direct

Connexion directe au réseau Microsoft via des ports dédiés, sans tiers : c'est l'entreprise qui gère et opère toute l'infrastructure dans ses propres datacenters (équipements, configuration des ports, BGP).

• Pas de partenaire : connexion directe de l'équipement à MSEE
• Ports dédiés : 10 Gbps ou 100 Gbps (400 Gbps en limited GA), toujours en paire de ports (active-active pour HA)
• Toute l'infrastructure est gérée en interne : routeurs, BGP, ports, configs
• Compliance-driven : gov, banking, où la souveraineté du trafic exige absence de tiers
• MACsec support (chiffrement L2 sur le port)
• Setup complexe : nécessite équipement physique en colocation près d'un MSEE site

MACsec

MACsec = chiffrement L2 (couche liaison) entre l'équipement client et MSEE. Différent d'IPsec qui chiffre L3. Cible les entreprises compliance-driven qui exigent le contrôle complet de l'infrastructure ou le chiffrement de bout en bout du lien physique.

• Use case : gov, banque, compliance qui exige que même le trafic sur circuit privé soit chiffré (la fibre optique pourrait être interceptée physiquement)
• Standard IEEE 802.1AE
• Disponible uniquement sur ExpressRoute Direct (pas via Provider)
• Configuration : une CAK (Connectivity Association Key) est stockée dans Azure Key Vault, MS configure le MSEE pour utiliser cette clé

D. Circuit SKUs

Trois SKU de circuit : Local, Standard, Premium.

D.1 Vue comparative

D.2 Détails par SKU

Local :

• Reach : 1 ou 2 régions dans/près de la même metro que la peering location (ex un circuit Marseille atteint France South)
• Coût : plus bas — egress data transfer inclus dans le port (idéal POC ou prod locale avec gros volumes)
• Pas de support multi-geo ni Global Reach

Standard :

• Reach : 1 geopolitical area (Europe, North America, Asia Pacific, etc.)
• Un circuit créé dans Europe peut atteindre West Europe, North Europe, France Central, etc.
• Pas Global Reach

Premium :

• Reach : mondial — un circuit créé en Europe peut atteindre East US, Southeast Asia, etc.
• Global Reach supporté
• Limites étendues : plus de routes BGP, plus de VNets connectables au circuit (jusqu'à 100 en Premium selon la bande passante, vs 10 en Standard/Local), présence globale
• Coût significativement plus élevé

D.3 Choix typique

• POC ou single-region : Local
• Prod régionale standard : Standard
• Multi-region global ou besoin de Global Reach : Premium

E. Billing Models

E.1 Quand choisir quoi ?

• Metered :
  • Usage bursty (gros pics ponctuels), trafic outbound modéré
  • Tu paies à la conso, prévisible si volume stable
  • Supporté Standard + Premium uniquement
• Unlimited :
  • Usage prévisible et continu (apps régulières en streaming, sync constants)
  • Au-delà d'un certain seuil (~10 TB/mois), rentable vs Metered
  • Supporté sur tous les SKU (Local, Standard, Premium)

E.2 Calcul de break-even

À volume élevé (> ~15 TB/mois outbound), Unlimited devient plus économique. Mais c'est très dépendant des prix négociés. À regarder avec ton commercial Azure.

F. Peering Types

ExpressRoute supporte 2 types de peering dans un circuit :

F.1 Private Peering (le plus courant)

• Accès privé aux VNets Azure (cas 90% des usages)
• ASN Microsoft : 12076
• Subnets BGP : /30 primary + /30 secondary (2 IPs chacun pour la liaison BGP)
• Routes propagées : tes CIDR on-prem ↔ tes CIDR de VNets Azure connectés

F.2 Microsoft Peering

• Accès privé aux services publics Microsoft : M365 (Exchange Online, SharePoint Online, Teams), Azure Public services (Storage, SQL Database public endpoint), Dynamics 365
• N'inclut PAS les VNets (c'est Private peering pour ça)
• Beaucoup d'entreprises n'activent PAS Microsoft peering (M365 est OK via internet régulier avec QoS bien configuré, ER est plus cher)
• Si activé : Route Filter obligatoire (sinon tu reçois 90 000 routes Microsoft, ton routeur explose)

Route Filter

Filtre les community values BGP pour ne récupérer que les services que tu veux :

• Exemple : "Exchange Online West Europe" seulement
• Évite de polluer ta table de routage avec tous les services Microsoft du monde
• Créé en Azure et lié au circuit

F.3 Azure Public Peering — Retiré

Anciennement un 3ème type pour les services publics Azure. Retiré, remplacé par Microsoft peering (qui inclut Azure public services).

G. BGP & ASNs

G.1 ASN clés

• Microsoft : 12076 (côté Azure pour ER, fixe)
• Customer : configurable, privé 64512-65534 ou public
• VPN Gateway BGP : 65515 (par défaut côté Azure, modifiable mais 8074-8076 sont réservés ER, à éviter)

G.2 BGP en ER

• BGP obligatoire (contrairement à VPN où c'est optionnel)
• Échange dynamique de routes entre CE (Customer Edge) et MSEE
• Route advertisement configurable (tu décides quels prefixes annoncer/recevoir)

H. ExpressRoute Gateway (côté Azure)

H.1 Caractéristiques

• VNet Gateway de type ExpressRoute (≠ VPN)
• Déployée dans GatewaySubnet (/27 min, recommandé /26 ou /25)
• 2 instances internes (HA managé par Azure)

H.2 SKUs

⚠️ La colonne VMs max = nombre de VMs supportées par la gateway (jusqu'à 11 000 sur les gros SKU). La colonne Routes apprises = nombre de routes BGP que la gateway accepte : 4 000 (Standard/ErGw1AZ) ou 9 500 (tous les SKU supérieurs). Ne pas confondre les deux (le 11 000 est un nombre de VMs, pas de routes).

🚨 Penser SKU AZ (ErGwXAZ) en prod 2026 : zone-redundant active-active par défaut.

H.3 Bottleneck multi-gateway

Le scénario : plusieurs VNets dans plusieurs régions, chacun avec sa propre ExpressRoute Gateway, tous connectés au même circuit.

Le problème : le circuit a une bandwidth fixe (ex 1 Gbps). Si chaque VNet GW peut tirer 1 Gbps mais que le circuit n'en supporte que 1 Gbps au total → le circuit est le bottleneck, pas les Gateways.

Solution :

• Augmenter la bandwidth du circuit (10 Gbps si plusieurs sites ER GW connectés)
• Ou utiliser des circuits séparés par region

I. ExpressRoute FastPath

I.1 Concept

FastPath = bypass de l'ExpressRoute Gateway pour le data plane → trafic on-prem → VNet direct via MSEE, sans passer par l'ER GW.

Pourquoi ? :

• L'ER GW (même UltraPerformance) est plafonnée à 10 Gbps
• Si tu as un circuit 100 Gbps et que ton trafic explose la GW → bottleneck
• FastPath bypass la GW → trafic atteint bande passante du circuit

I.2 Prérequis

• ExpressRoute Gateway SKU : ErGw3AZ, UltraPerformance, ou ErGwScale (avec ≥ 10 scale units)
• Le control plane (routes BGP) reste géré par l'ER GW. Seul le data plane bypasse.

I.3 FastPath limitations 2026

I.4 Use cases UDR + FastPath sur ExpressRoute Direct

Cas concret : une NVA firewall dans le hub (UDR 0.0.0.0/0 → Firewall NVA). On veut que le trafic on-prem → VNet passe par le firewall pour inspection.

Sans Direct + UDR sur FastPath : le trafic bypasse la GW mais aussi le firewall (pas top pour la compliance).

Avec ExpressRoute Direct + UDR sur GatewaySubnet : FastPath respecte les UDR. Donc trafic on-prem → MSEE → UDR check → routé vers firewall NVA → puis VNet de destination.

→ Inspection préservée + performance FastPath. Combo prod compliance + perf.

I.5 Private Link + FastPath (ER Direct uniquement)

FastPath avec Peered networks ou Private Link requiert ExpressRoute Direct.

Scénario : des serveurs on-prem doivent atteindre un Private Endpoint Azure (ex Storage en PE). Sans FastPath, le trafic passe par ER GW puis vers le PE → throughput limité par ER GW.

Avec FastPath + ER Direct : trafic on-prem → MSEE → directement vers PE → débit max du circuit.

→ Use case : analytics data exports massifs depuis on-prem vers Storage Azure en PE, plusieurs centaines de Mbps de throughput soutenu.

J. ExpressRoute Global Reach

Cas type : un site on-prem en France relié par ExpressRoute à Azure France, un site on-prem aux US relié par ExpressRoute à Azure US, et le besoin d'interconnecter les deux sites on-prem en transitant par le réseau Microsoft.

J.1 Concept

Global Reach = utilise le backbone Microsoft pour interconnecter 2 sites on-prem via leurs circuits ExpressRoute respectifs.

Sans Global Reach : 2 sites on-prem connectés à Azure via ER ne se "voient" pas entre eux (ER n'est pas transitif par défaut).

Avec Global Reach :

• 2 circuits ER liés via Global Reach
• Trafic on-prem A → MSEE A → backbone MS → MSEE B → on-prem B
• N'utilise pas les VNets Azure (transit direct par backbone MS)

J.2 Architecture

SITE A (Paris)                                   SITE B (New York)
  ┌──────────────┐                                 ┌──────────────┐
  │ Datacenter   │                                 │ Datacenter   │
  │ 10.1.0.0/16  │                                 │ 10.2.0.0/16  │
  └──────┬───────┘                                 └──────┬───────┘
         │                                                │
         ▼                                                ▼
  ┌──────────────┐    Microsoft backbone     ┌──────────────┐
  │ ER Circuit A │◄────── Global Reach ─────►│ ER Circuit B │
  │  (Paris)     │                            │  (New York)  │
  └──────────────┘                            └──────────────┘
         │                                                │
         ▼                                                ▼
  ┌──────────────┐                            ┌──────────────┐
  │ Azure WEU    │                            │ Azure EUS    │
  └──────────────┘                            └──────────────┘

J.3 Prérequis

• Premium SKU pour les circuits Global Reach cross-geopolitical area (ex Europe ↔ US). Standard suffit dans la même geo (ex 2 sites européens).
• Global Reach /29 subnet : range IP utilisé pour la liaison BGP entre les 2 circuits
• Configurable entre 2 circuits de la même sub ou de subs différentes via Authorization Key (voir section M)
• Microsoft peering n'est pas requis (Private peering suffit)

J.4 Cas d'usage

• DC-to-DC entre filiales géographiques (Paris ↔ NY) sans monter de tunnel VPN ou tirer du fibre optique privée
• Backbone Microsoft = SLA + latence + sécurité (privé, jamais internet)
• Alternative à un opérateur global propriétaire (énorme économie potentielle)

K. ExpressRoute High Availability

K.1 3 niveaux de résilience

K.2 Standard Resiliency (par défaut)

• Chaque circuit ER inclut 2 liens physiques vers 1 MSEE par défaut
• Active-active par défaut, supporte le load balancing
• SPOF : une seule région, donc si le site MSEE tombe (catastrophe locale, fibre coupée), tout est perdu
• 99.95% SLA Microsoft

K.3 High Resiliency — ExpressRoute Metro

Les 2 liens restent présents mais sont répartis sur 2 emplacements distincts au sein d'une même metro location (ex Singapore 1 et Singapore 2).

• 2 liens séparés géographiquement dans 2 sites différents au sein de la même metro area
• Exemple : Singapore 1 (Equinix SG1) + Singapore 2 (Equinix SG2) — 2 datacenters différents, même zone géographique
• Résiste à un outage local (incendie, coupure fibre dans 1 DC)
• Pas supporté partout : seulement quelques metro areas (vérifier la doc MS)
• Pratique : 1 seul circuit ER mais avec dual entry points résiliente

K.4 Maximum Resiliency — Full Redundancy

HA via régions séparées : 2 circuits ExpressRoute, chacun avec dual links et providers redondants.

• 2 circuits distincts dans 2 régions différentes (ex Paris + Marseille, ou Paris + Amsterdam)
• Idéalement avec 2 providers différents (Equinix + Orange) pour résilience opérateur
• BGP avec failover automatique
• Compliance gov / banking de très haute criticité
• Coût élevé : 2× tout (circuits + GW + bandwidth payée)

K.5 ExpressRoute Gateway HA — Zone Redundant

Les anciens SKU de Gateway ne supportaient pas la zone-redundancy. Les SKU modernes (ErGwXAZ) sont zone-redundant.

• Les SKU AZ (ErGw1AZ, ErGw2AZ, ErGw3AZ) sont déployés sur plusieurs AZ de la région
• Active-active par défaut, utilise BGP en arrière pour le dynamic routing
• Une AZ qui tombe → l'autre instance continue, transparente pour le trafic
• En réalité : les instances gérées par Azure sont réparties sur au moins 3 zones de disponibilité (3 AZ), pas seulement 2

L. S2S VPN as ExpressRoute Backup

Principe : déployer une ExpressRoute Gateway et, en parallèle, une VPN Gateway avec BGP activé. Un GatewaySubnet en /25 est recommandé pour héberger les 2 gateways.

L.1 Pattern

• ER GW primary + VPN GW backup, dans le même VNet
• GatewaySubnet /25 recommandé (cohabitation 2 GWs + scale future)
• BGP activé sur les 2 → failover automatique BGP
• BGP weight ou AS Path prepending : préférer ER over VPN

L.2 Configuration

1. Créer ER Gateway dans GatewaySubnet du VNet
2. Créer VPN Gateway dans le même GatewaySubnet (/25 minimum)
3. Connecter ER GW au circuit ER
4. Configurer VPN avec BGP enabled
5. Sur le routeur on-prem : annoncer les mêmes prefixes via les 2 chemins, avec préférence ER

L.3 BFD — Bidirectional Forwarding Detection

BFD s'active sur les équipements et permet un failover entre liens en quelques secondes au lieu d'attendre l'expiration des timers BGP.

Sans BFD :

• BGP détecte une panne avec son keepalive par défaut (180 sec) → failover en 3 min
• Trop long pour une prod critique

Avec BFD :

• Protocole light qui envoie des probes très fréquents (ms) entre routeurs
• Détection de panne en 300 ms - quelques secondes
• Trigger immédiat du BGP recovery

Configuration :

• Côté Azure : activé par défaut sur ER Gateway et VPN GW BGP-enabled
• Côté on-prem : à activer sur le routeur (Cisco, Juniper, etc.)
• Compatible avec ER private peering et S2S VPN BGP

L.4 Site-to-Site VPN OVER ExpressRoute ≠ S2S VPN backup

Ne pas confondre la coexistence S2S VPN + ExpressRoute (backup) avec le Site-to-Site VPN OVER ExpressRoute (chiffrement par-dessus le circuit) :

• VPN as ER backup = 2 chemins parallèles indépendants. Si ER tombe, VPN prend.
• VPN over ER (ER avec encryption) = on chiffre le trafic ER avec une couche IPsec supplémentaire par-dessus le circuit privé. Use case compliance qui exige chiffrement même sur backbone privé.

Et c'est différent de MACsec (chiffrement L2 sur le port physique en ER Direct, voir §C.3).

3 niveaux de chiffrement possibles :

1. MACsec : chiffrement L2 sur le port (ER Direct uniquement)
2. IPsec sur ER : tunnel VPN par-dessus ER (compliance "tout chiffré")
3. Application-level TLS : end-to-end TLS pour les apps

M. Authorization Key & Cross-Subscription Sharing

Les Authorization Keys et leur mécanisme de redeem permettent de connecter au circuit des VNets répartis sur plusieurs subscriptions.

M.1 Le problème

Un circuit ER coûte cher. Quand une entreprise a plusieurs subscriptions (par BU, par équipe), chaque sub a besoin de connecter ses VNets au circuit ER.

Sans authorization : seul le propriétaire de la sub où le circuit a été créé peut y connecter ses VNets.

M.2 Solution : Authorization Keys

Concepts :

• Circuit Owner : l'utilisateur (ou sub) qui détient le circuit ER
• Circuit User : utilisateur d'une autre sub qui veut connecter son VNet (via sa propre ER Gateway) au circuit

Process :

1. Circuit Owner génère une Authorization dans le circuit
   • ExpressRoute circuit > Authorizations > + Add
   • Nom : auth-for-sub-bu-finance (descriptif)
   • Azure génère une clé unique (UUID) + un Peer circuit URI (resource ID du circuit)
2. Circuit Owner partage la clé + URI au Circuit User (par email, ticket, etc.)
3. Circuit User dans sa propre sub :
   • Crée une VNet Gateway type ExpressRoute dans son VNet
   • Crée une Connection type ExpressRoute, choisit "Redeem authorization"
   • Colle la clé + URI fournis par l'owner
   • Connexion établie → son VNet est maintenant connecté au circuit cross-sub

M.3 Capacités du Circuit Owner

• Génère des authorizations (1 par VNet user max)
• Modifie ou révoque une authorization à tout moment
• Révocation = la connexion VNet du Circuit User est immédiatement supprimée (l'user perd l'accès au circuit)

M.4 Limites

• 1 authorization par VNet user (1 VNet = 1 auth = 1 connection)
• Si tu veux connecter plusieurs VNets de la même sub user → plusieurs authorizations générées
• Au-delà de 10 VNets connectés au circuit (limite Standard/Local) → upgrade SKU vers Premium (jusqu'à 100 VNets selon la bande passante)
• Compatible cross-tenant (entre 2 tenants Entra différents) avec quelques limitations portail

M.5 Use case typique

Holding multi-BU :

• Sub Network central : owner du circuit ER (gestion réseau central)
• Subs des BU (Finance, RH, Marketing, Industrial) : chaque BU a sa propre sub avec ses VNets
• Le NetOps central génère 1 authorization par VNet des BU
• Chaque BU consomme sa clé pour connecter ses VNets au circuit partagé
• Coût du circuit ER mutualisé, gouvernance par BU préservée

N. ExpressRoute Configuration

ExpressRoute est difficile à configurer sans un environnement on-prem et un partenaire pour s'entraîner. L'objectif ici est de comprendre à quoi ressemble le processus, pas de le pratiquer en lab.

N.1 Process Configure Private Peering (le plus courant)

1. Deploy ExpressRoute Circuit :

   • Home > ExpressRoute circuits > + Create
   • Name, RG, Region
   • Port type : Provider (le plus courant) OU Direct
   • Provider : sélectionner ton FAI (Equinix, Orange, etc.)
   • Peering location : ex Paris (lieu physique du peering)
   • Bandwidth : 1 Gbps (ou autre selon besoin)
   • SKU : Local, Standard, ou Premium
   • Billing model : Metered ou Unlimited
   • Create → Azure provisionne le circuit côté backbone (status : "Not provisioned")

2. Provision Circuit avec Provider :

   • Récupérer le Service Key du circuit (UUID)
   • Appeler le provider (ticket, email, portail self-service selon ton contrat) en fournissant le Service Key
   • Le provider configure leur côté → circuit passe en "Provisioned" côté Azure quand c'est OK

3. Configurer Private Peering :

   • Circuit > Peerings > Azure private peering > Configure
   • Peer ASN : ton ASN customer (ex 65001 — privé)
   • Primary subnet : /30 (ex 192.168.100.0/30) — IPs pour la session BGP primary entre CE et MSEE
   • Secondary subnet : /30 (ex 192.168.100.4/30) — IPs pour la session BGP secondary (HA)
   • VLAN ID : tag VLAN négocié avec le provider
   • MD5 hash (optionnel) : authentification BGP

   À propos des champs Peer ASN, subnet, primary/secondary :

   • Les /30 sont des tiny subnets de transit pour la liaison BGP entre le routeur CE et le MSEE Azure
   • 4 IPs par /30 : 1 pour CE, 1 pour MSEE, 2 réservées (network + broadcast)
   • 2 subnets = primary + secondary pour HA (2 sessions BGP parallèles)

4. Deploy ExpressRoute Gateway dans le VNet hub :

   • Virtual network gateways > + Create > Gateway type: ExpressRoute
   • SKU : ErGw2AZ ou ErGw3AZ selon bandwidth
   • GatewaySubnet (/27 min)
   • Public IP Standard (zone-redundant)

5. Créer la Connection entre VNet Gateway et Circuit :

   • ExpressRoute Gateway > Connections > + Add
   • Connection type : ExpressRoute
   • Sélectionner le circuit ER
   • Authorization : (vide si même sub que le circuit, sinon coller la clé)

6. Ajouter d'autres VNets :

   • Pour chaque autre VNet : créer une ER Gateway dans son VNet + Connection vers le même circuit
   • Si cross-sub : passer par Authorization Key (voir §M)

N.2 Process Configure Microsoft Peering

1. Deploy Circuit : idem ci-dessus
2. Provision Circuit with Provider : idem
3. Configure Microsoft Peering :
   • Circuit > Peerings > Microsoft peering > Configure
   • Peer ASN customer
   • Primary/Secondary /30 subnets (différents de ceux du Private peering)
   • Advertised public prefixes : tes plages d'IPs publiques (Azure vérifiera que tu en es bien propriétaire via le RIR ROA)
   • Customer ASN + Routing registry name (RIR : RIPE, ARIN, etc.)
4. Configurer un Route Filter (même région) :
   • Route filter > + Create
   • Service community values : sélectionner les services M365 / Azure Public à recevoir (ex "Exchange Online")
   • Lier le Route Filter au circuit
5. (Optionnel) Approval M365 :
   • Pour activer Exchange Online via ER : faire la demande à MS avec le Tenant ID Entra
   • MS valide selon la politique Office Express Route (réservé aux gros clients en général)

N.3 Pourquoi le RIR ROA (Route Origin Authorization) ?

Microsoft vérifie que tu es bien propriétaire des préfixes IP publiques que tu annonces (sinon n'importe qui pourrait "voler" des préfixes Microsoft). Le ROA dans ton RIR (RIPE pour Europe, ARIN US, etc.) est la preuve cryptographique de propriété.

O. Diagnose & resolve ExpressRoute connection issues

Un circuit ER met en jeu 2 couches d'état (provider / Microsoft) puis 2 couches de protocole (L2 ARP, L3 BGP). Diagnostiquer = remonter cette pile dans l'ordre : circuit provisionné ? → ARP up ? → BGP up ? → routes apprises ? → débit/connectivité.

O.1 États du circuit & du peering

Deux champs d'état distincts à lire (portail Overview ou Get-AzExpressRouteCircuit) :

🚨 Provider status bloqué sur Not provisioned → c'est le provider qu'il faut appeler (donne-lui le Service Key), pas Microsoft. Circuit status bloqué sur Not enabled → ticket Microsoft Support. Tant que le provider n'est pas Provisioned, le peering ne se configure pas.

Au niveau peering, surveiller aussi l'état BGP : si le peering reste vide après config provider (modèle L3 managé), faire Refresh sur le circuit (tire la conf de routage à jour). Pour Microsoft peering, l'état des advertised public prefixes doit être Configured (si Validation needed → la session BGP n'est pas active ; si Manual validation → ticket support avec preuve de propriété IP/ASN).

O.2 Vérifier les peerings (L2 puis L3)

💡 Logique de tri : ARP table vide → problème L2 (VLAN ID, câblage provider). ARP OK mais BGP en Active/Idle → problème L3 : vérifier que VlanId, AzureASN, PeerASN et le subnet /30 matchent côté CE, et que la clé MD5 (si activée) est identique des 2 côtés.

O.3 Circuit metrics (Azure Monitor)

Métriques Microsoft.Network/expressRouteCircuits clés (portail : ER circuit > Metrics / Insights) :

⚠️ Pendant une maintenance MS edge ↔ core, BgpAvailability peut afficher down alors que la session CE↔MSEE est up. Activer les maintenance alerts. Sur ER Direct, surveiller en plus LineProtocol et AdminState (état du port). Alertes minimales recommandées : ARP availability, BGP availability, Line Protocol.

O.4 Connection Monitor & Network Watcher (bout-en-bout)

• Connection Monitor (Network Watcher) = connectivité on-prem ↔ Azure de bout en bout (loss, latency, RTT) au-dessus de l'ER. Découvre automatiquement les circuits/peerings du chemin. Prérequis : Log Analytics agent sur les serveurs on-prem + Network Watcher agent sur les VMs Azure (private peering) ou endpoints externes (Microsoft peering) ; test TCP/ICMP. Donne une topologie hop-by-hop jusqu'au MS edge.
• Network Watcher / Diagnose and solve problems côté circuit : ER circuit > Diagnose and solve problems > Performance Issues → diagnostics de la gateway (maintenance récente, throughput) ; recommande un upgrade de SKU gateway si le débit sature.

O.5 Pièges classiques

• Route filter manquant sur Microsoft peering : depuis août 2017, aucun préfixe n'est annoncé tant qu'un route filter n'est pas attaché → "Microsoft peering up mais rien ne passe".
• MTU : l'ER est fixé à 1500 (Ethernet standard) ; contrairement au VPN, pas besoin de clamp TCP MSS. Ne pas forcer une MTU exotique.
• MD5 hash BGP : clé partagée différente entre MSEE et CE → la session BGP ne monte pas (la clé n'est jamais réaffichée côté Azure).
• Circuit pas provisionné côté provider (Not provisioned) : tout le reste est inutile tant que ce n'est pas réglé avec l'opérateur.
• Dépassement de la limite de préfixes : 4 000 routes en private peering (10 000 en Premium), 200 en Microsoft peering → au-delà, la session BGP tombe et se rétablit seule sous la limite.
• Mismatch VlanId / PeerASN / subnet /30 entre Azure et le CE : peering qui ne s'active pas. BGP terminé sur firewall stateful : casse le failover pendant les maintenances → terminer le BGP sur équipement stateless.

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : Banque retail — ExpressRoute primary + VPN backup, multi-region

Contexte business : banque française, infra critique. Le trafic core banking passe par ER vers Azure (analytics, BI, reporting réglementaire). Le SLA ACPR impose 99,99% de dispo. Pas de tunnel internet pour des données financières. Choix architectural : 2 circuits ExpressRoute Premium (Paris + Marseille, opérateurs différents) en Maximum Resiliency + VPN S2S de secours + BGP + BFD + Global Reach pour relier les datacenters. Architecture / pattern :

• 2 circuits ER Premium :
  • er-paris (Orange, 10 Gbps, Unlimited, France Central).
  • er-marseille (Equinix, 10 Gbps, Unlimited, France South).
• ExpressRoute Gateway ErGw3AZ dans le VNet hub (Active-Active, zone-redundant).
• VPN GW VpnGw3AZ dans le même GatewaySubnet /25, en secours.
• BGP partout avec BFD : bascule en moins d'une seconde.
• Global Reach entre er-paris et le circuit ER du datacenter partenaire à Londres (cabinet d'audit) : le flux d'audit passe par le backbone Microsoft.
• FastPath activé sur les 2 ER GW (SKU compatible) pour le débit maximum. Trade-offs assumés :
• Gain : 99,99% de dispo, bascule sub-seconde (BFD), trafic privé conforme ACPR.
• Perte : coût élevé (2 circuits Premium + VPN backup), architecture multi-région complexe à exploiter. Pièges à éviter :
• SKU Standard au lieu de Premium pour un Global Reach inter-géographie (Paris ↔ Londres = Europe ↔ UK désormais) : ça ne marche pas.
• Un seul circuit ER = point unique de panne. 2 circuits actifs/actifs minimum pour viser 99,99%.
• GatewaySubnet /27 : trop petit pour ER GW + VPN GW + croissance future.
• BFD non configuré côté on-prem : la bascule prend 3 minutes au lieu de 3 secondes.
• Microsoft peering activé pour M365 sans en avoir besoin : déluge de routes BGP et coût en hausse. Rester sur le Private peering.

📐 Réf. CAF/WAF — Connectivity to Azure (hybrid, ExpressRoute + VPN backup) : CAF recommande ExpressRoute comme canal primaire avec VPN S2S en backup et des circuits double peering location pour éliminer le SPOF. Lien

Scenario 2 : Holding multi-BU — circuit ER mutualisé cross-sub

Contexte business : holding industrielle, 6 BU avec chacune sa souscription Azure. L'équipe réseau centrale (NetOps) possède le circuit ER dans la sub Network. Chaque BU a ses VNets dans sa sub. But : mutualiser le coût de l'ER. Choix architectural : 1 circuit ER Standard (5 Gbps, Unlimited) tenu par NetOps + des Authorization Keys distribuées aux BU + 1 ER Gateway par BU dans sa sub. Architecture / pattern :

• Sub Network : propriétaire du circuit er-corp (Standard, 5 Gbps, peering location Paris).
• 6 subs BU (Finance, RH, IT, Industrial, Sales, Marketing).
• Pour chaque VNet à brancher, NetOps génère une Authorization Key dédiée :
  • auth-bu-finance-vnet-prod
  • auth-bu-finance-vnet-dev
  • ... (12-15 clés au total).
• Chaque BU :
  • Crée sa propre ER Gateway dans son VNet (sa sub, SKU ErGw2AZ).
  • Crée une Connection en mode « Redeem authorization » et colle la clé.
  • Son VNet est connecté au circuit ER partagé.
• Nouveau VNet : ticket à NetOps, qui génère la clé et l'envoie ; la BU la « redeem ».
• Départ : NetOps révoque l'autorisation dans le portail, la connexion disparaît aussitôt. Trade-offs assumés :
• Gain : coût ER mutualisé entre BU, gouvernance propre via Authorization Keys (séparation des subs).
• Perte : circuit partagé = goulot de bande passante potentiel, dépendance à NetOps pour tout branchement. Pièges à éviter :
• Donner les accès de la sub Network aux BU pour qu'elles se branchent seules : désastre de gouvernance. Les Authorization Keys donnent la bonne séparation.
• Oublier qu'1 clé = 1 VNet. Si Finance a 3 VNets, il faut 3 autorisations distinctes.
• Circuit à 5 Gbps mais somme des ER GW à 15 Gbps (3 BU × ErGw3AZ 10 Gbps) : le circuit devient le goulot. Passer le circuit à 10 Gbps.
• Clé d'autorisation partagée en clair sur Slack : une BU la file à un partenaire, accès non autorisé. Passer par Key Vault ou un ticket sécurisé.

📐 Réf. CAF/WAF — Network topology and connectivity (landing zone, connectivity subscription) : CAF préconise de centraliser le circuit ER dans une connectivity subscription dédiée et de le partager aux landing zones via le hub, alignant mutualisation du coût et gouvernance par BU. Lien

Scenario 3 : Gov / défense — ER Direct + MACsec + No Microsoft Peering

Contexte business : agence gouvernementale, classification Diffusion Restreinte. Aucun opérateur tiers ne doit pouvoir accéder au flux. Pas besoin de M365 via ER (M365 passe par internet, séparément). Choix architectural : ExpressRoute Direct (ports 100 Gbps en colocation gov) + MACsec activé + Private peering seulement (pas de Microsoft peering) + SKU Premium. Architecture / pattern :

• ExpressRoute Direct avec 2 ports 100 Gbps dans 2 metros différentes (Maximum Resiliency).
• MACsec activé sur les 4 ports (clé CAK dans un Key Vault dédié).
• Microsoft peering DÉSACTIVÉ : aucun trafic M365 / Azure public via l'ER.
• Private peering vers les VNets internes uniquement.
• ExpressRoute Gateway ErGw3AZ + FastPath pour le débit massif (analytics classifiée).
• UDR sur le GatewaySubnet : le trafic on-prem entrant passe d'abord par un firewall NVA homologué gov avant d'atteindre les VNets.
• Logs de diagnostic envoyés au SOC central. Trade-offs assumés :
• Gain : aucun opérateur tiers sur le flux, chiffrement L2 MACsec, FastPath + inspection NVA compatibles.
• Perte : ER Direct très coûteux (ports 100 Gbps dédiés), colocation gov et gestion des clés CAK à assurer. Pièges à éviter :
• ER via un opérateur : un tiers voit le trafic, refusé par la compliance gov. ER Direct obligatoire.
• MACsec non activé : flux en clair sur la fibre, interception physique possible. MACsec = défense en profondeur.
• Microsoft peering activé « au cas où » : routes BGP M365 exposées inutilement, surface d'attaque pour rien.
• FastPath court-circuite les UDR, donc pas d'inspection par le firewall (la compliance gov l'exige) : ER Direct permet d'avoir FastPath et UDR ensemble.

📐 Réf. CAF/WAF — WAF Security for ExpressRoute (encryption MACsec/IPsec, RBAC) : le pilier Security recommande MACsec sur ER Direct (chiffrement L2 link-layer) + RBAC + MD5 hash BGP, ce qui correspond au modèle gov "chaîne tierce zéro, flux chiffré". Lien

DEMO — chemins portail (vue config)

Setup ER nécessite un vrai circuit avec provider. Au AZ-700, c'est awareness de la procédure (pas hands-on en lab).

1. DEMO — Vue création du circuit (portail)

Home > ExpressRoute circuits > + Create

• Basics :
  • RG : rg-network
  • Name : er-paris
  • Region : France Central
• Configuration :
  • Port type : Provider
  • Provider : Orange Business
  • Peering location : Paris
  • Bandwidth : 1 Gbps
  • SKU : Standard
  • Billing model : Metered
• Review + create

→ Récupérer le Service Key dans Overview après création.

2. DEMO — Configurer Private Peering (portail)

Circuit > Peerings > Azure private peering > Configure

• Peer ASN : 65001
• Primary subnet : 192.168.100.0/30
• Secondary subnet : 192.168.100.4/30
• VLAN ID : 100
• Save

3. DEMO — Créer ER Gateway et Connection

Virtual network gateways > + Create

• Gateway type : ExpressRoute
• SKU : ErGw2AZ
• VNet : vnet-hub
• Public IP : pip-ergw (Standard, Zone-redundant)

Après création (30-45 min) :

ER Gateway > Connections > + Add

• Type : ExpressRoute
• Virtual network gateway : ergw-hub
• ExpressRoute circuit : er-paris
• Save

4. DEMO — Générer Authorization Key (cross-sub)

ExpressRoute circuit > Authorizations > + Add

• Name : auth-for-bu-finance
• Save

→ Récupérer Authorization Key + Peer circuit URI (resource ID) → envoyer au team BU Finance.

Coté BU Finance : dans leur sub, créer une Connection ExpressRoute avec ces 2 valeurs (cocher "Redeem authorization").

5. DEMO — Activer Global Reach (entre 2 circuits)

Prérequis : 2 circuits ER (peuvent être dans 2 subs différentes via Authorization Key + 2 régions cross-geo en SKU Premium).

ExpressRoute circuit A > Global Reach > + Add Global Reach connection

• Name : gr-paris-to-newyork
• Peer circuit : sélectionner Circuit B (ou coller son resource ID si cross-sub)
• Global Reach subnet /29 : ex 10.255.255.0/29
• (Si cross-sub) Authorization Key du circuit B
• Save

→ Trafic on-prem A peut maintenant atteindre on-prem B via backbone Microsoft.

6. DEMO — Activer FastPath

ExpressRoute Gateway > Configuration > FastPath > Enabled

• Prérequis : SKU ErGw3AZ ou UltraPerformance ou ErGwScale ≥ 10 SU
• Save → trafic on-prem ↔ VMs du VNet bypasse maintenant la GW