管理ネットワークの接続
この章では、ONS 15454 Data Communications Network(DCN; データ通信ネットワーク)の接続の概要について説明します。シスコの Optical Networking System(ONS)のネットワーク通信は、Cisco Transport Controller(CTC)コンピュータと ONS 15454 ノードの間の通信や、ネットワーク接続された ONS 15454 ノード間の通信を含め、IP に基づいています。この章では、一般的な Cisco ONS 15454 の IP ネットワークの構成と、実際の ONS 15454 設置に基づく Data Communications Network(DCN; データ通信ネットワーク)の詳細なケース スタディについて説明します。また、ONS 15454 の IP ルーティング テーブル、外部ファイアウォール、オープン Gateway Network Element(GNE; ゲートウェイ ネットワーク エレメント)ネットワークについても説明します。
ONS 15454 の DCN 通信は IP をベースにしていますが、ONS 15454 ノードは、Open System Interconnection(OSI; オープン システム インターコネクション)プロトコル スイートに基づく装置にネットワーク接続できます。また、この章では、ONS 15454 OSI の実装と、IP と OSI が混在した環境で ONS 15454 をネットワーク接続する方法を示すシナリオについても説明します。
IP ネットワーキングの概念や手順の包括的な説明、ネットワーク接続されたすべてのシナリオを満たすための IP アドレッシングの例については説明しません。ONS 15454 ネットワーキングの設定手順については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Turn Up a Node」の章を参照してください。
(注) 特に指定のない限り、この章での「ONS 15454」は、ANSI と ETSI 両方のシェルフ アセンブリを指します。
この章の内容は、次のとおりです。
• 「IP ネットワーキングの概要」
• 「IP アドレッシングのシナリオ」
• 「DCN ケース スタディ」
• 「DCN 拡張機能」
• 「ルーティング テーブル」
• 「外部ファイアウォール」
• 「オープンな GNE」
• 「TCP/IP および OSI ネットワーキング」
• 「リンク管理プロトコル」
• 「IPv6 ネットワークの互換性」
• 「IPv6 のネイティブ サポート」
• 「Cisco CRS-1 ルータとの統合」
• 「光パス トレース」
• 「共有リスク リンク グループ(SRLG)」
• 「予防的保護再生成」
(注) ONS 15454 を IP ネットワークに接続するには、サイトの LAN 管理者など、IP ネットワーキングの訓練を受け経験がある人と協力する必要があります。
17.1 IP ネットワーキングの概要
ONS 15454 は、IP 環境内で次のように多数の方法で接続できます。
• 直接接続またはルータ経由で LAN に接続できます。
• IP サブネット化により ONS 15454 ノード グループを作成することで、Data Communications Channel(DCC; データ通信チャネル)に接続されていないネットワーク内のノードをプロビジョニングできます。
• IP のさまざまな機能とプロトコルを使用して、特定のネットワーク目標を達成できます。たとえば、プロキシ Address Resolution Protocol(ARP; アドレス解決プロトコル)を使用すると、LAN 接続されている 1 台の ONS 15454 が、LAN 接続されていない ONS 15454 のためのゲートウェイとして機能できます。
• スタティック ルートを作成して、複数の CTC セッションを使用し、同じサブネットに存在する ONS 15454 との複数の CTC セッション間の接続を可能にできます。
• ONS 15454 は Open Shortest Path First(OSPF)ネットワークに接続できるため、ONS 15454 ネットワークの情報は複数の LAN と WAN に自動的に通知されます。
• ONS 15454 プロキシ サーバは、CTC コンピュータと ONS 15454 要素ノードの間の可視性とアクセシビリティを制御できます。
17.2 IP アドレッシングのシナリオ
ONS 15454 IP アドレッシングには、一般に 9 個のシナリオ(構成)があります。これらのシナリオをビルディング ブロックとして使用し、より複雑なネットワーク構成を構築できます。 表 17-1 に、IP ネットワークで ONS 15454 を設定するときに確認すべき項目の一般的なリストを示します。
表 17-1 ONS 15454 の IP の一般的なトラブルシューティング チェックリスト
|
|
リンク完全性 |
次の機器の間にリンクの完全性が存在することを確認します。 • CTC コンピュータとネットワーク ハブまたはスイッチ • ONS 15454(バックプレーン(ANSI)または MIC-C/T/P(ETSI)ワイヤラップピンまたは RJ-45 ポート)とネットワーク ハブまたはスイッチ • ルータ ポートとハブまたはスイッチポート |
ONS 15454 ハブまたはスイッチ ポート |
接続の問題が発生した場合、ONS 15454 に接続されているハブまたはスイッチのポートを 10 Mbps 半二重に設定します。 |
ping |
ノードに ping を実行し、コンピュータと ONS 15454 の間の接続をテストします。 |
IP アドレスとサブネット マスク |
ONS 15454 の IP アドレスとサブネット マスクが正しく設定されていることを確認します。 |
光接続 |
ONS 15454 光トランク ポートがサービス中で、各トランク ポートで DCC がイネーブルになっていることを確認します。 |
17.2.1 シナリオ 1:同じサブネット上にある CTC および ONS 15454
シナリオ 1 は、ONS 15454 LAN の基本的な構成を示します(図 17-1)。ONS 15454 と CTC コンピュータは同じサブネットにあります。すべての ONS 15454 が LAN A に接続され、すべての ONS 15454 が DCC 接続を備えています。
図 17-1 シナリオ 1:同じサブネット上にある CTC および ONS 15454(ANSI および ETSI)
17.2.2 シナリオ 2:ルータに接続された CTC および ONS 15454
シナリオ 2 では、CTC コンピュータはサブネット(192.168.1.0)にあり、LAN A に接続されています(図 17-2)。ONS 15454 は、異なるサブネット(192.168.2.0)にあり、LAN B に接続されています。LAN A と LAN B はルータで接続されています。ルータ インターフェイスの IP アドレスは LAN A(192.168.1.1)に設定され、ルータ インターフェイス B の IP アドレスは LAN B(192.168.2.1)に設定されています。各ルータのサブネット マスクは 255.255.255.0 です。
CTC コンピュータで、デフォルト ゲートウェイはルータ インターフェイス A に設定されています。LAN で Dynamic Host Configuration Protocol(DHCP)を使用している場合、デフォルト ゲートウェイと IP アドレスは自動的に割り当てられます。図 17-2 の例では、DHCP サーバは使用できません。
図 17-2 シナリオ 2:ルータに接続された CTC および ONS 15454(ANSI および ETSI)
17.2.3 シナリオ 3:プロキシ ARP を使用した ONS 15454 ゲートウェイのイネーブル化
ARP は、宛先ホストの上位の IP アドレスを物理アドレスに対応付けます。変換を行うためにルックアップ テーブル(ARP キャッシュと呼びます)が使用されます。アドレスが ARP キャッシュに見つからない場合、ARP 要求と呼ぶ特殊な形式のブロードキャストがネットワークに送出されます。ネットワーク上のいずれかのマシンが要求中に自身の IP アドレスを認識すると、そのマシンは ARP 応答を要求元ホストに返送します。応答には、受信側ホストの物理的なハードウェア アドレスが含まれています。この宛先 IP アドレス宛の以降のすべてのデータグラム(パケット)が物理アドレスに変換できるように、要求元ホストはこのアドレスを ARP キャッシュに格納します。
プロキシ ARP を使用すると、LAN 接続された 1 台の ONS 15454 が、LAN に接続されていない ONS 15454 の ARP 要求に応答できます(ONS 15454 のプロキシ ARP では、ユーザ設定が不要です)。そのためには、DCC 接続されている ONS 15454 が、LAN 接続されている(ゲートウェイ)ONS 15454 と同じサブネットにある必要があります。LAN デバイスが LAN 接続されていない ONS 15454 に ARP 要求を送信すると、ゲートウェイ ONS 15454(LAN 接続されている ONS 15454)がその MAC アドレスを LAN デバイスに返します。LAN デバイスは、リモート ONS 15454 向けのデータグラムを、プロキシ ONS 15454 の MAC アドレスに送信します。プロキシ ONS 15454 はそのルーティング テーブルを使用して、LAN 接続されていない ONS 15454 にデータグラムを転送します。
シナリオ 3 はシナリオ 1 に似ていますが、1 台の ONS 15454(ノード 1)のみが LAN に接続されています(図 17-3)。2 台の ONS 15454(ノード 2 とノード 3)が、セクション DCC を通じて ONS 15454 ノード 1 に接続されています。3 台の ONS 15454 すべてが同じサブネットにあるため、プロキシ ARP を使用することで ONS 15454 ノード 1 が ONS 15345 ノード 2 およびノード 3 のゲートウェイとして機能します。
(注) このシナリオでは、すべての CTC 接続がノード 1 に接続されていると仮定しています。ラップトップを ONS 15454 ノード 2 またはノード 3 に接続した場合、ネットワーク パーティショニングが発生し、ラップトップも CTC コンピュータもすべてのノードに到達できなくなります。ラップトップを直接 End Network Element(ENE; エンド ネットワーク要素)に接続する場合、スタティック ルートを作成するか(「シナリオ 5:スタティック ルートを使用した LAN への接続」を参照)、ONS 15454 プロキシ サーバをイネーブルにする(「シナリオ 7:ONS 15454 プロキシ サーバのプロビジョニング」を参照)必要があります。
次の点に注意してください。
• GNE と ENE の 15454 のプロキシ ARP はディセーブルになっています。
• どのイーサネット セグメントにも、プロキシ ARP サーバは 1 台だけありますが、ANSI または ETSI トポロジには複数のサーバが存在する可能性があります。
• プロキシ ARP サーバは、同じイーサネット セグメント上のノードまたはホストに対し、プロキシ ARP 機能を実行しません。
• 図 17-3 で、CTC ワークステーションがプロキシ ARP サーバと同じサブネット内および同じイーサネット セグメントに存在することが重要です。
図 17-3 シナリオ 3:プロキシ ARP の使用(ANSI および ETSI)
プロキシ ARP を使用して、DCC 接続されたノードのクラフト イーサネット ポートに接続されたホストと通信することもできます(図 17-4)。ホストが接続されているノードには、ホストへのスタティック ルートが設定されている必要があります。スタティック ルートは、すべての DCC ピアに OSPF を使用して伝播されます。既存のプロキシ ARP ノードは、追加のホストのゲートウェイです。各ノードはそのルーティング テーブルで、DCC ネットワークに接続されていないものの、同じサブネット内にあるホストへのルートを調べます。既存のプロキシ サーバは、これらの追加のホストの ARP 要求に、そのノードの MAC アドレスを使用して応答します。ルーティング テーブル中にホスト ルートが存在することで、追加のホスト宛の IP パケットが正しくルーティングされます。ノードと追加のホストの間でスタティック ルートを確立する以外に、プロビジョニングは必要ありません。適用される制約事項は、次のとおりです。
• すべての追加ホストについて、1 台のノードだけがプロキシ ARP サーバとして動作します。
• ノードは、イーサネット ポートに接続されているホストのプロキシ ARP サーバになることはできません。
図 17-4 で、ノード 1 は、ノード 2 とノード 3 に、CTC ホストに到達できることを通知します。同様に、ノード 3 は、ONS 152xx に到達できることを通知します。ONS 152xx は例として示してあり、あらゆるネットワーク要素を追加ホストとして設定できます。
図 17-4 シナリオ 3:プロキシ ARP とスタティック ルーティングの使用(ANSI および ETSI)
17.2.4 シナリオ 4:CTC コンピュータ上のデフォルト ゲートウェイ
シナリオ 4 はシナリオ 3 に似ていますが、ノード 2 とノード 3 がそれぞれ異なるサブネット 192.168.2.0 と 192.168.3.0 にあります(図 17-5)。ノード 1 と CTC コンピュータはサブネット 192.168.1.0 にあります。ネットワークに異なるサブネットが含まれているため、プロキシ ARP は使用されません。CTC コンピュータがノード 2 および 3 と通信するために、ノード 1 が CTC コンピュータ上でデフォルト ゲートウェイとして設定されています。
図 17-5 シナリオ 4:CTC コンピュータ上のデフォルト ゲートウェイ(ANSI および ETSI)
17.2.5 シナリオ 5:スタティック ルートを使用した LAN への接続
スタティック ルートは、次の 2 つの目的で使用します。
• ONS 15454 を、別のサブネットに存在する ONS 15454 にルータによって接続されている 1 つのサブネット上の CTC セッションに接続するため(これらのスタティック ルートは、OSPF がイネーブルな場合は不要です。シナリオ 6 に OSPF の例を示します)。
• 同じサブネットにある ONS 15454 の間で複数の CTC セッションを使用可能にするため。
図 17-6 で、サブネット 192.168.1.0 上にある 1 台の CTC が、インターフェイス A を通じてルータに接続されています(ルータでは OSPF が設定されていません)。異なるサブネットにある ONS 15454 は、ノード 1 を経由し、インターフェイス B を通じてルータに接続されています。ノード 2 と 3 は異なるサブネットにあるため、プロキシ ARP ではノード 1 がゲートウェイになりません。LAN A 上の CTC コンピュータに接続するために、スタティック ルートをノード 1 上で作成します。
図 17-6 シナリオ 5:1 台の CTC コンピュータを宛先として使用したスタティック ルート(ANSI および ETSI)
宛先とサブネット マスク エントリは、次のように ONS 15454 へのアクセスを制御します。
• 1 台の CTC コンピュータがルータに接続されている場合、CTC の完全な「ホスト ルート」IP アドレスを、サブネット マスク 255.255.255.255 を指定して宛先として入力します。
• サブネット上の複数の CTC コンピュータがルータに接続されている場合、宛先サブネット(この例では 192.168.1.0)とサブネット マスク 255.255.255.0 を入力します。
• すべての CTC コンピュータがルータに接続されている場合は、宛先 0.0.0.0 とサブネット マスク 0.0.0.0 を入力します。図 17-7 に例を示します。
ルータ インターフェイス B の IP アドレスをネクスト ホップとして入力し、コスト(送信元から宛先へのホップの数)は 2 になります。
図 17-7 シナリオ 5:複数の LAN 宛先があるスタティック ルート(ANSI および ETSI)
17.2.6 シナリオ 6:OSPF の使用
Open Shortest Path First(OSPF)は、リンク ステート インターネット ルーティング プロトコルの 1 つです。リンク ステート プロトコルは、「hello プロトコル」を使用して隣接ルータとのリンクをモニタし、ネイバーへのリンクのステータスをテストします。リンク ステート プロトコルは、直接接続されたネットワークとアクティブ リンクをアドバタイズします。各リンク ステート ルータはリンク ステート「アドバタイズメント」をキャプチャし、それを集めてネットワーク全体またはエリアのトポロジを作成します。ルータは、最短パス ツリーを構築することで、このデータベースからルーティング テーブルを計算します。ルートは、トポロジの変化が発生したときに再計算されます。
ONS 15454 は OSPF プロトコルを、ノードの検出、回線ルーティング、ノード管理のために、内部 ONS 15454 ネットワークで使用します。ONS 15454 トポロジが LAN 上の OSPF ルータに送信されるように、ONS 15454 上で OSPF をイネーブルにできます。ONS 15454 ネットワーク トポロジを LAN ルータにアドバタイズすることで、ONS 15454 サブネットワークのスタティック ルートを手動で入力する必要がなくなります。図 17-8 に、OSPF がイネーブルなネットワークを示します。図 17-9 に、OSPF を使用しない同じネットワークを示します。LAN A 上の CTC コンピュータがノード 2 およびノード 3 と通信するためには、スタティック ルートをルータに手動で追加する必要があります。これは、ノード 2 とノード 3 が異なるサブネットにあるためです。
OSPF では、ネットワークがエリアと呼ばれるより小さい領域に分割されます。エリアは、ネットワークに接続されているエンド システム、ルータ、および送信施設を、トラフィック パターンごとにまとめたものです。各 OSPF エリアには、エリア ID と呼ぶ一意の ID 番号があります。すべての OSPF ネットワークには、「エリア 0」と呼ぶ 1 つのバックボーン エリアがあります。他のすべての OSPF エリアはエリア 0 に接続する必要があります。
OSPF ネットワークにアドバタイズするために ONS 15454 OSPF トポロジをイネーブルにする場合、ONS 15454 ネットワークに 10 進形式で OSPF エリア ID を割り当てる必要があります。エリア ID は、IP アドレスと同様に、「ドット付きの 4 つの数字列」の値です。エリア ID 番号の割り当ては LAN 管理者と調整してください。DCC 接続されているすべての ONS 15454 には、同じ OSPF エリア ID を割り当てる必要があります。
(注) 1 つの OSPF エリア内の ONS 15454 の数は制限することを推奨します。これにより、CTC へのロードが高速になり、問題が発生する可能性が低くなるためです。
図 17-8 シナリオ 6:OSPF がイネーブル(ANSI および ETSI)
図 17-9 シナリオ 6:OSPF がディセーブル(ANSI および ETSI)
17.2.7 シナリオ 7:ONS 15454 プロキシ サーバのプロビジョニング
ONS 15454 プロキシ サーバは、ONS 15454 と CTC コンピュータの間の可視性を制限する必要がある環境で ONS 15454 をネットワーク接続するための一連の機能です。たとえば、フィールド技術者や Network Operations Center(NOC; ネットワーク オペレーション センター)の担当者の両方が同じ ONS 15454 にアクセスできるようにし、フィールド技術者が NOC LAN にアクセスできないようにネットワークを設定できます。そのためには、1 台の ONS 15454 を GNE としてプロビジョニングし、他の ONS 15454 をエンド ENE としてプロビジョニングします。GNE ONS 15454 は CTC コンピュータと ENE ONS 15454 間の接続をトンネリングすることで、管理機能を提供すると共に、ONS 15454 の管理目的以外でのアクセスを防ぎます。
ONS 15454 ゲートウェイの設定は次のことを行います。
• DCC IP トラフィックをイーサネット(クラフト ポート)トラフィックから分離し、フィルタリング ルールに基づいてパケットを受け付けます。フィルタリング ルール(表 17-3 および表 17-4 を参照)は、パケットが ONS 15454 DCC と TCC2/TCC2P/TCC3/TNC/TSC イーサネット インターフェイスのどちらに到着するかに依存します。
• Simple Network Time Protocol(SNTP; 簡易ネットワーク タイム プロトコル)および Network Time Protocol(NTP; ネットワーク タイム プロトコル)の要求を処理します。ONS 15454 ENE は、SNTP/NTP LAN サーバから GNE ONS 15454 を通じて時刻を取得します。
• Simple Network Management Protocol version 1(SNMPv1; 簡易ネットワーク管理プロトコル バージョン 1)トラップを処理します。GNE ONS 15454 は SNMPv1 トラップを ENE ONS 15454 から受信し、SNMPv1 トラップの宛先または ONS 15454 SNMP リレー ノードにトラップを転送または中継します。
ONS 15454 プロキシ サーバは、[Provisioning] > [Network] > [General] タブの [Enable proxy server on port] チェックボックスを使用してプロビジョニングします。このチェックボックスをオンにすると、ONS 15454 は、CTC クライアントと、プロキシ ONS 15454 に DCC 接続されている ONS 15454 の間のプロキシとして機能します。CTC クライアントは、DCC 接続されているノードに、プロキシ ノードを通じて接続を確立します。CTC クライアントは、それが動作しているホストからは直接到達できないノードに接続できます。オンにしない場合、ノードは CTC クライアントのプロキシとして動作しませんが、CTC クライアントが存在する間は確立済みのプロキシ接続が継続されます。また、プロキシ サーバを ENE または GNE として設定できます。
• External Network Element(ENE):ENE として設定されている場合、ONS 15454 は、そのイーサネット ポートを経由するデフォルト ルートまたはスタティック ルートをインストールもアドバタイズもしません。しかし、ENE は、DCC を経由するルートをインストールおよびアドバタイズします。CTC コンピュータは、TCC2/TCC2P/TCC3/TNC/TSC クラフト ポートを使用して ONS 15454 と通信できますが、他の DCC 接続されている ONS 15454 とは直接通信できません。
また、ファイアウォールがイネーブルになるため、ノードは DCC と LAN ポートの間で IP トラフィックがルーティングされるのを防ぎます。ONS 15454 は、LAN ポートに接続されているマシンまたは DCC を通じて接続されているマシンと通信できます。ただし、DCC 接続されているマシンは LAN 接続されているマシンと通信できず、LAN 接続されているマシンは DCC 接続されているマシンと通信できません。ファイアウォールがイネーブルになっているノードに LAN を使用して接続する CTC クライアントは、プロキシ機能を使用して DCC 接続されているノードを管理します。これらのノードには、プロキシ機能を使用しないと到達できません。DCC 接続されているノードに接続された CTC クライアントは、DCC 接続されている他のノードとファイアウォール自身のみを管理できます。
• Gateway Network Element(GNE; ゲートウェイ ネットワーク エレメント):GNE として設定されている CTC コンピュータは、DCC 接続されている他のノードから参照でき、ファイアウォールがイネーブルになっています。
• SOCKS プロキシのみ:[Proxy-only] が選択されている場合、ファイアウォールはイネーブルになりません。CTC は DCC 接続されている他の ONS 15454 と通信できます。
(注) Network Address Translation(NAT; ネットワーク アドレス変換)ルータまたは Port Address Translation(PAT; ポート アドレス変換)ルータを通じ、ノードに対して CTC を起動し、そのノードでプロキシがイネーブルになっていない場合、CTC セッションが開始され、最初は正常に見えます。しかし、CTC はアラーム更新を受信せず、2 分ごとに切断と再接続を行います。プロキシが誤ってディセーブルになっている場合でも、再接続サイクル中にプロキシをイネーブルにし、NAT または PAT ファイアウォール経由であってもノードを管理するための機能を回復できます。
(注) 異なるプライベート サブネットワークに属する ENE は、一意の IP アドレスを持っている必要はありません。異なる GNE に接続されている 2 台の ENE の IP アドレスが同じであってもかまいません。ただし、同じ GNE に接続されている ENE の IP アドレスは必ず一意であることが必要です。
図 17-10 に ONS 15454 プロキシ サーバの実装を示します。GNE ONS 15454 はセントラル オフィスの LAN と ENE ONS 15454 に接続されています。セントラル オフィスの LAN は、CTC コンピュータがある NOC LAN に接続されています。NOC CTC コンピュータの技術者とクラフト技術者は、どちらも ONS 15454 ENE にアクセスできる必要があります。しかし、クラフト技術者が NOC またはセントラル オフィスの LAN にアクセスまたは参照することを防ぐ必要があります。
この例で、ONS 15454 GNE にはセントラル オフィスの LAN 内の IP アドレスが割り当てられ、LAN ポートを通じて LAN に物理的に接続されています。ONS 15454 ENE には、セントラル オフィスの LAN の範囲外の IP アドレスが割り当てられ、プライベート ネットワークの IP アドレスが付与されます。ONS 15454 ENE がコロケーションされている場合、クラフト LAN ポートはハブに接続することもできます。ただし、ハブには他のネットワーク接続があってはなりません。
図 17-10 シナリオ 7:GNE と ENE が同じサブネットにある ONS 15454 プロキシ サーバ(ANSI および ETSI)
表 17-2 に、図 17-10 に示す構成での ONS 15454 GNE および ENE の推奨される設定を示します。
表 17-2 ONS 15454 ゲートウェイとエンド NE の設定
|
|
|
OSPF |
オフ |
オフ |
SNTP サーバ(使用する場合) |
SNTP サーバの IP アドレス |
ONS 15454 GNE の IP アドレスに設定 |
SNMP(使用する場合) |
SNMPv1 トラップの宛先 |
SNMPv1 トラップの宛先を ONS 15454 GNE のポート 391 に設定 |
図 17-11 に、異なるサブネットに ONS 15454 ENE がある同じプロキシ サーバの実装を示します。ONS 15454 GNE と ENE は、 表 17-2 に示す設定を使用してプロビジョニングされています。
図 17-11 シナリオ 7:GNE と ENE が異なるサブネットにある ONS 15454 プロキシ サーバ(ANSI および ETSI)
図 17-12 に、複数のリングに ONS 15454 ENE がある同じプロキシ サーバの実装を示します。
図 17-12 シナリオ 7:複数のリングに ENE がある ONS 15454 プロキシ サーバ(ANSI および ETSI)
表 17-3 に、ノードが ENE および GNE として設定されている場合に、ファイアウォールのパケットをフィルタするために ONS 15454 が従うルールを示します。パケットが ONS 15454 宛の場合、追加のルール( 表 17-4 を参照)が適用されます。拒否されたパケットはそのまま廃棄されます。
表 17-3 プロキシ サーバ ファイアウォール フィルタリング ルール
|
|
TCC2/TCC2P/TCC3/TNC/TSC イーサネット インターフェイス |
• ONS 15454 自身 • ONS 15454 のサブネット ブロードキャスト アドレス • 224.0.0.0/8 ネットワーク内(標準的なマルチキャスト メッセージのために使用される予約済みネットワーク) • サブネット マスク = 255.255.255.255 |
DCC インターフェイス |
• ONS 15454 自身 • 別の DCC インターフェイスを通じて接続された任意の宛先 • 224.0.0.0/8 ネットワーク内 |
表 17-4 プロキシ サーバ ファイアウォール フィルタリング ルール
|
|
TCC2/TCC2P/TCC3/TNC/TSC イーサネット インターフェイス |
• SNMP トラップ リレー ポート(391)宛の User Datagram Protocol(UDP; ユーザ データグラム プロトコル)パケット |
DCC インターフェイス |
• プロキシ サーバ ポート(1080)宛の Transmission Control Protocol(TCP; 伝送制御プロトコル)パケット |
プロキシ サーバを実装する場合、同じイーサネット セグメント上にある、DCC 接続されたすべての ONS 15454 のゲートウェイ設定が同じでなければならないことに注意してください。値が混在すると予測できない結果が生じ、共有イーサネット セグメントを通じて一部のノードに到達できなくなることがあります。
ノードが到達不能になった場合、次のいずれかの手順を実行して設定を修正します。
• 到達不能な ONS 15454 からクラフト コンピュータを切断します。到達不能な ONS 15454 への DCC 接続を持つ別のネットワーク ONS 15454 を通じて ONS 15454 に接続します。
• ネイバー ノードで DCC をディセーブルにすることで、ノードへのすべての DCC を切断します。CTC コンピュータを直接 ONS 15454 に接続し、そのプロビジョニングを変更します。
17.2.8 シナリオ 8:1 つのサブネット上の 2 台の GNE
ONS 15454 は GNE のロード バランシング機能を提供します。これにより CTC は、OSPF 上で ENE をアドバタイズすることなく、複数の GNE 上で ENE に到達できます。この機能により、ネットワークは、GNE が異なるサブネットにある場合でも、GNE の損失からすばやく復旧できます。GNE が障害になった場合、その GNE を経由するすべての接続が障害になります。CTC は障害になった GNE と、その GNE がプロキシになっていたすべての ENE から切断し、残りの GNE を通じて再接続します。GNE のロード バランシングにより、起動 GNE と DCC バンド幅への依存度が減り、その両方により CTC のパフォーマンスが向上します。
(注) デュアル GNE は、特殊なプロビジョニングを必要としません。
図 17-13 に、同じサブネット上に 2 台の GNE があるネットワークを示します。
図 17-13 シナリオ 8:同じサブネット上の 2 台の GNE(ANSI および ETSI)
図 17-14 に、異なるサブネット上に 2 台の GNE があるネットワークを示します。
図 17-14 シナリオ 8:異なるサブネット上の 2 台の GNE(ANSI および ETSI)
17.2.9 シナリオ 9:IP セキュア モードをイネーブルにした IP アドレッシング
TCC2、TCC2P、TCC3、TNC、および TSC カードのデフォルトのモードはリピータ モードです。このモードでは、前面と背面のイーサネット(LAN)ポートが 1 つの MAC アドレスと IP アドレスを共有します。TCC2P、TCC3、TNC、および TSC カードでは、ノードをセキュア モードにできます。このモードでは、前面アクセス クラフト ポートのユーザによるバックプレーン ポートを通じた LAN へのアクセスが禁止されます。セキュア モードをロックして、モードを変更できなくすることもできます。ノードをセキュア モードにする方法やセキュア ノードをロックする方法については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Manage the Node」の章を参照してください。
17.2.9.1 セキュア モードの動作
TCC2P、TCC3、TNC、または TSC ノードをリピータ モードからセキュア モードに変更すると、ONS 15454 に 2 個の IP アドレスをプロビジョニングでき、ポートに異なる MAC アドレスが割り当てられます。セキュア モードでは、1 個の IP アドレスが ONS 15454 バックプレーン LAN ポート用にプロビジョニングされ、もう 1 個の IP アドレスが、カードのイーサネット ポート用にプロビジョニングされます。どちらのアドレスも異なるサブネット上に存在し、クラフト アクセス ポートと ONS 15454 LAN の間でさらなる分離層が提供されます。セキュア モードがイネーブルな場合、バックプレーン LAN ポートとカードのイーサネット ポート用にプロビジョニングされた IP アドレスは、一般的なアドレッシング ガイドラインに従い、互いに異なるサブネットに存在する必要があります。
セキュア モードでは、バックプレーン LAN ポートに割り当てられた IP アドレスがプライベート アドレスになります。これによりノードは、セントラル オフィス LAN またはプライベート エンタープライズ ネットワークを通じて Operations Support System(OSS; オペレーション サポート システム)に接続されます。スーパーユーザは、CTC、ルーティング テーブル、または TL1 自律メッセージ レポート内で、バックプレーンの LAN の IP アドレスを隠蔽または公開するように設定できます。
リピータ モードでは、ノードを GNE または ENE にすることができます。ノードをセキュア モードにすると、SOCKS プロキシが自動的に有効になり、ノードがデフォルトで GNE ステータスになります。ただし、ノードを ENE に戻すことができます。リピータ モードでは、ENE の SOCKS プロキシをディセーブルにし、LAN ファイアウォールを超えてノードを効果的に分離できます。しかし、セキュア モードでは SOCKS プロキシをディセーブルにできません。ノードの GNE または ENE ステータスを変更し、SOCKS プロキシをディセーブルにする方法については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Turn Up a Node」の章を参照してください。
注意
セキュア モードをイネーブルにすると、TCC2P、TCC3、TNC、および TSC カードがリブートし、トラフィックに影響を与えます。
(注) TCC2 カードが取り付けられている場合、セキュア モード オプションが CTC に表示されません。1 枚の TCC2 と 1 枚の TCC2P カードがノードに取り付けられている場合、セキュア モードが CTC に表示されますが、変更はできません。
(注) 前面ポートとバックプレーン アクセス ポートの両方が ENE でディセーブルになっており、ノードが DCC 通信から切り離されている場合(ユーザ プロビジョニングまたはネットワーク障害により)、前面ポートとバックプレーン ポートは自動的に再度イネーブルになります。
図 17-15 に、同じサブネット上に存在する前面アクセス イーサネット ポート アドレスを使用した、セキュア モード ONS 15454 ノードの例を示します。
図 17-15 シナリオ 9:セキュア モードがイネーブルな同じサブネット上の ONS 15454 GNE と ENE
図 17-16 に、セキュア モードをイネーブルにしてルータに接続した ONS 15454 ノードの例を示します。それぞれの例で、ノードのポート アドレス(ノード アドレス)は、ノードのバックプレーン アドレスと異なるサブネット上にあります。
図 17-16 シナリオ 9:セキュア モードがイネーブルな異なるサブネット上の ONS 15454 GNE と ENE
17.2.9.2 セキュア ノードのロックおよびロック解除動作
セキュア モードは、セキュア モードで動作するノード上でロックまたはロック解除できます。デフォルトのステータスはロック解除であり、スーパーユーザのみがロックを実行できます。セキュア モードがロックされている場合、どのネットワーク ユーザもノードの設定(イーサネット ポートのステータスを含む)とロック ステータスを変更できません。セキュア ノードのロックを解除するには、シスコのテクニカル サポートに連絡し、シェルフ アセンブリの Return Material Authorization(RMA)を手配してください。必要に応じて「マニュアルの入手方法およびテクニカル サポート」を参照してください。ロックをイネーブルにすると、シェルフの EEPROM が永続的に変更されます。
ノードの設定ロックは、アクティブな TCC2P、TCC3、TNC、または TSC カードのデータベースをリロードしても保持されます。たとえば、ロック解除されているノードのデータベースを、アクティブな TCC2P、TCC3、TNC、または TSC カードへの転送のために、ロックされているノードのスタンバイ TCC2P、TCC3、TNC、または TSC カードにロードしようとしても(推奨されない操作)、ロック解除されているノードのステータス(アップロードされたデータベースによる)でノードのロック ステータスは上書きされません。ロックされているデータベースを、ロック解除されているセキュア ノードのスタンバイ TCC2P、TCC3、TNC、または TSC カードにロードしようとすると、アクティブな TCC2P、TCC3、TNC、または TSC カードがデータベースをアップロードします。アップロードされたデフォルトがロック済みステータスを示している場合、ノードがロック状態になります。ロックをイネーブルにする前にソフトウェア ロードがカスタマイズされている場合、ロック可能なすべてのプロビジョニング機能が、ロードで提供されているカスタマイズされた NE デフォルトに永続的に設定され、どのユーザも変更できません。
17.3 DCN ケース スタディ
ONS 15454 ネットワークは IP DCN と Optical Service Channel(OSC; 光サービス チャネル)、DCC、および Generic Communications Channel(GCC)上で管理されます。ONS 15454 は、DCN Network Management System(NMS; ネットワーク管理システム)と Dense Wavelength Division Multiplexing(DWDM; 高密度波長分割多重)の間のトラフィックを管理するため、レイヤ 3 ルータと同じ機能の多くを実行します。
ここでは、DCN 内で ONS 15454 ネットワークを実装するためのさまざまな方法を示すケース スタディについて説明します。各ケース スタディは、実際のフィールドでの設置を基にしています。ケース スタディには、ネットワークの問題、それを解決するために作成されたネットワーク トポロジ、IP アドレッシングの例、ソリューションの利点と欠点が含まれています。ケース スタディ全体で従うルーティングの原理としては、次のものがあります。
• ONS 15454 が DCN ルータに接続されている場合、デフォルト ゲートウェイはルータを指します。
• デフォルト ゲートウェイが OSC/DCC/GCC ネットワークにアドバタイズする必要がある場合、デフォルト ゲートウェイのスタティック ルートが追加されます。
• Network Element(NE; ネットワーク要素)が DCN ルータに接続されていない場合、デフォルト ゲートウェイは 0.0.0.0 に設定されます。
17.3.1 SOCKS プロキシの設定
SOCKS プロキシ(「シナリオ 7:ONS 15454 プロキシ サーバのプロビジョニング」を参照)を使用すると、ONS 15454 は、CTC クライアントと OSC、GCC、または DCC で接続された ONS 15454 ノードの間の接続のためのプロキシとして動作します。SOCKS プロキシにより DCN の実装が容易になりますが、次のいずれかの条件が存在する場合には使用しないことを推奨します。
• SNMP と SNMP トラップに基づいてネットワーク管理を行っている場合。ONS 15454 は SNMP トラップをプロキシ処理できますが、冗長な DCN 接続が必要な場合、ネットワーク管理プラットフォーム上でトラップの重複が発生します。
• Telnet とデバッグ セッションが必要な場合。これらは SOCKS プロキシ上では使用できません。
• すべてのノードへの直接 IP 接続が必要な場合。
これらの条件が存在せず、すべてのノードへの直接 IP 接続が不要な場合(つまり、CTC または Cisco Transport Manager(CTM)を使用して管理を行う場合)、DCN ルータに接続するすべてのノードで SOCKS プロキシのみのオプションを使用することを推奨します。
17.3.2 OSPF
ONS 15454 LAN インターフェイス上で OSPF をアクティブ化(「シナリオ 6:OSPF の使用」を参照)することは、復元力のある DCN 接続を作成するために使用できるもう 1 つの方法です。ただし、この方法は、NE から NOC まで、ネットワークのすべての要素で OSPF を実行している場合にのみ使用できます。これは必ずしも可能ではありません。たとえば、DCN 接続は、ONS 15454 ネットワークを使用している組織の制御が及ばないパブリック ネットワーク上に存在する場合があります。LAN 上で OSPF をイネーブルにすることを検討している場合、次の制限事項を考慮する必要があります。
• LAN 上で OSPF をイネーブルにする場合、内部 OSC/DCC/GCC OSPF エリアは 0.0.0.0 にできません。
• ONS 15454 は、OSPF エリア ボーダー ゲートウェイとして動作し、OSPF 仮想リンクをサポートできます。ただし、仮想リンクは OSC/DCC/GCC ネットワークを通過できません。
DCN ネットワーク内のすべての要素で OSPF が動作していない場合、分離されたエリアを作成するか OSPF エリア 0 を分割することなく LAN 上で OSPF をイネーブルにすることは非常に困難です。ただし、DCN ネットワークが完全な OSPF ネットワークの場合、復元力のある DCN ネットワークのために、LAN 上で OSPF をイネーブルにできます。
17.3.3 LAN 接続されていないマルチシェルフ ノードの管理
Dense Wavelength Division Multiplexing(DWDM; 高密度波長分割多重)マルチシェルフ管理機能を使用してノード コントローラ シェルフからの範囲を定める場合、ノード コントローラは、直接 LAN に到達できない場合に備えて特別にプロビジョニングする必要があります。
LAN 接続されていないマルチシェルフ ノードは、ノードで SOCKS プロキシをイネーブルにしない限り、CTC から管理できません。GNE/ENE ファイアウォール構成で、LAN 接続されていないネットワーク要素は、ファイアウォールが必要な場合、End Network Element(ENE; エンド ネットワーク要素)として設定する必要があります。LAN 接続されていないマルチシェルフ ノードでファイアウォールが不要な場合、ノードは SOCKS プロキシとして設定する必要があります。
LAN-Connected Network Element(LNE; LAN 接続ネットワーク要素)は、ネットワークのセキュリティ要件に応じて、Gateway Network Element(GNE; ゲートウェイ ネットワーク要素)または SOCKS プロキシとして設定できます。GNE/ENE ファイアウォール機能が必要な場合は、LNE を GNE として設定する必要があります。ファイアウォール機能は不要でも全 IP のネットワーキングが必要な設計の場合は、LNE を SOCKS プロキシとして設定する必要があります。ノードまたはシェルフを GNE、ENE、または SOCKS プロキシとしてプロビジョニングするための手順については、『 Cisco ONS 15454 DWDM Procedure Guide 』を参照してください。
17.3.4 DCN ケース スタディ 1:2 個のサブネットと 2 個の DCN 接続があるリング トポロジ
DCN ケース スタディ 1(図 17-17)は、ONS 15454 リング(DWDM または SONET/SDH)を示しています。リングは 2 個のサブネットに分割され、復元力のために 2 個の DCN 接続があります。
図 17-17 DCN ケース スタディ 1:2 個のサブネットと 2 個の DCN 接続がある ONS 15454 リング
通常運用中は、使用可能な 2 個の DCN 接続上に管理トラフィック負荷が分散されます。2 個の DCN 接続のいずれかが障害になった場合、第 2 の DCN 接続によってアクセシビリティが維持されるため、NE の管理を継続できます。しかし、SOCKS プロキシを使用できない場合の SNMP 用など、完全な IP の接続性が必要な場合、接続の復元力を達成することは次の理由で難しくなります。
• ONS 15454 はルートのオーバーロードをサポートしていません。同じネットワーク宛先に対して異なるコストで異なるルートを設定できません。
• LAN インターフェイスのリンクがアップ状態の場合、ONS 15454 は常にトラフィックをそのインターフェイス上でルーティングしようと試み、DCN ルータに接続されている NE 上のリンクは常にアップ状態になります。
• DCN 接続が障害になった場合、ルータは使用できます。
1 つの解決方法は、Generic Routing Encapsulation(GRE; 総称ルーティング カプセル化)トンネルを作成し、OSC/DCC/GCC ネットワークを使用してリモート ルータ 1 とリモート ルータ 2 を論理的に接続することです(図 17-18)。GRE トンネルがあれば、両方のリモート ルータに、DCN 障害の場合に NOC ネットワークに到達するための代替パスができます。ただし、代替パスはルーティング テーブルでオーバーロードになり、コストが高くなる可能性があります。
図 17-18 DCN ケース スタディ 1:2 個のサブネット、2 個の DCN 接続、GRE トンネルがある ONS 15454 リング
17.3.4.1 DCN ケース スタディ 1 の IP 設定
次の各項では、DCN ケース スタディ 1 におけるルータおよび ONS 15454 ノードでの IP 設定の例を示します。
17.3.4.1.1 NOC ルータの設定
インターフェイス設定
ip address 10.58.46.121 255.255.255.192
ip address 192.168.20.1 255.255.255.0
ip address 192.168.10.1 255.255.255.0
異なるコストでの代替パスを使用したスタティック ルート
ip route 192.168.100.0 255.255.255.0 192.168.10.2
ip route 192.168.100.0 255.255.255.0 192.168.20.2 10
ip route 192.168.200.0 255.255.255.0 192.168.20.2
ip route 192.168.200.0 255.255.255.0 192.168.10.2 10
17.3.4.1.2 ルータ 1 の IP の設定
インターフェイス設定
ip address 192.168.10.2 255.255.255.0
ip address 192.168.100.1 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.30.1 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.200.1
異なるコストでの代替パスを使用したスタティック ルート
ip route 0.0.0.0 0.0.0.0 192.168.10.1
ip route 10.0.0.0 255.0.0.0 192.168.10.1
ip route 10.0.0.0 255.0.0.0 Tunnel0 10
ip route 192.168.200.0 255.255.255.0 Tunnel0 10
ip route 192.168.200.1 255.255.255.255 192.168.100.80
ピア ルータ 2(192.168.200.1)へのホスト ルートは、ONS 15454 ネットワーク(192.168.100.80 経由)を指すことに注意してください。これは、GRE トンネルを設定するために必要です。この設定で、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスでオーバーロードされます。ただし、オーバーロードはこのラストリゾート ルートのみで発生します。
17.3.4.1.3 ルータ 2 の IP の設定
インターフェイス設定
ip address 192.168.20.2 255.255.255.0
ip address 192.168.200.1 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.30.2 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.100.1
異なるコストでの代替パスを使用したスタティック ルート
ip route 0.0.0.0 0.0.0.0 192.168.20.1
ip route 10.0.0.0 255.0.0.0 192.168.20.1
ip route 10.0.0.0 255.0.0.0 Tunnel0 10
ip route 192.168.100.0 255.255.255.0 Tunnel0 10
ip route 192.168.100.1 255.255.255.255 192.168.200.77
ルータ 1(192.168.100.1)へのホスト ルーティング パスは、ONS 15454 ネットワーク(192.168.200.77 によります)を指します。これは、GRE トンネルを設定するために必要です。この設定で、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスでオーバーロードされます。ただし、ラストリゾート ルートのオーバーロードが発生する可能性があります。 表 17-5 に、4 台の 15454 ノード上でのネットワーク設定を示します。スタティック ルートが作成されるため、DCN 接続されているノードは、ラストリゾート ルータとして動作できることをアドバタイズします。
表 17-5 DCN ケース スタディ 1 のノードの IP アドレス
|
|
|
|
ノード 1 |
192.168.100.80/24 |
192.168.100.1 |
0.0.0.0/0 - 192.168.100.1 |
ノード 2 |
192.168.100.79/24 |
0.0.0.0 |
-- |
ノード 3 |
192.168.100.78/24 |
0.0.0.0 |
-- |
ノード 4 |
192.168.100.77/24 |
192.168.100.1 |
0.0.0.0/0 - 192.168.200.1 |
17.3.4.2 DCN ケース スタディ 1 の制限事項
DCN ケース スタディ 1 は、2 台のルータ間で GRE トンネルを作成し、DCN 接続の復元力を持たせる方法を示しています。復元力は長所ですが、DCN 障害によりトラフィックが GRE トンネルに向けられると、OSC/DCC/GCC ネットワークで動作している ONS 15454 OSPF アルゴリズムによって計算されたパスは最短パスでなくなります。この構成における DCN 保護は ONS 15454 ネットワークに透過的であるため、以降、Round-trip delay Time(RTT; ラウンドトリップ遅延時間)が大幅に増加する可能性があります。ONS 15454 は同じルーティング テーブルを使用し続けます。また、DCN の障害が発生した場合、GRE トンネルを使用するルーティング パスでは、ONS 15454 ネットワーク上でトンネルが通過する必要がある OSC/DCC/GCC スパンの数と長さが増えるため、遅延がさらに増加します。
この遅延により、この DCN ケース スタディ 1 のソリューションを大規模なネットワークに適用するのが難しくなります。このソリューションを使用し、ネットワークの規模が大きくなった場合、多数の DCN 接続 NE が必要になります。たとえば、ONS 15454 DCN の設計における一般的なルールは、すべてのノードが、ネットワークに接続されているノードから 5 セクション データ通信チャネル(LDCC)/再生成セクション DCC(RS-DCC/OSC)または 8 回線 DCC(LDCC)/多重化セクション DCC(MS-DCC)スパン以内にある必要があるというものです。ケース スタディ 1 の設計を実装する場合、最大スパン数を半分にする必要があります。ただし、DCN ケース スタディ 1 の設計を、完全な IP ルーティングがあり、すべての NE に接続でき、CTC または CTM の管理だけが必要なネットワークで使用する場合、SOCKS プロキシ機能を使用して同じ DCN 接続の復元力を提供できます。
17.3.5 DCN ケース スタディ 2:両端に DCN 接続がある線形トポロジ
図 17-19 に示す DCN ケース スタディ 2 は、両端に DCN 接続がある 4 ノードの線形トポロジを示しています。
図 17-19 DCN ケース スタディ 2:両端に DCN 接続がある ONS 15454 線形トポロジ
DCN の復元力を維持するため、DCC/OSC/GCC 光リンク上のルータ 1 とルータ 2 の間でスタティック ルートが使用され、GRE トンネルが作成されます。この例で、すべての ONS 15454 は同じサブネットに属しています。これにより、すべてのホストの代替パスを設定する必要があるため、ルータ 1 とルータ 2 のスタティック ルート テーブルにはより多くのエントリがあります。
17.3.5.1 DCN ケース スタディ 2 の IP 設定
次の各項では、DCN ケース スタディ 2 におけるルータおよび ONS 15454 ノードでの IP 設定の例を示します。
17.3.5.1.1 NOC ルータの IP 設定
インターフェイス設定
ip address 10.58.46.121 255.255.255.192
ip address 192.168.20.1 255.255.255.0
ip address 192.168.10.1 255.255.255.0
異なるコストでの代替パスを使用したスタティック ルート
ip route 192.168.100.0 255.255.255.0 192.168.10.2
ip route 192.168.100.0 255.255.255.0 192.168.20.2 100
ip route 192.168.100.77 255.255.255.255 192.168.20.2
ip route 192.168.100.77 255.255.255.255 192.168.10.2 10
ip route 192.168.100.78 255.255.255.255 192.168.20.2
ip route 192.168.100.78 255.255.255.255 192.168.10.2 10
ip route 192.168.100.79 255.255.255.255 192.168.10.2
ip route 192.168.100.79 255.255.255.255 192.168.20.2 10
ip route 192.168.100.80 255.255.255.255 192.168.10.2
ip route 192.168.100.80 255.255.255.255 192.168.20.2 10
17.3.5.1.2 ルータ 1 の IP の設定
サイト 1 ルータ インターフェイス
ip address 192.168.10.2 255.255.255.0
ip address 192.168.100.1 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.30.1 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.100.2
異なるコストでの代替パスを使用したスタティック ルート
ip route 0.0.0.0 0.0.0.0 192.168.10.1
ip route 10.0.0.0 255.0.0.0 192.168.10.1
ip route 10.0.0.0 255.0.0.0 Tunnel0 10
ip route 192.168.100.2 255.255.255.255 192.168.100.80
ピア DCN ルータ(サイト 2、192.168.100.2)へのホスト ルーティング パスは、GRE トンネルを設定するために必要な ONS 15454 ネットワーク(192.168.100.80 による)を指していることに注意してください。この設定で、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスでオーバーロードされますが、ラストリゾート ルートのオーバーロードも起きる可能性があります。
17.3.5.1.3 ルータ 2 の IP の設定
インターフェイス設定
ip address 192.168.20.2 255.255.255.0
ip address 192.168.100.2 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.30.2 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.100.1
異なるコストでの代替パスを使用したスタティック ルート
ip route 0.0.0.0 0.0.0.0 192.168.20.1
ip route 10.0.0.0 255.0.0.0 192.168.20.1
ip route 10.0.0.0 255.0.0.0 Tunnel0 10
ip route 192.168.100.1 255.255.255.255 192.168.100.77
ルータ 1(192.168.100.1)へのホスト ルートは、ONS 15454 ネットワーク(192.168.200.77 による)を指すことに注意してください。これは、GRE トンネルを設定するために必要です。この設定で、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスでオーバーロードされます。ただし、ラストリゾート ルートのオーバーロードも発生する可能性があります。
表 17-6 に、4 台の 15454 ノード上でのネットワーク設定を示します。スタティック ルートが作成されるため、DCN 接続されているノードは、ラストリゾート ルータとして動作できることをアドバタイズします。
表 17-6 DCN ケース スタディ 2 のノード IP アドレス
|
|
|
|
ノード 1 |
192.168.100.80/24 |
192.168.100.1 |
0.0.0.0/0 - 192.168.100.1 |
ノード 2 |
192.168.100.79/24 |
0.0.0.0 |
-- |
ノード 3 |
192.168.100.78/24 |
0.0.0.0 |
-- |
ノード 4 |
192.168.100.77/24 |
192.168.100.1 |
0.0.0.0/0 - 192.168.200.1 |
17.3.5.2 DCN ケース スタディ 2 の制限事項
DCN ケース スタディ 2 の線形構成では、DCN ルータに障害が通知されないため、すべてのファイバ障害で管理ネットワークの通信が効果的に保護されるわけではありません。そのため、DCN ルータは、低コストのパス上でパケットの送信を続けます。この問題は、ファイバの障害が光リング ネットワークから内部的に保護されるリング トポロジでは発生しません。しかし、OSPF ダイナミック ルーティング プロトコルを DCN ネットワーク上で使用して、この問題に対する解決策を提供できます。OSPF の設定を DCN ケース スタディ 3 に示します。
17.3.6 DCN ケース スタディ 3:OSPF ルーティングを使用した、両端に DCN 接続がある線形トポロジ
DCN ケース スタディ 3 は、DCN ネットワークで OSPF ルーティングを使用することを除き、DCN ケース スタディ 2 と同じ線形トポロジです。そのためには、エンド ONS 15454 ノードで、ノード ビュー(シングルシェルフ モード)またはマルチシェルフ ビュー(マルチシェルフ モード)の [Provisioning] > [Network] > [OSPF] タブの [OSPF active on LAN] オプションをイネーブルにする必要があります。また、OSPF がルータ 1、ルータ 2、および NOC ルータの間で動作している必要があります。
通常、DCN 接続は、必ずしも OSPF を選択できるわけではないパブリック ネットワーク上を通過するため、ルータ 1、ルータ 2、および NOC ルータ間の接続は GRE トンネルとして設定され、OSPF をトンネル自体で実行できます。
図 17-20 に、個別の OSPF エリア、トンネル接続、必要な OSPF 仮想リンクがある線形構成を示します(トンネルが通過する物理接続は、実際のルーティング パスの直接の一部ではないため、図に示していません)。
図 17-20 DCN ケース スタディ 3:OSPF を使用した、両端に DCN 接続がある ONS 15454 線形トポロジ
17.3.6.1 DCN ケース スタディ 3 の IP 設定
次の各項では、DCN ケース スタディ 3 のルータおよび ONS 15454 ノードでの IP 設定の例を示します。
17.3.6.1.1 NOC ルータの IP 設定
インターフェイス設定
ip address 10.58.46.121 255.255.255.192
ip address 192.168.20.1 255.255.255.0
ip address 192.168.10.1 255.255.255.0
ip address 1.1.1.1 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.110.1 255.255.255.0
tunnel source Ethernet2/0
tunnel destination 192.168.10.2
ip address 192.168.210.1 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.20.2
OSPF ルーティングの設定
network 1.1.1.0 0.0.0.255 area 0
network 10.0.0.0 0.255.255.255 area 0
network 192.168.110.0 0.0.0.255 area 100
network 192.168.210.0 0.0.0.255 area 200
area 100 virtual-link 192.168.100.80
area 200 virtual-link 192.168.100.77
DCC/OSC/GCC OSPF エリア 1 をバックボーン エリア 0 に接続するために、エンド ONS 15454 への OSPF 仮想リンクが作成されていることに注意してください。NOC ルータではスタティック ルートが定義されません。
17.3.6.1.2 ルータ 1 の IP の設定
インターフェイス設定
ip address 192.168.10.2 255.255.255.0
ip address 192.168.100.1 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.110.2 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 192.168.10.1
OSPF とスタティック ルーティングの設定
network 192.168.100.0 0.0.0.255 area 100
network 192.168.110.0 0.0.0.255 area 100
ip route 0.0.0.0 0.0.0.0 192.168.10.1
17.3.6.1.3 ルータ 2 の IP の設定
インターフェイス設定
ip address 192.168.20.2 255.255.255.0
ip address 192.168.100.2 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.210.2 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 192.168.20.1
OSPF とスタティック ルーティングの設定
network 192.168.100.0 0.0.0.255 area 200
network 192.168.210.0 0.0.0.255 area 200
ip route 0.0.0.0 0.0.0.0 192.168.20.1
表 17-7 に、4 台の 15454 ノード上でのネットワーク設定を示します。スタティック ルートが作成されるため、DCN 接続されているノードは、ラストリゾート ルータとして動作できることをアドバタイズできます。
表 17-7 DCN ケース スタディ 3 のノードの IP アドレス
|
|
|
|
ノード 1 |
192.168.100.80/24 |
192.168.100.1 |
DCC/OSC/GCC エリア:0.0.0.1 LAN エリア:0.0.0.100 OSPF エリア範囲テーブル • 192.168.100.79/32:エリア 0.0.0.1 • 192.168.100.78/32:エリア 0.0.0.1 • 192.168.100.77/32:エリア 0.0.0.1 仮想リンク テーブル:1.1.1.1 |
ノード 2 |
192.168.100.79/24 |
0.0.0.0 |
DCC/OSC/GCC エリア:0.0.0.1 LAN 上で OSPF がディセーブル |
ノード 3 |
192.168.100.78/24 |
0.0.0.0 |
DCC/OSC/GCC エリア:0.0.0.1 LAN 上で OSPF がディセーブル |
ノード 4 |
192.168.100.77/24 |
192.168.100.1 |
DCC/OSC/GCC エリア:0.0.0.1 LAN エリア:0.0.0.200 OSPF エリア範囲テーブル • 192.168.100.80/32:エリア 0.0.0.1 • 192.168.100.79/32:エリア 0.0.0.1 • 192.168.100.78/32:エリア 0.0.0.1 仮想リンク テーブル:1.1.1.1 |
OSPF 仮想リンクでは、そのネイバーが、ネットワークに接続されている物理インターフェイスまたはトンネル インターフェイスではなく、そのルータ ID で示されることが必要です。NOC ルータ上のループバック インターフェイスを使用することで、実際のインターフェイスの IP アドレスとは独立してルータ ID を選択できます。
17.3.6.2 DCN ケース スタディ 3 の制限事項
DCN ケース スタディ 3 は、OSPF が DCN の高い復元力とより効率的なルーティングの選択肢を提供し、これによりパフォーマンスが向上することを示しています。OSPF は、ネットワークの高いスケーラビリティも提供します。OSPF を使用した場合の制限事項には次のものがあります。
• OSPF では複雑さが増します。たとえば、ONS 15454 とルータで OSPF 仮想リンクとアドバタイズメントをプロビジョニングするには、検討と計画が必要です。
• NOC とサイト ルータの間の DCN 接続で OSPF をイネーブルにする必要があります。これは、このケース スタディに示すように、GRE トンネルを通じて行うこともできます。
• OSPF エリアの分離について計画と検討を行う必要があります。「OSPF」 に示す制限を克服しバックボーン エリアでの分離されたエリアとセグメンテーションを避けるために仮想リンクを作成する場合も、同様に計画が必要です。
17.3.7 DCN ケース スタディ 4:2 個の DCN 接続がある、2 個の線形カスケード トポロジ
図 17-21 に示す DCN ケース スタディ 4 では、DCN ケース スタディ 3 に示されている単純な線形トポロジが拡張されています。ただし、この例で、同じサイト ルータに向かう 2 個の線形 DCN 接続とすべての ONS 15454 は同じサブネット内にあります。GRE トンネルは、リモート ルータ 1 とルータ 2 を OSC/DCC/GCC ネットワーク上で論理的に接続し、DCN ケース スタディ 1 の構成と似ています(図 17-18)。GRE トンネルは、DCN 障害が発生した場合に NOC ネットワークに到達するための代替パスをリモート ルータに提供します。しかし、ONS 15454 が同じサブネットにあることから、すべての代替パスがホストベースであるため、代替パスはルータ ルーティング テーブルをオーバーロードし、よりコストが高くなる可能性があります。
図 17-21 DCN ケース スタディ 4:2 個の DCN 接続がある、2 個の線形カスケード トポロジ
17.3.7.1 DCN ケース スタディ 4 の IP 設定
次の各項では、DCN ケース スタディ 4 のルータおよび ONS 15454 ノードでの IP 設定の例を示します。
17.3.7.1.1 NOC ルータの IP 設定
インターフェイス設定
ip address 10.58.46.121 255.255.255.192
ip address 192.168.20.1 255.255.255.0
ip address 192.168.10.1 255.255.255.0
異なるコストでの代替パスを使用したスタティック ルート
ip route 192.168.100.0 255.255.255.0 192.168.10.2
ip route 192.168.100.0 255.255.255.0 192.168.20.2 100
ip route 192.168.100.77 255.255.255.255 192.168.20.2 10
ip route 192.168.100.77 255.255.255.255 192.168.10.2 20
ip route 192.168.100.78 255.255.255.255 192.168.20.2
ip route 192.168.100.78 255.255.255.255 192.168.10.2 10
ip route 192.168.100.79 255.255.255.255 192.168.20.2
ip route 192.168.100.79 255.255.255.255 192.168.10.2 10
ip route 192.168.100.80 255.255.255.255 192.168.10.2
ip route 192.168.100.80 255.255.255.255 192.168.20.2 10
ip route 192.168.200.0 255.255.255.0 192.168.20.2
ip route 192.168.200.0 255.255.255.0 192.168.10.2 100
17.3.7.1.2 ルータ 1 の IP の設定
インターフェイス設定
ip address 192.168.10.2 255.255.255.0
ip address 192.168.100.1 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.30.1 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.100.2
異なるコストでの代替パスを使用したスタティック ルート
ip route 0.0.0.0 0.0.0.0 192.168.10.1
ip route 10.0.0.0 255.0.0.0 192.168.10.1
ip route 10.0.0.0 255.0.0.0 Tunnel0 10
ip route 192.168.100.2 255.255.255.255 192.168.100.80
ip route 192.168.100.77 255.255.255.255 Tunnel0 20
ip route 192.168.100.78 255.255.255.255 Tunnel0 10
ip route 192.168.100.79 255.255.255.255 Tunnel0 10
ピア DCN ルータ(ルータ 2、192.168.100.2)へのホスト ルーティング パスは、ONS 15454 ネットワーク(192.168.100.80 による)を指していることに注意してください。これは、GRE トンネルを設定するために必要です。この設定で、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスでオーバーロードされます。ただし、ラストリゾート ルートのオーバーロードも発生する可能性があります。
17.3.7.1.3 ルータ 2 の IP の設定
インターフェイス設定
ip address 192.168.20.2 255.255.255.0
ip address 192.168.100.2 255.255.255.0
GRE トンネル インターフェイスの設定
ip address 192.168.30.2 255.255.255.0
tunnel source Ethernet1/0
tunnel destination 192.168.100.1
異なるコストでの代替パスを使用したスタティック ルート
ip route 0.0.0.0 0.0.0.0 192.168.20.1
ip route 10.0.0.0 255.0.0.0 192.168.20.1
ip route 10.0.0.0 255.0.0.0 Tunnel0 10
ip route 192.168.100.1 255.255.255.255 192.168.100.79
ip route 192.168.100.80 255.255.255.255 Tunnel0 10
ピア DCN ルータ(ルータ、IP 192.168.100.1)へのホスト ルーティング パスは、ONS 15454 ネットワーク(192.168.200.79 による)を指していることに注意してください。これは、GRE トンネルを設定するために必要です。この設定で、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスでオーバーロードされます。ただし、ラストリゾート ルートもオーバーロードされる可能性があります。
表 17-8 に、4 台の 15454 ノード上でのネットワーク設定を示します。スタティック ルートが作成されるため、DCN 接続されているノードは、ラストリゾート ルータとして動作できることをアドバタイズできます。
表 17-8 DCN ケース スタディ 4 のノードの IP アドレス
|
|
|
|
ノード 1 |
192.168.100.80/24 |
192.168.100.1 |
0.0.0.0/0 - 192.168.100.1 192.168.100.1/32 - 192.168.100.80 |
ノード 2 |
192.168.100.79/24 |
192.168.100.2 |
192.168.100.2/32 - 192.168.100.79 |
ノード 3 |
192.168.100.78/24 |
192.168.100.2 |
0.0.0.0/0 - 192.168.100.2 |
ノード 4 |
192.168.100.77/24 |
0.0.0.0 |
-- |
17.3.7.2 DCN ケース スタディ 4 の制限事項
「DCN ケース スタディ 1 の制限事項」 で説明した制限の多くは、このケース スタディにも当てはまります。ただし、光ネットワークの中に DCN 接続があるため、問題はそれほど切実ではありません。線形トポロジに、中間にライン増幅器または Optical Add/Drop Multiplexing(OADM; オプティカル add/drop マルチプレクシング)ノードがある多くのスパンがある場合(これは、長距離接続をカバーするために行われることがあります)、DWDM ネットワークでは、大きな遅延が問題になることがあります。この場合、1 台の DCN が障害になると、スパンの中心に近いノードの管理パケットは、ポイントツーポイント接続全体の 1.5 倍の距離を転送されます。通常のルーティング値は 0.5 です。GRE トンネルの全接続長が代替ルーティング パスとして使用されます。
17.4 DCN 拡張機能
ONS 15454 DWDM ネットワークには、ネットワーク内のさまざまなノード間でデータを交換するための通信チャネルが必要です。ソフトウェア リリース 7.0 までは、使用可能な唯一のチャネルは、OSCM カードおよび OSC-CSM カードで提供される Optical Service Channel(OSC; 光サービス チャネル)でした。OSC チャネルの最大損失が 37 dB であるため、長距離の DWDM メトロ ネットワークでは、OSC チャネルを使用することで、コストとパフォーマンスの面で制限が増えます。
DCN 拡張機能の主な狙いは、OSC の制約を取り除き、すでに使用可能な外部 DCN またはトラフィック マトリックスを活用することにより、OSC チャネルを使用せずにノードに到達できるようにすることです。
次の 2 つの方法で、OSC チャネルを使用せずに、DWDM ネットワーク内の 2 台のノードを接続できます。
• 外部 DCN の使用
• GCC/DCC の使用
次の各項では、接続をプロビジョニングするときに考慮すべきさまざまな通信方法と要素について説明します。
17.4.1 OSC を使用したネットワーク
図 17-22 に、OSC を通信チャネルとして使用したポイントツーポイント ネットワークを示します。
図 17-22 OSC を使用したネットワーク
OSC チャネルを使用したネットワークでは、すべてのノードを Network Operations Center(NOC; ネットワーク オペレーション センター)から管理でき、すべてのノードが OSC チャネルを使用して互いに通信できます。OSC チャネルを使用する場合、ネットワーク トポロジ ディスカバリは自動的に実行されます。
17.4.2 外部 DCN を使用したネットワーク
図 17-23 に、外部 DCN を通信チャネルとして使用したポイントツーポイント ネットワークを示します。
図 17-23 外部 DCN を使用したネットワーク
外部 DCN を使用したネットワークでは、すべてのノードを Network Operations Center(NOC; ネットワーク オペレーション センター)から管理でき、すべてのノードが外部 DCN を使用して互いに通信できます。NOC は外部 DCN を通じて各ノードに接続されます。ノードには OSC 接続がないため、ノード間で OTS 間 PPC を作成する必要があります。OTS 間 PPC は、ノード間の DCN 接続を作成します。OTS 間 PPC のプロビジョニング方法については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Create Circuits and Provisionable Patchcords」の章を参照してください。
17.4.3 GCC/DCC を使用したネットワーク
図 17-24 に、GCC/DCC を通信チャネルとして使用したポイントツーポイント ネットワークを示します。
図 17-24 GCC/DCC を使用したネットワーク
GCC/DCC を使用したネットワークでは、1 台の ONS 15454 ノード(たとえばノード A)が Gateway Network Element(GNE; ゲートウェイ ネットワーク エレメント)としてプロビジョニングされます。NOC は GNE のみに接続されます。すべてのノードを Network Operations Center(NOC; ネットワーク オペレーション センター)から管理でき、すべてのノードが GCC/DCC を使用して互いに通信できます。
しかし、そのようなネットワークでは、組み込み OSC チャネルがないため、ネットワーク トポロジの検出は自動的に行われません。正しいトポロジを設定するためには、ノードの隣接関係を手動でプロビジョニングする必要があります。GCC/DCC を使用したネットワークで DCN 拡張機能をプロビジョニングする方法については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Create Circuits and Provisionable Patchcords」の章を参照してください。
17.5 ルーティング テーブル
ONS 15454 のルーティング情報は、[Maintenance] > [Routing Table] タブに表示されます。ルーティング テーブルは次の情報を提供します。
• [Destination]:宛先ネットワークまたはホストの IP アドレスが表示されます。
• [Mask]:宛先ホストまたはネットワークに到達するために使用するサブネット マスクが表示されます。
• [Gateway]:宛先ネットワークまたはホストに到達するために使用するゲートウェイの IP アドレスが表示されます。
• [Usage]:表示されているルートが使用された回数を示します。
• [Interface]:宛先にアクセスするために使用される ONS 15454 インターフェイスを示します。値は次のとおりです。
– [motfcc0]:ONS 15454 イーサネット インターフェイス。つまり、TCC2/TCC2P/TCC3 上の RJ-45、ANSI シェルフの場合はバックプレーンの LAN 1 ピン、ETSI シェルフの場合は MIC-C/T/P 上の LAN 接続。
– [pdcc0]:SDCC または RS-DCC インターフェイス。つまり、SDCC または RS-DCC 終端として識別された OC-N/STM-N トランク カード。
– [lo0]:ループバック インターフェイス。
表 17-9 に、ONS 15454 のルーティング エントリの例を示します。
表 17-9 ルーティング テーブル エントリの例
|
|
|
|
|
|
1 |
0.0.0.0 |
0.0.0.0 |
172.20.214.1 |
265103 |
motfcc0 |
2 |
172.20.214.0 |
255.255.255.0 |
172.20.214.92 |
0 |
motfcc0 |
3 |
172.20.214.92 |
255.255.255.255 |
127.0.0.1 |
54 |
lo0 |
4 |
172.20.214.93 |
255.255.255.255 |
0.0.0.0 |
16853 |
pdcc0 |
5 |
172.20.214.94 |
255.255.255.255 |
172.20.214.93 |
16853 |
pdcc0 |
エントリ 1 は次のことを示します。
• 宛先(0.0.0.0)はデフォルト ルート エントリです。このルーティング テーブル上のすべての未定義の宛先ネットワークまたはホスト エントリは、デフォルト ルート エントリにマッピングされます。
• マスク(0.0.0.0)は、デフォルト ルートでは常に 0 になります。
• ゲートウェイ(172.20.214.1)は、デフォルト ゲートウェイ アドレスです。このルーティング テーブルにないか、ノードのローカル サブネット上にないすべての発信トラフィックは、このゲートウェイに送信されます。
• インターフェイス(motfcc0)は、ゲートウェイに到達するために ONS 15454 イーサネット インターフェイスが使用されることを示します。
エントリ 2 は次のことを示します。
• 宛先(172.20.214.0)は、宛先ネットワークの IP アドレスです。
• マスク(255.255.255.0)は 24 ビット マスクであり、サブネット 172.20.214.0 内のすべてのアドレスが宛先になることができることを意味します。
• ゲートウェイ(172.20.214.92)は、ゲートウェイ アドレスです。このネットワークに属するすべての発信トラフィックはこのゲートウェイに送信されます。
• インターフェイス(motfcc0)は、ゲートウェイに到達するために ONS 15454 イーサネット インターフェイスが使用されることを示します。
エントリ 3 は次のことを示します。
• 宛先(172.20.214.92)は、宛先ホスト IP アドレスです。
• マスク(255.255.255.255)は 32 ビット マスクであり、アドレス 172.20.214.92 のみが宛先であることを示します。
• ゲートウェイ(127.0.0.1)はループバック アドレスです。ホストはこのアドレスを使用して自身にネットワーク トラフィックを渡します。
• インターフェイス(lo0)は、ゲートウェイに到達するためにローカル ループバック インターフェイスが使用されることを示します。
エントリ 4 は次のことを示します。
• 宛先(172.20.214.93)は、宛先ホスト IP アドレスです。
• マスク(255.255.255.255)は 32 ビット マスクであり、アドレス 172.20.214.93 のみが宛先であることを示します。
• ゲートウェイ(0.0.0.0)は、宛先ホストがノードに直接接続されていることを意味します。
• インターフェイス(pdcc0)は、宛先ホストに到達するために DCC インターフェイスが使用されることを示します。
エントリ 5 は、直接接続されていないノードを通じてアクセス可能な DCC 接続ノードを示します。
• 宛先(172.20.214.94)は、宛先ホスト IP アドレスです。
• マスク(255.255.255.255)は 32 ビット マスクであり、アドレス 172.20.214.94 のみが宛先であることを示します。
• ゲートウェイ(172.20.214.93)は、IP アドレス 172.20.214.93 を持つノードを通じて宛先ホストにアクセスすることを示します。
• インターフェイス(pdcc0)は、ゲートウェイに到達するために DCC インターフェイスが使用されることを示します。
17.6 外部ファイアウォール
ここでは、外部ファイアウォールの Access Control List(ACL; アクセス コントロール リスト)の例を示します。 表 17-10 に、TCC2/TCC2P/TCC3/TNC/TSC が使用するポートの一覧を示します。
表 17-10 TCC2/TCC2P/TCC3/TNC/TSC が使用するポート
|
|
|
0 |
未使用 |
D |
20 |
FTP |
D |
21 |
FTP コントロール |
D |
22 |
SSH |
D |
23 |
Telnet |
D |
80 |
HTTP |
D |
111 |
SUNRPC |
NA |
161 |
SNMP トラップの宛先 |
D |
162 |
SNMP トラップの宛先 |
D |
513 |
rlogin |
D |
683 |
CORBA IIOP |
OK |
1080 |
プロキシ サーバ(SOCKS) |
D |
2001 ~ 2017 |
I/O カード Telnet |
D |
2018 |
アクティブ TCC2/TCC2P/TCC3/TNC/TSC 上の DCC プロセッサ |
D |
2361 |
TL1 |
D |
3082 |
Raw TL1 |
D |
3083 |
TL1 |
D |
5001 |
BLSR サーバ ポート |
D |
5002 |
BLSR クライアント ポート |
D |
7200 |
SNMP アラーム入力ポート |
D |
9100 |
EQM ポート |
D |
9401 |
TCC ブート ポート |
D |
9999 |
フラッシュ マネージャ |
D |
10240 ~ 12287 |
プロキシ クライアント |
D |
57790 |
デフォルト TCC リスナー ポート |
OK |
次の Access Control List(ACL; アクセス コントロール リスト)の例は、プロキシ サーバ ゲートウェイ設定がイネーブルになっていない場合のファイアウォールの設定を示します。この例で、CTC ワークステーションのアドレスは 192.168.10.10 であり、ONS 15454 のアドレスは 10.10.10.100 です。ファイアウォールは GNE に接続されているため、受信方向は CTC から GNE の向きで、送信方向は GNE から CTC の向きです。CTC の Common Object Request Broker Architecture(CORBA)標準定数は 683 であり、TCC の CORBA デフォルトは TCC 固定(57790)です。
access-list 100 remark *** Inbound ACL, CTC -> NE ***
access-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq www
access-list 100 remark *** allows initial contact with ONS 15454 using http (port 80) ***
access-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq 57790
access-list 100 remark *** allows CTC communication with ONS 15454 GNE (port 57790) ***
access-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 established
access-list 100 remark *** allows ACKs back from CTC to ONS 15454 GNE ***
access-list 101 remark *** Outbound ACL, NE -> CTC ***
access-list 101 permit tcp host 10.10.10.100 host 192.168.10.10 eq 683
access-list 101 remark *** allows alarms etc., from the 15454 (random port) to the CTC workstation (port 683) ***
access-list 101 permit tcp host 10.10.10.100 host 192.168.10.10 established
access-list 101 remark *** allows ACKs from the 15454 GNE to CTC ***
次の ACL の例は、プロキシ サーバ ゲートウェイ設定がイネーブルになっている場合のファイアウォールの設定を示します。最初の例と同様に、CTC ワークステーションのアドレスは 192.168.10.10 であり、ONS 15454 のアドレスは 10.10.10.100 です。ファイアウォールは GNE に接続されているため、受信方向は CTC から GNE の向きで、送信方向は GNE から CTC の向きです。CTC の CORBA 標準定数は 683 であり、TCC の CORBA デフォルトは TCC 固定(57790)です。
access-list 100 remark *** Inbound ACL, CTC -> NE ***
access-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq www
access-list 100 remark *** allows initial contact with the 15454 using http (port 80) ***
access-list 100 permit tcp host 192.168.10.10 host 10.10.10.100 eq 1080
access-list 100 remark *** allows CTC communication with the 15454 GNE (port 1080) ***
access-list 101 remark *** Outbound ACL, NE -> CTC ***
access-list 101 permit tcp host 10.10.10.100 host 192.168.10.10 established
access-list 101 remark *** allows ACKs from the 15454 GNE to CTC ***
17.7 オープンな GNE
ONS 15454 は、Point-to-Point Protocol(PPP)ベンダー拡張または OSPF タイプ 10 の不透明な Link-State Advertisement(LSA; リンクステート アドバタイズメント)をサポートしていない、非 ONS ノードと通信できます。これらのどちらも、ノードとリンクの自動的な検出で必要です。オープンな GNE 構成を使用すると、GCC ベースのネットワークが、非 ONS ノードの IP ネットワークとして機能できます。
オープンな GNE ネットワークを構成するために、GCC の終端をプロビジョニングして、デフォルト IP アドレス 0.0.0.0 または指定した IP アドレスを使用し、遠端の非 ONS ノードを含めることができます。GCC の作成時に [Far End is Foreign] チェックボックスをオンにすることで、遠端の非 ONS ノードをプロビジョニングします。デフォルトの 0.0.0.0 の IP アドレスを使用することで、遠端の非 ONS ノードが、自身を任意の IP アドレスで識別できます。0.0.0.0 以外の IP アドレスを設定した場合、遠端ノードが自身をその IP アドレスで識別した場合にのみリンクが確立され、さらなるレベルのセキュリティが提供されます。
デフォルトでは、プロキシ サーバは検出された ONS ピアへの接続のみを許可し、ファイアウォールは GCC ネットワークと LAN の間のすべての IP トラフィックをブロックします。ただし、プロキシ トンネルをプロビジョニングして、非 ONS ノードへの SOCKS バージョン 5 の接続用に最大 12 個の追加の宛先を許可できます。また、ファイアウォール トンネルをプロビジョニングして、GCC ネットワークと LAN の間の直接 IP 接続のために、最大 12 個の追加の宛先を許可できます。プロキシおよびファイアウォール トンネルには、送信元と宛先のサブネットが含まれます。SOCKS 接続または IP パケット フローが許可されるには、接続は送信元サブネットで開始され、宛先サブネットで終端する必要があります。プロキシ接続は、CTC クライアントが送信元サブネット内にあり、要求された宛先が宛先サブネット内にある場合に許可されます。ファイアウォール トンネルを使用すると、IP トラフィックがノードのイーサネット インターフェイスと pdcc インターフェイスの間でルーティングされます。すべての受信イーサネット パケットは、その送信元アドレスがトンネルの送信元に一致し、その宛先がトンネルの宛先に一致する場合に、ファイアウォールの通過を許可されます。すべての受信 pdcc パケットは、その送信元アドレスがトンネルの宛先に一致し、その宛先がトンネルの送信元に一致する場合に、ファイアウォールの通過を許可されます。トンネルは TCP パケットと UDP パケットのみに影響します。
プロキシまたはファイアウォール トンネルの使用可否は、ノードのネットワーク アクセス設定によって変わります。
• ノードで、GNE モードまたは ENE モードでプロキシ サーバがイネーブルに設定されている場合、プロキシ トンネルまたはファイアウォール トンネルを設定する必要があります。
• ノードで、プロキシ サーバがプロキシ専用モードでイネーブルに設定されている場合、プロキシ トンネルを設定できます。ファイアウォール トンネルは許可されません。
• ノードでプロキシ サーバがディセーブルに設定されている場合、プロキシ トンネルもファイアウォール トンネルも許可されません。
図 17-25 に、GCC ネットワークに接続されている外部ノードの例を示します。この例でプロキシとファイアウォールが有用なのは、これらがないと GNE が PC と外部ノードの間の IP トラフィックをブロックするためです。
図 17-25 外部終端のためのプロキシおよびファイアウォール トンネル
図 17-26 に、ENE イーサネット ポートに接続されているリモート ノードを示します。この例でプロキシとファイアウォールが有用なのは、これらがないと GNE が PC と外部ノードの間の IP トラフィックをブロックするためです。この構成では、ENE 上のファイアウォール トンネルも必要です。
図 17-26 ENE イーサネット ポートへの外部ノード接続
17.8 TCP/IP および OSI ネットワーキング
ONS 15454 DCN 通信は、TCP/IP プロトコル スイートを基にしています。ただし、ONS 15454 は、OSI プロトコル スイートを使用する機器にもネットワーク接続できます。TCP/IP プロトコルと OSI プロトコルに直接の互換性はありませんが、同じ目的を持っており、OSI 参照モデルの同じレイヤに相当します。OSI プロトコル、プロセス、シナリオの詳細については、『 ONS 15454 Reference Manual 』の「Management Network Connectivity」の章を参照してください。OSI/Multiservice Transport Platform(MSTP; マルチサービス トランスポート プラットフォーム)シナリオについて次の各項で説明します。
OSI/MSTP シナリオ 1(図 17-27)で、SDCC または RS-DCC は、OSI ベースのサードパーティ NE から ONS NE 上のトランスポンダ(TXP)カードまたはマックスポンダ(MXP)カードへの OC-N/STM-N 信号を伝送します。これは、GCC により別の MSTP NE 上の TXP/MXP カードに伝送され、その後 SDCC または RS-DCC によって別のサードパーティ NE に伝送されます。このシナリオでは、クライアント インターフェイスをセクション モードまたは回線終端モードでプロビジョニングできる TXP または MXP が必要です。これには次のものが含まれます。
• TXP_MR_2.5 および TXPP_MR_2.5(OC-N/STM-N SFP が搭載されている場合)
• TXP_MR_10G および TXP_MR_10E(クライアントが OC-192/STM-64 として設定されている場合)
• MXP_2.5_10G および MXP_2.5_10E
OSI は、OSC 終端と GCC 終端のいずれかまたは両方を通じて他の TXP/MXP カードに伝送またはトンネルされる必要があります。サードパーティ NMS はその NE への OSI 接続が可能であり、MSTP ONS NE がサードパーティ ベンダーの OSI ベースの SONET 機器用の GNE として機能します。
図 17-27 OSI/MSTP シナリオ 1
OSI/MSTP シナリオ 2(図 17-28)は、シナリオ 1 に似ていますが、MSTP NE は OSI NMS に接続できません。
図 17-28 OSI/MSTP シナリオ 2
OSI/MSTP シナリオ 3(図 17-29)は次のものを示します。
• OSI は、SDCC または RS-DCC 終端上で伝送されます。
• OSI は、OSC 終端と GCC 終端のいずれかまたは両方を通じて他のピア TXP/MXP に伝送またはトンネルされる必要があります。
• OSS はすべての NE への IP 接続が可能です。
• MSTP NE はサードパーティの OSI ベースの SONET NE のための GNE です。MSTP NE は、すべてのメディエーション機能を実行します。
図 17-29 OSI/MSTP シナリオ 3
OSI/MSTP シナリオ 4(図 17-30)は次のものを示します。
• OSI は、SDCC または RS-DCC 終端上で伝送されます。
• OSI は、OSC 終端と GCC 終端のいずれかまたは両方を通じて他のピア TXP/MXP に伝送またはトンネルされる必要があります。
• OSS は、サードパーティの NE ネットワークを通じて、すべての NE への IP 接続が可能です。
• MSTP NE はサードパーティの OSI ベースの SONET NE のための GNE です。MSTP NE は、すべてのメディエーション機能を実行します。
• サードパーティ ベンダー NE は、シスコ MSTP ネットワーク用の GNE です。
図 17-30 OSI/IP シナリオ 4
17.9 リンク管理プロトコル
ここでは、Link Management Protocol(LMP; リンク管理プロトコル)の管理と設定について説明します。特定のアラームをトラブルシューティングする方法については、『Cisco ONS 15454 DWDM Troubleshooting Guide』を参照してください。LMP の設定については、『Cisco ONS 15454 DWDM Procedure Guide』を参照してください。
(注) LMP での CTM のサポートは必須ではありません。
LMP は、Cisco ONS 15454 ノード間または Cisco ONS 15454 ノードとベンダー固有のハードウェアを使用する選択した非シスコ ノードの間で Traffic Engineering(TE; トラフィック エンジニアリング)リンクを確立するために使用されます。
17.9.1 概要
LMP は、制御チャネルを使用してノード間の TE リンクを管理します。TE リンクは、トラフィックがネットワーク上およびインターネット上を流れるための、最も効率的なパスを定義するために設計されています。トラフィック エンジニアリングには、トラフィック管理、キャパシティ管理、トラフィック測定およびモデリング、ネットワーク モデリング、およびパフォーマンス分析が含まれています。トラフィック エンジニアリング手法には、コール ルーティング、接続ルーティング、Quality of Service(QoS)リソース管理、ルーティング テーブル管理、およびキャパシティ管理が含まれています。
LMP は、2 台の Optical Cross-Connect(OXC)ノードなど、ピア ノード間の TE リンクを管理します。ピア ノードには同等のシグナリングとルーティングがあります。LMP は、OXC などのノードと隣接 Optical Line System(OLS)ノードの間の TE リンクも管理します。OLS ノードの例は、ONS 15454 DWDM ノードです。
ルータ、スイッチ、OXC ノード、DWDM OLS ノード、および add/drop マルチプレクサ(ADM)があるネットワークでは、Generalized Multiprotocol Label Switching(GMPLS)などの共通のコントロール プレーンを使用してリソースのプロビジョニングを行い、保護と復元の手法を使用してネットワークの存続可能性を高めます。LMP は GMPLS プロトコル スイートの一部です。
複数の個別のリンクから 1 個の TE リンクを構成できます。TE リンクの管理は、アウトオブバンドの方法と同様に、インバンド メッセージングを使用して達成できます。次の項目は、TE リンクを管理するノード ペアの間の LMP について説明したものです。LMP は次のことを実現します。
• 制御チャネルの接続の維持
• データ リンクの物理接続の確認
• リンク プロパティ情報の相互の関連付け
• ダウンストリーム アラームの抑止
• 複数の種類のネットワークにおける保護または復元目的でのリンク障害の局所化
DWDM ネットワークは、多くの場合 Multiprotocol Label Switching(MPLS; マルチプロトコル ラベル スイッチング)と GMPLS を共通のコントロール プレーンとして使用し、パケットがネットワーク全体でルーティングされる方法を制御します。
LMP は、ルーティング、シグナリング、リンク管理のために、ノード間に存在する必要がある制御チャネルを管理します。制御チャネルが存在するためには、各ノードに他のノードから到達可能な IP インターフェイスが存在している必要があります。IP インターフェイスの組み合わせが制御チャネルを構成します。制御メッセージ用のインターフェイスは、データ用のインターフェイスと同じである必要はありません。
17.9.1.1 MPLS
MPLS は、ルーティング テーブルやルーティング プロトコルに依存しないネットワーク トラフィック パターンを設計するためのメカニズムを提供します。MPLS では、ネットワークでパケットを転送する方法を表す短いラベルがネットワーク パケットに割り当てられます。従来のレイヤ 3 転送メカニズムでは、各ホップがパケット ヘッダーを分析し、ルーティング テーブルの検索に基づいてネクスト ホップを決定する必要があります。MPLS では、パケット ヘッダーの分析は、パケットが MPLS クラウドに入るときに 1 度だけ実行されます。その後パケットは、ラベルで識別される、Label Switch Path(LSP; ラベル スイッチ パス)と呼ばれるストリームに割り当てられます。短い固定長のラベルは、転送テーブルへのインデックスであり、従来の各ホップでのルーティング テーブルの検索よりも効率的です。MPLS を使用すると、制御プロトコル(LSP を管理するために使用します)とユーザ データの両方を同じベアラ インターフェイス上で伝送できます。
17.9.1.2 GMPLS
GMPLS は MPLS を基にしており、Time Division Multiplexing(TDM; 時分割多重)スロット(SONET や SDH など)、レイヤ 1 での Wavelength Division Multiplexing(WDM; 波長分割多重)波長、およびファイバなど追加のテクノロジーをサポートするようにプロトコル拡張されています。MPLS では、制御トラフィック(シグナリングとルーティング)をベアラ インターフェイス上で伝送できます。これは、個別の制御チャネルが使用される GMPLS には当てはまりません。GMPLS 制御チャネルは LMP を使用して管理されます。GMPLS では、隣接する 2 台のノード間の制御チャネルは、これらのノード間のデータ リンクと同じ物理メディアを使用する必要がありません。
17.9.2 LMP の設定
LMP の設定は、次の 4 つのトピックで構成されます。
• 制御チャネルの管理
• TE リンクの管理
• リンク接続の検証
• 障害管理
17.9.2.1 制御チャネルの管理
制御チャネルの管理では、隣接するノード間の制御チャネルを確立および維持します。制御チャネルは、ノード間での Config メッセージの交換と高速キープアライブ メカニズムを使用します。後者は、下位のメカニズムを使用して制御チャネルの障害を検出できない場合に必要です。最大 4 個の LMP 制御チャネルをサポートできます。
ノードは最初に設定メッセージ(Config、ConfigAck、および ConfigNack)を交換します。これは、ID を交換しキープアライブ プロトコルのためのパラメータをネゴシエートするために使用されます。次に、ノードは Hello メッセージの交換を連続的かつ高速に実行します。これはチャネルの稼動状態をモニタするために使用します。
(注) ID には、Local Node Id、Remote Node Id、Local Control Channel Id、Remote Control Channel Id があります。パラメータは HelloInterval と HelloDeadInterval です。
LMP アウトオブファイバ制御チャネルと LMP アウトオブバンド制御チャネルは、シェルフでサポートおよび終端されます。イーサネットはデータ プレーンで使用されるファイバと分離されているため、アウトオブファイバ制御チャネルは、制御チャネルのためのコントロール プレーン ネットワーク(イーサネット)の使用を含みます。オーバーヘッド バイトはペイロードと分離されているため、アウトオブバンド制御チャネルは、SDCC バイトや LDCC バイトなどの、制御チャネル用のオーバーヘッド バイトの使用を含みます。インバンドとは、制御メッセージがデータ メッセージと同じチャネル内にあることを意味します。したがって、アウトオブバンドとは、オーバーヘッド バイトが、同じファイバ、同じファイバ内の制御メッセージ専用の個別の回線(SONET/SDH 回線)、同じファイバ内の個別の波長(DWDM)のいずれかにあることを意味します。
(注) オーバーヘッド バイトは、SONET ネットワークの場合は SDCC または LDCC、SDH ネットワークの場合は RS-DCC または MS-DCC、DWDM ネットワークの場合は GCC または OSC です。
アウトオブバンドは、インファイバ(ただし非インバンド)を意味します。インファイバとは、制御メッセージがデータ メッセージと同じファイバ内にあり、インバンドおよびアウトオブバンドの両方を含むことを意味します。アウトオブファイバとは、制御メッセージがデータ プレーンとは異なるパスを経由することを意味します。これには、個別のファイバやイーサネットが含まれます。
OLS リンクへのピア ノードの制御チャネル管理は、2 台のピア ノード間のリンクの制御チャネル管理と同じです。
(注) ソフトウェアは、管理目的での制御チャネルのグレースフルなダウンをサポートしています(IETF の LMP のドキュメントの第 3.2.3 項を参照)。ただし、グレースフル リスタートのための対応はありません(RFC 4204 の第 8 項を参照)。
• グレースフルとは、制御チャネルに参加しているノードがリンクをダウンさせることに合意するということです。制御チャネルをグレースフルにダウンさせるために、ノードは、HelloDeadInterval の期限が切れるか、他のノードが ControlChannelDown フラグが設定されたメッセージを返送するまで、他のノードへのメッセージ中で ControlChannelDown フラグを設定します。いずれの場合も、ノードはこの制御チャネルのメッセージ送信を停止します。制御チャネルをダウンさせる前に、データ リンクを管理するために使用可能なバックアップ制御チャネルが存在する必要があります。
• 非グレースとは、いずれかのノードが単にメッセージの送信を停止することを意味します。相手側は、HelloDeadInterval の後に障害を宣言しますが、制御チャネルがアップ状態に戻ったかどうかを確認するために Hello メッセージを送信し続けます。
17.9.2.2 TE リンクの管理
LMP は、リンクが TE リンクにグループ化され、それらのリンクのプロパティが両方のエンドポイントで同じになるようにします。これは TE リンクの管理またはリンク プロパティの相関と呼ばれます。
リンク プロパティの相関は、TE リンクのプロパティを同期させ、TE リンクの設定を確認するために使用します。LMP のリンク プロパティの相関機能は、1 つ以上のデータ リンクを 1 つの TE リンクに集約し、TE リンクのプロパティをネイバー ノードと同期させます。この手順は、LinkSummary メッセージをネイバーに送信することで開始されます。LinkSummary メッセージには、ローカルおよびリモート Link Identifier、TE リンクを構成するすべてのデータ リンクのリスト、さまざまなリンク プロパティが含まれます。LinkSummary の受信に応答して LinkSummaryAck または LinkSummaryNack メッセージを送信し、リンク プロパティの同意または不同意を示すことが義務付けられています。
(注) 最大 256 個の LMP TE リンクがサポートされます。
17.9.2.3 リンク接続の検証
リンク接続の検証はこのリリースではサポートされていませんが、将来サポートされる可能性があります。
17.9.2.4 障害管理
障害管理は、制御チャネルがデータ リンクとは物理的に異なる場合に特に有用です。これは、1 つ以上の TE リンク データ チャネルのステータスに関する迅速な通知のために使用されます。障害管理の使用は、TE リンクの LinkSummary 交換の一部としてネゴシエートされます。データ リンクの障害と TE リンクの障害は迅速に切り分けられ、障害管理は単方向と双方向の LSP をサポートしています。透過的なデバイスが有用なのは、割り当てたデータ リンクの稼動状態をモニタするための従来の方法がすでに適切でない場合があるためです。障害管理は、レイヤ 2 やレイヤ 3 ではなく、物理層に委任されます(たとえば、光の損失またはデータの光モニタリング)。障害管理は、ChannelStatus、ChannelStatusAck、ChannelStatusRequest、および ChannelStatusResponse メッセージを使用します。
(注) LMP Channel Activation/Deactivation Indication 手順はサポートされていません。これらは、IETF の LMP のドキュメントの第 6.4 項と第 6.5 項で説明されています。
17.9.3 LMP WDM
LMP は、ピア ノード(シグナリングまたはルーティングでピアになっているノード)間のトラフィック エンジニアリング リンクを管理します。LMP WDM 拡張機能図 17-31 に、LMP と LMP-WDM の間の関係を示します。OXC 1 と OXC 2 は、制御チャネルが LMP で管理される制御チャネルです。LMP-WDM は、OXC ノードと OLS ノードの間の制御チャネルを管理します。
図 17-31 LMP と LMP-WDM の関係
2 台の OLS ノードが、LMP-WDM を通じて、2 台のピア ノード(OXC 1 および OXC 2)に設定や光リンクの現在の状態を伝えることができる場合、手動設定が削減され、障害検出と回復が強化されるため、ネットワークのユーザビリティが向上します。
17.9.4 LMP ネットワークの実装
図 17-32 に、ネットワーク レベルの LMP の実装を示します。これは、MPLS および GMPLS に基づくエンドツーエンド ルーティングを使用した、IP プラス光ネットワークです。主なネットワーク コンポーネントは次のとおりです。
• ルータ
– シスコ Carrier Router System(CSR; キャリア ルーティング システム)
– シスコ Gigabit Switch Router(GSR; ギガビット スイッチ ルータ)
• OXC ノード
• Ultra long-haul(ULH)DWDM 機器
LMP およびその他の機能を使用すると、Cisco ONS 15454 DWDM ノードが ULH DWDM の役割を果たすことができます。図 17-32 に、ネットワーク コンポーネント間の関係を示します。
図 17-32 LMP システムの実装
17.10 IPv6 ネットワークの互換性
IPv6 では、IP の設定と管理が単純化され、インターネットとインターネット関連のテクノロジーの将来的な拡張をサポートするための、IPv4 よりも広いアドレス空間があります。IPv4 アドレスでは 32 ビットが使用されるのに対して、IPv6 では 128 ビットのアドレスが使用されます。また、IPv6 では、新しいアドレッシング アーキテクチャをより柔軟に設計できます。
Network Address Translation-Protocol Translation(NAT-PT)をサポートするルータが、ONS 15454 DWDM などの GNE とクライアント ワークステーションの間に配置されていれば、Cisco ONS 15454 DWDM を IPv6 ネットワークで使用できます。NAT-PT は、ユーザが IPv4 ネットワークから IPv6 ネットワークに移行するのに役立つ移行ツールです。NAT-PT は RFC-2766 で規定されています。IPv4 ノードと IPv6 ノードは、IPv6 スタックと IPv4 スタックが、IPv6 DCN ネットワークと IPv4 DCC ネットワークの間でインターフェイスできるようにすることで、NAT-PT を使用して互いに通信します。
(注) IPv6 は、Cisco ONS 15454 DWDM ソフトウェア R8.0 以降で、外部 NAT-PT ルータを使用してサポートされています。
17.11 IPv6 のネイティブ サポート
Cisco ONS 15454 DWDM ソフトウェア R9.0 以降では、ネイティブな IPv6 をサポートしています。ONS 15454 DWDM は、IPv6 機能をイネーブルにすることで、IPv6 DCN ネットワーク上で管理できます。IPv4 に加えて IPv6 をイネーブルにした後、IPv6 DCN 上で CTC、TL1、および SNMP を使用し、ONS 15454 DWDM を管理できます。各 NE には、IPv4 アドレスに加えて IPv6 アドレスを割り当てることができます。IPv4 アドレス、IPv6 アドレス、またはデバイスの DNS 名を入力することで NE にアクセスできます。IPv6 アドレスは、NE の LAN インターフェイスのみに割り当てられます。DCC/GCC インターフェイスは IPv4 アドレスを使用します。
デフォルトでは、IPv6 をイネーブルにした場合、ノードは IPv4 パケットと IPv6 パケットの両方を LAN インターフェイス上で処理します。IPv6 パケットのみを処理する場合、ノードで IPv4 をディセーブルにする必要があります。IPv4 をディセーブルにする前に、IPv6 がイネーブルになっており、ノードがマルチシェルフ モードになっていないことを確認してください。
図 17-33 に、IPv6 DCN と IPv4 DCC の相互作用を示します。
図 17-33 IPv6-IPv4 相互作用
IPv6 DCN 上で MSTP マルチシェルフ ノードを管理できます。RADIUS、FTP、SNTP、およびその他のネットワーク アプリケーションは IPv6 DCN をサポートしています。IPv6 アドレスをイネーブルにするには、CTC または TL1 管理インターフェイスから必要は設定変更を行う必要があります。IPv6 をイネーブルにした後、プロビジョニングした IPv6 アドレスを使用して CTC または TL1 セッションを開始できます。ノードへのすべての IPv6 接続で使用されるポートは、IPv4 で使用されるポートと同じです。
NE は、IPv6 モードまたは IPv4 モードのいずれかになります。IPv4 モードでは、LAN インターフェイスに IPv6 アドレスが割り当てられません。NE には、IPv4 と IPv6 のいずれであっても、IPv4 アドレスとサブネット マスクがあります。TCC2/TCC2P/TCC3/TNC/TSC カードは、IPv6 アドレスをプロビジョニングしても自動的にリブートしませんが、IPv4 アドレスを変更すると TCC2/TCC2P/TCC3/TNC/TSC カードがリセットされます。 表 17-11 に、IPv4 ノードと IPv6 ノードの違いを示します。
表 17-11 IPv6 ノードと IPv4 ノードの違い
|
|
IPv6 アドレスと IPv4 アドレスの両方がクラフト イーサネット インターフェイスに割り当てられます。 |
IPv6 アドレスはそのクラフト イーサネット インターフェイスに割り当てられません。 |
デフォルト ルータは、IPv6 接続のための IPv6 アドレスと、IPv4 接続のための IPv4 アドレスを持ちます。 |
デフォルト ルータには IPv4 アドレスがあります。 |
LAN 上で OSPF をイネーブルにできません。LAN 上で OSPF がイネーブルな場合、IPv4 NE を IPv6 NE に変更できません。 |
LAN 上で OSPF をイネーブルにできます。 |
LAN 上で RIP をイネーブルにできません。LAN 上で RIP がイネーブルな場合、IPv4 NE を IPv6 NE に変更できません。 |
LAN 上でスタティック ルートまたは RIP をイネーブルにできます。 |
スタティック ルート、プロキシ トンネル、ファイアウォール トンネル上でサポートされていません。 |
スタティック ルート、プロキシ トンネル、ファイアウォール トンネル上でサポートされています。 |
ルーティングの判断は、プロビジョニングされているデフォルト IPv6 ルータを基にして行われます。 |
|
17.11.1 IPv6 イネーブル モード
ノード上で設定されるデフォルトの IP アドレスは IPv4 です。CTC または TL1 管理インターフェイスを使用して IPv6 をイネーブルにできます。CTC インターフェイスから IPv6 をイネーブルにする方法の詳細については、『 Cisco ONS 15454 DWDM Procedure Guide 』を参照してください。TL1 コマンドを使用して IPv6 をイネーブルにする方法の詳細については、『 Cisco ONS 15454 TL1 Command Guide 』を参照してください。
17.11.2 IPv6 ディセーブル モード
IPv6 は、CTC または TL1 管理インターフェイスからディセーブルにできます。CTC インターフェイスから IPv6 をディセーブルにする方法の詳細については、『 Cisco ONS 15454 DWDM Procedure Guide 』を参照してください。TL1 コマンドを使用して IPv6 をディセーブルにする方法の詳細については、『 Cisco ONS 15454 TL1 Command Guide 』を参照してください。
17.11.3 非セキュア モードの IPv6
非セキュア モードでは、IPv6 は前面と背面のイーサネット インターフェイスでサポートされています。NE の前面ポートと背面ポートでプロビジョニングされた IPv6 アドレスを使用して CTC または TL1 セッションを開始できます。
17.11.4 セキュア モードの IPv6
セキュア モードでは、IPv6 は背面イーサネット インターフェイス上でのみサポートされます。IPv4 が背面のイーサネット インターフェイスでディセーブルになっている場合でも、前面ポートは IPv4 のみをサポートします。セキュア モードでの IPv6 アドレスのプロビジョニングの詳細については、『 Cisco ONS 15454 DWDM Procedure Guide 』を参照してください。セキュア モードの動作については、「シナリオ 9:IP セキュア モードをイネーブルにした IP アドレッシング」を参照してください。
17.11.5 IPv6 の制約事項
IPv6 には次の設定上の制限があります。
• NE を IPv6 イネーブルとしてプロビジョニングできるのは、ノードが SOCKS またはファイアウォールがイネーブルな GNE または ENE の場合のみです。
• IPSec はサポートされません。
• NE が IPv6 ノードとしてプロビジョニングされている場合、OSPF/RIP は LAN インターフェイスでイネーブルにできません。
• スタティック ルート/ファイアウォール/プロキシ トンネルのプロビジョニングは、IPv6 がイネーブルであっても IPv4 アドレスのみに適用されます。
• セキュア モードでは、IPv6 は背面イーサネット インターフェイス上でのみサポートされます。IPv6 は前面ポートではサポートされません。
• ONS プラットフォームは、IPv6 をネイティブにサポートするために、内部的に NAT-PT を使用します。NAT-PT は、パケット変換のために IPv4 アドレス範囲 128.x.x.x を使用します。IPv6 機能をイネーブルにする場合は、アドレス範囲 128.x.x.x を使用しないでください。
17.12 Cisco CRS-1 ルータとの統合
ここでは、Cisco ONS 15454 DWDM ノードと Cisco CRS-1 ルータの統合について説明します。DWDM ノードと Cisco CRS-1 ルータの間でエンドツーエンド回線接続をプロビジョニングする方法については、『 Cisco ONS 15454 DWDM Procedure Guide 』を参照してください。
この機能は、1 台の Cisco CRS-1 ルータから別の Cisco CRS-1 ルータへの、(GMPLS を使用しない)MSTP ネットワークを通過するエンドツーエンド回線プロビジョニング機能を提供します。言い換えれば、CTC を使用して、MSTP ネットワークに関係する Cisco CRS-1 ノードを含む OCH トレール回線を作成できます。この機能を使用すると、回線プロビジョニング機能が Cisco CRS-1 ルータの Physical Layer Interface Module(PLIM; 物理層インターフェイス モジュール)トランク ポートに拡張されます。
(注) Cisco ONS ソフトウェア リリース 9.1 は、Cisco IOS XR ソフトウェア リリース 3.9.0 を使用した Cisco CRS-1 ルータのみをサポートします。以前のバージョンの Cisco IOS XR ソフトウェアがある場合、Cisco CRS-1 ルータ上で LMP を設定できず、ルータは CTC ネットワーク ビュー内で不明なノードとして表示されます。
Cisco CRS-1 ルータの詳細については、 http://www.cisco.com/en/US/products/ps5763/tsd_products_support_series_home.html で入手できるマニュアル セットを参照してください。
17.12.1 カードの互換性
次の Cisco CRS-1 DWDM PLIM がこの機能をサポートしています。
• 4-10GE-ITU/C
• 1OC768-ITU/C
• 1OC768-DSPK
次の ONS 15454 DWDM カードがこの機能をサポートしています。
• 32MUX-O
• 32DMX-O
• 32WSS
• 32DMX
• 40-DMX-C
• 40-DMX-CE
• 40-MUX-C
• 40-WSS-C
• 40-WSS-CE
17.12.2 ノード管理
図 17-34 は、DWDM ノードと Cisco CRS-1 ルータを含む典型的なノードを表しています。
図 17-34 Cisco ONS 15454 DWDM ノードと Cisco CRS-1 ルータ ネットワーク
17.12.2.1 物理的な接続
ONS 15454 DWDM ノードは、「ONS 15454 接続」に示す複数の方法を使用して CTC に接続できます。Cisco CRS-1 ルータは、イーサネット インターフェイスを使用し、TCP/IP を通じて CTC に接続する必要があります。DWDM ノードと Cisco CRS-1 ルータの間には、次の目的で 2 つの物理接続が存在している必要があります。
• LMP のプロビジョニング:TCC2P カード(Cisco ONS 15454 側)および RP カード(Cisco CRS-1 ルータ側)で提供される 10 Mbps イーサネット インターフェイス。
• 10 Gbps および 40 Gbps トラフィック:マルチプレクサ、デマルチプレクサ、または WSS カード(Cisco ONS 15454 側)の OCH ポート、および PLIM トランク ポート(Cisco CRS-1 ルータ側)から提供されるファイバ接続。Cisco ONS 15454 側と Cisco CRS-1 ルータ側の両方で LC コネクタを使用する必要があります。
17.12.2.2 CTC 表示
CTC ネットワーク ビューには、ログインした DWDM ノードと、ログイン ノードへの DCC 接続がある DWDM ノードへの LMP 制御チャネルがある Cisco CRS-1 ルータが表示されます(図 17-35)。データ リンクが確立されている場合、ネットワーク ビューには Cisco CRS-1 ルータと DWDM ノードの間のリンクも表示されます。
図 17-35 CTC ネットワーク ビューでの Cisco CRS-1 ルータ
ネットワーク ビューでの Cisco CRS-1 ルータの色は、Cisco CRS-1 ルータのアラーム ステータスによって変わります。DWDM ノードと Cisco CRS-1 ルータの間のリンクの色は、リンク ステータスによって変わります。ノードとリンクの色の詳細については、「CTC ノードの色」および「DCC リンク」を参照してください。
17.12.3 回線管理
ここでは、DWDM ノードと Cisco CRS-1 ルータでの LMP のプロビジョニングと Optical Channel(OCH)トレール回線のプロビジョニングについて説明します。
17.12.3.1 LMP のプロビジョニング
1 台の Cisco CRS-1 ルータから別の Cisco CRS-1 ルータへの、DWDM ネットワークを通過するエンドツーエンド回線接続をプロビジョニングするには、最初と最後の DWDM ノード(Cisco CRS-1 ルータに隣接するノード)の OCH ポートと、Cisco CRS-1 ルータ PLIM トランク ポート上で、LMP を設定する必要があります。LMP の設定では、制御チャネル、TE リンク、およびデータ リンクを作成します。CTC は主にデータ リンクを使用して回線ルートを発見します。Cisco CRS-1 ルータと DWDM ノードの間の各 10 Gbps または 40 Gbps ファイバについて、TE リンクとデータ リンクを作成する必要があります。Cisco CRS-1 ルータではリンク バンドリング(1 つ以上のデータ リンクを 1 つの TE リンクに集約すること)がサポートされていないため、データ リンクごとに専用の TE リンクが必要です。ポートの対応付けが正しい場合(LinkSummary メッセージを使用して確認します)、データ リンクの動作状態が Up-Free に遷移します。
DWDM ノードの OCH ポートと Cisco CRS-1 ルータの PLIM ポートの間でデータ リンクを作成する際、CTC は ラムダ チューニング を実行します。つまり、CTC は、DWDM ノードの OCH ポート上でサポートされている波長に合わせて、自動的に PLIM トランク ポートの波長を調整します。LMP の詳細については、「リンク管理プロトコル」を参照してください。
DWDM ノードと Cisco CRS-1 ルータ上の LMP は、CTC を通じて設定できます。LMP の設定の詳細については、『Cisco ONS 15454 DWDM Procedure Guide』を参照してください。
17.12.3.2 OCH トレール回線のプロビジョニング
DWDM ノードと Cisco CRS-1 ルータで LMP をプロビジョニングした後、1 台の Cisco CRS-1 ルータから別の Cisco CRS-1 ルータへ、MSTP ネットワークを通過する OCH トレール回線を作成できます。OCH トレール回線のエンドポイント(送信元と宛先)は Cisco CRS-1 ルータであることが必要です。CTC では、OCH トレール回線の混在モード(Cisco CRS-1 ルータから DWDM ノード)が許可されていません。
また、OCH トレール回線の作成の一部として、次の Optical Transport Network(OTN)回線パラメータを回線の両方のエンドポイントで定義する必要があります。
• ITU-T G.709
• Forward Error Correction(FEC; 前方誤り訂正)
• Signal Fail Bit Error Rate(SF BER; 信号損失ビット エラー レート)
• Signal Degrade Bit Error Rate(SD BER; 信号劣化ビット エラー レート)
OCH トレール回線の送信元と宛先ノードを定義した後、CTC は、2 台のエンドポイント間の有効なルートについて回線を評価します。有効なルートが存在する場合、CTC は影響のあるすべてのノード上で必要な接続を作成します。
17.12.4 CTC からの Cisco CRS-1 ルータの管理
Cisco CRS-1 ルータと DWDM ノードで LMP をプロビジョニングすると、Cisco CRS-1 ルータが CTC ネットワーク ビューに表示されます。Cisco CRS-1 ルータのアクティブ アラーム、Performance Monitoring(PM; パフォーマンス モニタリング)パラメータ、ソフトウェア バージョンを CTC から参照できます。
特定の PLIM ポートの PM パラメータを参照するには、CTC ネットワーク ビューで Cisco CRS-1 ルータを右クリックし、[Show Router Port Status] > [ rack/slot/module/port ] の順に選択します(図 17-36 を参照)。
図 17-36 Cisco CRS-1 ルータの PM パラメータ
アクティブなすべてのアラームを表示するには、CTC ネットワーク ビューで Cisco CRS-1 ルータを右クリックし、[Show Active Alarms] を選択します。
(注) Loss of Signal(LOS; 信号消失)アラームは、Cisco CRS-1 ルータでは重大として報告されませんが、ONS 15454 ノードでは重大として報告されます。この不整合を避けるには、Cisco Craft Works Interface(CWI)を使用して、Cisco CRS-1 ルータの LOS アラームの重大度を手動で変更できます。
ソフトウェア バージョンを表示するには、CTC ネットワーク ビューで [Maintenance] > [Software] タブをクリックします。各ノードで動作しているソフトウェアのバージョンが [Working Version] カラムに表示されます。
17.13 光パス トレース
Photonic Path Trace(PPT; 光パス トレース)は、ONS 15454 MSTP ネットワーク内の光パスを検証するためのプロトコルです。
PPT は、証拠に基づくパス検証を実行し、プロビジョニングに失敗した場合にノードを識別します。PPT は各ポートの電力レベルを使用してパスを検証します。光パス内のすべてのノードについて、PPT はしきい値に対する電力レベルをヒストグラムの形式で報告します。ヒストグラムは CTC の [Edit Circuit] ウィンドウの [Photonic Path Trace] タブに表示されます。各ノードについて、経由したすべてのポートから収集した電力値がヒストグラムに表示されます(図 17-37)。
図 17-37 光パス トレース
(注) PPT を開始する光パス上に OCHNC または OCH トレール回線が存在する必要がります。
光パスに対して PPT を開始する方法については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Turn Up a Network」の章を参照してください。
17.14 共有リスク リンク グループ(SRLG)
Shared Risk Link Group(SRLG; 共有リスク リンク グループ)は、リンクまたは DWDM ノードに割り当てることができる一意の 32 ビット値です。この数値は、障害になる可能性があるリンクまたはリソース グループの ID として使用できます。複数のリンクがリソースを共有しており(たとえば共有のファイバ)、そのリソースが障害になるとグループ内の他のリンクも障害になる場合、これらのリンクが 1 つの SRLG を構成します。そのため、グループ内のリンクには共有のリスクがあります。リンクは複数の SRLG に属することができます。SRLG 情報は、リンクが属する SRLG の順序付けられていないリストであり、ルーティングの判断を行うためにルータ層によって使用されます。たとえば、ルータが冗長パスを経由する場合、パス計算により、ルーティングが同じ SRLG を共有するリンクを通過しないようになります。
SRLG には、unique(一意)と additional(追加)の 2 つの種類があります。すべてのリンクまたは DWDM ノードに一意の SRLG 属性を割り当てる必要があります。DWDM ノードまたはリンクの追加 SRLG はオプションであり、CTC で定義できます。リンクの追加 SRLG はリンクに関係する追加のリスクを計算します。リンクの追加 SRLG のリストは、CTC の [Additional Span SRLG information] 属性で定義できます。このリストには、最大 20 個の SRLG を含めることができます。
DWDM ノードまたはリンクの SRLG 値が変化した場合、関係するすべてのルータ ポートの SRLG 属性が更新されます。新しいルータベースの OCH トレールが作成された場合、新たに作成した回線に含まれる DWDM ノードとリンクの SRLG 情報が自動的に送信元と宛先ルータに通知されます。SRLG 情報は、ルータ ポートの SRLG 値が DWDM ノードの SRLG 値と異なる場合にも同期されます。SRLG 情報は、CTC で集約レポートまたは詳細レポートとして表示できます。DWDM ノードとリンク上での SRLG のプロビジョニングの詳細については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Turn Up a Network」の章を参照してください。
17.15 予防的保護再生成
DWDM ネットワークで光信号が低下しても、ダウンストリーム ルータはそれに気づきません。FEC 制限に達した場合、重大なパケット損失が発生してトラフィックが中断し、LOF アラームが発生します。LOF アラームは、ルータ層内で Fast Reroute(FRR; 高速リルート)メカニズムを起動し、トラフィックがバックアップ パスに切り替えられます。
予防的保護再生成機能は、LOF アラームが発生する前にバックアップ パスへの FRR を開始することで、トラフィックが中断される前に無中断スイッチオーバーを実現します。
予防的保護再生成は、OTU2_XP カードが Standard regen モードまたは Enhanced FEC モードでリジェネレータとして使用されている場合に、OTU2_XP カード ポートでイネーブルにできます。予防的保護再生成は、2 台の Cisco CRS-1 ルータ間で OCH トレール回線を作成する際にも設定できます。
アップストリーム ルータと ONS ノードの間の光信号の BER が、トリガ ウィンドウとして設定されている期間トリガしきい値を超えると、すぐに PPR-FDI アラームが ONS ノードによって生成されます。PPR-FDI アラームはダウンストリーム ルータに送信され、それによりバックアップ パスへのスイッチオーバーが起動されます。次にダウンストリーム ルータは、バックアップ パスに切り替えるための PPR-BDI アラームをアップストリーム ルータに送信します。
CTC で OTU2_XP カードと OCH トレールの予防的保護再生成を設定する方法の詳細については、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Provision Transponder and Muxponder Cards」の章を参照してください。