ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

BGPモニタリング

BGP MED属性

BGP MEDを使用すると、隣接するASがトラフィックを送信する際に使用するエントリポイントを指定できます。その仕組み、重要な場面、そしてトラフィックエンジニアリングで使用する際に避けるべき一般的な落とし穴について学びましょう。

6〜10分
デントン千倉

章

    ニュースレター

    最新情報のメール配信を登録

    最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

    シェア

    クイックダウンロード:

    BGP MEDを使用すると、隣接ASに対してどのエントリポイントを優先すべきかを指示できますが、これは両者がそれを尊重することに同意した場合にのみ機能し、デフォルトでは同じ隣接ASからのルート間でのみ比較されます。

    • MEDは、パス選択順序においてLOCAL_PREFとAS_PATHの後に評価され、両方の属性が等しい場合にのみ有効になります。

    • デフォルトでは、MEDは同じAS内のルート間でのみ比較されます。always-compare-medを有効にすると、ASをまたいだMEDの比較が可能になりますが、予期しないルーティング変更が発生する可能性があります。

    • MEDは非推移的であり、下流のピアには渡されないため、その影響は直接隣接するASに限定されます。

    • トラフィックエンジニアリングにMEDポリシーを利用する前に、近隣のASとMEDポリシーについて明確に合意してください。MED値を無視する近隣ASは、期待どおりに動作しません。

    現代生活に不可欠な多くの活動はインターネットに依存しており、インターネットはBGP（Border Gateway Protocol）に依存しています。つまり、BGPのパフォーマンスは世界規模で影響を及ぼす可能性があります。BGPのパフォーマンスが著しく低下したり、ルーティングプロトコルに問題が発生したりすると、世界中の経済は莫大な生産性と資金を失う可能性があります。 

    その結果、BGP モニタリングは現代のネットワークにおいて不可欠な要素となっています。簡単に言うと、BGP は「インターネットのプロトコル」であり、グローバル インターネットを構成する自律システム (ネットワーク) 間でルーティング情報を交換するために使用されます。この記事では、マルチエグジット ディスクリミネータ (MED) またはメトリックとして知られる BGP 属性と、それがルーティング決定にどのように影響するかについて説明します。 

    BGP MEDはトラフィックエンジニアリングに使用される属性であり、他のピアに経路をアドバタイズする自律システムによって設定されます。トラフィックに影響を与えようとする上で重要な役割を果たします。 進入 自律システムに組み込まれる。MEDは評価される。 After ローカル優先度とASパス属性。1つ以上のルートでMEDを比較する場合、MEDが最も低いルートがタイブレーカーとなります。

    経路選択の評価順序とタイブレーク属性についてさらに詳しく知りたい場合は、BGPパス選択に関する記事をご覧ください。 こちら.

    Junosにおけるパス選択の実装方法を完全に理解するには、以下を参照してください。 このページ.

    BGP MED は の 2 つ以上のルートが学習された場合のルート選択プロセスで使用されます。 同じASN そしてそれらのルートは 同じ宛先（プレフィックス）。 ASNから学習したルートが1つしかない場合、比較対象となるMEDが2つ以上必要となるため、BGP MEDはルート選択に影響を与えません。

    例えば、クラウドプロバイダーやコンテンツプロバイダーと複数のピアリングがあり、それぞれが類似したルートセットをアドバタイズしているとします。すべてのセッションで同じローカルプリファレンスとASパス長を持つルート192.168.50.0/24が受信された場合、このケースではMEDが比較されます。

    別のクラウドまたはコンテンツプロバイダーとのピアリングが1つしかない場合、このASN（ネクストホップとして）を介して利用できる宛先プレフィックスごとのルートは1つだけです。この状況では、MEDは 比較対象となる適切な代替ルートが存在しないため、ルート選定プロセスにおいて考慮する必要があります。

    BGP MEDの説明

    デフォルトでは、ルーターベンダーによって異なりますが、ポリシーで別途設定されていない限り、アドバタイズされたルートの BGP MED は 0 または IGP コストと等しくなります。BGP ルートを受信する自律システムは、別途設定されていない限り、通常はデフォルトで MED を「尊重」（つまり、ルーティング決定に MED を考慮）します。MED を無視する選択肢については、この記事でさらに詳しく説明します。

    MEDは4バイト/32ビットのフィールドであるため、値の範囲は0から4,294,967,295までですが、一般的に使用される値は0から数千までです。これらの値は、例えば0から100の範囲で任意に選択できます。表に示すように、優先するピアリングをプライマリとしてMED 0に設定し、優先するピアリングをバックアップとしてMED 20に設定することができます。

    表に構成例を示し、以下で詳しく説明します。使用されている数値はあくまで例ですが、MED値間の相対的な差に注目することで、結果として生じる動作を理解できます。

    ピアリング1MEDピアリング2MED医学分野で栄誉を授かりましたか？結果
    00はいトラフィックは負荷分散されています
    020はいピアリング1がプライマリ、ピアリング2がバックアップ
    9378はいピアリング2がプライマリ、ピアリング1がバックアップ
    5447いいえMEDは無視されるため、MEDはそれぞれ0として扱われます。

    値は、ルーターによって0に設定することも、IGPメトリックをBGP MEDにコピーすることによって設定することもできます。たとえば、BGP経由でアドバタイズされるルートのIGPコストが54の場合、BGP MEDは54に設定されることがあります。

    MEDは、受信したセッションを超えて伝播しません。例えば、ASN AからアナウンスされたBGP MEDはASN Bで受信されますが、BがこのルートをASN Cに再アドバタイズした場合、BGP MEDは0、IGPメトリック、または管理者が設定した値に上書きされます。 

    MEDの使用に関する基本原則は以下のとおりです。

    • （MEDを比較する場合）MED値が最も低い方が「勝ち」となる。
    • 同等のMEDは、（受信側のネットワーク構成によっては）負荷分散を行う可能性があります。
    • セッション間でMED（マルチアクセス・ディレクティブ）が不均等にアドバタイズされると、通常はプライマリとバックアップのトラフィック分散（または3つのセッションの場合はプライマリ、バックアップ、三次など）が発生します。

    不均等なMED

    一般的な方法として、一方のピアリングをMED 0に設定し、もう一方を50などのより高い値に設定するという方法があります。これは、受信ネットワークへのピアリングが2つあり、一方の容量が大きい場合、その容量が大きいピアリングをプライマリとし、もう一方をバックアップとして機能させたい場合に有効です。

    最善の方法は、地理的に分散した場所に同等の容量のリンクを配置し、BGP MEDをIGPメトリックと同じ値に設定することです。これにより、ピアネットワークはIGPコストを把握し、ネットワークへの出口ポイントに関して最適なルーティング決定を行うことができます。

    同等のMED

    不均等MED戦略のいずれも使用したくない場合は、MEDをデフォルトのままにするか、明示的にゼロに設定してください。これにより、ピアのネットワークで「ホットポテト」ルーティングが発生し、あなたのネットワーク宛てのトラフィックは、必ずしも最適なパスではなく、ピアのネットワークから最も近い出口から出ていきます。

    このシンプルな戦略が広く用いられている理由はいくつかあります。

    • メトリック0を広告するのは、一般的なデフォルト設定です。
    • ネットワーク上でトラフィックを長時間伝送すると、通過するすべてのリンクでリンク帯域幅を消費するためコストがかさみます。そのため、レイテンシや帯域幅/輻輳の観点からは最適な経路ではないかもしれませんが、トラフィックをできるだけ早くネットワーク外に転送することが望ましい場合があります。したがって、MEDを受信したネットワークは、MEDを完全に無効にして、MEDを0にリセットする場合があります。

    クライアントの声

    送信するMEDについて考えてみてください。受信側のネットワークには、送信トラフィックをどのように処理してほしいですか？特定のピアリングを優先させるのか、IGPメトリックに従うのか、それとも最も近い出口を探すのか？

    MEDをIGPメトリックと同じ値に設定するのが、迷った場合の良い出発点となります。通常、BGPセッションを切断することなく変更できるため、最小限のリスクで最適なチューニング状態を見つけるための実験が可能です。

    また、受信したBGPルートMEDについても検討してください。それらをどのように処理しますか？受信したMEDをそのまま使用しますか、それともすべてのMEDをゼロに書き換えるポリシーを設定しますか？最寄りの出口でトラフィックを遮断するか、受信したMEDに基づいてトラフィックをルーティングするかを検討してください。

    構成例

    エクスポート ポリシーでアウトバウンド MED を設定する Junos 設定例を見てみましょう。使用例については、コード ブロック内のコメントを参照してください。

    # Announce MED = IGP
