IP : IP ルーティング

ODR を使用した大規模スタブ ネットワークの設計

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

目次

概要
スタブ ネットワークとトランジット ネットワークの比較
ハブアンドスポーク ネットワークと ODR
1 つのの出口を持つスポーク
複数の出口を持つスポーク
     1 つのハブを使用したロード バランシングまたはバックアップ
     複数のハブを使用したロード バランシングまたはバックアップ
ODR と他のルーティング プロトコルの比較
ODR と EIGRP の比較
ODR と OSPF の比較
     OSPF ポイントツーポイント スタブ ネットワーク
     OSPF ポイントツーマルチポイント スタブ ネットワーク
ODR と RIPv2 の比較
     デマンド回線での RIPv2
ODR を使用した大規模ネットワークの設計
ハブ上で EIGRP が動作する ODR
     冗長性と集約
ハブ上で OSPF が動作する ODR
     冗長性と集約
ポイントツーポイント ネットワークを使用した ODR
ポイントツーマルチポイント ネットワークを使用した ODR
ODR と複数のベンダー
将来の成長に関する問題
パフォーマンス
コンバージェンスを高速化するためのタイマーの調整
     ハブ ルータ
     スポーク ルータ
ODR ルートのフィルタおよび集約
telco タイマーの調整
CPU パフォーマンス
機能拡張
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

On-Demand Routing(ODR)は、ブロードキャストまたは非ブロードキャスト メディア上の他の Cisco デバイスの検出に使用されるプロトコルであり、Cisco Discovery Protocol(CDP)の機能を拡張したものです。 CDP を使用すると、デバイス タイプ、IP アドレス、隣接 Cisco デバイスで実行されている Cisco IOS(R) のバージョン、隣接デバイスの機能などを検出できます。 Cisco IOS ソフトウェア リリース 11.2 において、CDP を介してスタブ ルータの接続 IP プレフィックスをアドバタイズするために、CDP に ODR が追加されました。 この機能は、各ネットワークまたはサブネット用に追加の 5 バイト、IP アドレス用に 4 バイト、および IP とともにサブネット マスクをアドバタイズするために 1 バイトを必要とします。 ODR は、Variable Length Subnet Mask(VLSM; 可変長サブネット マスク)情報を伝送できます。

ODR は、ルーティング プロトコルのアップデートにネットワーク帯域幅を使用したくないエンタープライズ リテール カスタマー向けに設計されています。 たとえば X.25 環境では、そのリンクでルーティング プロトコルを実行すると、多くの場合非常にコストが高くなります。 スタティック ルーティングは優れた選択肢ですが、スタティック ルートを手動で維持するとオーバーヘッドが大きくなりすぎます。 ODR は CPU に負荷をかけず、レイヤ 2 での IP ルートのダイナミックな伝搬に使用されます。

ODR はルーティング プロトコルではないため、設定時にはルーティング プロトコルとして扱わないでください。 ODR はレイヤ 2 で CDP を使用するため、さまざまな IP ルーティング プロトコル用の従来の設定は ODR では動作しません。 ODR を設定するには、ハブ ルータで router odr コマンドを使用します。 他の IP ルーティング プロトコルを併用した ODR の設計、実装、およびインタラクションは難しいものになる可能性があります。

LAN Emulation(LANE; LAN エミュレーション)を例外として、ODR は Cisco 700 シリーズ ルータや ATM リンクでは動作しません。

スタブ ネットワークとトランジット ネットワークの比較

ただ通過して行くだけの情報を通すことがないようなネットワークをスタブ ネットワークと呼びます。 ハブアンドスポーク トポロジは、スタブ ネットワークのよい例です。 多くのサイトがデータ センターに接続された大規模な組織では、このタイプのトポロジを使用します。

スポーク側では、Cisco 2500、1600、および 1000 シリーズ ルータなどのローエンド ルータが使用されます。 ある別のネットワークに到達するために情報がスポーク ルータを通過する場合、そのスタブ ルータはトランジット ルータになります。 このような設定になるのは、ハブ ルータに加えて別のルータにスポークが接続されている場合です。

共通の問題は、スポークが送信できる ODR アップデートの大きさです。 通常、複数のスポークが 1 つのハブにだけ接続されています。 スポークが他のルータに接続されている場合、それらはスタブではなくなり、トランジット ネットワークになります。 ローエンド ボックスには通常 1 つまたは 2 つの LAN インターフェイスがあります。 たとえば、Cisco 2500 は 2 つの LAN インターフェイスをサポートできます。 通常の状態では、(スポーク側に 2 つの LAN がある場合)CDP の一部として 10 バイトのパケットが送信されます。 CDP はデフォルトで有効になっているため、余分なオーバーヘッドの問題は生じません。 サイズの大きい ODR アップデートが存在する状況は発生しません。 真のハブアンドスポーク環境では ODR アップデートのサイズは問題ではありません。

ハブアンドスポーク ネットワークと ODR

ハブアンドスポーク ネットワークは、ハブ(ハイエンド ルータ)が多数のスポーク(ローエンド ルータ)にサービスを提供する典型的なネットワークです。 特別な場合では、冗長性を確保するため、または独立したハブを介して追加のスポークをサポートするために、複数のハブが存在する場合があります。 このような状態では、両方のハブで ODR を有効にします。 また、2 つのハブの間で ODR ルーティング情報を交換するために、ルーティング プロトコルも必要になります。

図 1: ハブアンドスポーク トポロジ

odrhs.jpg

1 つの出口を持つスポーク

