EIGRPのメトリックについてまとめています。
ルーティングプロトコルによってメトリックに採用するものは異なります。
例えば、RIPは経由したルーターの数(ホップ数)、OSPFはインタフェースのコストの累積値を使用しますが、EIGRPは複数のメトリック(帯域幅、遅延、負荷、信頼性)をもとに複合メトリック値を算出し使用します。
EIGRP メトリックWeightの公式(Classicモード)
EIGRPの複合メトリック値を算出する公式を下記に示します。
うっ・・・見てもよく分かりませんね。。。
デフォルト設定ではK1とK3のみが１で、他のK2,K4,K5は０なので下記の式になります。
※Delayの算出方法：累積Delay(μsec単位)/10
※ちなみに、K5が０だったら、式全体が０になっちゃうと思うのですが、RFCに下記の記述があります。
If K5 is equal to 0, then reliability quotient is defined to be 1.
「K5が０のときは、[K5/(信頼性 + K4)]は１として扱う」
(https://tools.ietf.org/html/rfc7868#section-5.5.3)
EIGRP メトリックWeightの公式(Namedモード)
EIGRPにはClassicモードとNamedモードがありますが、上記はClassicモードの公式です。Namedモードでは下記の公式になります。
うー・・・さっきのClassicモードの公式よりも複雑になった気が・・・K6ってなんだ!?。。。しかもスループットとかLatencyとか単語が微妙に変わっているし。。。
デフォルト設定ではK1とK3のみが１で、他のK2,K4,K5,K6は０なので下記の式になります。
※Latencyの算出方法：65536*累積Delay(picosec単位)/10^6
※65536はWide-Scale定数
詳細は下記RFCをご参照ください。
5.6.2.2. Wide Metric Conversion Constants
(https://tools.ietf.org/html/rfc7868#section-5.6.2.2)
5.6.2.3. Throughput Calculation
(https://tools.ietf.org/html/rfc7868#section-5.6.2.3)
5.6.2.4. Latency Calculation
(https://tools.ietf.org/html/rfc7868#section-5.6.2.4)
EIGRP メトリックWeight検証構成(Classicモード)
EIGRP メトリックWeightの検証構成を以下に示します。現状、すべてのルータのインタフェースにてEIGRPが動作しています。
EIGRPメトリック検証環境
各ルータのメトリックWeightは「show ip protocolコマンド」で確認することができます。
*** IP Routing is NSF aware ***
Routing Protocol is “eigrp 100”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
※現在はデフォルト設定なのでK1とK3のみが１の設定です。
R3からみて10.10.10.10/32のメトリックはいくつになるか計算してみます。R3からR1の10.10.10.10/32までの経路上で最小帯域幅はR1(Gi0/0)-R2(Gi0/0)間の100Mbpsです。Delay累積値は、R1(Lo0)の5000μsec、R2(Gi0/0)の100μsec、R3(Gi0/0)の10μsecを足し合わせて5110μsecです。では、これらの値を公式に代入する値に修正します。帯域幅は10^7をKbpsの最小単位帯域幅で割り、Delayは10μsec単位に合わせます。よって、帯域幅は10^7/100000(Kbps)=100、Delayは5110/10=511です。
R3ルーティングテーブル(10.10.10.10/32)
実際のR3の複合メトリックと一致していることが分かります。
EIGRP メトリックWeight検証構成(Namedモード)
それでは次に同様のことをNamedモードで行ってみましょう。
EIGRPメトリック検証環境(Namedモード)
各ルータのメトリックWeightは「show ip protocolsコマンド」で確認することができます。
*** IP Routing is NSF aware ***
Routing Protocol is “eigrp 100”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(A) Address-Family Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
※現在はデフォルト設定なのでK1とK3のみが１の設定です。
また、各ルータインタフェースのDelay値(picosec単位)は「show ip eigrp topologyコマンド」で確認することができます。
Total delay is 1250000 picoseconds
R3からみて10.10.10.10/32のメトリックはいくつになるか計算してみます。R3からR1の10.10.10.10/32までの経路上で最小帯域幅はR1(Gi0/0)-R2(Gi0/0)間の100Mbpsです。累積Delay値は、R1(Lo0)の1250000picosec、R2(Gi0/0)の100000000picosec、R3(Gi0/0)の10000000picosecを足し合わせて111250000picosecです。では、これらの値を公式に代入する値に修正します。スループットは65536を10^7を最小単位帯域幅(Kbps)で割った値に掛けます。Latencyは65536をpicosec単位のDelayを10^6で割った値に掛けます。よって、スループットは65536*10^7/100000(Kbps)=6553600、Latencyは65536*111250000(picosec)/10^6=7290880です。
=6553600 +7290880=13844480
R3ルーティングテーブル(10.10.10.10/32)(Namedモード)
実際のR3の複合メトリックと一致していることが分かります。ちなみに、複合メトリック値とルーティングテーブルのメトリック値が異なっていることが分かります。これはEIGRP Namedモードでは64ビットのメトリックを使用するのに対して、ルーティングテーブル(RIB)のメトリックは32ビットを使用しているためです。つまり、64ビットのメトリック値を32ビットに置き換えています。metric rib-scaleコマンドを使用することで置き換えることができます。デフォルトは128なので、13844480/128=108160となります。
<1-255> Rib scale
Metric rib-scale 200
R3ルーティングテーブル(10.10.10.10/32)(Namedモード・RIBスケール200)
RIBスケール値をデフォルトは128から200へ変更したので、13844480/200=69222.4→69222となります。
EIGRP メトリックWeightとネイバー形成
EIGRPでネイバーを形成する際、双方のEIGRPルータはメトリックWeightが一致していなければなりません。一致していなければ、下記のようなメッセージが表示されてネイバーを構成することができません。というか、まずK値なんていじらないから、実務ではあまり起こらないだろうな。。。ちなみに、一致するまでコンソールにログメッセージが出力されつづけるので嫌でも気付きます。
<0-8> Type Of Address (Only TOS 0 supported)
<0-255> K1
<0-255> K2
<0-255> K3
<0-255> K4
<0-255> K5
<0-255> K6
参考文献
RFC
5.5.3. Coefficients K4 and K5
5.6.2.2. Wide Metric Conversion Constants
5.6.2.3. Throughput Calculation
5.6.2.4. Latency Calculation
コメントを残す