set policy-options policy-statement EXPORT-TO-ACME term ANNOUNCE then metric igp

# Announce MED = 0 on Peering 1, MED = 50 on Peering 2
set policy-options policy-statement EXPORT-TO-ACME-1 term ANNOUNCE <...>
set policy-options policy-statement EXPORT-TO-ACME-1 term ANNOUNCE then metric 0
set policy-options policy-statement EXPORT-TO-ACME-2 term ANNOUNCE then metric 20

    Junos は、受信する MED については、特に指定がない限り、デフォルトでそれらを尊重します。受信 MED を上書きして 0 に設定する場合、つまりインポート ポリシーでホット ポテト ルーティングを実装する場合は、次のようにします。

    # Override incoming MED, rewrite as 0
set policy-options policy-statement IMPORT-FROM-ACME term PERMIT then metric 0

    検証コマンド

    受信したルートのMEDを表示するためのコマンドは次のとおりです。

    @router> show route receive-protocol bgp 192.168.10.1 8.8.8.0/24 extensive

  8.8.8.0/24 (10 entries, 1 announced)
     Accepted
     Nexthop: 192.168.10.1
     MED: 42  <<<<<<<<<<<<<<<<<<<<<<<<<<< Received MED shown
     AS path: 15169 I
     Communities:

    広告されているルートのMED（最大有効距離）を確認する方法は以下のとおりです。

    @router> show route advertising-protocol bgp 192.168.10.1 172.16.0.0/12 extensive

