ExpressRoute メンテナンス時の AS-path prepend 確認するためにメーカー側確認すべき BGP コマンドの意味を解説

はじめに

ExpressRoute の計画メンテナンス通知を受けた際、Microsoft から

「AS-path prepend を受け入れる構成であることを確認してください」
と案内されることがあります。
しかし、実際にネットワーク機器メーカーやベンダーへ相談すると、

show ip bgp neighbors <Azure-ピアIP> policy detail
show ip bgp neighbors <Azure-ピアIP> received-routes
show ip bgp neighbors <Azure-ピアIP> paths <正規表現>
show ip route <Azureプレフィックス> <マスク>

などのコマンド実行を依頼され、
「このコマンドで一体何を確認したいのか？」
と疑問に思う方も多いのではないでしょうか。

本記事では、それぞれのコマンドの目的と、メーカーが裏で何を見ようとしているのかを分かりやすく解説します。

ExpressRoute メンテナンス時の AS-path prepend とは？

ExpressRoute のメンテナンス時、Microsoft はメンテナンス対象となる MSEE（Microsoft Enterprise Edge）ルータからの経路広告において、以下のように意図的に AS_PATH を長くして送信してきます。

通常時：   AS12076
メンテナンス時： AS12076 AS12076 AS12076 AS12076

このように AS 番号を重複させて経路の優先度を下げる手法を AS-path prepend と呼びます。
BGP では「AS_PATH が短い経路」を優先するルールがあるため、これにより オンプレミス ➔ Azure のトラフィックを、自動的にメンテナンス対象外（正常稼働中）の別回線へと迂回させることができます。

そのため、お客様側のルータが

• AS-path prepend（伸びた AS_PATH）を正しく受信・認識できるか
• Local Preference や Weight などの設定によって、AS-PATH による経路決定が阻害（無視）されていないか
  を確認することが非常に重要になります。

---

各コマンドの目的と解説

コマンド①：ポリシーの確認

show ip bgp neighbors <Azure-ピアIP> policy detail

目的

BGP ピア（Azure 接続口）に適用されているフィルタリングや属性変更のポリシー（route-map、prefix-list、policy-map など）を確認する。

メーカーは何を見ているのか？

「AS-path prepend による経路選択が、ルータの設定によって無効化されていないか」 を確認しています。

⚠️ よくあるドハマりパターン：Local Preference の罠
オンプレミス側ルータで「Primary 回線からの受信経路には常に local-preference 200（Secondary は 100）」といった固定設定を入れているケースです。
BGP の経路決定ルールでは、Local Preference は AS_PATH よりも優先されます。そのため、Microsoft がいくら AS-path prepend（12076 12076 12076）を送ってきて AS_PATH を伸ばしても、Local Preference の値が勝ってしまい、メンテナンス中の Primary 回線を掴み続けて通信障害が発生するリスクがあります。

これを防ぐために、まずポリシー設定を確認します。

---

コマンド②：受信経路の確認

show ip bgp neighbors <Azure-ピアIP> received-routes

目的

Azure から実際に見えている（受信している）BGP 経路のリストと、その AS_PATH を確認する。

メーカーは何を見ているのか？

「Microsoft から送られてきた AS-path prepend（延伸された AS_PATH）が、正しくルータまで届いているか」 を確認しています。

通常時の表示例：

Network          AS_PATH
172.16.10.0/24   12076
172.16.0.0/16    12076

メンテナンス時の表示例（期待される値）：

Network          AS_PATH
172.16.10.0/24   12076 12076 12076 12076
172.16.0.0/16    12076 12076 12076 12076

---

コマンド③：特定 AS_PATH の抽出

show ip bgp neighbors <Azure-ピアIP> paths <正規表現>

目的

大量にある BGP 経路の中から、特定の AS_PATH パターンを持つ経路だけを抽出する。

メーカーは何を見ているのか？

今回の Azure 側の ASN は 12076 です。

通常時は 12076 が 1 つだけですが、メンテナンス時には 12076 12076 ... のように連続して並びます。このコマンド（正規表現）を使うことで、通常時の経路と prepend された経路を迅速に見分ける・確認することができます。

