Azure ExpressRoute計画メンテナンスの「AS-path prepend」通知とは？仕組みとオンプレ側で必要な設定を分かりやすく解説
Azure ExpressRouteの計画メンテナンス通知やダッシュボードで、よく目にするこの一文。
「AS-path prependが適切に設定されていれば、トラフィックがシームレスに冗長接続へ切り替わるため、サービスの中断は発生しません。そうでなければ、切り替わるまでの間、一時的な影響やパフォーマンス低下が生じる可能性があります。」
「そもそもAS-path prependって何？」「『適切に設定されている』って具体的にオンプレルーターで何をしていればいいの？」と疑問に思うインフラエンジニアの方も多いのではないでしょうか。
今回は、AS-path prependの基本的な仕組みから、Azureの計画メンテナンス時に裏側で起きている具体的な動作、そしてオンプレミス側で確認すべきポイントについて分かりやすく解説します。
1. AS-path prepend（ASパス プリペンド）とは？
一言で言うと、「自社のAS番号をわざと複数回重ねて広報し、その経路を『遠回りなルート』に見せかけるBGPの技術」です。
BGPの基本ルール：「短いは正義」
インターネットやExpressRouteで使われるBGP（Border Gateway Protocol）は、宛先までに通過するAS（自治システム）の数が一番少ないルート（AS-pathが最短のルート）を最優先で選ぶ仕組みを持っています。
Prepend（かさ増し）の仕掛け
あえて自分のAS番号を重複して付加（prepend）すると、パケットを送る側からは「なんだか遠回りなルートだな」と見えます。
【通常ルート】
AS-Path: 65000 (長さ: 1) ➔ 近い！優先して使う
【Prepend適用ルート】
AS-Path: 65000 65000 65000 (長さ: 3) ➔ 遠い！できれば使わない
これを利用することで、対向のルーターに対して「こちらのルートは遠回りだから、できれば別のルートを使ってね」と優先度を意図的に下げることができます。
2. 【例解説】Azure計画メンテナンス時に裏側で起きていること
Microsoftからの通知にある「AS-path prependを利用した経路制御」とは、具体的にどのような挙動を指しているのでしょうか？
ExpressRouteが Primary（回線A） と Secondary（回線B） の2本で冗長化されている環境で、Microsoftが回線Aの計画メンテナンスを行う場合を例に挙げてみましょう。
【 Azure（Microsoft） 】
│ │
(回線A/Primary) (回線B/Secondary)
│ │
▼ ▼
【 オンプレミスルーター 】
① Microsoft（Azure側）が自動で行う「お作法」
Microsoftは回線Aを切断してメンテナンスに入る前に、回線AのBGP広報に対して AS 12076（MicrosoftのAS番号）を8回追加（Prepend） します。
-
回線Aからオンプレへ届くBGPパス:
12076 12076 12076 12076 12076 12076 12076 12076 12076（超・遠回り） -
回線Bからオンプレへ届くBGPパス:
12076（通常の最短ルート）
回線Aを切断する前に「回線Aは超遠回りになったよ！」という情報をあらかじめオンプレ側に流すことで、通信を事前に回線Bへ避難させる（プレ・フェイルオーバー）という処理をMicrosoft側が自動で行ってくれています。
② オンプレミス側ルーターの挙動と「確認すべきこと」
この時、オンプレミス側のルーターが「Azureから届いたASパスの長さを素直に評価して、自発的に回線Bを選べる設定になっているか」が運命の分かれ道になります。
-
【正常な動作（適切な設定になっている場合）】
オンプレミスルーターは「回線AはASパスが9個分あって超遠回りだな。回線Bは1個分で近いから、これからはAzure宛ての通信をすべて回線Bから送ろう」と判断します。
➔ 回線Aが物理的に落とされる前に、オンプレ ➔ Azure の通信がシームレスに回線Bへ切り替わり、無断裁でメンテナンスに突入できます。 -
【問題が発生する動作（不適切な設定の場合）】
オンプレミス側で「回線A」を優先したいがために、ASパスの長さを無視するような強力な固定設定（非常に高い Local Preference やスタティックルートなど）を入れている場合。
➔ AzureがどれだけPrependして「回線Aは遠回りだよ」と教えてくれても、オンプレルーターがそれを無視して回線Aを使い続けようとします。結果として、回線Aが物理的に落とされた瞬間に通信断（BGPセッションダウンまでの数10秒〜数分間）が発生してしまいます。
3. オンプレミス側で「適切なBGP優先制御」を行うための3つのポイント
「オンプレミス側で適切なBGP優先制御（AS-path prependを含む）を構成する」とは、具体的に以下の状態を作ることを指します。
ポイント①：両方の回線で広報するIP帯（Prefix）を完全に一致させる
BGP最優先の法則は「ロンゲストマッチ（最も細かいサブネットを優先）」です。「広報するIP帯（Prefix）の細かさが両系で異なっていると、AS-path prependでいくら『遠回り』に設定しても、BGPはそれを無視して細かい方のIP帯（不適切なルート）へ通信を流してしまうから。
PrimaryとSecondaryの両方のBGPピアから、全く同じIPアドレス帯（例: どちらからも 10.0.0.0/16）を広報します。
ポイント②：通常運用時に自社から出す通信も Prepend で差をつける
アクティブ/スタンバイ構成で運用する場合、オンプレミスからAzureへ送るBGP広報でも、サブ系（Secondary）にのみ AS-path prepend（2〜3個付与）を設定します。
これにより、通常時の「Azure ➔ オンプレ」の通信も確実にPrimary回線を通るようになります。つまり、自社から外に広報する情報に Prepend をつける意味は、「Azure からオンプレへ帰ってくる（入ってくる）通信のメイン経路を確定させるため」 です。
これは「通常時に『Azure ➔ オンプレ（入り）』の通信をメイン回線に100%固定し、メンテナンスが発生した際に行きと帰りの経路がズレる障害（非対称ルーティングによる通信断）を防ぐため」に必要となります。
✕ Prepend の設定が不十分な場合（通常時）
オンプレ ➔ Azure（行き）： Primary 回線を通る
Azure ➔ オンプレ（帰り）： Prepend がないため、Azure 側の都合で Secondary 回線を通ってしまう（非対称ルーティング発生）
✕ この状態で Primary 回線（メイン）のメンテナンスが入ると…
Microsoft が Primary 回線をメンテナンスで切断した瞬間、以下のパケットドロップが発生します。
セッションの強制切断
オンプレミス側のファイアウォール（FW）やルーターは「行きのパケットを渡していない Secondary 回線」から突然帰りのパケットが届くため、不正な通信（ステートフルインスペクション違反）とみなして破棄（ドロップ） します。
切替時の通信断
普段から行きと帰りがバラバラだと、片方の回線がメンテナンスに入った際の「正常な切り替え」が正しく行われず、既存の TCP セッション（Web 接続や DB 接続など）がすべて切断されます。
- 正しく Prepend が設定されている場合の挙動（メンテナンス時）
〇 通常時（Prepend 設定あり）
オンプレ ➔ Azure（行き）： Primary 回線
Azure ➔ オンプレ（帰り）： Primary 回線（Prepend の差により Azure が選択）
※行きと帰りが完全に一致（対称ルーティング）
〇 Primary 回線の計画メンテナンス時
Microsoft が Primary 回線に AS 12076 を 8 回 Prepend して遠回り化させます。
同時に、オンプレ側もあらかじめ Secondary 回線に Prepend を入れた「きれいなアクティブ/スタンバイ構成」になっているため、Azure 側もオンプレ側も迷うことなく、一瞬で「行き・帰り」の両方の通信を Secondary 回線へシフト します。
行きと帰りの経路が一致したまま Secondary 回線に切り替わるため、ファイアウォールでブロックされることなく、既存の通信セッションを維持したまま無断裁でメンテナンスを通過 できます。
ポイント③：Azureからの経路広報（AS-Path長）を素直に受け入れる設定にする
オンプレミスルーター側で特定回線を強制するような過度なBGP属性（Local Preference等）の上書きを行わず、BGPの標準的な経路選択アルゴリズム（AS-Pathが短い方を優先するルール）が機能する状態にしておきます。
まとめ：通知が来たらここをチェック！
Microsoftからの「AS-path prepend」に関するメンテナンス通知は、次のようなメッセージです。
「Microsoft側で事前に回線AにAS 12076を8回Prependして『遠回り化』させ、通信を回線Bへ逃がす準備をします。オンプレミス側のルーターも、そのBGP広報に従ってスムーズに回線Bへ切り替えられる状態になっていますか？」
事前に以下の3点を確認しておけば、ExpressRouteの計画メンテナンスを恐れる必要はありません。
- オンプレ側で特定回線への強力な固定ルーティング（高Local Pref等）をしていないか？
- Primary / Secondaryの両回線から広報しているPrefix（IP帯）が完全に同一か？
- Secondary回線側に適切な Prepend 設定（2〜3個）が入っているか？
標準的なBGP冗長設計ができていれば、何もしなくても自動でシームレスに切り替わりますのでご安心ください！