EIGRP メトリックを使用したトラフィックエンジニアリング

EIGRPのトラフィックエンジニアリングについてまとめています。
トラフィックエンジニアリングとは、パケットの転送を制御するの意味です。EIGRPのトラフィックエンジニアリングは、基本的にインタフェースのDelay値を使用して制御することが多いですね。帯域幅を変えると、メトリック計算全体に影響が出てしまいますからね。

EIGRP トラフィックエンジニアリング検証構成

EIGRP トラフィックエンジニアリングの検証構成を以下に示します。現状、すべてのルータのインタフェースにてEIGRPが動作しています。

EIGRPトラフィックエンジニアリング検証環境

R2のルーティングテーブルを確認してみると、R3とR4から100.100.100.0/24のルート情報を等コストで学習していることが分かります。
ちなみに、メトリック計算式は以下の通りです。
256*[10^7/1000000(Kbps) + (10 +10(μsec))/10] =256*(10 + 2)=256*12=3072

R2ルーティングテーブル

EIGRP インタフェースDelay値の変更

それでは、R1から100.100.100.100へアクセスする際、R3のみを通過するようにR2のDelay値を変更してみましょう。方法としては２種類があります。R2のGi1/0のDelayを下げることでGi1/0のインタフェースを優先して通るようにする、もう１つはR2のGi2/0のDelay値を上げることでGi2/0のインタフェースを通らないようにする(結果、Gi1/0のインタフェースを通るようになる。)
今回はR2のGi2/0のインタフェースを20μsecへ上げることで、R3を通過する設定を作ってみます。
使用するコマンドは「Delayコマンド」です。

EIGRPトラフィックエンジニアリング検証環境(R2 Gi2/0変更後)

EIGRP トラフィックエンジニアリングの設定確認

EIGRPインタフェースのDelay値を変更したので、実際にR3経由で通信しているか確認してみましょう。まずはR2のルーティングテーブルの確認です。確かにR4経由のルートはメトリックが加算されて、ルーティングテーブルにはR3経由のルートのみが格納されていますね。
ちなみに、R4経由のメトリック計算式は以下の通りです。
256*[10^7/1000000(Kbps) + (20 +10(μsec))/10] =256*(10 + 3)=256*13=3328

R2ルーティングテーブル(Delay変更後)

それではR1からTracerouteを実行してみます。

R1からのTraceroute

R4を経由せず、R3を経由して100.100.100.100に到達していることが確認できました。

参考文献

CCO
EIGRP Wide Metrics