上記の図 1 では、複数のスポークが 1 箇所のハブに接続されており、このため、ハブのすべてのルーティング情報を 1 つの出口で受信する代わりに、スポークはデフォルト ゲートウェイに依存できるようになっています。 スポークでは高度なルーティングの決定を行う必要がないので、すべての情報をスポークに渡す必要はありません。 スポークは常にトラフィックをハブに送信するので、スポークで必要なのはハブに向かうデフォルト ルートだけです。

スポークのサブネット情報がハブに送信されるための手段が必要です。 Cisco IOS 11.2 よりも前では、これを実現するには、スポークでルーティング プロトコルを有効にするしかありませんでした。 しかし、ODR を使用すると、スポーク側でルーティング プロトコルを有効にする必要はありません。 ODR では、スポーク側では Cisco IOS 11.2 と、ハブに向かうスタティックなデフォルト ルートだけが必要になります。

複数の出口を持つスポーク

一次リンクに障害が発生した場合の冗長性やバックアップの目的のため、スポークにはハブへの複数の接続が存在する場合があります。 多くの場合、この冗長性のためには独立したハブが必要になります。 このような状態では、スポークには複数の出口があります。 このネットワークでも、ODR は正しく動作します。

スポークはポイントツーポイントである必要があります。それ以外の場合、デフォルトのフローティング スタティック ルートは機能しません。 マルチポイント設定では、ブロードキャスト メディアでのように、ネクストホップの障害を検出する手段がありません。

1 つのハブを使用したロード バランシングまたはバックアップ

ロード バランシングを実現するには、距離が等しいスポークで 2 つのスタティックなデフォルト ルートを定義します。これにより、スポークはこれら 2 つのパスの間でロード バランシングを行います。 宛先へのパスが 2 つ存在する場合、ODR はルーティング テーブルで両方のルートを保持し、ハブ上でロード バランシングを行います。

バックアップのために、2 つのスタティック デフォルト ルートを定義し、距離において、1 つのルートがもう一方のルートよりも優先されるようにします。 スポークは一次リンクを使用し、一次リンクがダウンした場合もフローティング スタティック ルートは機能します。 ハブ ルータでは、各 CDP 隣接ルータのアドレスに対して distance コマンドを使用し、ある距離をもう一方の距離よりも優先させます。 この設定により、あるリンクを介して学習された ODR ルートは、もう一方のルートよりも優先されます。 この設定は、高速の一次リンクと低速(低帯域幅)のバックアップ リンクが存在し、ロード バランシングが望ましくないような環境では便利です。

注: 現在、上記の手段を除き、ハブが 1 つの状況では、スポーク側ではあるリンクをもう一方のリンクより優先させる方式はありません。 IOS 12.0.5T 以降を使用している場合、ハブは自動的に両方のリンクを介してデフォルト ルートを送信します。すると、スポークは 2 つのパスを区別できず、またそのルーティング テーブルに両方をインストールしてしまいます。 あるデフォルト ルートをもう一方よりも優先させるには、優先させる対象であるより低い管理距離で、パスを持つスポーク上でスタティックなデフォルト ルートを使用する方法しかありません。 これにより、ODR を介してスポークに着信するデフォルト ルートが自動的にオーバーライドされます。 スポークが 1 つのリンクをもう一方のリンクよりも優先できるようなノブをスポークに提供するというアイデアは、現時点では検討中です。

図 2: 複数の出口と 1 つのハブがあるスポーク

odr3.jpg

複数のハブを使用したロード バランシングまたはバックアップ

これらの設定は、複数のハブが存在する場合、ロード バランシングやバックアップにも使用できます。 スポークからのリンクの 1 つに障害が発生した場合でも別のハブを介して宛先に到達できるように、すべてのハブはフルメッシュである必要があります。 詳細については、この文書の「ODR と他のルーティング プロトコルの比較」の項を参照してください。 同様に、複数のハブが存在するケースでは、IOS 12.0.5T 以降が使用されている場合、複数のハブが ODR のデフォルト ルートをスポークに送信し、スポークはルーティング テーブルに両方のハブによるルートをインストールします。 将来の機能拡張では、スポークで 1 つのハブをもう一方のハブよりも優先させることができるようになります。 現時点では、スポークのルータで定義されているスタティックなデフォルト ルートを介して、static route コマンドで管理距離を使用することで、1 つのハブをもう一方のハブよりも優先させることができます。 これはロード バランシングの状態には影響しません。

図 3: 複数の出口と複数のハブがあるスポーク

odr4.jpg

ODR と他のルーティング プロトコルの比較

IP ルーティングに対する ODR の最大の利点は、レイヤ 3 でルーティング プロトコルを有効にすることなく、ハブ ルータが IP プレフィックスを学習する点です。 ODR アップデートは、レイヤ 2 上の CDP の一部です。

ODR と EIGRP の比較

真のハブアンドスポーク環境では、すべてのスポークにすべてのルーティング情報を渡す必要はありません。 低速リンクのスポークは、ルーティング アップデートと近隣関係の維持で帯域幅を浪費します。 スポーク上で Enhanced Interior Gateway Routing Protocol(EIGRP)を有効にすることで、ルーティング アップデートはスポークに送信されます。 大規模ネットワークでは、このようなアップデートは巨大になり、CPU 帯域幅を浪費し、またスポーク ルータでより多くのメモリが必要になる場合があります。

EIGRP を使用したよりよいアプローチは、ハブでフィルタを適用する方法です。 ハブがスポークにデフォルト ルートだけをダイナミックに送信するように、ルーティング情報が制御されます。 このようなフィルタは、スポーク側でのルーティング テーブルのサイズ縮小に役立ちますが、ハブが隣接ルータを失った場合は、その他すべての隣接ルータに対してクエリーを送出します。 ハブが隣接ルータから応答を受けることは絶対にないので、これらのクエリーは不要です。

