MultiExit Discriminator(MED)を使用したBGPベストパス選択への影響

ダウンロード オプション

  • PDF     (417.0 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
Updated: 2026 年 7 月 30 日
Document ID:13759

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

はじめに

このドキュメントでは、bgp deterministic-medコマンドの概要と、このコマンドがMultiexit Discriminator(MED)に基づくパス選択にどのように影響するかについて説明しています。

前提条件

要件

次の項目に関する知識があることが推奨されます。

  • 基本的な IP ルーティング
  • ボーダー ゲートウェイ プロトコル（BGP）

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

表記法

シスコのドキュメント表記の詳細は、『シスコテクニカルティップスの表記法』を参照してください。

MED 属性

MEDはオプションの非経過的なBGP属性で、複数のエントリポイントを持つ自律システム(AS)への優先パスに関するヒントを外部隣接ルータに提供します。MEDはルートの外部メトリックとも呼ばれ、低いMED値が高い値よりも優先されます。デフォルトでは、BGPは同じ隣接ASから受信したパス間だけでMED値を比較します。

note-icon

注:bgp always-compare-medが設定されていない限り、BGPはデフォルトで、同じ隣接ASから受信したパスのMED値のみを比較します。詳細については、『bgp deterministic-medコマンドとbgp always-compare-medコマンドの相違点』を参照してください。

Network Topology 

Network TopologyNetwork Topology

例

このシナリオでは、AS 65502はAS 65501を持つISPのユーザです。R4は、冗長性を確保するためにISP側の2つの異なるルータに接続され、2つのネットワーク（10.4.0.0/16と10.5.0.0/16）をISPにアドバタイズします。このセクションでは、一部の関連する設定だけが示されています。

R4 
!
hostname r4
!
ip cef
!
!
interface Loopback10
 ip address 10.4.0.1 255.255.0.0
!
interface Loopback11
 ip address 10.5.0.1 255.255.0.0
!
interface Serial0/0
 ip address 192.168.20.4 255.255.255.0
!
interface Serial1/0
 ip address 192.168.30.4 255.255.255.0
!
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 10.4.0.0 mask 255.255.0.0
 network 10.5.0.0 mask 255.255.0.0
 neighbor 192.168.20.2 remote-as 65501
 neighbor 192.168.30.3 remote-as 65501
 no auto-summary
!
ip classless
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 exec-timeout 0 0
 login
!
!
end
R2 
!
hostname r2
!
ip cef
!
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Ethernet0/0
 ip address 172.16.0.2 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 serial restart-delay 0
!
interface Serial2/0
 ip address 192.168.20.2 255.255.255.0
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 redistribute connected
 passive-interface Serial2/0
 network 10.2.2.2 0.0.0.0 area 0
 network 172.16.0.2 0.0.0.0 area 0
 network 192.168.1.2 0.0.0.0 area 0
 network 192.168.20.2 0.0.0.0 area 0
!
router bgp 65501
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65501
 neighbor 10.1.1.1 update-source Loopback0
 neighbor 10.3.3.3 remote-as 65501
 neighbor 10.3.3.3 update-source Loopback0
 neighbor 192.168.20.4 remote-as 65502
 no auto-summary
!
ip classless
!
!
line con 0
 exec-timeout 0 0
 transport preferred all
 transport output all
line aux 0
 transport preferred all
 transport output all
line vty 0 4
 exec-timeout 0 0
 login
 transport preferred all
 transport input all
 transport output all
!
end

関連するR1およびR3の設定では、R2と同じ設計を使用します。R1、R2、およびR3はループバックインターフェイスを介してiBGP到達可能性があり、IGPはBGPネクストホップへの到達可能性を提供します。R3には、R4とのeBGPセッションと、R1およびR2とのiBGPセッションがあります。

R1 は R2 とピア接続する iBGP と、R3 とピア接続する iBGP を持ちます。R4によってアドバタイズされた2つのネットワークについて、R1、R2、およびR3 BGPテーブルの内容を確認します。

r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 7
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal

r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.3.3.3 
  65502
    192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best

r3#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.2.2.2 
  65502
    192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.30.4 from 192.168.30.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best

r3#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.2.2.2 
  65502
    192.168.30.4 from 192.168.30.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal

r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  65502
    192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
  65502
    192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal

r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Not advertised to any peer
  65502
    192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

R2とR3の両方が、BGPベストパス選択アルゴリズムに基づいて予測される最適パスを外部ルートとしてR4から選択します。詳細については、BGP ベスト パス選択アルゴリズムを参照してください。

同様に、前述のBGPの最適パス属性が一致し、最も低いBGPルータIDがタイブレーカとして使用されるため、R1は2つのネットワークへのアクセスにR2を選択します。R2のルータIDは10.2.2.2で、R3のルータIDは10.3.3.3です。R2のルータIDは10.2.2.2で、R3のルータIDは10.3.3.3であるため、R2が選択されます。この基本設定では、AS 65502内の2つのネットワークへのすべてのトラフィックは、デフォルトでR1からR2を通過し、次にR4を通過します。ここで、R4がAS 65501から受信するトラフィックをロードバランスすると仮定します。 R4 ISPを変更せずにこれを行うには、MEDを使用して一方のネットワークのトラフィックを強制的に一方のパスでダウンさせ、他方のネットワークのトラフィックをもう一方のパスでダウンさせるようにR4を設定します。

note-icon

注：説明したMEDの設定例では、真の等コストロードバランシングではなく、プレフィクスごとのトラフィックエンジニアリングが提供されることに注意してください。

必要な設定を適用した後のR4の設定を次に示します。

R4 
!
hostname r4
!
ip cef
!
!
!
interface Loopback10
 ip address 10.4.0.1 255.255.0.0
!
interface Loopback11
 ip address 10.5.0.1 255.255.0.0
!
interface Serial0/0
 ip address 192.168.20.4 255.255.255.0
!
interface Serial1/0
 ip address 192.168.30.4 255.255.255.0
!
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 10.4.0.0 mask 255.255.0.0
 network 10.5.0.0 mask 255.255.0.0
 neighbor 192.168.20.2 remote-as 65501
 neighbor 192.168.20.2 route-map setMED-R2 out
 neighbor 192.168.30.3 remote-as 65501
 neighbor 192.168.30.3 route-map setMED-R3 out
 no auto-summary
!
ip classless
no ip http server
!
!
access-list 1 permit 10.4.0.0 0.0.255.255
access-list 2 permit 10.5.0.0 0.0.255.255
!
route-map setMED-R3 permit 10
 match ip address 1
 set metric 200
!
route-map setMED-R3 permit 20
 match ip address 2
 set metric 100

!--- The route-map setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 
!--- network and a MED of 100 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R3. 

! 
route-map setMED-R2 
permit 10 match ip address 1 
set metric 100 
! 
route-map setMED-R2 permit 20 
match ip address 2 
set metric 200 

!--- The route-map setMED-R2 is applying a MED of 100 to the 10.4.0.0/16 
!--- network and a MED of 200 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R2.  
! 
! 
! 
line con 0 
exec-timeout 0 0 
line aux 0 
line vty 0 4 
exec-timeout 0 0 
login 
! 
! 
end
note-icon

注:この例では、10.4.0.0/16と10.5.0.0/16のみがアドバタイズされます。追加のプレフィックスが同じネイバーにアドバタイズされる場合、適切なアクセスリストまたはルートマップシーケンスに追加します。一致しないプレフィックスを、発信ルートマップによってフィルタリングされることなくアドバタイズする必要がある場合は、最終的な許可シーケンスを追加します。

注:発信ルートマップが適用されたら、clear ip bgp * soft outコマンドを実行して発信BGPアップデートを更新します。実稼働環境では、可能な場合、ネイバー固有のソフト発信クリアを使用します。たとえば、clear ip bgp 192.168.20.2 soft outおよびclear ip bgp 192.168.30.3 soft outを使用します。

MEDが適用されると、R2はR2からR4へのパス/リンクを10.4.0.0/16に対する最適パスとして選択し、R3はR3からR4へのパス/リンクを10.5.0.0/16に対する最適パスとして選択します。図に示す収束した状態では、R1は各プレフィックスの適格な最適なiBGPアドバタイズメントを受信し、10.4.0.0/16にR2、10.5.0.0/16にR3を使用します。

r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
  Not advertised to any peer
  65502
    192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best

r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
  Not advertised to any peer
  65502
    192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best

R2の表示については、次の例を参照してください。

r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 100, localpref 100, valid, external, best


r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.20.4 
  65502
    192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

R3がR2経由のiBGPを通じて学習したパスを最適パスとして選択した後、R3はR4で学習したパスをアドバタイズしなくなったため、R2は10.4.0.0/16の1つのパスを示しています。R3は、R2を使用して10.4.0.0/16にアクセスしていることに気付くと、10.4.0.0/16のアップデートを取り消します（BGPルート取り消しを送信します。このアップデートには到達不能メトリックが含まれています）。標準のiBGPアドバタイズメントルールにより、R3はiBGPを通じて学習されたパスをこのトポロジ内の別のiBGPピアにアドバタイズし直すことができません。

r3#show ip bgp 10.4.0.0
BGP routing table entry for 10.4.0.0/16, version 20
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.30.4 
  65502
    192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.30.4 from 192.168.30.4 (10.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

これにより、R2はこの不要な情報を保存する必要がないため、メモリを節約できます。R2とR4の間のBGPセッションに障害が発生した場合、R2は10.4.0.0/16に関する到達不能なアップデートをR3に送信します。この更新によって、10.4.0.0/16 に関する R3 ルートでの更新が R4 を経由して R3 から R2 へ送信されます。R2はR3経由でルーティングを開始できます。

MEDコマンド

確定MED比較を有効にするには、BGPルータコンフィギュレーションモードでbgp deterministic-medコマンドを設定します。 有効な場合、bgp deterministic-med コマンドは、比較前に同じASからのパスをグループ化することによって、MEDに基づくベストパスの決定から時間的依存関係を削除します。これにより、同じ自律システム(AS)から受信したすべてのルートで、正確なMEDの比較が行われます。

bgp deterministic-medコマンドを無効にすると、受信したルートの順序がMEDに基づくベストパスの決定に影響することがあります。これは、パスの長さが全く同じでありながら、MED が異なる複数の AS またはコンフェデレーション サブ AS から同じルートを受信するときに発生する可能性があります。

例

たとえば、次のルートについて考えます。

エントリ ASパス MED ローカル プリファレンス ASパスの長さ Origin

エントリ1

AS 65001

100

100

1

IGP

エントリ2

AS 65002

50

100

1

IGP

エントリ3

AS 65001

20

100

1

IGP

MEDがディセーブルの状態のBGPルータ

着荷注文1の例

BGPルートが受信された順序は次のとおりです（entry1はBGPテーブル内で最も古いエントリで、entry3は最新のエントリ）。

  1. エントリ1
  2. エントリ2
  3. エントリ3

最初は1つのルートだけが存在するため、entry1がベストパスになります。AS65002のentry2とAS65001のentry1を比較する場合、ルートがさまざまな隣接ASからのものであるため、MEDは無視されます。残りのすべてのアトリビュートが同じであるため、ルータは現在の最適パスentry1を維持します。

MED 20を持つAS65001からのentry3とMED 100を持つAS65001からのentry1を比較すると、両方のルートが同じ隣接ASから到達しているため、MEDが評価されます。20は100よりも小さいため、entry3が最終的なベストパスになります。

着荷オーダー2の例

ここで、同じルートが異なる順序で到着するとします。

  1. エントリ2
  2. エントリ3
  3. エントリ1

最初に、entry2がベストパスとして選択されます。AS65001のentry3とAS65002のentry2を比較する場合、ルートがさまざまな隣接ASからのものであるため、MEDは評価されません。残りのすべてのアトリビュートが等しいため、ルータは現在の最適パスentry2を維持します。

AS65001のentry1とAS65002のentry2を比較すると、ルートが異なる隣接ASから到達しているため、MEDは再度無視されます。その結果、ルータはentry2を最終的なベストパスとして保持します。

MEDが無効の場合、ルートの到着順序は比較シーケンスに影響します。 受信したルータはまったく同じ3つのルートですが、ルートが異なる順序で到着したため、異なるベストパスが選択されています。 これは、bgp deterministic-medコマンドが排除するように設計されている時間的依存関係です。

note-icon

注:BGPパス選択基準の詳細については、『BGPでベストパスを選択するアルゴリズム』を参照してください。

MEDがイネーブルの状態のBGPルータ

MEDがイネーブルになっていると、ルータはMEDに基づく決定を行う前に、まずネイバーASによってルートをグループ化します。この場合は、同じ AS のルートがグループ化され、各グループのベスト エントリが比較されます。この例では、AS 65001とAS 65002の2つのASがあります。

Group ASパス エントリ 選択したルート 原因

group 1

AS 65001

entry1(MED 100)、entry3(MED 20)

エントリ3

下位MED(20 < 100)

group 2

AS 65002

entry2(MED 50)

エントリ2

唯一の候補

グループ1では、MEDが低いため、ベストパスはentry3です（パスは同じASからのものであるため、この決定ではMEDが使用されます）。 グループ 2 では、エントリは 1 つのみ（entry2）です。 ベストパスは各グループの勝者の比較によって決定されますが、各グループの勝者は異なるASのものであるため、デフォルトではこの比較にMEDは使用されません。

この時点で、残りのルートが異なるネイバーASから発信されているため、MEDは考慮されなくなります。BGPベストパスアルゴリズムは、後続の属性（eBGPとiBGP、ネクストホップへのIGPメトリック、最も古いパス、ルータIDなど、属性の違いによって異なる）を引き続き使用します。

主な利点は、このプロセスが受信されたルートに依存しないことです。ルータがルートを次のように学習するかどうか。

  • entry1 → entry2 → entry3
  • entry2 → entry3 → entry1
  • entry3 → entry1 → entry2

その結果、着荷注文は、更新が受信された順序ではなくルート属性に基づいて決定されるため、同じ結果が生成されます。

note-icon

注：entry3（グループ1の勝者）とentry2（グループ2の勝者）を比較する際に、bgp always-compare-medも有効になっていた場合は、MEDが低いためentry 3が勝者になります。

note-icon

注:bgp deterministic-medコマンドをイネーブルにすると、同じAS内の異なるピアからアドバタイズされたルートを選択するときに、MED変数が比較されます。bgp always-compare-medコマンドをイネーブルにすると、異なるASのネイバーからのパスについて、MEDが比較されます。

この例では、優先順位のより高いBGPアトリビュート（Weight、Local Preference、AS Path length、Originなど）がすべて同一であることを前提としています。この目的は、MEDの影響を切り分け、bgp deterministic-medを無効にすることで、ルートの到着順序に応じてベストパスが決定される理由を説明することです。

新しいネットワークの導入の場合は、常にbgp always-compare-medを有効にすることを推奨します。また、bgp always-compare-med コマンドが有効になると、BGP MED の判断は常に確定的なものになります。

bgp deterministic-med コマンドと bgp always-compare-med コマンドの詳細については、bgp deterministic-med コマンドと bgp always-compare-med コマンドの違いを参照してください。

関連情報

更新履歴

改定 発行日 コメント
3.0
30-Jul-2026
タイトル、概要、スペル、文法を更新し、セクション/読みやすさを区切るために横線を挿入しました。
2.0
26-Jan-2024
SEOとフォーマットを更新。
1.0
10-Dec-2001
初版
TAC Authored

シスコ エンジニア提供

  • Cisco TACエンジニア

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