IP : IP ルーティング

Cisco ルータにおけるルートの選択

2010 年 10 月 6 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 1 月 2 日) | フィードバック

概要

特にルーティングを新しく学ぶ人が Cisco ルータに寄せる関心の 1 つに、ルーティング プロトコル、手動設定、およびその他のさまざまな手段によって提供されたルートからルータが最適なルートをどのように選択するのか、ということがあります。ルートの選択は、想像されるよりもずっとシンプルですが、それを理解するためには、Cisco ルータの動作のしくみについて若干の知識が必要になります。



前提条件

要件

このドキュメントに関する特別な要件はありません。



使用するコンポーネント

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



表記法

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



関与するプロセス

Cisco ルータでのルーティング テーブルの作成と維持には次の 3 つのプロセスが関与します。

  • 実際にネットワーク(またはルーティング)プロトコルを実行する Enhanced Interior Gateway Routing Protocol (EIGRP)、Border Gateway Protocol (BGP)、Itermediate System-to-Intermediate System (IS-IS)、および Open Shortest Path First (OSPF) などの各種ルーティング プロセス

  • ルーティング プロセスから情報を受け取り、転送プロセスからの情報要求にも応答するルーティング テーブル

  • ルーティング テーブルから情報を要求し、パケット転送に関する決定を行う転送プロセス

ルーティング テーブルの作成方法を理解するため、ルーティング プロトコルとルーティング テーブル間のやり取りについて詳しく見てみましょう。



ルーティング テーブルの作成

ルーティング テーブルの作成中の主な考慮点は次のとおりです。

  • アドミニストレーティブ ディスタンス:これは、ルートのソースの信頼性を示す尺度です。複数のルーティング プロトコルからルータが宛先を認識する場合に、アドミニストレーティブ ディスタンスが比較され、アドミニストレーティブ ディスタンスが短い方のルートが優先されます。言い換えると、これはルートのソースの信用度です。

  • メトリック:同じ宛先に対して複数のパスが認識される場合、指定された宛先への最適なパスを計算するためにルーティング プロトコルによって使用される尺度です。それぞれのルーティング プロトコルは異なるメトリックを使用します。

  • プレフィクス長

各ルーティング プロセスは、更新とその他の情報を受け取るため、指定された宛先への最適なパスを選択して、このパスをルーティング テーブルに格納しようとします。たとえば、EIGRP が 10.1.1.0/24 へのパスを認識し、この特定のパスがこの宛先への最適な EIGRP パスであると判断すると、EIGRP は認識したパスをルーティング テーブルに格納しようとします。

ルータは、ルーティング プロセスから提供されたルートを格納するかどうかを、処理対象のルートのアドミニストレーティブ ディスタンスに基づいて決定します。このパスがこの宛先に対して(テーブル内の他のルートと比較して)最小のアドミニストレーティブ ディスタンスであれば、ルーティング テーブルに格納されます。このルートが、最適なアドミニストレーティブ ディスタンスのルートでなければ、そのルートは拒否されます。

理解を深めるため、例を見てみましょう。ルータで 4 つのルーティング プロセス EIGRP、OSPF、RIP、および IGRP が実行中であるとします。ここで、これら 4 つのプロセスすべてが 192.168.24.0/24 ネットワークへのさまざまなルートを認識し、それぞれが内部のメトリックとプロセスによって、そのネットワークへの最適なパスを選択したとします。

これら 4つの各プロセスは、192.168.24.0/24 へのルートをルーティング テーブルに格納しようとします。ルーティング プロセスは、それぞれアドミニストレーティブ ディスタンスが割り当てられており、これを使用してどのルートを格納するかが決定されます。

デフォルトのアドミニストレーティブ ディスタンス

接続済み

0

スタティック

1

eBGP

20

EIGRP(内部)

90

IGRP

100

OSPF

110

IS-IS

115

RIP

120

EIGRP(外部)

170

iBGP

200

EIGRP サマリー ルート

