内容

概要

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

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

フィルタおよび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 以降で修正されています。

- スポークで一方のハブを優先するようにスポークのODR距離を増減するには、CSCdr35460で追跡される提案が行われます。コードはすでにテスト済みで、まもなく顧客に提供されます。

関連情報

- IP ルーティングに関するサポート ページ

- テクニカルサポート - Cisco Systems