ODR を使用する大規模なスタブネットワークの設計

ダウンロードオプション

PDF (458.5 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (168.4 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (179.4 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2005 年 8 月 10 日

Document ID:13710

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

スタブネットワークか中継ネットワークか

ハブ・アンド・スポーク・ネットワークおよびODR

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

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

単一のハブでのロードバランシングまたはバックアップ

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

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

ODR か EIGRP か

ODR かOSPF か

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

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

ODR か RIPv2 か

デマンド回線上のRIPv2

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

ハブで実行されるEIGRP を使用するODR

冗長性および集約

ハブで実行されるOSPF を使用するODR

冗長性および集約

ポイントツーポイント・ネットワークでのODR

ポイントツーマルチポイント・ネットワークでのODR

ODR およびマルチプルベンダ

将来の成長の問題

パフォーマンス

速やかな収束のためのタイマーの調節

Hub ルータ

スポークルータ

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

Telco タイマの調節

CPUパフォーマンス

機能拡張

概要

On-Demand Routing（ODR）は、ブロードキャストまたは非ブロードキャストメディア上の他の Cisco デバイスの検出に使用されるプロトコルであり、Cisco Discovery Protocol（CDP）の機能を拡張したものです。CDP を使用すれば、デバイスタイプ、IP アドレス、隣接するシスコデバイスで実行されている Cisco IOS® のバージョン、隣接するデバイスの機能などを検出することができます。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：ハブアンドスポークトポロジ

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

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

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

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

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

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

単一のハブでのロードバランシングまたはバックアップ

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

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

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

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

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

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

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

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

ODR over IPルーティングの最大の利点は、ハブルータがレイヤ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 パケットサイズ）とを比較してください。また、OSPF helloはレイヤ3で発生し、ODR更新はレイヤ2で発生します。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のアップデートを送信場合、各スポークでを複製します。レイヤ 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：冗長性と集約：コアは集約されたルートを受信中

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

ハブで実行されるOSPF を使用するODR

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

冗長性および集約

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

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

この例では、冗長性を確保するため、ハブが相互に接続されていることが非常に重要です。この接続は、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 のステータスは、次のとおりです。

ルータ	制限
1,000	300
2600	300
3600	800
4x00	300
5200	300
5300	700
5800	3,000
7200	3,000
RSP	1,000

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

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

将来の成長の問題

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

図 7：将来の成長

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

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

パフォーマンス

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

速やかな収束のためのタイマーの調節

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

Hub ルータ

ハブからスポークへのトラフィックの量を少なくするには、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 は、その他すべてのトラフィックのプライマリおよびバックアップ機能にサービスを提供します。これらの要件に基づいて、次に示す各リモートルータの設定テンプレートを参照してください。

コンバージェンスを高速化するには、invalid、holddown、および 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 以降を使用している場合、ハブルータがすべてのスポークに向けて自動的にデフォルトルートを送信するため、デフォルトのスタティックルートは必要ありません。

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 以降で修正されています。
スポークで一方のハブを優先するようにスポークのODR距離を増減するには、CSCdr35460で追跡される提案が行われます。コードはすでにテスト済みで、まもなく顧客に提供されます。

ODR を使用する大規模なスタブネットワークの設計

ダウンロード オプション

偏向のない言語

翻訳について

内容

このドキュメントは役に立ちましたか?

シスコに問い合わせ

ダウンロードオプション