5

内部の EIGRP ルートのアドミニストレーティブ ディスタンスが最適なので(アドミニストレーティブ ディスタンスが小さいほど、優先度は高くなります)、そのルートがルーティング テーブルに格納されます。



バックアップ ルート

RIP、IGRP、OSPF などの他のプロトコルは、格納されなかったルートをどのように処理するのでしょうか。EIGRP から認識された最も優先度の高いルートが失敗した場合はどうなるでしょうか。Cisco IOS® Software では、この問題を解決するために 2 つのアプローチが使用されます。1 つは、各ルーティング プロセスにおいて最適なルートを定期的に格納しようとする方法です。最も優先度の高いルートが失敗したら、(アドミニストレーティブ ディスタンスに従って)次善のルートが次の試行に続きます。もう 1 つの解決策は、最適なパスが失敗した場合、失敗したルーティング プロトコルのテーブルにそのルートを格納して保持し、さらに失敗を報告するようルーティング テーブル プロセスに指示する方法です

IGPR のように固有のルーティング情報テーブルを持たないプロトコルに対しては、1 番目の方法が使用されます。IGRP はルートについての更新を受け取るたびに、ルーティング テーブルに更新された情報を格納しようとします。これと同じ宛先へのルートがルーティング テーブルにすでにある場合は、格納の試行は失敗します。

EIGRP、IS-IS、OSPF、BGP、RIP などのように、ルーティング情報の独自のデータベースを持つプロトコルについては、ルートを格納する最初の試行が失敗すると、バックアップ ルートが登録されます。ルーティング テーブルに格納されたルートがなんらかの理由で失敗すると、ルーティング テーブルの更新プロセスがバックアップ ルートを登録した各ルーティング プロトコル プロセスを呼び出し、ルーティング テーブルにルートを再格納するように依頼します。登録されたバックアップ ルートにより複数のプロトコルがある場合は、アドミニストレーティブ ディスタンスに基づいて、優先されたルートが選択されます。



アドミニストレーティブ ディスタンスの調整

デフォルトのアドミニストレーティブ ディスタンスは、ネットワークにとって必ずしも適切とは限りません。たとえば、 RIP ルートが IGRP ルートに対して優先されるように調整したい場合があります。アドミニストレーティブ ディスタンスを調整する方法を説明する前に、アドミニストレーティブ ディスタンスの変更に伴う影響について理解する必要があります。

ルーティング プロトコルでアドミニストレーティブ ディスタンスを変更することは、大きな危険を伴う可能性があります。デフォルトのディスタンスを変更することによって、ルーティング ループやネットワーク内のその他の異常の原因になることがあります。アドミニストレーティブ ディスタンスの変更には十分な注意を払い、どうしても必要であると判断した場合にのみ、変更に伴うあらゆる事態について十分理解したうえで行うことをお勧めします。

プロトコルに全体に対しては、ディスタンスの変更は比較的容易です。ルーティング プロセスのサブ設定モードで distance コマンドを使用することで簡単にディスタンスを設定します。一部のプロトコルに限り、1 つの発信元のみから認識されたルートのディスタンスを変更することもできます。また、一部のルートだけのディスタンスを変更することができます。

スタティック ルートについては、ip route コマンドの後にディスタンスを入力することにより、各ルートのディスタンスを変更することができます。

ip route network subnet mask next hop distance

すべてのスタティックなルートのアドミニストレーティブ ディスタンスを一度に変更することはできません。



メトリックによるルート選択プロセスの決定