* 172.16.0.0/12 (3 entries, 1 announced)
 BGP group PEERS type External
     Nexthop: Self
     MED: 0  <<<<<<<<<<<<<<<<<<<<< Advertised MED shown
     AS path: I
     Communities: 64512:123

    結論

    どのMEDを宣伝するか、また受信したMEDをどのように処理するかによって、ルーティングの決定が左右され、結果として、広告主の受信方向と受信側の送信方向におけるトラフィックの流れに影響します。 

    MED = IGP を宣伝し、受信したすべての MED を尊重するのがベストプラクティスです。上記のように、一部のネットワークは IGP MED を無視することを選択する場合があります。できる最善のことは、情報を宣伝することです。 希望 彼らが使用できるようにするためです。

    一部のネットワークは、すべてのセッションでMED = 0を通知することを選択しており、これも妥当な立場と言えるでしょう。

    多くのネットワークではBGP MED（コールドポテトルーティングとも呼ばれる）を尊重する慣習に従っていますが、MEDを完全に無視し、トラブルシューティングを容易にするシンプルなポリシー（すべてのルートが両方の視点から最も近い出口を経由する、いわゆるホットポテトルーティング）を採用しているネットワークも少なくありません。これにより、例えば容量計画によって帯域幅が問題にならず、レイテンシよりも一貫したポリシー構成と動作が重要視される場合など、運用コストを削減できる可能性があります。この点において、サポートスタッフのスキルも重要な要素となるでしょう。

    トラフィックパターン、リンク帯域幅、パス遅延、およびスタッフの知識レベルをレビューし、自社ネットワークおよびピアネットワークに最適なポリシーを検討することをお勧めします。迷った場合は、MED = IGP をアドバタイズし、受信した MED を尊重することから始めるのが良いでしょう。

    受信トラフィックの流れを正確に把握できます。

    LogicMonitorのネットワーク可視性により、アクティブなBGPパス、属性状態、ピアリングポイント全体にわたるトラフィック分布をチームが可視化できるため、受信ルーティングポリシーを検証し、予期しない変更を検出できます。

    よくあるご質問

    BGP MEDとは何ですか？

    BGP MED（Multi Exit Discriminator）は、隣接ASがネットワークへの受信トラフィックをルーティングする方法に影響を与えるために使用される、オプションの非推移的なBGP属性です。同じ隣接ASへの接続が複数ある場合、各接続に異なるMED値を設定することで、隣接ASがどの接続を優先すべきかを指示できます。MED値が低いほど優先されます。MEDはBGPメトリックと呼ばれることもあります。

    BGPパス選択において、MEDはいつ比較されるのか？

    MEDは、BGPパス選択プロセスの比較的後半、WEIGHT（Cisco固有）、LOCAL_PREF、ローカルで生成されたルート、AS_PATHの長さ、およびORIGINコードの後に​​評価されます。つまり、MEDは、それ以前のすべての属性が等しい場合にのみパス選択に影響を与えます。デフォルトでは、MEDは同じ隣接ASから学習したルート間でのみ比較されます。always-compare-medオプション（ほとんどのプラットフォームで利用可能）を使用すると、異なるAS間でのMED比較が可能になります。

    なぜMEDは同じASからのルート間でのみ比較されるのですか？

    同一AS間でのMED比較に対するデフォルトの制限は、安全対策です。異なるASは異なるMEDスケールや意味論を使用する可能性があるため、AS間でMEDを比較すると、直感的でない、あるいは誤ったルーティング判断につながる可能性があります。例えば、AS Aがリンク帯域幅を示すためにMEDを使用し、AS Bが地理的な優先順位を示すためにMEDを使用している場合、両者を直接比較しても意味がありません。この制限により、MEDは意図されたとおり、つまり特定のネイバーからの自身のエントリポイントに関するヒントとしてのみ使用されることが保証されます。

    MEDは、トラフィックが私の希望するリンクを経由して流入することを保証しますか？

    いいえ。MEDはあくまで提案であり、保証ではありません。隣接するASはMED値を無視したり、それを上書きするルーティングポリシーを使用したりすることができます。隣接AS自身のルーティングポリシー、LOCAL_PREF設定、AS_PATHの長さ設定などの要素が、MEDヒントよりも優先される場合があります。受信トラフィックの予測可能なエンジニアリングを実現するには、隣接ASがMEDをどのように処理するかについて連携することが不可欠です。

    デントン千倉著

    テクニカルライター

    デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

    免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

    © LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。