最善のアプローチは、ODR を使用して、EIGRP のクエリーと隣接ルータのメンテナンスのオーバーヘッドをなくす方法です。 ODR のタイマーを調整することで、コンバージェンス時間を長くできます。

現在は、ハブアンドスポークの状態で EIGRP をよりよくスケーリングする、新しい機能が EIGRP にあります。 EIGRP のスタブ機能の詳細については、「Enhanced IGRP スタブ ルーティング」を参照してください。

ODR と OSPF の比較

Open Shortest Path First(OSPF)は、ハブアンドスポーク環境にいくつかのオプションを提供し、stub no-summary オプションのオーバーヘッドは最小限になります。

大規模ハブアンドスポーク ネットワークで OSPF を実行していると、問題が発生する場合があります。 この項の例ではフレームリレーを使用しますが、これはフレームリレーが最も一般的なハブアンドスポーク トポロジであるためです。

OSPF ポイントツーポイント スタブ ネットワーク

この例では、ポイントツーポイント設定により接続された 100 箇所のスポーク上で OSPF が有効になっています。 第 1 に、/30 ネットワーク マスクを使用してサブネット化しても、多数の無駄な IP アドレスが存在します。 第 2 に、1 つのエリアにこれら 100 箇所のスポークがあって、1 箇所のスポークがフラッピングした場合、Shortest Path First(SPF; 最短パス優先)アルゴリズムが実行され、CPU に負荷がかかります。 この状態は特に、リンクが継続的にフラッピングしている場合のスポーク ルータに当てはまります。 スポーク ルータに関する限り、隣接ルータのフラップが増えると、問題が発生する可能性があります。

OSPF では、エリアはスタブであり、インターフェイスではありません。 スタブ ネットワークに 100 台のルータがある場合、サイズの大きなデータベースを保持するためにスポークではより多くのメモリが必要になります。 この問題は、大きなスタブ エリアを小さなエリアに分割することで解決できます。 ただし、1 つのスタブ エリアでのフラップによってもスポーク上での SPF の実行がトリガされるため、このオーバーヘッドは、集約ルートと外部ルートを持たない小さなスタブ エリアを作成することでは解消できません。

もう 1 つのオプションとしては、1 つのエリアに各リンクを含める方法があります。 このオプションを使用すると、ハブ ルータは各エリアに対して独立した SPF アルゴリズムを実行し、エリア内のルート用の集約 Link-State Advertisement(LSA; リンク状態アドバタイズメント)を作成する必要があります。 このオプションは、ハブ ルータのパフォーマンスに悪影響を及ぼす可能性があります。

上位のプラットフォームにアップグレードしても恒久的な解決策にはなりませんが、ODR には解決策が用意されています。 ODR を介して学習されたルートは、これらのルートをその他のハブ ルータに通知するために、OSPF に再配布できます。

OSPF ポイントツーマルチポイント スタブ ネットワーク

ポイントツーマルチポイント ネットワークでは、あらゆるスポークを同じサブネットに配置することで、IP アドレス空間が節約されます。 また、生成されるルータ LSA ハブのサイズは半分になります。これは、すべてのポイントツーポイント リンクに対して 1 つのスタブだけが生成されるためです。 ポイントツーマルチポイント ネットワークでは、サブネット全体が強制的に 1 つのエリアに含められます。 リンク フラップが発生した場合、スポークは SPF を実行しますが、SPF は CPU に負荷をかける可能性があります。

hello ストーム

OSPF hello パケットは小サイズですが、隣接ルータが多すぎる場合、サイズが大きくなる可能性があります。 hello はマルチキャストであるため、ルータはパケットを処理します。 OSPF ハブが送受信する hello パケットは、20 バイトの IP ヘッダー、24 バイトの OSPF ヘッダー、20 バイトの hello パラメータ、および認識された各隣接ルータ用の 4 バイトから構成されます。 100 台の隣接ルータがあるポイントツーマルチポイント ネットワーク内のハブからの OSPF hello パケットは 464 バイトの長さになる可能性があり、30 秒ごとにすべてのスポークにフラッディングされます。

表 1: 100 台の隣接ルータの OSPF hello パケット

20 バイトの IP ヘッダー

24 バイトの OSPF ヘッダー

20 バイトの hello パラメータ

4 バイトの各隣接ルータの Router ID(RID; ルータ ID)

. . .

. . .

. . .

. . .

. . .

ハブからスポークへは余分な情報は送信されないため、ODR ではオーバーヘッドは解決されています。 スポークは、サブネットごとに 5 バイトの IP プレフィクスをハブ ルータに送信します。 hello パケットのサイズを考えながら、30 秒の間隔での ODR(接続された 1 つのサブネットの情報を送信するスポーク)の 5 バイトと、OSPF の 68 バイト(スポークからハブに送信される IP ヘッダーを含む最小の hello パケット サイズ)プラス 68 バイト(ハブからスポークに送信される最小の hello パケット サイズ)とを比較してください。 また、ODR アップデートはレイヤ 2 で行われるのに対し、OSPF hello はレイヤ 3 で行われます。 ODR を使用すると、送出される情報ははるかに少なくなるため、重要なデータにリンク帯域幅を使用できます。

ODR と RIPv2 の比較

Routing Information Protocol バージョン 2(RIPv2)も、ハブアンドスポーク環境用の優れた選択肢です。 RIPv2 を設計するには、ハブからスポークにデフォルト ルートを送信します。 続いてスポークは RIP を介して接続インターフェイスをアドバタイズします。 RIPv2 が使用できるのは、アドバタイズする必要があるスポーク上にセカンダリ アドレスが存在する場合、複数のベンダーのルータが使用されている場合、または真のハブアンドスポーク状態ではない場合です。

デマンド回線での RIPv2