ルートは、ルーティング プロトコルのアドミニストレーティブ ディスタンスに基づいてルーティング テーブル内に選択および作成されます。ルーティング プロトコルから認識されたアドミニストレーティブ ディスタンスが最小のルートが、ルーティング テーブルに格納されます。単一のルーティング プロトコルから同じ宛先へのパスが複数ある場合、複数のパスは同じアドミニストレーティブ ディスタンスを持つため、最適なパスはメトリックに基づいて選択されます。メトリックは、特定のルートに関連付けられた値で、優先度が最も高いものから低いものまで順位を付けます。メトリックを決定するために使用されるパラメータは、ルーティング プロトコルによって異なります。最小のメトリックのパスが最適なパスとして選択され、ルーティング テーブルに格納されます。同じ宛先に同じメトリックのパスが複数ある場合は、これらの同等のコストパスに基づいてロード バランシングが行われます。ロード バランシングに関する詳細は、「ロード バランシングの機能のしくみ」を参照してください。



プレフィクス長

一般に発生するもう 1 つの状況として、プレフィクス長の相違がありますが、ルータがこれをどのように処理するかを理解するため、別のシナリオを見てみましょう。ここでもまた、ルータで 4 つのルーティング プロセスが実行されていて、各プロセスが次のルートを受信したとします。

  • EIGRP(内部): 192.168.32.0/26

  • RIP: 192.168.32.0/24

  • OSPF: 192.168.32.0/19

これらのルートのどれがルーティング テーブルに格納されるのでしょうか。EIGRP 内部ルートが最適のアドミニストレーティブ ディスタンスであるため、1 番目のルートが格納されると考えがちです。しかし、これらのルートはプレフィクス長(サブネット マスク)がそれぞれが異なるため、異なる宛先であると見なされ、これらすべてがルーティング テーブルに格納されます。

ルーティング テーブルからの情報を転送エンジンでどのように使用して転送に関する決定を行うのかを見てみましょう。



転送に関する決定

ルーティング テーブルに格納したばかりの 3 つのルートが、ルータ上でどのように表示されるかを確認してみましょう。

router# show ip route
     ....
     D   192.168.32.0/26 [90/25789217] via 10.1.1.1
     R   192.168.32.0/24 [120/4] via 10.1.1.2
     O   192.168.32.0/19 [110/229840] via 10.1.1.3
     ....

宛先が 192.168.32.1 のルータ インターフェイスにパケットが到達した場合、ルータはどのルートを選択するのでしょうか。それは、プレフィクス長、つまりサブネット マスクに設定されているビット数によって決まります。パケットの転送の際は、プレフィクスの長い方が短い方よりも常に優先されます。

この場合、192.168.32.1 宛てのパケットは 10.1.1.1 に向けて送られます。これは、192.168.32.1 が 192.168.32.0/26 ネットワークの範囲内(192.168.32.0〜192.168.32.63)に属するためです。このパケットは使用可能な他の 2 つのルートの範囲内にも属しますが、ルーティング テーブル内でプレフィクス長が最も長いのは 192.168.32.0/26 です(26 ビットに対して他は 24 ビットまたは 19 ビット)。

同様に、192.168.32.100 が宛先のパケットがルータのインターフェイスの 1 つに到達すると、192.168.32.100 が 192.168.32.0/26 の範囲内(192.168.32.0 〜192.168.32.63)ではなく 192.168.32.0/24 の宛先の範囲内(192.168.32.0 〜 192.168.32.255)に属するため、パケットは 10.1.1.2 に転送されます。ここでもまた、パケットは 192.168.32.0/19 の範囲内にも属していますが、プレフィクス長が長いのは 192.168.32.0/24 です。



IP クラスレス

ip classless 設定コマンドがルーティング プロセスおよび転送プロセスに含まれる場面ではしばしば煩雑さが伴います。実際には、IP クラスレスは IOS の転送プロセスの操作に対してだけ作用し、ルーティング テーブルの作成方法には作用しません。IP クラスレスが設定されていない(no ip classless コマンドを使用している)場合は、ルータはスーパーネットにパケットを転送することはありません。例として、再び 3 つのルートをルーティング テーブルに格納し、ルータを経由してパケットをルーティングしてみましょう。

注:スーパーネットまたはデフォルト ルートが IS-IS や OSPF により認識される場合は、no ip classless 設定コマンドは無視されます。この場合は、パケット交換の動作は、ip classless が設定されている場合と動揺に実行されます。

