【Azure】VNet AとVNet Bの両方にGatewayを置くと何が起きる？BGP伝搬と非対称ルーティングの罠
Azureでネットワーク設計を行っていると、以下のような要件に出くわすことがあります。
「VNet A と VNet B をピアリングしつつ、両方の VNet に Gateway（ExpressRoute / VPN）を配置して、同じオンプレミスに接続して冗長化したい」
一見すると障害に強い理想的なマルチアクティブ構成に見えますが、実際の案件でこれをやると「通信が通らない」「片方のVNetだけ不安定」といったトラブルに直面しがちです。
現場ではよく「BGPの伝搬ができなくなるらしい」と一言で片付けられがちですが、正確にはAzureがBGPを伝搬できないわけではありません。
本記事では、この構成で発生する問題のメカニズム（Gateway Transitの制約、BGP Best Path、非対称ルーティング、AS Path Loop）を分かりやすく解説します。
1. 想定するネットワーク構成
まず、問題となる構成イメージです。
On-Premises
|
ExpressRoute / VPN
|
+---------------+---------------+
| |
VNet A ------------------------ VNet B
ER/VPN GW ER/VPN GW
\________ Peering ________/
- VNet A と VNet B は VNet Peering 接続
- 両方の VNet に Gateway を配置
- 同じオンプレミスネットワークと BGP で接続
一見するときれいな構成ですが、裏では複数の技術的制約が絡み合っています。
2. なぜ問題が起きるのか？5つのリスク
リスク①：Gateway Transit が利用できない（Azureの仕様制約）
Azure VNet Peeringには「1つのVNetは自身のGatewayを使うか、ピアリング先のGateway（Use Remote Gateway）を使うかの二者択一」という厳格なルールがあります。
VNet A ── [ ExpressRoute Gateway ]
VNet B ── [ ExpressRoute Gateway ]
← この状態でVNETA,VNETBどちらでも「Use Remote Gateway = ON」は不可！
「自分のVNetにGatewayが配置されている状態」では、どのVNetであっても Use Remote Gateway は選択できない（エラーになる）。
結果:
VNet A は Gateway A を使い、VNet B は Gateway B を使うしかありません。
「Gateway A が死んだら自動的に Gateway B をピアリング越しに使う」といったGatewayの相互バックアップ（Transit）は設定できないことになります。
リスク②：オンプレ側で「同じ経路」を複数広報・学習する
次にBGPの動作です。
- VNet Aのアドレス空間：
10.10.0.0/16 - VNet Bのアドレス空間：
10.20.0.0/16
VNet Peeringが組まれると、Gateway A・Gateway Bは共に相手のVNetアドレスを認識します。その結果、両方のGatewayがオンプレミスに対して同じプレフィックスを広報し始めます。
オンプレミスルータから見ると、以下のように複数ルートが見える状態になります。
[ 10.10.0.0/16 への経路 ]
- Path 1: OnPrem ── Gateway A ── VNet A
- Path 2: OnPrem ── Gateway B ── Peering ── VNet A
リスク③：BGP Best Path により想定外の Gateway が選ばれる
BGPは複数経路を受信すると、以下のアルゴリズムに従って自動的に1つのベストパス（最良経路）を選び出します。
- Weight
- Local Preference
- AS Path
- MED ...
この結果、設計者が意図していた「OnPrem ➔ Gateway A ➔ VNet A」ではなく、BGPの計算結果によって「OnPrem ➔ Gateway B ➔ Peering ➔ VNet A」がベストパスに選ばれてしまうケースが発生します。
💡 ポイント
これは障害でもバグでもなく、**BGPの正常な仕様（経路選択動作）**です。
リスク④：非対称ルーティングによる通信遮断（最重要）
実案件で最も致命的になるのがこの非対称ルーティング（Asymmetric Routing）です。
【往路（行き）】 OnPrem ──➔ Gateway A ──➔ VNet A
【復路（帰り）】 VNet A ──➔ Peering ──➔ Gateway B ──➔ OnPrem
行きと帰りで通るGatewayが変わってしまうと、経路の途中にステートful機器（Azure Firewall、Palo Alto、FortiGateなど）が存在する場合に大問題が発生します。
なぜ落ちるのか？
ファイアウォールは「SYNパケット（行き）を見ていないのに、ACKパケット（帰り）だけが飛んできた」と判断するため、セキュリティ違反として**TCPセッションを即座にドロップ（Connection Reset / Timeout）**します。
リスク⑤：AS Path Loop Detection による経路破棄
他チームからよく耳にする「BGPの伝搬不備」は、このAS Path Loop Detection（ループ検出）を指していることが多いです。
BGPには、自分が所属するAS番号が経路に含まれている場合、ループとみなしてその経路を破棄する仕組みがあります。
BGP AS Pathループ検出によるオンプレミス側の経路ドロップ
Azureの各ゲートウェイ（VNet AおよびVNet B）からオンプレミスへ経路を広報する際、Azureの内部AS番号（デフォルト: 65515）が付与されます。
ピアリングされた両方のVNetから同一オンプレミスへ経路が広報されると、オンプレミス側のルータは「過去に通過したAS番号が含まれている」と認識し、ループ防止機能によって経路をドロップ（自動破棄）します。
この結果、オンプレミスからVNet B（またはVNet A）へのルートがルーティングテーブルに登録されず、通信不能となる場合があります。
OnPrem (AS65000) ➔ Azure GW (AS65515) ➔ OnPrem (AS65000)
↳ 自分自身のASN(65000)が含まれているためドロップ！
ただし、これはオンプレ側のASN設定、Route Reflectorの有無、AllowAS-In や AS Override などのBGPオプションによって挙動が変わるため、「必ず起きる」とは言えません。
そのため現場では、AS Loopよりも「想定外のBest Path選択」や「非対称ルーティング」の方がはるかに高い頻度で問題化します。
詳しい説明はこちらをご参照：
https://qiita.com/tanhiroshi/items/657715817a1accc263d2
3. Microsoftが推奨する構成（Hub-Spoke）
特別で複雑な要件がない限り、Microsoftが推奨するHub-Spoke（ハブ＆スポーク）アーキテクチャを採用するのがベストプラクティスです。
OnPremises
|
ExpressRoute
|
Hub VNet
ER Gateway
|
+----------+----------+
| |
Spoke A Spoke B
(Use Remote GW) (Use Remote GW)
GatewayをHub VNetに集約し、各Spoke VNetからは Use Remote Gateway（Gateway Transit）を利用してオンプレミスと通信します。
Hub-Spoke構成のメリット
- 構造がシンプルになり、BGP経路のバッティングが起きない
- 非対称ルーティングを根本から防げる
- Gatewayの台数が減るため、コスト（時間あたりのGateway料金）を削減できる
- 運用・トラブルシューティングが極めて容易
4. まとめ
今回の構成で注意すべき本質は、「AzureがBGP伝搬できない」のではなく、「複数のGatewayが同じオンプレミスとBGP接続することで経路選択が複雑化し、意図しない通信経路になること」です。
⚠️ チェックリスト（この構成のリスク）
- Gateway Transit（リモートゲートウェイの使用）を併用できない
- 同一Prefixが複数Gatewayから重複広報される
- BGP Best Pathの選定により、予期せぬGateway経由になる
- 非対称ルーティングが発生し、FW等でセッションが切断される
- 一部環境で AS Path Loop Detection による経路破棄が発生する
マルチGateway構成を検討する際は、本当にその冗長化が必要なのかを再検討し、特別な理由がない限りはHub-Spoke構成によるGateway集約を第一選択とすることをおすすめします。