バージョン 2 にはいくつかの変更点がありますが、プロトコルは大幅には変更されていません。 この項では、デマンド回線に関する RIP へのいくつかの機能拡張を説明します。

今日のインターネットワークは、多数のリモート サイトへの接続を提供するため、ダイヤルアップ ネットワーク、またはプライマリ サイトのバックアップの方向へ移行しつつあります。 このような種類の接続では、通常の稼働時には、渡されるデータ トラフィックがほとんどまったく存在しない場合があります。

このような回線では、RIP の定期的な動作が問題の原因になります。 RIP は、低帯域幅のポイントツーポイント インターフェイスで問題が発生します。 アップデートは、高帯域幅を使用するサイズの大きいルーティング テーブルを使用して 30 秒ごとに送信されます。 このような状態では、Triggered RIP を使用するのが最善です。

Triggered RIP

Triggered RIP は、隣接ルータとすべてのルーティング情報を交換するルータ用に設計されています。 ルーティングの変更が行われると、変更部分だけが隣接ルータに伝搬されます。 受信側ルータは、その変更をただちに適用します。

Triggered RIP のアップデートが送信されるのは、次の場合だけです。

  • ルーティング アップデートの要求が受信された場合。

  • 新しい情報が受信された場合。

  • 宛先が、ダウン中の回線からアップ中の回線に変更された場合。

  • ルータが最初にオンになった場合。

Triggered RIP の設定例を次に示します。

Spoke#configure terminal 
  Enter configuration commands, one per line.  End with CNTL/Z. 
  Spoke(config)#int s0.1 
  Spoke(config-if)#ip rip triggered 
  Spoke(config)#int s0.2 
  Spoke(config-if)#ip rip triggered 
  interface serial 0 
  encapsulation frame-relay 
  interface serial 0.1 point            /* Primary PVC */ 
  ip address 10.x.x.x 255.255.255.0 
  ip rip triggered 
  frame-relay interface-dlci XX 
  interface serial 0.2 point       /* Secondary PVC */ 
  ip address 10.y.y.y 255.255.255.0 
  ip rip triggered 
  frame-relay interface-dlci XX 
  router rip 
    network 10.0.0.0 
  Spoke#show ip protocol 
  Routing Protocol is "rip" 
    Sending updates every 30 seconds, next due in 23 seconds 
    Invalid after 180 seconds, hold down 180, flushed after 240 
    Outgoing update filter list for all interfaces is not set 
    Incoming update filter list for all interfaces is not set 
    Redistributing: rip 
    Default version control: send version 1, receive any version 
      Interface        Send  Recv    Triggered RIP    Key-chain 
      Ethernet0           1        1 2 
      Serial0.1             1        1 2               Yes 
      Serial0.2             1        1 2               Yes 
    Routing for Networks: 
      10.0.0.0 
    Routing Information Sources: 
      Gateway         Distance      Last Update 
    Distance: (default is 120) 

スポークに接続されているハブ ルータのインターフェイスでは ip rip triggered コマンドが設定されている必要があります。

RIPv2 と ODR を比較すると、RIPv2 はレイヤ 3 で動作し、ODR はレイヤ 2 で行われるため、ODR の方が優れた選択肢です。 1000 箇所以上のスポークにハブが RIPv2 アップデートを送信する場合、各スポークに関してレイヤ 3 でパケットを複製する必要があります。 レイヤ 2 での通常の 1 分ごとの CDP アップデート以外は、ODR はハブから何も送信しないため、CPU にまったく負荷をかけません。 スポークからレイヤ 2 で、接続サブネットの情報を送信する処理は、レイヤ 3 で RIPv2 を送信する処理よりもはるかに CPU 負荷が低くなります。

ODR を使用した大規模ネットワークの設計

ODR は、他のすべてのルーティング プロトコルよりも、大規模ネットワークでの動作に優れています。 ODR の最大の利点は、接続シリアル リンクでルーティング プロトコルを有効にする必要がない点です。 現在のところ、接続インターフェイス上で有効にしないでもルーティング情報を送信できるようなルーティング プロトコルは存在しません。

ハブ上で EIGRP が動作する ODR

EIGRP を実行する場合は、リンク上で不必要な EIGRP hello が送信されないように、ハブアンドスポーク ネットワークへのパッシブ インターフェイス接続を確立します。 可能な場合は、ハブとスポークの間のネットワークに対するネットワーク文を定めない方が適しています。これは、リンクがダウンした場合、EIGRP はコア隣接ルータに不必要なクエリーを送出しないためです。 設定にはネットワーク文を定めないため、リンクが EIGRP ドメインに含まれないように、ハブとスポークの間では常に偽のネットワークを選択します。

冗長性と集約

ハブが 1 箇所の状況では、追加設定は不要です。 スポークからなる特定の接続サブネットを集約し、それらをコアに向けてリークします。 ただし、そこにはクエリーのオーバーヘッドが常に存在します。 スポークの 1 つから特定のルートが失われた場合、コア ルータですべての隣接ルータにクエリーを送出します。

複数のハブが存在する場合は、両方のハブが接続されていて、ハブの間で EIGRP が動作していることが非常に重要です。 可能であれば、このリンクは、スポークが宛先である他のリンクに干渉しないように、固有のメジャー ネットである必要があります。 EIGRP は特定のインターフェイスでは有効にすることができないので、この設定は必要です。これにより、そのインターフェイスをパッシブにしても、EIGRP を介してのアドバタイズが行われます。 インターフェイスが集約されている場合、1 つのスポークが失われると依然としてクエリーが送出されます。 2 つのハブ間のリンクがスポークと同じメジャー ネット内に存在しない限り、設定は正しく動作するはずです。

図 4: 冗長性と集約: コアは集約されたルートを受信中