router# show ip route
....
     172.30.0.0/16 is variably  subnetted, 2 subnets, 2 masks
D        172.30.32.0/20 [90/4879540] via  10.1.1.2
D       172.30.32.0/24  [90/25789217] via 10.1.1.1
S*   0.0.0.0/0 [1/0] via 10.1.1.3  

172.30.32.0/24 ネットワークには、アドレス 172.30.32.0 から 172.30.32.255 まで、172.30.32.0/20 ネットワークには、アドレス 172.30.32.0 から 172.30.47.255 までが含まれています。このルーティング テーブルから 3 つのパケットを交換し、結果がどうなるかを確認してみましょう。

  • 宛先が 172.30.32.1 のパケットは、最長のプレフィクス照合であるため、10.1.1.1 に転送されます。

  • 宛先が 172.30.33.1 のパケットは、最長のプレフィクス照合であるため、10.1.1.2 に転送されます。

  • 宛先が 192.168.10.1 のパケットは 10.1.1.3 に転送されます。このネットワークはルーティング テーブルに存在しないため、このパケットはデフォルト ルートに転送されます。

  • 宛先が 172.30.254.1 のパケットは破棄されます。

これらの 4 つの中で驚くべき結果は、破棄されるという最後のパケットです。これは、宛先の 172.30.254.1 は既知の主要ネットワーク 172.30.0.0/16 の範囲内ですが、ルータが主要ネットワーク内の特定のサブネットを認識していないために破棄されます。

これが、クラスフル ルーティングの本質的な特性です。主要ネットワークの一部が認識されていても、パケットの宛先とされている主要ネットワーク内サブネットが未知であれば、パケットは破棄されます。

このルールの最も複雑な点は、宛先の主要ネットワークがルーティング テーブルにまったく存在しない場合、ルータがデフォルトのルートだけを使用するということです。

これにより、次の図のように、1 つの接続がネットワークの他の部分に戻ってくるリモート サイトがあり、そこでルーティング プロトコルがまったく実行されていないようなネットワークでは問題が生じる場合があります。

21a.gif

リモート サイトのルータは次のように設定されています。

interface Serial 0
     ip address 10.1.2.2 255.255.255.0
   !
   interface Ethernet 0
     ip address 10.1.1.1 255.255.255.0
   !
   ip route 0.0.0.0 0.0.0.0 10.1.2.1
   !
   no ip classless

この設定では、リモート サイトのホストからは(10.x.x.x クラウドを経由して)インターネット上の宛先に到達できますが、社内ネットワークの 10.x.x.x クラウド内の宛先には到達できません。なぜなら、リモート ルータは、10.0.0.0/8 ネットワークの一部と、直接接続している 2 つのサブネットを認識していますが、10.x.x.x の他のサブネットは認識していないため、これらの他のサブネットは存在しないと想定し、それらを宛先にするパケットはすべて廃棄されるためです。しかし、インターネット宛のトラフィックは、10.x.x.x のアドレス範囲内の宛先にはならないため、デフォルト ルートから正しくルーティングされます。

この問題を解決するには、リモート ルータで ip classless を設定します。これにより、ルータが自身のルーティング テーブルでクラスフルなネットワークの境界を無視でき、単純に最長プレフィクス照合のルートを検出してルーティングできるようになります。



要約

要約すると、転送に関する決定は、3 つのプロセス、ルーティング プロトコル、ルーティング テーブル、および転送に関する決定とパケットの交換を行う実際のプロセスのセットから構成されます。これら 3 つのプロセスのセットとそれらの関係を以下の図に示しています。

21b.gif

実際にルーティング テーブルに格納されているルートの中では、最長のプレフィクス照合を持つものが常に優先されます。一方、ルートがルーティング テーブルに格納されるときは、最小のアドミニストレーティブ ディスタンスのルーティング プロトコルが常に優先されます。



関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 8651