【Azure×BGP】「AS Pathループ検出」で通信が落ちる仕組みと回避策
Azureでネットワークを設計・構築していると、他チームやインフラベンダーから「その構成、BGPのAS Pathループ検出に引っかかって経路がドロップ（破棄）されますよ」と指摘されることがあります。
一見すると難しそうな専門用語ですが、要約すると「ルータが『この経路、同じ場所をぐるぐる回っているループ経路だ！』と勘違いして、安全のために通信ルートを捨ててしまう現象」です。
本記事では、この「AS Pathループ検出」のメカニズムと、AzureのマルチGateway構成でなぜ発生するのかを分かりやすく解説します。
1. そもそも「AS Pathループ検出」とは？
BGP（Border Gateway Protocol）は、インターネットや大規模な企業ネットワークで経路情報（「どのIPアドレスへはどう行けばいいか」）を交換するためのプロトコルです。
BGPには、広報する経路情報の中に「これまで通過してきたAS番号のリスト（AS Path属性）」を書き込むルールがあります。
💡 AS（Autonomous System）とは？
ネットワークの管理単位（グループ）のこと。Azureの内部AS番号はデフォルトで65515、オンプレミス側の企業ネットワークには65001などの番号が割り当てられます。
BGPの絶対ルール（ループ防止）
ルータが新しい経路情報を受け取ったとき、その「通過してきたAS番号のリスト」をチェックします。
-
正常なルート:
[ 65001 ➔ 65515 ]（自分と違う番号を通ってきた ➔ OK！） -
ループルート:
[ 65515 ➔ 65001 ➔ 65515 ]（「あれ？自分自身のAS番号（65515）がもう一回入ってるぞ！？」）
このように、「自分の所属するAS番号」や「過去に通過したAS番号」がリストに含まれていると、ルータは「ルーティングループ（無限ループ）が発生している」と判断し、その経路を即座に破棄（ドロップ）します。
これが AS Path Loop Detection（AS Path ループ検出） です。
2. AzureのマルチGateway構成で起きるメカニズム
では、なぜ「ピアリングされたVNet A・Bの両方にGatewayを置いて同じオンプレミスに繋ぐ」と、この現象が起きてしまうのでしょうか？
分かりやすく図で追ってみましょう。
構成イメージ
- オンプレミスルータ (AS:
65001) - VNet A の Gateway (AS:
65515) - VNet B の Gateway (AS:
65515) ※AzureのデフォルトAS番号
[ VNet A ] (10.10.0.0/16) ── [ Gateway A ] (ASN: 65515) ──┐
│ (VNet Peering) │ (ExpressRoute/VPN)
[ VNet B ] (10.20.0.0/16) ── [ Gateway B ] (ASN: 65515) ──┼── [ オンプレミス ] (ASN: 65001)
経路伝搬のステップ
- 直接ルートの広報（正常）
- Gateway B は、自身の
10.20.0.0/16をオンプレミスに広報します。 - 通過リスト（AS Path）：
[ 65515 ]➔ オンプレミスは問題なく学習。
- ピアリング経由の迂回ルートの広報（事件発生！）
- VNet A と VNet B はピアリングされているため、Gateway A もピアリング経由で VNet B のアドレス（
10.20.0.0/16）を認識します。 - Gateway A は「うちを通っても VNet B に行けますよ！」とオンプレミスに広報しようとします。
- すでに
65515（Gateway B）を通ってきた経路に、さらに Gateway A 自身の65515が追加されます。 - 通過リスト（AS Path）：
[ 65515, 65515 ]（またはピアリング伝搬の状況によって自ASが含まれる形に）
- オンプレミスルータでのドロップ
- オンプレミスルータは Gateway A から届いた迂回ルートを見てこう判断します。
🤖 ルータの判定:
「AS65515が重複して含まれている（または過去に通過したルートに見える）。これは危険なループルートだ！ 破棄（ドロップ）する！」
結果として、Gateway A を経由したバックアップ経路は完全に拒否され、人間が期待した「片方が死んだらもう片方に迂回する」という動的な切り替え機能が動かなくなります。
3. さらに恐ろしい「本命ルート全滅」のパターン
上記は「迂回ルートが消える」話でしたが、オンプレミス側のAS番号（65001）が絡むと、「メインの通信ルートすら全滅する」という最悪のケースも発生します。
もし、ネットワークの伝搬順序や設定によって「VNet A ➔ オンプレミス ➔ VNet B」という経路情報が形成されてしまった場合：
Gateway A (65515) ──➔ オンプレ (65001) ──➔ Gateway B (65515) ──➔ オンプレ (65001)へ再広報
- Gateway A から出たルートがオンプレミス（
65001）を経由して Gateway B に届く。 - そのルート（AS Path:
65515, 65001）が Gateway B から再度オンプレミスへ送信される。 - オンプレミスルータは、届いた経路の中に自分自身のAS番号（
65001）を発見する。 - 「自分が過去に送り出した経路が戻ってきた！ループだ！」と判断し、ルートを拒否。
このパターンに陥ると、オンプレミス側で VNet B へのルートがルーティングテーブルから消去され、オンプレミス ➔ VNet B への通信が一切できなくなります。
4. この問題の対策・回避策
AS Pathループ検出による通信トラブルを防ぐには、以下の3つのアプローチがあります。
対策①：Hub-Spoke構成にする（★一番の推奨）
VNet B の Gateway を削除し、VNet A（Hub）の Gateway 1台に集約します。
- 理由: そもそも Gateway が1つになれば、BGPの競合や重複広報自体が起きなくなります（根本解決）。
対策②：ピアリング間でゲートウェイ転送をオフにする
VNet A と VNet B のピアリング設定で、ゲートウェイ転送を許可する / リモートゲートウェイを使用する を双方ともOFFにします。
- 理由: VNet A-B 間で互いの Gateway 経路を共有しなくなるため、ループ経路が生成されません。
対策③：オンプレミスルータで allowas-in を設定する
オンプレミスルータ側の設定で「自AS番号が1〜2回含まれていてもドロップせず受信する」というコマンド（Cisco等の allowas-in）を入れます。
- 注意: 機器の設定変更が必要になり、本物のルーティングループが発生した際にとめられなくなる運用リスクがあるため、あまり推奨されません。
まとめ
BGPの「AS Pathループ検出」による経路ドロップは、バグや障害ではなく「BGPルータがルーティングループ事故を防ぐための正常な防御機能」です。
複数 Gateway 構成では、この善意の防御機能が裏目に出て、必要なルートが拒否されてしまいます。
Azureネットワークを設計する際は、こうしたBGPのループ検出リスクを避けるためにも、特別な事情がない限り「Hub VNet への Gateway 集約（Hub-Spoke構成）」を選択するのが最も安全でシンプルなベストプラクティスとなります。