odr7.jpg

EIGRP の利点としては、EIGRP はインターフェイス レベルで集約することができるため、スポーク サブネットの集約されたルートがコアに送信され、さらに EIGRP はもう一方のハブにより詳細な経路を送信する点が挙げられます。 ハブとスポークの間のリンクがダウンした場合、2 つ目のハブを介して宛先に到達することが可能です。

ハブ上で OSPF が動作する ODR

このシナリオでは、スポークに接続されたリンクで OSPF を有効にする必要はありません。 通常のシナリオでは、OSPF がリンク上で有効にされ、ある特定のリンクが継続的にフラッピングしている場合、SPF の実行、ルータ LSA の登録、集約 LSA の登録などを含むいくつかの問題の原因になる可能性があります。 ODR を実行している場合は、OSPF ドメインに、接続されているシリアル リンクを含めないでください。 主な問題は、スポークの LAN セグメント情報の受信です。 この情報は、ODR を介して取得できます。 1 つのリンクが継続的にフラッピングしている場合、そのリンクはハブ ルータのルーティング プロトコルには干渉しません。

冗長性と集約

スポークの接続インターフェイスの 1 つがダウンした場合、ルート計算を回避するため、コアにリークする前に特定のリンクをすべて集約することができます。 コア ルータの情報が集約されている場合は、そのインターフェイスを検出することはできません。

図 5: 冗長性と集約: コア ルータは集約されたルートを受信中

odr6.jpg

この例では、冗長性を確保するため、ハブが相互に接続されていることが非常に重要です。 この接続は、OSPF コアにリークする前に、スポーク接続されたサブネットも集約します。

将来の機能拡張を備えた NSSA

最終的には、コアに集約できるだけでなく、Not-So-Stubby Area(NSSA)リンクを介してハブを横断するより詳細な情報も使用できるようになる、OSPF NSSA 機能が実現されます。 NSSA を実行する利点としては、集約されたルートをコアに送信できることが挙げられます。 続いて、スポークの宛先に到達するように、コアはトラフィックをどちらかのハブに送信できます。 ハブとスポークの間のリンクがダウンした場合は、他のハブを介して宛先に到達するように、両方のハブにはより詳細なタイプ 7 LSA が存在します。

NSSA を使用した設定例を次に示します。

N2507: Hub 1 
  router odr 
    timers basic 8 24 0 1 
  ! 
  router ospf 1 
    redistribute odr subnets 
    network 1.0.0.0 0.255.255.255 area 1 
    area 1 nssa 
  N2504: Hub 2 
  router odr
    timers basic 8 24 0 1 
  ! 
  router ospf 1 
    redistribute odr subnets 
    network 1.0.0.0 0.255.255.255 area 1 
    area 1 nssa 
  N2507#show ip route 
  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
         D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
         E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
         i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
         U - per-user static route, o - ODR 
  Gateway of last resort is not set 
  C    1.0.0.0/8 is directly connected, Serial0 
  C    2.0.0.0/8 is directly connected, Serial1 
       3.0.0.0/24 is subnetted, 1 subnets 
  C       3.3.3.0 is directly connected, Ethernet0 
  o    150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
  o    200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
  o    200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
  N2504#show ip route 
  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
         D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
         E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
         i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
         U - per-user static route, o - ODR 
  Gateway of last resort is not set 
  C    1.0.0.0/8 is directly connected, Serial0 
  C    2.0.0.0/8 is directly connected, Serial1 
       3.0.0.0/24 is subnetted, 1 subnets 
  C       3.3.4.0 is directly connected, TokenRing0 
  C    5.0.0.0/8 is directly connected, Loopback0 
  C    6.0.0.0/8 is directly connected, Loopback1 
  O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0 
  O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 
  O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 

NSSA を使用した集約と将来の機能拡張

次の例に示すように、OSPF コアにサブネットが正しく集約できるように、サブネットの連続ブロックをスポークに割り当てます。 サブネットが集約されておらず、接続されている 1 つのサブネットがダウンした場合、コア全体はそのサブネットを検出し、ルートを再計算します。 連続したブロックの集約ルートを送信することにより、スポーク サブネットにフラップが発生しても、コアはそれを検出しません。

N2504#configure terminal 
  Enter configuration commands, one per line.  End with CNTL/Z. 
  N2504(config)#router ospf 1 
  N2504(config-router)#summary-address 200.1.0.0 255.255.0.0 
  N2504#show ip ospf database external 
         OSPF Router with ID (6.0.0.1) (Process ID 1) 
                  Type-5 AS External Link States 
    LS age: 1111 
    Options: (No TOS-capability, DC) 
    LS Type: AS External Link 
    Link State ID: 200.1.0.0 (External Network Number ) 
    Advertising Router: 6.0.0.1 
    LS Seq Number: 80000001 
    Checksum: 0x2143 
    Length: 36 
    Network Mask: /16 
          Metric Type: 2 (Larger than any link state path) 
          TOS: 127 
          Metric: 16777215 
          Forward Address: 0.0.0.0 
          External Route Tag: 0

距離の問題

この例では、両方のハブからより詳細な情報が受信されます。 OSPF の距離は 110 であり ODR の距離は 160 であるため、同じサブネットに関してもう一方のハブから情報が受信された場合、情報は ODR に干渉します。 もう一方のハブはスポークの宛先に到達するよう常に優先されるため、最適ではないルーティングの原因になります。 この状態に対処するには、ODR ルートが常に OSPF ルートよりも優先されるように、distance コマンドを使用して ODR の距離を 110 よりも短くします。 ODR ルートに障害が発生した場合は、データベースから OSPF 外部ルートがルーティング テーブルにインストールされます。