例：

show ip bgp neighbors 192.168.1.1 paths 12076

---

コマンド④：最終採用経路（ルーティングテーブル）の確認

show ip route <Azureプレフィックス> <マスク>

目的

BGP テーブルで選ばれたベストパスが、最終的にルータのルーティングテーブル（RIB）に採用されているか確認する。

メーカーは何を見ているのか？

「受信した経路」と「実際に通信に使われる経路」は異なる場合があるためです。

例：

show ip route 172.16.0.0 255.255.0.0

実行結果の例：

Routing entry for 172.16.0.0/16
  Known via "bgp 65001"
  Next Hop: 192.168.1.1 (Primary 側)

いくら BGP 上で prepend された経路を受信していても、コマンド①で触れた Local Preference や Weight の影響があると、ルーティングテーブルには依然として Primary 側がネクストホップとして残り続けてしまいます。

そのため、最終的にどの回線（ネクストホップ IP）経由で通信が行われるかをこのコマンドで引導を渡す形で確認します。

---

【実践】テスト用環境における実行コマンド一覧

テスト・サンプル用のアドレスに置き換えたそのまま使える実行用リストです。メーカーへ調査ログを提出する際はこちらをコピー＆ペーストして順次実行してください。

前提パラメータ（テスト用 IP）

• Primary ピア IP: 192.168.1.1　（ER回線のPrimaryIP）
• Secondary ピア IP: 192.168.2.1（ER回線のSecondaryIP）
• Azure 側プレフィックス:
• (例です。ERGWのSubnetのPrefxとPeeringしているSpokeVnetのPrefxです)
• 172.16.10.0/24
• 172.16.20.0/24
• 172.16.0.0/16
• 172.17.0.0/16

---

1. BGP ポリシー詳細の確認（Primary / Secondary）

Primary 回線と Secondary 回線の両方に適用されているポリシーを確認します。

show ip bgp neighbors 192.168.1.1 policy detail
show ip bgp neighbors 192.168.2.1 policy detail

2. 受信経路の確認（Primary / Secondary）

それぞれのピアから受信している実際の AS_PATH を確認します。

show ip bgp neighbors 192.168.1.1 received-routes
show ip bgp neighbors 192.168.2.1 received-routes

3. 特定 AS (12076) 経路の抽出（Primary / Secondary）

12076 を含む経路のみを抽出し、AS-path prepend の状態をピンポイントで確認します。

show ip bgp neighbors 192.168.1.1 paths 12076
show ip bgp neighbors 192.168.2.1 paths 12076

4. ルーティングテーブル（最終採用経路）の確認

確認対象となる各 Azure プレフィックスに対し、ルータが現在 Primary（192.168.1.1）と Secondary（192.168.2.1）のどちらをアクティブなネクストホップとして採用しているかを確認します。

show ip route 172.16.10.0 255.255.255.0
show ip route 172.16.20.0 255.255.255.0
show ip route 172.16.0.0 255.255.0.0
show ip route 172.17.0.0 255.255.0.0

---

もし事前確認で「自動迂回できない」と判明したら？

もしメーカーの調査によって「Local Preference 固定設定などの理由で自動切り替えが機能しない」と分かった場合は、以下のいずれかの事前対策を検討する必要があります。

1. ルータの設定修正:
   Local Preference による固定制御をやめ、AS_PATH 長を正しく考慮できる BGP ポリシーへ見直す。

---

まとめ

コマンドの目的をまとめると、以下のようになります。

コマンド	確認目的
policy detail	AS-PATH より優先される設定（Local Preference 等）がないか確認
received-routes	Azure から実際に受信した AS_PATH を確認
paths	重複した AS_PATH（12076 12076...）を迅速に抽出
show ip route	最終的に通信に採用されたベストパス（ネクストホップ）を確認

メーカー側は単に「設定が入っているか」を見たいのではなく、「Microsoft がメンテナンス時に付与する AS-path prepend が、このルータの経路選定ロジックで正しく判定され、無事に Secondary 回線へ迂回できる状態にあるか」 を検証しようとしています。