フレームリレー上でのルーティングプロトコル 【For CCNA】
目次
フレームリレー上でルーティングプロトコルを使うときの考慮事項
フレームリレーネットワーク上でルーティングプロトコルを利用する際に考慮すべきことが次の2つあります。
- ノンブロードキャストネットワークへのブロードキャスト/マルチキャストの転送
- ディスタンスベクタ型ルーティングプロトコルの利用におけるスプリットホライズンの問題点
この2点をきちんと考えておかないと、フレームリレー上でルーティングプロトコルを利用できません。この2点の詳細を解説します。
ノンブロードキャストネットワークへのブロードキャスト/マルチキャストの転送
まず、ノンブロードキャストネットワークへのブロードキャスト/マルチキャストの転送についてです。一般に、ルーティングプロトコルのパケットの送信先IPアドレスには、ブロードキャスト/マルチキャストアドレスが使われます。そのため、フレームリレーなどノンブロードキャストネットワーク上でルーティングプロトコルを利用するには、次のような注意が必要です。
- 擬似ブロードキャスト機能によってブロードキャスト/マルチキャストアドレスを送信先IPアドレスに持つパケットを転送できるようにします。これは、主にRIP/EIGRPを利用するときとマルチキャストルーティングを行うときに考慮します。
- フレームリレーネットワーク上ではルーティングプロトコルのパケットをユニキャストアドレスで転送するように追加の設定を行います。これは、主にOSPFを利用するときに考慮します。
ディスタンスベクタ型ルーティングプロトコルの利用におけるスプリットホライズンの問題点
次に、ディスタンスベクタ型ルーティングプロトコルの利用におけるスプリットホライズンの問題点です。ハブ&スポークトポロジで、RIP/EIGRPなどのディスタンスベクタ型ルーティングプロトコルを利用すると、スプリットホライズンのルールによってスポークルータにお互いのルート情報を伝えることができなくなってしまいます。
たとえば、次の図の例でルーティングプロトコルにRIPv2を利用していると考えます。R2は10.2.2.0/24というルート情報をフレームリレーネットワーク上に送信します。このルート情報は、R2－R3間にはPVCが設定されていないので流れていきません。R1にのみ伝わっていきます。R1は、このルート情報を受信すると自身のルーティングテーブルに追加します。R1からルート情報を送信するとき、スプリットホライズンによってSerial0から受信した10.2.2.0/24というルート情報を送信することができません。R1から送信されるルート情報は、10.1.1.0/24のみになってしまいます。
すると、R3では10.1.1.0/24のルート情報はルーティングテーブルに存在しますが、10.2.2.0/24のルート情報はルーティングテーブルに存在しません。結局、R3から10.2.2.0/24あてのパケットをルーティングすることができなくなります。
同じことが、R3の10.3.3.0/24のルート情報にもいえます。つまり、スポーク間のパケットをルーティングすることが不可能になります。
ディスタンスベクタ型ルーティングプロトコルを利用している場合のこのようなスプリットホライズンの問題を解決する方法として、次の3つが考えられます。
- フルメッシュ化する
- ハブルータでスプリットホライズンを無効にする
- ハブルータでサブインタフェースを作成し、論理的にインタフェースを分割する
フルメッシュ化すれば、R2－R3間で直接ルート情報を送受信することができるのでスプリットホライズンは問題になりません。ただし、フルメッシュ化するには追加のコストが必要です。
ハブルータでスプリットホライズンを無効にすれば、スポーク間でルート情報を伝えることができます。本来、スプリットホライズンはルーティングループを防止するために考えられています。それを無効にするため、潜在的なルーティングループ発生の可能性があることに注意しなければいけません。
サブインタフェースを作成して、論理的にインタフェースを分割すればスプリットホライズンは適用されません。スプリットホライズンはあくまでも同一インタフェースにおけるルート情報の送受信についてのみ考えているからです。
ただし、サブインタフェースを作成すれば、そのサブインタフェースごとにそれぞれIPアドレスを設定し、サブネット自体も分割することになり、ネットワーク構成が複雑化します。