N2504(config)#router odr 
  N2504(config-router)#distance 100 
  N2504(config-router)#end 
  N2504#show ip route 
  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
         D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
         E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
         i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
         U - per-user static route, o - ODR 
  Gateway of last resort is not set 
  C    1.0.0.0/8 is directly connected, Serial0 
  C    2.0.0.0/8 is directly connected, Serial1 
       3.0.0.0/24 is subnetted, 1 subnets 
  C       3.3.4.0 is directly connected, TokenRing0 
  C    5.0.0.0/8 is directly connected, Loopback0 
  C    6.0.0.0/8 is directly connected, Loopback1 
  o    150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
  o    200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
  o    200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
  O    200.1.0.0/16 is a summary, 00:04:38, Null0 

N2 ルートはまだデータベース内にあり、スポークへのメイン ハブ リンクがダウンした場合はアクティブになります。

N2504#show ip ospf database nssa 
         OSPF Router with ID (6.0.0.1) (Process ID 1) 
                  Type-7 AS External Link States (Area 1) 
    LS age: 7 
    Options: (No TOS-capability, Type 7/5 translation, DC) 
    LS Type: AS External Link 
    Link State ID: 150.0.0.0 (External Network Number ) 
    Advertising Router: 6.0.0.1 
    LS Seq Number: 80000002 
    Checksum: 0x965E 
    Length: 36 
    Network Mask: /16 
          Metric Type: 2 (Larger than any link state path) 
          TOS: 0 
          Metric: 20 
          Forward Address: 1.0.0.2 
          External Route Tag: 0 

NSSA への機能拡張を使用することで、タイプ 7 のより詳細な LSA は NSSA データベース内に存在します。 次に示すように、集約されたルートの代わりに、NSSA データベースの出力が表示されます。

LS age: 868 
  Options: (No TOS-capability, Type 7/5 translation, DC) 
  LS Type: AS External Link 
  Link State ID: 200.1.1.0 (External Network Number) 
  Advertising Router: 3.3.3.1 
  LS Seq Number: 80000001 
  Checksum: 0xDFE0 
  Length: 36 
  Network Mask: /24 
          Metric Type: 2 (Larger than any link state path) 
          TOS: 0 
          Metric: 20 
          Forward Address: 1.0.0.1 
          External Route Tag: 0 
  LS age: 9 
  Options: (No TOS-capability, Type 7/5 translation, DC) 
  LS Type: AS External Link 
  Link State ID: 200.1.2.0 (External Network Number) 
  Advertising Router: 3.3.3.1 
  LS Seq Number: 80000002 
  Checksum: 0xFDC3 
  Length: 36 
  Network Mask: /24 
          Metric Type: 2 (Larger than any link state path) 
          TOS: 0 
          Metric: 20 
          Forward Address: 1.0.0.2 
          External Route Tag: 0 

デマンド回線

デマンド回線は Cisco IOS 11.2 の機能で、ハブアンドスポーク ネットワークでも使用できます。 一般的にこの機能は、ダイヤル バックアップのシナリオや、X.25 またはフレームリレーの Switched Virtual Circuit(SVC; 相手先選択接続)環境で便利です。 デマンド回線の設定例を次に示します。

router ospf 1 
  network 1.1.1.0 0.0.0.255 area 1 
  area 1 stub no-summary 
  interface Serial0                   /* Link to the hub router  */ 
    ip address 1.1.1.1 255.255.255.0 
    ip ospf demand-circuit 
    clockrate 56000 
  Spoke#show ip o int s0 
  Serial0 is up, line protocol is up 
    Internet Address 1.1.1.1/24, Area 1 
    Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64 
    Configured as demand circuit. 
    Run as demand circuit. 
    DoNotAge LSA not allowed (Number of DCbitless LSA is 1). 
    Transmit Delay is 1 sec, State POINT_TO_POINT, 
    Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
      Hello due in 00:00:06 
    Neighbor Count is 1, Adjacent neighbor count is 1 
      Adjacent with neighbor 130.2.4.2 
    Suppress hello for 0 neighbor(s) 

ハブアンドスポーク ネットワークでデマンド回線の機能を使用すると、トポロジに何らかの変化が生じた場合、回線がアップ状態になり、新しい隣接関係が形成されます。 たとえば、フラップが発生したスポークにサブネットが存在する場合、デマンド回線は隣接関係を確立し、この情報をフラッディングします。 スタブ エリア環境では、この情報はスタブ エリア全体にフラッディングされます。 ODR は、この情報をその他のスポークにリークしないことで、この問題を解決します。 詳細については、「OSPF デマンド回線の機能」を参照してください。

ポイントツーポイント ネットワークを使用した ODR

Interface Descriptor Block(IDB; インターフェイス記述ブロック)の制限に関する現在の Cisco IOS 12.0 のステータスは、次のとおりです。

ルータ

制限

1000

300

2600

300

3600

800

4x00

300

5200

300

5300

700

5800

3000

7200

3000

RSP

1000

IOS 12.0 よりも前では、1 つのハブがサポートできるスポークの最大数は、IDB の制限により 300 でした。 ネットワークで 300 箇所を超えるスポークが必要になる場合は、ポイントツーポイント設定は適切な選択肢ではありませんでした。 また、各リンクに関して独立した CDP パケットが生成されました。 ポイントツーポイント リンクでの CDP アップデートの送信に関する時間計算量は n2 です。 上記の表により、さまざまなプラットフォームに関する IDB の制限が判明します。 各プラットフォームでサポートされているスポークの最大数は同じではありませんが、各リンクに対する独立した CDP パケットの作成のオーバーヘッドは依然として問題になります。 したがって、大規模なハブアンドスポークの状態では、ポイントツーポイント インターフェイスよりも、ポイントツーマルチポイントを設定する方が優れた解決策になります。

