EIGRPのPoisonedフローティングサマリールートについてまとめています。
これはEIGRPフローティングサマリールートの話の続きですね。EIGRPフローティングサマリールートでは、スタティックルートを設定することでNull0宛てのルートがルーティングテーブルにインストールされることを防いだわけですが、今回は集約時に自動で作成されるNull0宛てのルートのAD値を変更することでルーティングテーブルへのインストールを防ぎます。
Poisonedとはよく言ったものですねー
EIGRP Poisonedフローティングサマリールート検証構成
EIGRP Poisonedフローティングサマリールートの検証構成を以下に示します。(EIGRPフローティングサマリールートの検証構成と同一です。)
現状、すべてのルータのインタフェースにてEIGRPが動作しています。R1のGi0/0にてルート集約を行い、デフォルトルート(0.0.0.0/0)を広報しています。各ルータのルーティングテーブルは下記のようになります。
R1ではルート集約を行っているので、自身のルーティングテーブルにはNull0宛てのデフォルトルートが現れます。集約して出来たデフォルトルートはR2、R3へ広報されて、各ルータのルーティングテーブルに表示されます。R3から疎通テストをしてみると、下記のようにインターネットや端末には問題なく疎通できることが確認できます。
EIGRPルート手動集約の設定
R3のルーティングテーブルをよりシンプルにするために、R2にて集約をしてみます。
設定コマンドはこちら。
ここでは集約してデフォルトルートを広報してみようと思いますので、下記コマンドになります。
(config-if)# ip summary-address eigrp 100 0.0.0.0 0.0.0.0
この設定を行うことで、R3のルーティングテーブルはデフォルトルートが1つというかなりシンプルな表示になります。
R2では、集約を行ったことでルーティングテーブルにNull0宛てのデフォルトルートが自動的に設定されます。しかも、このデフォルトルートはAD=5で設定されるので、今までR1から学習していたAD=90のデフォルトルートを上書くことになります。
R2ではNull0宛てのデフォルトルートが、今までR1から学習していたデフォルトルートを上書きました。これによって、疎通にどのような影響があるかR3から確認してみましょう。
なんと、R3からインターネットへの疎通が出来なくなっています!!
(ping結果が「U」は「host unreachable」の意味です。)
これはR2がNull0宛てのデフォルトルートを持ったことで、R2に直接接続されているネットワーク以外に疎通が出来なくなったからです。(R2の直接接続ネットワーク以外へのパケットはNull0宛てに転送(ドロップ)されてしまいます。。)
EIGRP Poisonedフローティングサマリールートの設定と確認方法
この状況を改善させるには、以下の2つの手法があります。
・R2で集約した際に自動設定された集約ルートのADを255に上げて、ルーティングテーブルに登録させない(Poisoned)
今回は自動設定された集約ルートのADを255に上げて、ルーティングテーブルに登録させないやり方を試してみたいと思います。
ADが5より小さい(AD=1 – 4)集約ルートを新たにルーティングテーブルに追加するやり方はこちら↓
使用するコマンドは、summary-metricコマンドです。ADは90より大きければ良いのですが、今回は255で設定してます。
R2へsummary-metricコマンドの設定が完了したので、R2のルーティングテーブルを確認してみます。
集約ルートのAD値を255に変更したことで、Null0宛てのデフォルトルートがルーティングテーブルに登録されなくなりました。その結果、R1が広報したデフォルトルートが登録されています。それでは、再度R3から疎通確認をしてみましょう。
先ほど、疎通できなかったインターネットにも疎通ができています。ルーティングテーブルも先ほどと変わらずに、デフォルトルート1本とシンプルな構成です。
コメントを残す