ExpressRoute Resiliencyを理解するための前提
1 ExpressRoute circuit自体はMicrosoft edgeへの冗長connectionを持つが、単一peering location/provider/customer edgeに残るfailure domainを消さない。 Microsoftはmaximum resiliencyとして異なるpeering locationsの2 ExpressRoute circuitsへの接続を推奨する。
Metro等のHigh resiliencyは同metro内の複数physical peering locationを使い、Standardのsingle location redundancyよりlocation障害耐性を高める。 Azure側ではzone-redundant ExpressRoute gatewayや複数VNet connectionも別failure domain。circuit二重化だけでgateway single pointを見落とさない。
S2S VPNをbackupに使う場合はBGP/route preferenceとfailover/failback時のstateful asymmetryを事前に試験する。 DR circuitを「standbyなので使わない」と放置せず、定期的にroute/trafficを流してprovider/CE/config driftを検出する。
Control plane と data plane
Provider / responsibility boundary
ExpressRoute circuit、peering、MSEE側BGP、VNet gateway / FastPath、Azure route propagationを管理する。
customer edgeからMicrosoft edgeまでのL2/L3 service、cross-connect、VLAN等を担当する。provider provisioningはAzure resource stateと別に追う。
CE routerのBGP policy、local preference / AS path、prefix filter、冗長回線を管理する。片系だけ正常でもend-to-end冗長性は成立しない。
仕組み
failure domainをCE chassis、last mile、provider POP、peering location、MSEE pair、ExpressRoute circuit、Azure gateway/zone、Azure regionに分解する。
Maximum resiliencyは物理的に異なるpeering locationsへcircuitsを分け、customer側も共通duct/colo/routerを避ける。
High/Metro topologyを使う場合でもcustomer siteから両physical peering locationまでのdiversityをproviderへ確認する。
DR path preferenceはAzure-boundとon-prem-boundを両方設計する。片方向だけAS path prependしてもreturnが別circuitになる場合がある。
Resiliency Guard等preview評価機能は補助として使い、実failover testの代替にしない。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- normal stateで全primary/secondary BGP sessionと全critical routeが期待通り存在する。
- 1 linkを計画停止し、同circuit secondary pathへの収束とpacket lossを記録する。
- 1 circuit/locationを停止し、second circuitまたはVPN backupへbest routeが移ることを確認する。
- Azure側NIC effective routes、CE FIB、stateful FW session pathを同時に確認する。
- application transactionを継続監視し、BGP convergenceとuser-visible interruptionを対応付ける。
- 復旧後のfailbackでroute oscillation/asymmetryが発生しないことを確認する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Path inventory | 各prefixについてnormal/1-link-down/1-circuit-down/1-location-down時のexpected pathを表にする。 |
| Advertisement symmetry | 両circuitsから同一prefixを広告するか、意図したmore-specific/AS path policyを明文化する。 |
| Azure selection | connection weight/route selection/effective routeでAzure→on-premのpreferred pathを確認する。 |
| On-prem selection | local preference/AS path/IGPでon-prem→Azureのpreferred pathを確認し、stateful FWを跨ぐ場合はsymmetryを合わせる。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Class | criticalityに応じMaximum / High / Standardを明示選択する。 | 単一circuitの二重linkを「DR済み」と呼ばないため。 |
| Provider diversity | logical circuitsだけでなくfiber/POP/CE/coloの物理diversityを確認する。 | 共通障害点はAzure resource diagramに現れない。 |
| Backup VPN | RTOとbandwidthが許す場合にthird pathとして設計し定期試験する。 | 緊急時だけ初接続するbackupは設定driftで失敗しやすい。 |
| Test cadence | maintenance/failure injectionを定期化し、route・loss・applicationを記録する。 | 構成レビューだけでは実convergenceを証明できない。 |
確認手順
Azure Portal / provider / edge
- 全circuitsでProvider/Circuit status、primary/secondary BGP、route countを一覧化する。
- peering locations/provider/customer edgeの物理topologyをnetwork diagramへ記載する。
- ExpressRoute gateways/connectionsのzone/SKU/stateとspoke effective routesを確認する。
- planned failoverでlink/circuit単位に停止し、CE/Azure routeとapplication SLIを同時収集する。
Verification discipline
- subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
- control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
- advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
- 変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。
az network express-route list -g <rg> -o table
az network express-route peering list -g <rg> --circuit-name <circuit> -o table
az network vnet-gateway show -g <rg> -n <er-gateway> -o jsonc
az network nic show-effective-route-table -g <rg> -n <nic> -o tableGet-AzExpressRouteCircuit -ResourceGroupName <rg>
Get-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <er-gateway>
Get-AzEffectiveRouteTable -NetworkInterfaceName <nic> -ResourceGroupName <rg>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 冗長構成なのに全断 | 共通provider/colo/CE/gateway failure | physical topology + multi-layer logs | logical circuit数ではなく共通failure domainを探す |
| failover後一方向だけ失敗 | 双方向route preference不一致 | CE/Azure best path + FW session | asymmetric routingを確認する |
| standby circuitが本番時だけ失敗 | 長期未試験、config drift/provider issue | standby BGP/traffic history | 定期active testを導入する |
| failbackでflap | policy/timer差、route oscillation | BGP updates + application timeline | 復旧順序とpreferenceをrunbook化する |
変更時の確認と rollback
- resiliency change前に全pathのroute tables、BGP states、application baselineを保存する。
- second path追加はまずnon-preferredでroute visibilityを検証し、traffic cutoverを別stepにする。
- rollback時は追加routeをwithdrawし、元pathがboth-direction bestへ戻ったことを確認する。
- DR topology撤去はfailure toleranceを下げる変更としてrisk acceptanceを明示する。
What changed recently
2026年のExpressRoute guidanceはMaximum / High / Standard resiliencyを明確に区別し、複数physical peering locationを重視しています。Resiliency Guardのguided modelはpreviewとして扱い、実failover testを置き換えません。