ポイントツーマルチポイント ネットワークを使用した ODR

1 つのハブが複数のスポークをサポートしているポイントツーマルチポイント ネットワークでは、主に次の 3 つの問題が存在します。

  • ハブは 300 を超えるスポークを容易にサポートできます。 たとえば、10.10.0.0/22 ネットワークでは、1 つのマルチポイント インターフェイスで 1024-2 のスポークをサポートできます。

  • マルチポイント環境では、すべての隣接ルータに対して 1 つの CDP パケットが生成され、レイヤ 2 で複製されます。 CDP アップデートの時間計算量は n にまで軽減します。

  • ポイントツーマルチポイント設定では、すべてのスポークに割り当てることができるサブネットは 1 つだけです。

ODR と複数のベンダー

一般的に、複数のベンダーが使用されていると ODR は動作しないと誤解されています。 ネットワークが真のハブアンドスポーク ネットワークである限り、ODR は正しく動作します。 たとえば、100 箇所のスポークがあり、そのうち 2 つが別のベンダーのルータである場合も、異なるルータに接続されているリンクでルーティング プロトコルを有効にし、残りの 98 箇所の Cisco スポークで ODR を実行することができます。

図 6: 複数のベンダーを使用した ODR

odr10.jpg

98 台の Cisco ルータに接続されたハブ ルータは ODR を介してサブネット アップデートを受信し、残りの異なる 2 台のルータからはルーティング プロトコルのアップデートを受信します。 異なるルータに接続されているリンクは、独立したポイントツーポイントまたはポイントツーマルチポイント サブネット上に存在する必要があります。

将来の成長に関する問題

ある組織が 100 箇所のスポークで ODR を実行している場合、最終的にはトポロジをハブアンドスポーク ネットワークから変更する必要がある場合があります。 たとえば、あるスポークを上位のプラットフォームにアップグレードし、そのスポークを他の新しい 20 箇所のスポークを対象としたハブに流用することを決める場合などです。

図 7: 将来の成長

odr9.jpg

新しいハブでルーティング プロトコルを実行し、ODR の設計を現状のままにしておくことも可能です。 新しいハブが 20 箇所以上の新しいスポークをサポートする場合、ODR は新しいハブで実行可能です。 新しいハブは ODR を介してこれらの新しいスポーク サブネットについて学習し、別のルーティング プロトコルを介してこの情報を元のハブに再配布することができます。

この状態は、ODR が 2 箇所のハブで始まった時点に似ています。 プロトコルの変更に伴うオーバーヘッドはありません。 基本的には、ルータがスタブである限り、ODR は実行可能です。

パフォーマンス

ODR の実行時には、コンバージェンスを高速化し、パフォーマンスを改善するために、複数の設定を調整できます。

コンバージェンスを高速化するためのタイマーの調整

大規模な ODR 環境では、コンバージェンスを高速化するために ODR タイマーを調整し、ハブからスポークへの CDP アップデートのタイマーを大きくし、ハブの CPU パフォーマンスを最小にします。

ハブ ルータ

ハブからスポークへのトラフィックの量を少なくするには、CDP アップデートタイマーはデフォルトの 60 秒にする必要があります。 ホールドタイムは最大値(255 秒)にまで大きくする必要があります。 ハブ ルータが維持する必要がある CDP 隣接関係テーブルは非常に多いので、数台の隣接ルータがダウンした場合には、255 秒(許可されている最大ホールドダウン時間)間はメモリから CDP のエントリを削除しないようにしてください。 隣接ルータが 4 分以内にアップ状態に戻った場合は、CDP 隣接関係の再作成は不要なので、この設定によりハブ ルータには柔軟性が提供されます。 古いテーブル エントリを使用し、ホールドダウン タイマーをアップデートすることができます。

