～ExpressRoute & VPNハイブリッド構成におけるMEDの高度活用～
本記事では、AzureにおけるExpressRouteとサイト間VPN（S2S VPN）を併用したハイブリッドネットワーク構成を前提に、BGPルーティング制御におけるMED (Multi Exit Discriminator) の高度な活用方法を中心に解説します。
大規模企業のネットワークエンジニアが、複雑な経路選択やフェールオーバーを設計・運用する際、必ず押さえておきたいBGP属性の使いどころと、Azure固有の制約点について踏み込みます。技術的難易度は高めですが、往復経路の一貫性やトラブルシュートの実際を知るうえで、MEDのメカニズムを理解することは不可欠です。
1. ExpressRouteとサイト間VPNにおけるBGPピアリングの要点
Azure上でのExpressRoute接続では、オンプレミス側（CE/PEルーター）とMicrosoftのエッジ（MSEE）の間でBGPピアリングを行います。
通常はプライベートピアリング用に/30サブネットを割り当て、Azure側がAS番号12076でピアリングを確立し、オンプレ側はユーザー任意のプライベートASを採用する形です。
回線ごとに冗長リンク（プライマリ／セカンダリ）が標準提供され、高い可用性を持ちます。一方、サイト間VPN（S2S VPN）は、Azure VPNゲートウェイ（既定AS番号65515）とオンプレミスのVPNルーター間でIPsecトンネルを構築し、そのトンネル内部でBGPピアリングを張る仕組みです。
どちらもBGPによる動的経路学習が可能ですが、ExpressRouteは専用線ゆえに帯域保証や低レイテンシを得やすく、大規模ミッションクリティカル環境で好まれます。VPNはインターネット経由の暗号化通信であり、導入コストと柔軟性に優れますが、帯域や遅延面では不利です。
Azureでは複数の回線・トンネルを同一VNetに共存させる「coexistence構成」も可能です。
これにより、平常時はExpressRouteを優先し、障害発生時にはVPNへ切り替える「ハイブリッド接続」が実現します。
Azure内部ではWeightなど独自の手法でExpressRouteを優先する動作が既定になっており、ユーザーは特に何も設定しなくても「Azure視点ではExpressRouteがメイン、VPNはバックアップ」という流れが基本です。
ただし、オンプレミス側から見た経路選択の挙動や、Azureからオンプレへのトラフィック経路などは、BGP属性（LocalPref、AS PATH、MEDなど）を用いて慎重に制御しないと思わぬ非対称ルーティングが発生し、通信断や帯域浪費を招きます。
2. BGPのMED属性とその仕様
MED (Multi Exit Discriminator) はBGPのオプション属性（Optional Non-Transitive）であり、同一ASが複数の出口（EBGPセッション）を持つ場合に「どの出口を使って欲しいか」というヒントを隣接ASに示すために利用します。
具体的には、MED値の小さい経路を優先させる想定で、IGPコストや地理的距離などを反映して設定するケースが多いです。
ただし、RFC標準では「同じ隣接ASから学習した複数の経路間でのみ MEDを比較する」挙動が基本となります（Cisco IOSなどの実装でbgp always-compare-medを有効化すると、異なるASからの経路間でもMEDを比較できるようになる）。
MEDは非貫通属性であり、隣接AS間を越えて転送されません。
つまり、あるASが付与したMEDは、その次のASには継承されずに打ち消されるのが標準です。
またBGP経路選択の優先順位としては、WeightやLocalPref、AS-PATH長、Originなどの比較が先に行われ、すべて同等だった場合にようやくMEDが参照されます。
実運用ではLocalPrefやAS-PATH操作を使った経路制御が優先されることが多く、MEDは繊細なチューニングに用いられることが多いというのが実情です。
3. AzureのMED取り扱いとExpressRoute/VPNの既定挙動
3.1 Azure側からオンプレへの経路広告におけるMED
Microsoft公式ドキュメントやQ&Aによると、Azure（MSEEやVPN Gateway）は既定でMEDを付与しない、もしくは未定義（0扱い）で経路を広告します。
ExpressRouteとVPNのどちらも同一であり、特別にMED差を付けて広告してくることはありません。
そのためオンプレ側ルーターが同一プレフィックスを「ER経由とVPN経由の2通り」で学習した場合、両経路ともMEDは同値となり、さらに上位属性（LocalPrefやAS-PATH長など）の結果次第でベストパスが決まります。
3.2 MEDを用いたAzureへの経路制御は非サポート
Azureはオンプレミスから広告されるMEDをルート選択にほとんど利用しません。
すなわち、オンプレ側で「VPN経路にはMEDを高く、ExpressRoute経路には低く設定し、AzureからのIngressトラフィックを最適化しよう」と試みても、Azureはそれを参照せず、内部で持つWeight設定などに基づいてExpressRouteを優先する設計を優先します。
Microsoftは公式に「AzureはMEDによる制御をサポートしていない」と回答しており、AS-PATHプリペンドやConnection Weight変更を推奨しています。
この点が汎用的なBGPネットワークとは異なる大きな制約点です。
4. オンプレ側ルーターでのMED設定例とフェールオーバーへの応用
4.1 BGP設定例（Cisco IOS／Juniper JUNOS）
Cisco IOSの場合
router bgp 65001
bgp always-compare-med
neighbor 198.51.100.2 remote-as 12076 ! ExpressRoute MSEE
neighbor 198.51.100.2 route-map ER-IN in
neighbor 10.1.1.1 remote-as 65515 ! VPN Gateway
neighbor 10.1.1.1 route-map VPN-IN in
!
ip prefix-list AZURE-PFX seq 5 permit 10.0.0.0/8 le 32
!
route-map ER-IN permit 10
match ip address prefix-list AZURE-PFX
set metric 0
!
route-map VPN-IN permit 10
match ip address prefix-list AZURE-PFX
set metric 100
bgp always-compare-med を使い、異なるAS番号（12076 vs 65515）間でもMEDを比較するように調整
ExpressRouteから学習した経路にはMED=0を付与、VPNから学習した経路にはMED=100を付与
MEDが小さいほど優先度が高いので、結果としてオンプレから見るとER経路が常にベストパスとなる
Juniper JUNOSの場合
set routing-options path-selection always-compare-med
set policy-options policy-statement AZURE-IN term 1 from route-filter 10.0.0.0/8 orlonger
set policy-options policy-statement AZURE-IN term 1 then next term
set policy-options policy-statement AZURE-IN term 2 from protocol bgp
set policy-options policy-statement AZURE-IN term 2 from neighbor 10.1.1.1
set policy-options policy-statement AZURE-IN term 2 then metric 100
set policy-options policy-statement AZURE-IN term 2 then accept
set policy-options policy-statement AZURE-IN term 3 from protocol bgp
set policy-options policy-statement AZURE-IN term 3 from neighbor 198.51.100.2
set policy-options policy-statement AZURE-IN term 3 then metric 0
set policy-options policy-statement AZURE-IN term 3 then accept
set protocols bgp group AZURE-ER type external peer-as 12076
set protocols bgp group AZURE-ER neighbor 198.51.100.2 import AZURE-IN
set protocols bgp group AZURE-VPN type external peer-as 65515
set protocols bgp group AZURE-VPN neighbor 10.1.1.1 import AZURE-IN
Ciscoと同様に set routing-options path-selection always-compare-med を有効化
2つのBGP隣接（ER, VPN）で同一プレフィックスを学習した場合、ERのMED=0が優先、VPN=100が二次経路となる
4.2 フェールオーバーシナリオ
オンプレ→Azure方向の通信で、普段はExpressRoute（MED=0）を使い、ExpressRouteダウン時にVPN（MED=100）へ自動切り替えする動作をMEDベースでも実現可能です。
ただし前述の通り、MEDより上位属性のLocalPrefやWeightが優先されるため、そちらで明示的に差をつける方法がより一般的です。
MED比較を使うなら、必ず bgp always-compare-med を全ルーターで統一し、AS-PATH長やLocalPref差が無い状態を作るように留意が必要です。
5. MEDと他BGP属性（LocalPref、AS-PATH、Weight）の優先順位
BGPでは基本的に以下の優先順位で経路選択が行われます。
Weight（Cisco固有／Azure内のConnection Weightも類似挙動）
Local Preference
Locally Originated（networkコマンドや再配布による自己起源）
AS-PATH 長
Origin コード（IGP < EGP < incomplete）
MED（小さいほど優先）
最終的にNeighbor IPやIGPコストなど細かな要素
MEDは最下層近くに位置し、あくまで「最終的な候補同士」の比較材料です。
LocalPrefを設定するとそちらが優先され、MEDで微調整を図ろうとしても上位属性差が優先となってしまうため無効化されるケースが多いです。
複雑な設計でMEDを使う場合は、他属性を同値にしてからMEDで意図的に差をつける必要がありますが、運用保守面ではハードルが高く、構築後のトラブルシュートで苦労することもあるため、慎重なアーキテクチャ設計が求められます。
6. VNet間ピアリングや再配送時におけるMEDの注意点
6.1 トランジットルーティングとループ防止
Azureでは標準的に「複数のExpressRouteやVPN接続間でのトランジットルーティング」をサポートしていないため、ハブ＆スポーク構成でNVAを置いて経路を中継するケースが多いです。
その際、オンプレ→(ER)→VNet A→(NVA)→VNet B→(VPN)→オンプレのようなループが発生しないように、BGP属性やルートフィルタで経路再広告を遮断する必要があります。
MEDを使った経路優先制御だけではループ防止を完全に担保できず、AS-PATH検出やコミュニティタグによるフィルタリングが推奨されます。
特にAzureはExpressRouteがAS 12076、VPNがAS 65515 で別ASとなるため、AS-PATHだけではループ検出をバイパスする可能性もあります。
ルーター側で「12076起源の経路は65515へ再広告しない」といった明示的ポリシーを設定しましょう。
6.2 経路再配送とMEDリセット
BGPからOSPFなどへの再配送を行い、さらに別のBGPセッションに広告する構成では、MEDは非貫通属性ゆえに初期化されることが普通です。Cisco IOSならdefault-metricやルートマップで再設定しなければならず、Juniperはpolicyステートメントでメトリックを再度セットしなければなりません。再配送経路にMEDを期待して設計すると、想定外に値がリセットされてしまい経路選択が狂うことがあるため要注意です。
7. トラブルシュート事例：MEDが絡む非対称経路と対処
以下にMEDが絡んだ代表的なトラブル例と、その対処法を紹介します。
AzureへのMED適用が効かない
オンプレ側からAzureにMEDを広告しても、AzureはMEDを考慮しないためIngress経路制御ができない。
対処: AS-PATHプリペンドやConnection Weightの設定で優先度を調整。AzureドキュメントにもMEDは非サポートと明記されている。
異なる属性設定により非対称ルーティング
オンプレ側でVPN経路に高LocalPrefを設定、Azure側はExpressRouteを優先するWeight設定。結果として片方向はVPN、逆方向はERとなりFWでセッション破棄。
対処: 双方向で整合的に優先経路を合わせる。オンプレでもExpressRouteを高LocalPrefにし、VPNは低くするなどの整合性確保。
ルータ間でMED比較設定に不整合
あるルーターだけ bgp always-compare-med を有効にし、別のルーターでは未設定のままにした結果、経路ベストパスがルーター間で食い違い、フラッピングが起きる。
対処: BGPドメイン全体でalways-compare-medやdeterministic-medを統一設定する。スケールの大きいエンタープライズ環境ほど厳格なポリシーが必要。
8. まとめと推奨アーキテクチャ
オンプレ→Azureの経路制御でMEDを使う
ExpressRouteとVPNを両方から学習した経路に対し、「VPN経由をバックアップ」とするための調整には、Cisco/Juniperルーターでalways-compare-medを有効化し、VPN経路にMED値を大きく、ExpressRoute経路に小さく設定する方法がある。
ただし、LocalPrefとの整合性やAS-PATHの違いに注意し、運用難易度が上がる点を覚悟する必要がある。
Azure→オンプレの経路制御でMEDを期待しない
AzureはMEDを考慮しないため、Ingressトラフィックを制御するにはAS-PATHプリペンドかWeight設定を活用する。ExpressRouteプライベートピアリングなどで複数回線を持つ場合は、Connection Weightにより優先経路を指定できる。
高度なルーティングにはループ防止策も必須
ハイブリッド構成でNVAを用いたトランジットや再配送が絡む場合、MEDだけでなくAS-PATHフィルタ、コミュニティベースのポリシーなどを組み合わせてループや重複経路を排除する。
本当にMEDが必要か再考を
BGP標準ではMEDは優先度が低い属性であり、多くの場合LocalPrefやAS-PATH操作の方が直感的で管理しやすい。Azure固有のWeightも踏まえ、最終的にどういう経路をベストパスにしたいのかを明確化したうえで、最適な属性を選択することが望ましい。
大企業のネットワーク運用では、ExpressRouteを主としたハイブリッド接続が欠かせない存在となりつつあります。
しかしAzureは汎用BGP実装と異なる部分も多く、特にMEDについては制約が大きい点に留意が必要です。本記事の内容を踏まえ、AS全体のルートポリシーを丁寧に設計・統一することで、フェールオーバーや最適経路選択の安定運用を実現してください。
加えて、トラブルシュート時にはBGPデバッグログやフローテレースだけでなく、Azure Monitorおよびオンプレ側ルーターのBGPテーブルを突合し、経路属性の不整合（MED不比較、LocalPref差、AS-PATHミス）をいち早く発見する仕組みを整えておくと良いでしょう。