高いメトリックから低いメトリックへのEIGRPの操作

はじめに

このドキュメントでは、Enhanced Interior Gateway Routing Protocol(EIGRP)のルートメトリック操作の問題について説明します。この操作では、既知のEIGRPの動作が原因で、変更されたメトリックが有効になりません。

バックグラウンド

この問題は、Intelligent WAN(IWAN)の導入の1つで発生しました。IWANの導入では、ネットワークオペレータがブランチルータでEIGRP遅延メトリックを使用してトラフィックパスのプリファレンスに影響を与えようとしました。パスプリファレンスは、EIGRP設定の下の配布リストと遅延メトリックの調整の影響を受けました。図1に示すトポロジを確認します。

図1:IWANトポロジ

このトポロジでは、ネットワークオペレータは両方のデータセンターのすべてのブランチルータで配布リストを使用したルート操作を実行して、特定のリンクを優先パスとして使用するプレフィクスを優先しようとします。たとえば、DC2のプレフィックス10.2.0.0/16は、この優先順位シーケンスのスポークルータの優先ルートです：DC2-BR2、DC2-BR1、DC1-BR2、DC1-BR1。つまり、たとえばSpoke-1などのスポークルータのトラフィックを送信するパスプリファレンスは、最初にDC2-BR2ルータに向け、次にDC2-BR1ルータ、次にDC1-BR2に向け、最後にDC1-BR1ルータに向かいます。ネットワークオペレータは、DC1-SW1ノードのDCIインターフェイスにもEIGRP遅延を設定しています。

DC1-BR1ルータからのEIGRPメトリック操作の設定例を次に示します。

! Configuration from DC1-BR1 router
router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 100
 !
 af-interface default
 passive-interface
 exit-af-interface
 !
 af-interface Tunnel100
 summary-address 10.0.0.0 255.0.0.0
 summary-address 10.2.0.0 255.255.0.0
 no passive-interface
 no split-horizon
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/1
 no passive-interface
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/3
 no passive-interface
 exit-af-interface
 !
 topology base
 distribute-list route-map set-metric-Gig out GigabitEthernet0/0/1
 distribute-list route-map set-metric-tag-all out Tunnel100
 exit-af-topology
 network 10.1.2.0 0.0.0.255
 network 10.1.10.0 0.0.0.3
 network 10.1.123.0 0.0.3.255
 eigrp router-id 10.1.0.11
 exit-address-family 
!
route-map set-tag-all deny 10
 match tag 102 201 202
!
route-map set-tag-all permit 100
 match ip address prefix-list set-spoke-delay-4000
 set metric 100000 4000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 300
 match ip address prefix-list set-spoke-delay-1000
 set metric 100000 1000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 400
 match ip address prefix-list set-spoke-delay-2000
 set metric 100000 2000 255 1 1500
 set tag 101
 
!
ip prefix-list set-spoke-delay-4000 seq 100 permit 10.2.0.0/16
. . . 
! 

Tunnel100は、INETリンクを介したスポークルータへのダイナミックマルチポイントVPN(DMVPN)トンネルです。上記の設定では、プレフィクス10.2.0.0/16は遅延4000で設定されています。同様に、DC2-BR2、DC2-BR1、およびDC1-BR2の各ノードで、同じプレフィクスに対して遅延をそれぞれ1000、2000、および3000に設定して、優先順位を設定します。この例では例示目的でDMVPNトンネルを使用していますが、この問題はインターフェイスに依存しません。

問題

この問題はスポークルータで実際に発生し、DC2ブランチルータから受信したプレフィクス10.2.0.0/16のメトリックは異なりますが、DC1ブランチルータから受信したメトリックは同じです。スポークルータからの次の出力は、この動作を示しています。

Spoke-1# show ip eigrp topology 10.2.0.0/16 | in delay
        Total delay is 60000000000 picoseconds  (from DC 2 BR2)
        Total delay is 100020000000 picoseconds  (From DC 1 BR1)
        Total delay is 70000000000 picoseconds  (From DC 2 BR1)
        Total delay is 100020000000 picoseconds  (From DC 1 BR2)

この動作により、DC1-BR1ルータとDC1-BR2ルータから受信したパスに対して、優先順位が順番に与えられなくなります。

解決方法

この問題の主な原因は、ネットワークオペレータが、受信した値よりも低い絶対値（低いメトリック）にメトリックを設定しようとしたことです。これは、 show ip eigrp events コマンドをDC1ブランチルータで発行します。この出力は、ルートマップがメトリックを操作して、プレフィクスに実際に存在する値よりも低い値にしようとしていることを示しています。

DC1-BR1# show ip eigrp events
. . .
06:47:11.891 Can't reduce rtmap metric, old/new: metric(2950430720) metric(1972633600)
. . .

どのルーティングプロトコルでも、メトリックを減らすことはできません。これは、負のコストを持つインターフェイスがあることを意味します。これにより、ループ防止条件が無効になり、ネットワーク内で不整合が発生する可能性があります。この問題に対する解決策は、次の2つの方法で実行できます。

• 受信したプレフィックスのパスの遅延値を減らします。以前のケースでは、DCIインターフェイスのEIGRP遅延値を減らすことで、問題を軽減できました。
• メトリック操作を実行する場合は、より高い絶対メトリックを設定します。