中央ルータの IP 設定テンプレートの例を次に示します。

  cdp holdtime 255 
        router odr 
          timers basic 8 24 0 1  /* odr timer's are update, invalid, hold down, flush 
          router eigrp 1 
          network 10.0.0.0 
          redistribute odr 
          default-metric 1 1 1 1 1
  

各リモート サイト(倉庫、地域拠点、および配送拠点)からの 3 つの Permanent Virtual Circuit(PVC; 相手先固定接続)があります。 PVC の 2 つは、2 つの独立した中央ルータに接続されています。 3 つ目の PVC は PayPoint ルータに接続されています。 PayPoint ルートへの PVC は、PayPoint ネットワークが宛先であるトラフィックに対して使用される必要があります。 その他 2 つの PVC は、その他すべてのトラフィックのプライマリおよびバックアップ機能にサービスを提供します。 これらの要件に基づいて、次に示す各リモート ルータの設定テンプレートを参照してください。

コンバージェンスを高速化するには、invalidholddown、および flush などの ODR タイマーを調整することが非常に重要です。 router odr が設定されると、CDP が IP プレフィックスを送出しないにも関らず、アップデート タイマーが存在する場合にだけコンバージェンス タイマーを設定できるため、ODR アップデート タイマーは隣接ルータの CDP アップデート タイマーと一致する必要があります。 このタイマーは CDP タイマーとは異なり、コンバージェンスを高速化するためにだけ使用可能です。

スポーク ルータ

スポークは CDP パケットで ODR アップデートを送信しているため、コンバージェンスを高速化するには CDP アップデートのタイマーを非常に小さい値に保つ必要があります。 真のスポーク環境では、CDP 隣接ルータの holddown 時間に制限はありません。これは、スポークが CDP テーブルに保持するエントリがごく少数であるためです。 255 秒の最大のホールドダウン時間を設定することをお勧めします。そうすると、ハブ PVC がダウンしても、4 分以内に復帰した場合には、古いテーブル エントリが使用できるので、新規の CDP 隣接関係が不要となります。

リモート サイトの IP 設定テンプレートの例を次に示します。

  cdp timer 8 
  cdp holdtime 255 
  interface serial 0 
  encapsulation frame-relay 
  cdp enable 
  interface serial 0.1 point                      /* Primary PVC */ 
  ip address 10.x.x.x 255.255.255.0 
  frame-relay interface-dlci XX 
  interface serial 0.2 point                      /* Secondary PVC */ 
  ip address 10.y.y.y 255.255.255.0 
  frame-relay interface-dlci XX 
  interface bri 0 
  interface BRI0 
  description Backup ISDN for frame-relay 
  ip address 10.c.d.e 255.255.255.0 
  encapsulation PPP 
  dialer idle-timeout 240 
  dialer wait-for-carrier-time 60 
  dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx 
  ppp authentication chap 
  dialer-group 1 
  isdn spid1 xxxxxxx 
  isdn spid2 xxxxxxx 
  access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
  dialer-list 1 LIST 101 
  /* following are the static routes that need to be configured on the remote routers 
  ip route 0.0.0.0 0.0.0.0 10.x.x.x 
  ip route 0.0.0.0 0.0.0.0 10.y.y.y 
  ip route 0.0.0.0 0.0.0.0 bri 0 100 
  ip classless 
  

IOS 12.0.5T 以降を使用している場合、ハブ ルータがすべてのスポークに向けて自動的にデフォルト ルートを送信するため、デフォルトのスタティック ルートは必要ありません。

ODR ルートのフィルタおよび集約

ODR ルートは、コアにリークされる前にフィルタリングできます。 これには distribute-list in コマンドを使用します。 コアにリークする場合、スポークのすべての接続サブネットを集約する必要があります。 集約が不可能である場合、不必要なルートはハブ ルータでフィルタリングできます。 複数のハブ ネットワークでは、スポークは、別のハブへのリンクである接続インターフェイスをアドバタイズする場合があります。

この場合、ハブがこれらのルートをルーティング テーブルに入れないように、distribute-list コマンドを適用する必要があります。 ODR がハブに再配布された場合、その情報はコアにはリークされません。

telco タイマーの調整

telco タイマーを調整し、スポークのコンバージェンス時間を大きくすることが重要です。 ハブ側からの PVC がダウンした場合、スポークはそれをすばやく検出し、第 2 のハブに切り替えることができる必要があります。

CPU パフォーマンス

ODR プロセスでは、CPU 利用率はあまり大きくありません。 ODR を約 1000 台の隣接ルータでテストした場合、CPU 利用率は 3 〜 4 % でした。 ハブ上の ODR のタイマーを限界まで設定することで、コンバージェンスの高速化に役立ちます。 デフォルト設定を使用した場合、CPU 利用率は 0 〜 1 % に留まります。

ODR タイマーと CDP タイマーを限界まで設定した場合も、次の出力から CPU 利用率は高くないことが判明します。 このテストは、Cisco 7206 の 150 MHz のプロセッサを使用して行われました。

Hub#show proc cpu 
  CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3% 
  PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
     . 
     . 
    18    11588036  15783316   734   0.73%  1.74%  1.95%   0 CDP Protocol 
     . 
     . 
    48    3864      5736        673  0.00%  0.00%  0.00%   0 ODR Router 
  Hub#show proc cpu 
  CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
  PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
      . 
      . 
     18    11588484  15783850    734   2.21%  1.83%  1.96%   0 CDP Protocol 
      . 
      . 
     48        3864     5736     673   0.00%  0.00%  0.00%   0 ODR Router 
  Hub#show proc cpu 
  CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3% 
  PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11588676  15784090    734   1.31%  1.79%  1.95%   0 CDP Protocol 
    . 
    . 
   48        3864      5736    673   0.00%  0.00%  0.00%   0 ODR Router 
  Hub#show proc cpu 
  CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3% 
  PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11588824  15784283    734   0.65%  1.76%  1.94%   0 CDP Protocol 
    . 
    . 
   48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 
  Hub#show proc cpu 
  CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
  PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11589004  15784473    734   1.96%  1.85%  1.95%   0 CDP Protocol 
    . 
    . 
   48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 
  Hub#show proc cpu 
  CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
  PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11589188  15784661    734   1.63%  1.83%  1.94%   0 CDP Protocol 
    . 
    . 
   48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router

機能拡張

Cisco IOS 12.0.5T よりも前の ODR のバージョンには、いくつかの制限がありました。 Cisco IOS 12.0.5T 以降での機能拡張のリストを次に示します。

  • CSCdy48736 の前では、セカンダリ サブネットは CDP アップデートで /32 としてアドバタイズされます。 これは、12.2.13T 以降で修正されています。

  • 現在、CDP ハブはスポークにデフォルト ルートを伝搬するため、スポークにデフォルトのスタティック ルートを追加する必要はありません。 コンバージェンス時間は大幅に長くなっています。 ネクストホップがダウンした場合、スポークは ODR を介してそれをすばやく検出し、コンバージします。 この機能は、Bug CSCdk91586 を通じて、12.0.5T に追加されています。

  • ハブとスポークの間のリンクが IP 番号未設定である場合、ハブにより送信されるデフォルト ルートはスポークで認識されない場合があります。 この不具合は CSCdx66917 で、IOS 12.2.14、12.2.14T 以降で修正されています。

  • スポークが 1 つのハブをもう一方よりも優先させることができるように、スポーク上で ODR の距離を増減するために、CSCdr35460 の追跡を通じて推奨事項が作成されています。 コードはすでにテストされ、間もなくお客様が利用できるようになる予定です。


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

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


関連情報


Document ID: 13710