この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、ONS 15454 Data Communication Network(DCN; データ通信ネットワーク)接続の概要について説明します。Cisco Optical Networking System(ONS)ネットワークの通信は、Cisco Transpot Controller(CTC)コンピュータと ONS 15454 ノード間の通信、ネットワーク接続された ONS 15454 ノード間の通信を含め、IP に基づいて行われます。この章では、一般的な Cisco ONS 15454 IP ネットワーク構成および実際の ONS 15454 のインストレーションに基づいた詳細な DCN のケース スタディについて説明します。また、ONS 15454 IP ルーティング テーブル、外部ファイアウォール、および開放型 Gateway Network Element(GNE; ゲートウェイ ネットワーク エレメント)ネットワークについて説明します。
ONS 15454 DCN の通信は IP ベースですが、ONS 15454 ノードは Open Systems 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 の両方のシェルフ アセンブリを意味します。
• 「LMP」
(注) ONS 15454 を IP ネットワークに接続する場合には、LAN 管理者または IP ネットワークのトレーニングを受けた経験を持つ現場担当者と一緒に作業してください。
IP 環境で ONS 15454 を接続する方法は、いろいろあります。
• IP サブネット化で ONS 15454 ノード グループを作成する。このノード グループにより、Data Communications Channel(DCC; データ通信チャネル)に接続されていないネットワーク内のノードをプロビジョニングできます。
• さまざまな IP 機能とプロトコルを使用してネットワーク上で特定の作業を行う。たとえば、プロキシ Address Resolution Protocol(ARP; アドレス解決プロトコル)により、LAN に接続された 1 つの ONS 15454 を、LAN に接続されていない ONS 15454 のゲートウェイとして使用できます。
• スタティック ルートを作成し、複数の CTC セッションを使用して、複数の CTC セッションがある同じサブネット上の ONS 15454 を接続します。
• ONS 15454 を Open Shortest Path First(OSPF)ネットワークに接続し、ONS 15454 ネットワークの情報を複数の LAN や WAN で自動的に通信します。
• ONS 15454 プロキシ サーバは、CTC コンピュータと ONS 15454 要素ノードの間の可視性とアクセス可能性を制御します。
ONS 15454 の IP アドレッシングには、一般的に 9 つのシナリオ(構成)があります。これらのシナリオは、より複雑なネットワーク構成の基礎として使用してください。 表15-1 に、IP ネットワークで ONS 15454 を設定する際の一般的なチェック項目の一覧を示します。
|
|
---|---|
• CTC コンピュータと、ネットワーク ハブまたはスイッチ • ONS 15454(バックプレーン [ANSI] または MIC-C/T/P [ETSI] ワイヤラップ ピンまたは RJ-45 ポート)と、ネットワーク ハブまたはスイッチ |
|
接続で問題が発生した場合は、ONS 15454 に接続しているハブまたはスイッチ ポートを 10 Mbps の半二重に設定します。 |
|
シナリオ 1 は、ONS 15454 の基本的な LAN 構成を示します(図15-1)。ONS 15454 と CTC コンピュータは同一サブネット上に存在します。すべての ONS 15454 が LAN A に接続され、すべての ONS 15454 が DCC 接続されています。
図15-1 シナリオ 1:同一サブネット上の CTC と ONS 15454(ANSI および ETSI)
シナリオ 2 では、CTC コンピュータはサブネット(192.168.1.0)上にあり、LAN A(図15-2)に接続されています。ONS 15454 は異なるサブネット(192.168.2.0)上にあり、すべて LAN B に接続されています。ルータによって、LAN A と LAN B が接続されています。ルータ インターフェイス A の 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 アドレスが自動的に割り当てられます。図15-2 では、DHCP サーバを使用していません。
図15-2 シナリオ 2:ルータに接続された CTC と ONS 15454(ANSI および ETSI)
ARP は、上位レベルの IP アドレスを宛先ホストの物理アドレスに一致させます。ARP は、ルックアップ テーブル(ARP キャッシュと呼ばれる)を使用して変換を行います。ARP キャッシュ内でアドレスが見つからない場合は、ARP 要求と呼ばれる特別な形式でブロードキャストをネットワークに送信します。ネットワーク上の 1 つのマシンがそのマシンの IP アドレスを含む ARP 要求を認識すると、ARP 要求の送信側ホストへ ARP 応答を返します。ARP 応答には、受信側ホストの物理ハードウェア アドレスが含まれます。送信側ホストはその ARP キャッシュにこのアドレスを保存します。このため、この宛先 IP アドレスへの以降のすべてのデータグラム(パケット)を物理アドレスに変換できます。
プロキシ ARP により、LAN に接続された ONS 15454 は、LAN に接続されていない ONS 15454 の ARP 要求に応答できます(ONS 15454 プロキシ ARP に対する設定は必要ありません)。ただし、DCC 接続の ONS 15454 が LAN 接続(ゲートウェイ)の ONS 15454 と同じサブネット上に存在する必要があります。LAN 装置が LAN に接続されていない ONS 15454 に ARP 要求を送信すると、(LAN に接続されている)ゲートウェイ ONS 15454 が LAN 装置に MAC(メディア アクセス制御)アドレスを返します。LAN 装置は、次にリモートの ONS 15454 宛てのデータグラムを、このプロキシ ONS 15454 の MAC アドレスに送信します。プロキシ ONS 15454 は自身の ARP テーブルを使用して、このデータグラムを LAN に接続されていない ONS 15454 に送信します。
シナリオ 3 はシナリオ 1 に似ていますが、LAN に接続されている ONS 15454(ノード 1)は 1 つだけです(図15-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 機能を実行しません。
• 図15-3 では、CTC ワークステーションがプロキシ ARP サーバと同じサブネットおよびイーサネット セグメントに配置されていることが重要です。
図15-3 シナリオ 3:プロキシ ARP の使用(ANSI および ETSI)
また、プロキシ ARP を使用して、DCC 接続されたノードのクラフト イーサネット ポートに接続されているホストと通信することもできます(図15-4)。ホストが接続されているノードは、そのホストへのスタティック ルートがなければなりません。スタティック ルートは、OSPF によってすべての DCC ピアへ伝播されます。ホストを追加した場合、既存のプロキシ ARP ノードがゲートウェイになります。各ノードは、同じサブネット上にあって DCC ネットワークに接続されていないホストへのルートを、それぞれのルーティング テーブルで調べます。このような追加ホストに対する ARP 要求には、対象ノードのMAC アドレスを使用して既存のプロキシ サーバが応答します。ルーティング テーブルにホストへのルートが存在していれば、追加ホストにアドレス指定されているIP パケットを正常にルーティングできます。ノードと追加ホスト間のスタティック ルートを確立する以外に、プロビジョニングは必要ありません。次の制約事項が適用されます。
• 指定した任意の追加ホストのプロキシ ARP サーバとして機能できるノードは 1 つのみです。
• ノードは、そのイーサネット ポートに接続されているホストのプロキシ ARP にすることはできません。
図15-4 では、ノード 1 は、ノード 2 および 3 に対し、ノード 1 が CTC ホストに到達できることを通知します。同様に、ノード 3 は、ノード 3 が ONS 152xx に到達できることを通知します。図では例として、ONS 152xx が示されていますが、実際には、どのネットワーク要素でも追加ホストとしてセットアップできます。
図15-4 シナリオ 3:スタティック ルーティングでのプロキシ ARP の使用(ANSI および ETSI)
シナリオ 4 はシナリオ 3 に似ていますが、ノード 2 とノード 3 がそれぞれ 192.168.2.0 と 192.168.3.0 の異なるサブネットにあります(図15-5)。ノード 1 と CTC コンピュータはサブネット 192.168.1.0 にあります。このネットワークに異なるサブネットが含まれるため、プロキシ ARP は使用しません。CTC コンピュータが ノード 2 および 3 と通信するために、ノード 1 が CTC コンピュータのデフォルト ゲートウェイとなります。
図15-5 シナリオ 4:CTC コンピュータのデフォルト ゲートウェイ(ANSI および ETSI)
• ONS 15454 をサブネット上の CTC セッションに接続し、ルータによって別のサブネット上にある ONS 15454 に接続します(OSPF がイネーブルの場合には、これらのスタティック ルートは必要ありません。シナリオ 6 に、OSPF の例を示します)。
• 同一サブネット上にある ONS 15454 の間で複数の CTC セッションをイネーブルにします。
図15-6 では、サブネット 192.168.1.0 上の CTC がインターフェイス A でルータに接続されています(このルータは OSPF で設定されていません)。別のサブネット上の ONS 15454 は ノード 1 に接続され、インターフェイス B でルータに接続されています。ノード 2 と 3 がそれぞれ異なるサブネットにあるため、プロキシ ARP はノード 1 をゲートウェイとしてイネーブルにしません。LAN A 上の CTC コンピュータに接続するために、ノード 1 でスタティック ルートが作成されます。
図15-6 シナリオ 5:宛先として使用される CTC コンピュータのスタティック ルート(ANSI および ETSI)
宛先エントリとサブネット マスク エントリは、ONS 15454 へのアクセスを制御します。
• 単一の CTC コンピュータがルータに接続されている場合は、サブネット マスク 255.255.255.255 で、宛先として完全な CTC「ホスト ルート」IP アドレスを入力します。
• サブネット上の複数の CTC コンピュータが 1 つのルータに接続されている場合は、宛先サブネット(この例では 192.168.1.0)とサブネット マスク 255.255.255.0 を入力します。
• すべての CTC コンピュータが 1 つのルータに接続されている場合は、宛先 0.0.0.0 とサブネット マスク 0.0.0.0 を入力します。図15-7 に例を示します。
ルータ インターフェイス B の IP アドレスがネクストホップとして入力されています。コスト(送信元から宛先へのホップの数)は 2 です。
図15-7 シナリオ 5:複数の LAN 宛先のスタティック ルート(ANSI および ETSI)
OSPF は、リンクステート インターネット ルーティング プロトコルです。リンクステート プロトコルは、「hello プロトコル」を使用して隣接ルータとのリンクをモニタリングしたり、ネイバへのリンクのステータスをテストします。リンクステート プロトコルは、直接接続されているネットワークとそのアクティブなリンクをアドバタイズします。それぞれのリンクステート ルータは、リンクステート「アドバタイズ」を取り込み、これらをまとめてネットワーク全体の、または領域のトポロジを作成します。ルータは、このデータベースから最短パス ツリーを構築してルーティング テーブルを計算します。ルートは、トポロジが変更されたときに再計算されます。
ONS 15454 は内部 ONS 15454 ネットワーク内で、ノードの検出、回線のルーティング、ノードの管理のために OSPF プロトコルを使用します。ONS 15454 で OSPF をイネーブルにすることで、ONS 15454 トポロジが LAN 上の OSPF ルータに送信されます。ONS 15454 ネットワーク トポロジを LAN ルータにアドバタイズすることで、ONS 15454 サブネットワークのスタティック ルートを手動で入力する必要がなくなります。図15-8 に、OSPF がイネーブルにされたネットワークを示します。図15-9 に、OSPF が使用されていない同一ネットワークを示します。スタティック ルートは、LAN A 上の CTC コンピュータが、ノード 2 および 3 と通信するために手動でルータに追加する必要があります。これは、これらのノードがそれぞれ異なるサブネット上にあるためです。
OSPF は、ネットワークを、領域と呼ばれる小さなリージョンに分割します。領域は、トラフィック パターン別に構成するネットワークの終端システム、ルータ、および伝送ファシリティの集まりです。各 OSPF 領域には、領域 ID と呼ばれる一意の ID 番号があります。各 OSPF ネットワークには、「領域 0」と呼ばれるバックボーン領域が 1 つあります。他のすべての OSPF 領域は領域 0 に接続する必要があります。
OSPF ネットワークへのアドバタイズのために ONS 15454 OSPF トポロジをイネーブルにする場合は、ONS 15454 ネットワークに 10 進形式の OSPF 領域 ID を割り当てる必要があります。領域 ID は IP アドレスに類似した「ドットで区切られた 4 つの」値です。LAN 管理者に相談して、割り当てる領域 ID 番号を決定してください。DCC 接続されたすべての ONS 15454 には、同じ OSPF 領域 ID を割り当ててください。
(注) OSPF 領域の ONS 15454 の数を制限することを推奨します。これにより CTC へのロード時間が短縮され、エラーが発生する可能性も減少します。
図15-8 シナリオ 6:OSPF がイネーブルになっているネットワーク(ANSI および ETSI)
図15-9 シナリオ 6:OSPF がイネーブルではないネットワーク(ANSI および ETSI)
ONS 15454 プロキシ サーバは、ONS 15454 と CTC コンピュータの間の可視性とアクセス可能性を制限する必要のある環境で ONS 15454 をネットワーク接続できるようにする機能セットです。たとえば、ネットワークを設定して、現場技術者が Network Operations Center(NOC)LAN にアクセスするのを制限しながら、現場技術者と NOC の担当者の両者が同じ ONS 15454 にアクセスできるようにできます。この設定を行うには、1 つの ONS 15454 を GNE として設定し、他の ONS 15454 を ENE として設定します。GNE ONS 15454 は CTC コンピュータと ENE ONS 15454 の間の接続をトンネルし、ONS 15454 管理目的以外のアクセスを制限しながら管理できます。
ONS 15454 ゲートウェイの設定により、次の作業を実行します。
• DCC IP トラフィックをイーサネット(クラフト ポート)トラフィックから分離し、フィルタリング規則に基づいてパケットを受け付ける。フィルタリング規則(プロキシ サーバのファイアウォール フィルタリング規則 および プロキシ サーバのファイアウォール フィルタリング規則 を参照)は、パケットが ONS 15454 DCC または TCC2/TCC2P イーサネット インターフェイスのどちらに着信するかによって異なります。
• Simple Network Time Protocol(SNTP; 簡易ネットワーク タイム プロトコル)および Network Time Protocol(NTP)の要求を処理する。ONS 15454 ENE は、SNTP/NTP LAN サーバから GNE ONS 15454 を介して Time-of-Day(ToD)を得ることができます。
• SNMP 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 クライアントが終了するまで継続しますが、このノードは CTC クライアントのプロキシとしては動作しません。また、プロキシ サーバを ENE または GNE として設定することができます。
• ENE ― ENE として設定すると、ONS 15454 はイーサネット ポートを通るデフォルト ルートやスタティック ルートの設定もアドバタイズも行いません。ただし、ENE は DCC を通るルートに対して設定およびアドバタイズを行います。CTC コンピュータは、TCC2/TCC2P クラフト ポートを使用して ONS 15454 と通信できますが、DCC 接続された他の ONS 15454 には直接通信できません。
また、ファイアウォールがイネーブルになり、ノードで DCC と LAN ポート間の IP トラフィックがルーティングされなくなります。ONS 15454 は、LAN ポートに接続されたマシン、または DCC によって接続されたマシンと通信できます。ただし、DCC 接続されたマシンは、LAN 接続されたマシンと通信できません。同様に、LAN 接続されたマシンは DCC 接続されたマシンと通信できません。ファイアウォール対応ノードとの接続に LAN を使用している CTC クライアントは、プロキシ機能を使用して DCC 接続されたノードを管理できます。別の方法では、この DCC 接続されたノードに到達することはできません。DCC 接続されたノードに接続されている CTC クライアントは、他の DCC 接続されたノードとファイアウォールそのものだけを管理できます。
• GNE ― GNE として設定すると、CTC コンピュータは、他の DCC 接続されたノードと通信できるようになり、ファイアウォールがイネーブルになります。
• SOCKS プロキシのみ ― プロキシのみを選択すると、ファイアウォールはイネーブルになりません。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 アドレスを持つ必要があります。
図15-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 が 1 つの場所に設置されている場合は、クラフト LAN ポートをハブに接続できます。ただし、ハブが他のネットワークに接続されていないようにします。
図15-10 シナリオ 7:同一サブネット上に GNE と ENE を備えた ONS 15454 プロキシ サーバ(ANSI および ETSI)
表15-2 に、図15-10 の構成における ONS 15454 GNE および ENE の推奨設定値を示します。
|
|
|
---|---|---|
図15-11 に、異なるサブネット上にある ONS 15454 ENE を使用したプロキシ サーバの実装を示します。ONS 15454 GNE および ENE は 表15-2 に示す設定でプロビジョニングされます。
図15-11 シナリオ 7:異なるサブネット上に GNE と ENE を備えた ONS 15454 プロキシ サーバ(ANSI および ETSI)
図15-12 に、ONS 15454 ENE が複数のリングにある場合の同一プロキシ サーバの実装を示します。
図15-12 シナリオ 7:ENE が複数のリングにある ONS 15454 プロキシ サーバ(ANSI および ETSI)
表15-3 に、ノードが ENE および GNE として設定される場合にファイアウォールのパケットをフィルタリングするために ONS 15454 が従う規則を示します。パケットの宛先が ONS 15454 の場合は、 表15-4 に示す追加の規則が適用されます。拒否されたパケットは報告せずに、そのまま廃棄されます。
|
|
---|---|
• ONS 15454 のサブネット ブロードキャスト アドレス • 224.0.0.0/8 ネットワーク内のアドレス(標準マルチキャスト メッセージで使用するために予約されているネットワーク) |
|
|
|
---|---|
プロキシ サーバを実装する場合、同一イーサネット セグメント上の DCC 接続されたすべての ONS 15454 で、ゲートウェイ設定を同じにする必要があります。これらの設定が異なると予測できない結果となり、共用イーサネット セグメントでいくつかのノードが到達不可能になる場合があります。
ノードが到達不可能になった場合は、次のいずれかを実行して設定を正しく修正します。
• 到達不可能となった ONS 15454 からクラフト コンピュータを接続解除します。到達不可能となった ONS 15454 に DCC 接続されている別のネットワーク ONS 15454 を介して問題の ONS 15454 に接続します。
• 近接ノードの DCC をすべてディセーブルにすることで、ノードへの接続を解除します。CTC コンピュータを ONS 15454 に直接接続して、その設定を変更します。
ONS 15454 は、GNE のロード バランシングに対応しており、ENE を OSPF によってアドバタイズすることなく、複数の GNE を介して CTC から ENE へ接続することができます。この機能により、GNE が異なるサブネット上にある場合でも、ネトワークが GNE 損失から迅速に回復することができます。1 つの GNE が停止すると、その GNE を介した接続はすべて停止します。CTC は障害のある GNE およびその GNE がプロキシ機能を担っていたすべての ENE からの接続を解除し、そのあとで、残っている GNE を介して再接続します。GNE ロード バランシングは、ともに CTC のパフォーマンスを強化する、起動 GNE と DCC 帯域幅への依存を低減します。
(注) デュアル GNE は特別なプロビジョニングを必要としません。
図15-13 に、同一サブネットにデュアル GNE を設定したネットワークを示します。
図15-13 シナリオ 8:同一サブネットにおけるデュアル GNE(ANSI および ETSI)
図15-14 に、異なるサブネット上にデュアル GNE を設定したネットワークを示します。
図15-14 シナリオ 8:異なるサブネットにおけるデュアル GNE(ANSI および ETSI)
TCC2 カードおよび TCC2P カードは、いずれもデフォルトでリピータ モードになっています。このモードでは、前面と背面のイーサネット(LAN)ポートは、単一の MAC アドレスと IP アドレスを共有しています。TCC2P カードを使用すると、ノードをセキュア モードにすることができます。これにより、前面からアクセスするクラフト ポートのユーザがバックプレーン ポートを介して LAN にアクセスするのを防ぐことができます。セキュア モードはロックすることができ、モードを変更しないようにできます。ノードをセキュア モードに設定することや、セキュア ノードをロックすることについては、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Manage the Node」の章を参照してください。
TCC2P ノードをリピータ モードからセキュア モードに変更することで、ONS 15454 の 2 つの IP アドレスをプロビジョニングすることができ、ノードでポートに個別の MAC アドレスを割り当てることができます。セキュア モードでは、1 つの IP アドレスが ONS 15454 バックプレーン LAN ポートにプロビジョニングされ、他の IP アドレスは、TCC2P イーサネット ポートにプロビジョニングされます。両方のアドレスは別のサブネットにあり、クラフト アクセス ポートと ONS 15454 LAN 間の分離レイヤが 1 つ増えます。セキュア モードがイネーブルの場合、バックプレーン LAN ポートと TCC2P イーサネット ポートにプロビジョニングされている IP アドレスは、一般的な IP アドレッシング ガイドラインに従う必要があり、互いに異なるサブネットに存在する必要があります。
セキュア モードでは、バックプレーン LAN ポートに割り当てられた IP アドレスがプライベート アドレスになり、このアドレスがノードをセントラル オフィス LAN または企業のプライベート ネットワーク経由で Operations Support System(OSS)に接続します。スーパーユーザは、CTC、ルーティング テーブル、または TL1 自律メッセージ レポートのバックプレーン LAN IP アドレスを表示したり隠したりするようにノードを設定できます。
リピータ モードでは、ノードは GNE または ENE です。ノードをセキュア モードにすると、自動的に SOCKS プロキシがオンになり、ノードはデフォルトで GNE 状態になります。ただし、ノードを ENE に戻すこともできます。リピータ モードでは、LAN ファイアウォールの先にあるノードを効率的に分離するために、ENE の SOCKS プロキシをディセーブルにすることができますが、セキュア モードではディセーブルにできません。ノードの GNE または ENE のステータスを変更して SOCKS プロキシをディセーブルにするには、『 Cisco ONS 15454 DWDM Procedure Guide 』の「Turn Up a Node」の章を参照してください。
(注) TCC2 カードがインストールされている場合、セキュア モード オプションは CTC には表示されません。1 つの TCC2 と 1 つの TCC2P カードがノードに装着されている場合、セキュア モードが CTC に表示されますが、変更できません。
(注) 前面およびバックプレーン アクセス ポートが ENE でディセーブルになっていて、(ユーザのプロビジョニングまたはネットワーク障害により)ノードが DCC 通信から隔離されている場合、前面およびバックプレーン ポートは自動的に再度イネーブルになります。
図15-15 に、同じサブネットにある前面アクセス イーサネット ポート アドレスのセキュア モード ONS 15454 ノードの例を示します。
図15-15 シナリオ 9:同一サブネット上の ONS 15454 GNE および ENE(セキュア モードがイネーブルの場合)
図15-16 に、セキュア モードをイネーブルにしてルータに接続された ONS 15454 の例を示します。各例では、ノードの TCC2P ポート アドレス(ノード アドレス)がノード バックプレーン アドレスとは別のサブネットにあります。
図15-16 シナリオ 9:異なるサブネット上の ONS 15454 GNE および ENE(セキュア モードがイネーブルの場合)
セキュア モードは、セキュア モードで動作するノードでロックまたはロック解除できます。デフォルトのステータスはロック解除で、スーパーユーザのみがロックを発行できます。セキュア モードがロックされている場合、ノードの設定(イーサネット ポート ステータスを含む)およびロック ステータスは、どのネットワーク ユーザからも変更できません。セキュア ノードのロックを解除するには、Cisco Technical Support に連絡してシェルフ アセンブリ用の Return Material Authorization(RMA; 返品許可)を手配してください。必要に応じて、「マニュアルの入手方法、テクニカル サポート、およびセキュリティ ガイドライン」 を参照してください。ロックをイネーブルにすると、シェルフの EEPROM が永久的に変更されます。
ノードの設定ロックは、アクティブ TCC2P カードのデータベースがリロードされると保持されます。たとえば、ロックされていないノード データベースをロックされたノードのスタンバイ TCC2P カードに書き込んでアクティブ TCC2P カードに転送しようとした場合(推奨されない処理)、ロックされていないノードのステータス(アップロードされたデータベース経由)は、ノードのロック ステータスに上書きされません。ロックされたデータベースをロックされていないセキュア ノードのスタンバイ TCC2P カードに書き込もうとした場合、アクティブ TCC2P カードはデータベースをアップロードします。アップロードされたデフォルトがロック ステータスを示している場合、そのノードはロックされます。ロックがイネーブルになる前にソフトウェアの書き込みがカスタマイズされている場合、ロック可能なすべてのプロビジョニング機能がその書き込みで提供されるカスタマイズされた NE デフォルトに永久に設定され、どのユーザからも変更できません。
ONS 15454 ネットワークは、IP DCN、Optical Service Channel(OSC; 光サービスチャネル)、DCC、および General Communications Channel(GCC; 汎用通信チャネル)で管理されます。ONS 15454 は、DCN Network Management System(NMS; ネットワーク管理システム)と Dense Wavelength Division Multiplexing(DWDM; 高密度波長分割多重)光ネットワーク間のトラフィックを管理するため、レイヤ 3 ルータと同じ多くの機能を行います。
ここでは、ONS 15454 ネットワークを DCN に実装するさまざまな方法を示すケース スタディを紹介します。これらのケース スタディは、実際の現場でのインストレーションに基づいています。これらには、ネットワークの問題、その問題を解決するために作成されたネットワーク トポロジ、IP アドレッシングの例、および解決法の長所と短所が含まれます。ケース スタディで従ったルーティングの原則には、次のものがあります。
• ONS 15454 が DCN ルータに接続されている場合、デフォルト ゲートウェイはルータを示します。
• デフォルト ゲートウェイが OSC/DCC/GCC ネットワークにアドバタイズする必要がある場合、デフォルト ゲートウェイにスタティック ルートが追加されます。
• Network Element(NE; ネットワーク要素)が DCN ルータに接続されていない場合、デフォルト ゲートウェイは 0.0.0.0 に設定されます。
SOCKS プロキシ(シナリオ 7:ONS 15454 プロキシ サーバのプロビジョニング 参照)では、ONS 15454 は、CTC クライアントと OSC、GCC、または DCC により接続されている ONS 15454 ノード間の接続のプロキシとして機能できます。SOCKS プロキシにより DCN の実装は簡単になりますが、次のいずれかの条件がある場合は使用すべきではありません。
• ネットワーク管理が SNMP および SNMP トラップに基づいています。ONS 15454 は SNMP トラップをプロキシすることができますが、冗長 DCN 接続が必要な場合、ネットワーク管理プラットフォームでのトラップ重複が発生します。
• Telnet および デバッグ セッションが必要です。これらは SOCKS プロキシでは使用できません。
これらの条件がなく、すべてのノードへの直接 IP 接続を持つための要件がない(CTC や Cisco Transport Manager [CTM] を使用して管理を行う)場合、DCN ルータに接続するすべてのノードに SOCKS プロキシのみのオプションを使用することを推奨します。
ONS 15454 LAN インターフェイスでの OSPF(シナリオ 6:OSPF の使用 参照)の有効化は、復元力のある DCN 接続を作成するために使用できる別のオプションです。ただし、このオプションは、NE から NOC へのネットワークにあるすべての要素が OSPF を実行する場合にのみイネーブルにできます。これは常に可能というわけではありません。たとえば、DCN 接続は、ONS 15454 ネットワークを使用する組織の管理の範囲外にあるパブリック ネットワーク上にある可能性があります。LAN で OSPF をイネーブルにすることを検討している場合、次の制限事項を考慮する必要があります。
• OSPF が LAN でイネーブルになっている場合、内部の OSC/DCC/GCC の OSPF 領域は 0.0.0.0 になりません。
• ONS 15454 は OSPF 領域のボーダ ゲートウェイとして動作し、OSPF の仮想リンクをサポートすることができます。ただし、仮想リンクは OSC/DCC/GCC ネットワークを通過できません。
DCN ネットワークにあるすべての要素が OSPF を実行していない場合、分離された領域の作成や OSPF 領域 0 のセグメント化を行わずに LAN で OSPF をイネーブルにすることは、きわめて困難です。ただし、DCN ネットワークが完全な OSPF ネットワークである場合、LAN での OSPF のイネーブル化は、復元力のある DCN ネットワークでは使用される可能性があります。
DCN ケース スタディ 1(図15-17)は、ONS 15454 リング(DWDM または SONET/SDH)を示します。リングは 2 つのサブネットに分割され、2 つの DCN 接続をもっているので復元力があります。
図15-17 DCN ケース スタディ 1:2 つのサブネットおよび 2 つの DCN 接続のある ONS 15454 リング
通常の動作中、この構成により、2 つの使用可能な DCN 接続での管理トラフィック ロードを平衡化します。2 つの DCN 接続のいずれかに障害が発生した場合、もう 1 つの DCN 接続がアクセス可能性を維持するため、NE 管理を継続できます。ただし、完全な IP 接続が必要な場合、たとえば、SOCKS プロキシが使用できないときの SNMP では、次の理由のために、接続の復元力を達成するのは困難です。
• ONS 15454 はルートの過負荷をサポートしません。同じネットワーク宛先に異なるコストで異なるルータを設定することはできません。
• ONS 15454 は、リンクがアップのときには常に LAN インターフェイス上でトラフィックのルーティングを試み、DCN ルータに接続されている NE 上のリンクは常にアップしています。
• DCN 接続に障害が発生した場合、そのルートはもはや使用できません。
1 つの解決法は、Generic Routing Encapsultation(GRE; 総称ルーティング カプセル化)トンネルを作成し、OSC/DCC/GCC ネットワークを使用して、リモート ルータ 1 と リモート ルータ 2 を論理的に接続することです(図15-18)。GRE トンネルの使用により、両方のリモート ルータには、DCN に障害が発生した場合に NOC ネットワークに到達する代替パスができます。ただし、代替パスはルーティング テーブルで過負荷になり、コストが高くなる可能性があります。
図15-18 DCN ケース スタディ 1:2 つのサブネット、2 つの DCN 接続、および GRE トンネルのある ONS 15454 リング
次のセクションでは、DCN ケース スタディ 1 におけるルータおよび ONS 15454 ノードでの IP 設定例を示します。
ピア ルータ 2(192.168.200.1)へのホスト ルートは、ONS 15454 ネットワークを示します(192.168.100.80 経由)。これは GRE トンネルを設定するために必要です。この設定では、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスにより過負荷になります。ただし、過負荷は、この最後の手段であるルートで発生する可能性があります。
ルータ 1(192.168.100.1)へのホスト ルーティング パスは、ONS 15454 ネットワークを示します(192.168.200.77 経由)。これは GRE トンネルを設定するために必要です。この設定では、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスにより過負荷になります。ただし、過負荷は、この最後の手段であるルートで発生する可能性があります。 表15-5 に、4 つの ONS 15454 ノードでのネットワーク設定を示します。スタティック ルートが作成され、DCN に接続されたノードは、最後の手段であるルータとして動作する機能をアドバタイズします。
|
|
|
|
---|---|---|---|
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 つの Section Data Communications Channel(SDCC; セクション データ通信チャネル)/Regeneration Section DCC(RS-DCC; 再生セクション DCC)/OSC または 8 つの Line DCC(LDCC; 回線 DCC)/Multiplex Section DCC(MS-DCC; 多重化セクション DCC)スパン内に配置します。ケース スタディ 1 の設計を実装する場合、最大スパン数を半分に分けるべきです。ただし、完全な IP ルーティングを持ち、すべての NE への接続を持つネットワークで DCN ケース スタディ 1 の設計を使用し、CTC/CTM 管理のみを必要とする場合、SOCKS プロキシ機能を使用して、同じ DCN 接続の復元力を提供できます。
DCN ケース スタディ 2(図15-19)は、両端に DCN 接続がある 4 ノード線形トポロジを示します。
図15-19 DCN ケース スタディ 2:両端に DCN 接続がある ONS 15454 線形トポロジ
DCN の復元力を維持するために、スタティック ルートが使用され、DCC/OSC/GCC 光リンク上のルータ 1 とルータ 2 間に GRE トンネルが作成されます。この例では、すべての ONS 15454 は同じサブネットの一部です。したがって、すべてのホストに代替パスを設定する必要があるため、ルータ 1 およびルータ 2 のスタティック ルートには、より多くのエントリがあります。
次のセクションでは、DCN ケース スタディ 2 におけるルータおよび ONS 15454 ノードでの IP 設定例を示します。
ピア DCN ルータ(サイト 2、192.168.100.2)へのホスト ルーティング パスは、GRE トンネルを設定するために必要な ONS 15454 ネットワーク(192.168.100.80 経由)を示します。この設定では、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスにより過負荷になりますが、最後の手段であるルートの過負荷も発生する可能性があります。
ルータ 1(192.168.100.1)へのホスト ルートは、ONS 15454 ネットワークを示します(192.168.200.77 経由)。これは GRE トンネルを設定するために必要です。この設定では、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスにより過負荷になります。ただし、過負荷は、この最後の手段であるルートでも発生する可能性があります。
表15-6 に、4 つの ONS 15454 ノードでのネットワーク設定を示します。スタティック ルートが作成され、DCN に接続されたノードは、最後の手段であるルータとして動作する機能をアドバタイズします。
|
|
|
|
---|---|---|---|
DCN ケース スタディ 2 の線形構成は、DCN ルータが障害の通知を受けないため、すべてのファイバ障害のための管理ネットワーク通信を効果的に保護しません。したがって、パケットを低コスト パスで送り続けます。この問題は、ファイバ障害が光リング ネットワークから内部で保護されるリング トポロジでは発生しません。ただし、DCN ネットワークで OSPF ダイナミック ルーティング プロトコルを使用することにより、この問題を解決できます。OSPF 設定は、DCN ケース スタディ 3 で示します。
DCN ケース スタディ 3 は、OSPF ルーティングを DCN ネットワークで使用することを除いて、DCN ケース スタディ 2 と同じ線形トポロジです。このトポロジでは、ノード ビュー(シングルシェルフ モード)またはマルチシェルフ ビュー(マルチシェルフ モード)の Provisioning > Network > OSPF タブにある LAN オプションの OSPF アクティブを両端の ONS 15454 ノードでイネーブルにする必要があります。さらに、OSPF は、ルータ 1、ルータ 2、および NOC ルータ間で動作している必要があります。
DCN 接続 は通常 OSPF が常にオプションであるとは限らないパブリック ネットワークを通過するため、ルータ 1、ルータ 2、および NOC ルータ間の接続は、OSPF がトンネルで動作できるように GRE トンネルとして設定されます。
図15-20 に、それぞれの OSPF 領域、トンネル接続、および必要な OSPF 仮想リンクのある線形構成を示します(トンネルを通過しない物理的接続は、直接的に実際のルーティング パスの一部ではないため、図に示しません。)。
図15-20 DCN ケース スタディ 3:OSPF を使用する両端に DCN 接続がある ONS 15454 線形トポロジ
次のセクションでは、DCN ケース スタディ 3 におけるルータおよび ONS 15454 ノードでの IP 設定例を示します。
両端の ONS 15454 への OSPF 仮想リンクが作成され、DCC/OSC/GCC OSPF 領域 1 をバックボーン領域 0 に接続します。NOC ルータでは、スタティック ルートが定義されていません。
表15-7 に、4 つの ONS 15454 ノードでのネットワーク設定を示します。スタティック ルートが作成され、DCN に接続されたノードは、最後の手段であるルータとして動作する機能をアドバタイズできます。
|
|
|
|
---|---|---|---|
• 192.168.100.79/32 - 領域 0.0.0.1 • 192.168.100.78/32 - 領域 0.0.0.1 |
|||
• 192.168.100.80/32 - 領域 0.0.0.1 • 192.168.100.79/32 - 領域 0.0.0.1 |
OSPF 仮想リンクでは、近接ノードは、ネットワークに接続されている物理またはトンネル インターフェイスではなく、ルータ IDで示す必要があります。NOC ルータでループバック インターフェイスを使用することにより、実際のインターフェイス IP アドレスから独立したルータ ID が選択されます。
DCN ケース スタディ 3 では、OSPF がより良い DCN 復元力とより効率的なルーティング選択を提供できるため、パフォーマンスが向上することを示しています。OSPF はネットワーク スケーラビリティも向上させます。OSPF を使用する際には、次の制限事項があります。
• OSPF の使用によって複雑さが増します。たとえば、ONS 15454 およびルータでの OSPF 仮想リンクとアドバタイズのプロビジョニングには、熟慮した上での計画が必要です。
• OSPF は、NOC とサイト ルータ間の DCN 接続でイネーブルにする必要があります。これは、このケース スタディで示すように、GRE トンネルによって行うこともできます。
• OSPF 領域の分離には、熟慮した上での計画が必要です。制限事項(OSPF 参照)を克服し、バックボーン領域での分離された領域とセグメント化を防ぐための仮想リンクの作成にも、計画が必要です。
DCN ケース スタディ 4(図15-21)では、DCN ケース スタディ 3 で示した簡易線形トポロジを拡張します。ただし、この例では、2 つの線形 DCN 接続は同じサイト ルータにあり、すべての ONS 15454 は同じサブネットにあります。GRE トンネルは、OSC/DCC/GCC ネットワーク上で、リモートのルータ 1 およびルータ 2 を論理的に接続します。これは、DCN ケース スタディ 1 の構成(図15-18)と似ています。GRE トンネルの使用により、リモート ルータには、DCN に障害が発生した場合に NOC ネットワークに到達する代替パスができます。ただし、ONS 15454 が同じサブネットにあるために、すべての代替パスはホスト ベースであるので、代替パスによりルータのルーティング テーブルが過負荷になり、より高いコストが発生する可能性があります。
図15-21 DCN ケース スタディ 4:2 つの DCN 接続のある 2 つの線形カスケード トポロジ
次のセクションでは、DCN ケース スタディ 4 におけるルータおよび ONS 15454 ノードでの IP 設定例を示します。
ピア DCN ルータ(ルータ 2、192.168.100.2)へのホスト ルーティング パスは、ONS 15454 ネットワークを示します(192.168.100.80 経由)。これは GRE トンネルを設定するために必要です。この設定では、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスにより過負荷になります。ただし、過負荷は、この最後の手段であるルートでも発生する可能性があります。
ピア DCN ルータ(ルータ、IP 192.168.100.1)へのホスト ルーティング パスは、ONS 15454 ネットワークを示します(192.168.200.79 経由)。これは GRE トンネルを設定するために必要です。この設定では、10.0.0.0 への外部ルート(NOC ネットワークを含む)のみが代替パスにより過負荷になります。ただし、過負荷は、この最後の手段であるルートでも発生する可能性があります。
表15-8 に、4 つの ONS 15454 ノードでのネットワーク設定を示します。スタティック ルートが作成され、DCN に接続されたノードは、最後の手段であるルータとして動作する機能をアドバタイズできます。
|
|
|
|
---|---|---|---|
「DCN ケース スタディ 1 の制限事項」 で説明した多くの制限事項は、このケース スタディにも適用されます。ただし、DCN 接続が光ネットワークの中央にあるため、これらはそれほど大きな問題ではありません。DWDM ネットワークでは、線形トポロジに中間ノード回線増幅器または Optical Add/Drop Multiplexing(OADM; 光分岐挿入)ノードによる多くのスパンがある場合(長距離接続に対応するためにときどき行われる)、遅延の増大が問題となる可能性があります。この場合、1 つの DCN に障害が発生すると、スパンの中央に近いノードの管理パケットは、完全なポイントツーポイント接続の 1.5 倍の時間で伝送されます。通常のルーティングの値は 0.5 です。GRE トンネルの完全な接続の長さは、代替ルーティング パスとして使用されます。
ONS 15454 ルーティング情報は Maintenance > Routing Table タブで表示されます。ルーティング テーブルには、次の情報が表示されます。
• Destination ― 宛先ネットワークまたはホストの IP アドレスを表示します。
• Mask ― 宛先ホストまたはネットワークに到達するために使用するサブネット マスクを表示します。
• Gateway ― 宛先ネットワークまたはホストに到達するために使用するゲートウェイの IP アドレスを表示します。
• Usage ― リストされたルートの使用回数を表示します。
• Interface ― 宛先にアクセスするために使用する ONS 15454 インターフェイスを表示します。値は次のとおりです。
–motfcc0 ― ONS 15454 イーサネット インターフェイス、すなわち、TCC2/TCC2P の RJ-45 ジャック、バックプレーン上の LAN 1 ピン(ANSI シェルフの場合)、MIC-C/T/P 上の LAN 接続(ETSI シェルフの場合)
–pdcc0 ― SDCC または RS-DCC インターフェイス、つまり SDCC または RS-DCC 終端として認識された OC-N/STM-N トランク カード
表15-9 に、ONS 15454 のルーティング エントリ例を示します。
|
|
|
|
|
|
---|---|---|---|---|---|
• 宛先(0.0.0.0)はデフォルトのルート エントリです。ルーティング テーブル内のすべての未定義宛先ネットワークまたは宛先ホスト エントリはデフォルトのルート エントリにマッピングされます。
• マスク(0.0.0.0)は常にデフォルト ルートを示す 0 です。
• ゲートウェイ(172.20.214.1)はデフォルトのゲートウェイ アドレスです。ルーティング テーブルにないすべての送信トラフィック、またはノードのローカル サブネットにない送信トラフィックは、このゲートウェイに送信されます。
• インターフェイス(motfcc0)は、ゲートウェイに到達するために ONS 15454 イーサネット インターフェイスを使用することを示します。
• 宛先(172.20.214.0)は、宛先ネットワーク IP アドレスです。
• マスク(255.255.255.0)は 24 ビット マスクで、172.20.214.0 サブネット内のすべてのアドレスが宛先となります。
• ゲートウェイ(172.20.214.92)はゲートウェイ アドレスです。このネットワークに属するすべての送信トラフィックは、このゲートウェイに送信されます。
• インターフェイス(motfcc0)は、ゲートウェイに到達するために ONS 15454 イーサネット インターフェイスを使用することを示します。
• 宛先(172.20.214.92)は、宛先ホスト IP アドレスです。
• マスク(255.255.255.255)は 32 ビット マスクで、アドレス 172.20.214.92 だけが宛先であることを示します。
• ゲートウェイ(127.0.0.1)はループバック アドレスです。このホストは、このアドレスを使用してネットワーク トラフィックを自身に送信します。
• インターフェイス(lo0)は、ゲートウェイに到達するためにローカル ループバック インターフェイスを使用することを示します。
• 宛先(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 であるホストによって宛先ホストがアクセスされることを示します。
ここでは、外部ファイアウォールの Access Control List(ACL; アクセス制御リスト)の例を示します。 表15-10 は、TCC2/TCC2P で使用するポートの一覧です。
|
|
|
---|---|---|
次に示す 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)です。
次に示す ACL の例では、プロキシ サーバのゲートウェイ設定がイネーブルな場合のファイアウォール設定を示しています。最初の例と同様に、CTC ワークステーションのアドレスは 192.168.10.10、ONS 15454 アドレスは 10.10.10.100 です。ファイアウォールは GNE に接続されているため、受信が CTC から GNE、送信が GNE から CTC へと送られます。CTC CORBA 標準定数が 683、TCC CORBA デフォルトが TCC 固定(57790)です。
ONS 15454 は、ノードおよびリンクの自動検出に必要な、PPP(ポイント ツー ポイント プロトコル)ベンダー拡張または OSPF タイプ 10 オパーク Link State Advertisement(LSA; リンクステート アドバタイズ)をサポートしない非 ONS ノードと通信できます。オープン GNE を設定することにより、GCC ベースのネットワークを非 ONS ノードの IP ネットワークとして機能させることができます。
オープン GNE ネットワークを設定するには、GCC 終端をプロビジョニングして、遠端の非 ONS ノードを含めることができます。この場合、0.0.0.0 のデフォルト IP アドレスまたは指定 IP アドレスのどちらかを使用します。GCC 作成時に [Far End is Foreign] チェックボックスをオンにして遠端の非 ONS ノードを設定します。0.0.0.0 のデフォルト IP アドレスを使用する場合、遠端の非 ONS ノードは任意の IP アドレスで自身を識別します。0.0.0.0 以外の IP アドレスを指定する場合は、セキュリティ レベルを追加することで、遠端ノードが指定 IP アドレスで自身を識別する場合にだけリンクが確立します。
デフォルトでは、プロキシ サーバは検出された ONS ピアにだけ接続を許可し、ファイアウォールが GCC ネットワークと LAN の間のすべての IP トラフィックをブロックします。ただし、プロキシ トンネルをプロビジョニングして、非 ONS ノードに対して 12 までの SOCKS バージョン 5 接続の宛先を追加できます。また、ファイアウォール トンネルをプロビジョニングして、GCC ネットワークと LAN の間を直接 IP 接続するための宛先を 12 まで追加できます。プロキシ トンネルおよびファイアウォール トンネルには、送信元と宛先の両方のサブネットが含まれます。この接続は送信元のサブネットから発生し、宛先のサブネットで終了します。そのあとで SOCKS 接続または IP パケット フローが許可されます。CTC クライアントが送信元サブネットにあり、要求した宛先が宛先サブネットにある場合、プロキシ接続が許可されます。ファイアウォール トンネルにより、ノード イーサネットと pdcc インターフェイスの間で IP トラフィックをルーティングできます。着信イーサネット パケットは、送信元アドレスがトンネル送信元に一致し、宛先がトンネル宛先に一致する場合に、ファイアウォールを介して許可されます。着信 pdcc パケットは、送信元アドレスがトンネル宛先に一致し、宛先アドレスがトンネル送信元に一致する場合に、ファイアウォールを介して許可されます。トンネルは TCP および UDP パケットだけに影響します。
プロキシ トンネルまたはファイアウォール トンネル(またはその両方)のアベイラビリティは、ノードのネットワーク アクセス設定によって異なります。
• ノードに GNE または ENE モードでイネーブルになったプロキシ サーバが組み込まれている場合は、プロキシ トンネルまたはファイアウォール トンネル(またはその両方)を設定する必要があります。
• ノードに proxy-only モードでイネーブルになったプロキシ サーバが組み込まれている場合は、プロキシ トンネルを設定できます。ファイアウォール トンネルは許可されません。
• ノードに組み込まれているプロキシ サーバがディセーブルの場合は、プロキシ トンネルもファイアウォール トンネルも許可されません。
図15-22 に、GCC ネットワークに接続された外部ノードの例を示します。この例では、プロキシ トンネルおよびファイアウォール トンネルが有効に機能しています。これらのトンネルがないと、GNE により PC と外部ノードの間の IP アクセスがブロックされます。
図15-22 外部終端のプロキシ トンネルおよびファイアウォール トンネル
図15-23 に、ENE イーサネット ポートに接続されたリモート ノードを示します。この例では、プロキシ トンネルおよびファイアウォール トンネルが有効に機能しています。これらのトンネルがないと、GNE により PC と外部ノードの間の IP アクセスがブロックされます。この構成には ENE のファイアウォール トンネルも必要です。
図15-23 ENE イーサネット ポートへの外部ノード接続
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(図15-24)では、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/MXP には次のものがあります。
• TXP_MR_2.5 および TXPP_MR_2.5(OC-N/STM-N SFP が取り付けられている場合)
• TXP_MR_10G および TXP_MR_10E(クライアントが OC-192/STM-64 として設定されている場合)
OSI は、OSC 終端、GCC 終端、またはその両方を使用して他の TXP/MXP カードに伝送される(またはトンネルされる)必要があります。サードパーティ製の NMS は、サードパーティ ベンダー OSI ベースの SONET 機器の GNE として機能する MSTP ONS NE を使用して、自身の NE に OSI 接続します。
OSI/MSTP シナリオ 2(図15-25)は、シナリオ 1 に似ていますが、MSTP NE が OSI NMS へ接続していない点が異なります。
OSI/MSTP シナリオ 3(図15-26)では、次の内容が示されています。
• OSI は SDCC または RS-DCC 終端上で伝送される。
• OSI は、OSC 終端、GCC 終端、またはその両方を使用して他のピア TXP/MXP に伝送される(またはトンネルされる)必要がある。
• MSTP NE は、サードパーティ製の OSI ベースの SONET NE の GNE である。MSTP NE はすべてのメディエーション機能を実行する。
OSI/MSTP シナリオ 4(図15-27)では、次の内容が示されています。
• OSI は SDCC または RS-DCC 終端上で伝送される。
• OSI は、OSC 終端、GCC 終端、またはその両方を使用して他のピア TXP/MXP に伝送される(またはトンネルされる)必要がある。
• OSS は、サードパーティ製 NE ネットワークを使用してすべての NE と IP 接続できる。
• MSTP NE は、サードパーティ製の OSI ベースの SONET NE の GNE である。MSTP NE はすべてのメディエーション機能を実行する。
• サードパーティ ベンダー製の NE は、Cisco MSTP ネットワークの GNE になる。
ここでは、Link Management Protocol(LMP; リンク管理プロトコル) 2 の管理と設定について説明します。特定アラームのトラブルシューティングについては、『Cisco ONS 15454 DWDM Troubleshooting Guide』を参照してください。LMPの設定については、『Cisco ONS 15454 DWDM Procedure Guide』を参照してください。
LMP は、Cisco ONS 15454 のノード間、またはCisco ONS 15454 のノードとベンダー固有のハードウェアを使用する他社製の選択されたノードの間で、Traffic Engineering(TE; トラフィック処理)リンクを確立するために使用します。
LMP は、制御チャネルを使用してノード間の TE リンクを管理します。TE リンクは、ネットワークおよびインターネット上のトラフィック フローで可能な最も効率的なパスを定義するように設計されています。トラフィック処理には、トラフィック管理、容量管理、トラフィック測定とモデル化、ネットワークのモデル化、およびパフォーマンス分析が含まれます。トラフィック処理の方法には、呼ルーティング、接続ルーティング、Quality of Service(QoS; サービス品質)リソース管理、ルーティング テーブル管理、および容量管理などがあります。
LMP は、2 つの Optical Cross-connect(OXC; 光クロスコネクト)ノードのようなピア ノード間の TE リンクを管理します。ピア ノードには、同等のシグナリングおよびルーティングがあります。LMP は、OXP などのノードと隣接する Optical Line System(OLS; 光回線システム)ノードの間の TE リンクも管理します。OLS ノードの例として、ONS 15454 DWDM ノードがあります。
ルータ、スイッチ、OXC ノード、DWDM OLS ノード、および Add/Drop Multiplexer(ADM; アド/ドロップ マルチプレクサ)のあるネットワークでは、Generalized Multiprotocol Label Switching(GMPLS)などの共通のコントロール プレーンを使用して、リソースをプロビジョニングし、保護および復元技術を使用するネットワークの存続可能性を提供します。LMP は、GMPLS プロトコル スイートの一部です。
1 つの TE リンクは、いくつかの個々のリンクから形成できます。TE リンクの管理は、帯域外方式のほかに、帯域内メッセージングによって遂行できます。次の資料で、TE リンクを管理する 1 組のノード間の LMPについて説明します。LMP は次のタスクを実行します。
• 複数のタイプのネットワークで、保護および復旧の目的でリンク障害をローカライズする
DWDM ネットワークでは、頻繁に Multiprotocol Label Switching(MPLS; マルチプロトコル ラベル スイッチング)と GMPLS を共通のコントロール プレーンとして使用して、パケットをネットワークでどのようにルーティングするかを制御します。
LMP は、ルーティング、シグナリング、およびリンク管理のためにノード間に存在しなければならない制御チャネルを管理します。制御チャネルが存在するためには、各ノードに、もう一方のノードから到達できる IP インターフェイスが付いている必要があります。これらの IP インターフェイスがまとまって制御チャネルを形成します。コントロール メッセージ用のインターフェイスは、データ用と同じインターフェースである必要はありません。
MPLS は、ルーティング テーブルおよびルーティング プロトコルから独立しているエンジニアリング ネットワークのトラフィック パターンのメカニズムを提供します。MPLS は、パケットをネットワークにどのように転送するかを示すショート ラベルをネットワーク パケットに割り当てます。従来のレイヤ 3 転送メカニズムでは、各ホップでパケット ヘッダーを分析し、ルーティング テーブルのルックアップに基づいて次のホップを決定する必要があります。MPLS では、パケット ヘッダーの分析は、パケットが MPLS クラウドに入ったときに 1 回だけ行われます。その後、パケットは、ラベルに指定されている Label Switch Path(LSP; ラベル スイッチ パス)として知られるストリームに割り当てられます。この短い固定の長さのラベルは、転送テーブルにおけるインデックスです。転送テーブルは、従来の各ホップでのルーティング テーブルのルックアップより効率的です。MPLS を使用して、制御プロトコル(LSPの管理に使用される)とユーザ データの両方を同じ伝送インターフェイスで伝送できます。
GMPLS は、MPLS がベースになっていて、Time Division Multiplexing(TDM; 時分割多重)スロット(SONET および SDH など)、レイヤ 1 の Wavelength Division Multiplexing(WDM; 波長分割多重)波長、およびファイバを含む、追加のテクノロジーをサポートするための拡張されたプロトコルを備えています。MPLS の場合、制御トラフィック(シグナリングおよびルーティング)は、伝送インターフェイスで実行できます。GMPLS では、MPLS の場合とは異なり、別の制御チャネルが使用されます。GMPLS 制御チャネルは、LMPによって管理されます。GMPLS では、2 つの隣接ノード間の制御チャネルは、これらのノード間のデータ リンクと同じ物理メディアを使用する必要はありません。
制御チャネル管理では、隣接ノード間の制御チャネルを確立して維持します。制御チャネルでは、ノード間で Config メッセージ交換とファスト キープアライブ メカニズムを使用します。後者は、より低いレベルのメカニズムが制御チャネルの障害の検出に使用できない場合に必要となります。最大で 4 つの LMP 制御チャネルをサポートできます。
ノードは最初にコンフィギュレーション メッセージ(Config、ConfigAck、および ConfigNack)を交換し、これらのメッセージは、識別子を交換してキープアライブ プロトコルのためのパラメータを取り決めるために使用されます。次に、ノードは Hello メッセージの連続高速交換を行い、これらのメッセージは、チャネルのヘルスをモニタリングするために使用されます。
(注) 識別子は 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 フラグをもう一方のノードに設定します。どちらの場合でも、その後、ノードはこの制御チャネルへのメッセージ送信を停止します。制御チャネルがテイク ダウンする前に、データ リンクを管理するために使用できるバックアップ制御チャネルが配置されている必要があります。
• ノングレースフルとは、ノードのうちの 1 つがメッセージ送信を停止することを意味します。もう一方の側は HelloDeadInterval のあとに障害を宣言しますが、Hello メッセージを送信し続けて制御チャネルがバックアップされるかどうかを確認します。
LMP は、リンクが TE リンクに分類され、これらのリンクのプロパティが両方のエンドポイントで同じになることを保証します。これが「TE リンク管理」または「リンク プロパティ相関」と呼ばれるものです。
リンク プロパティ相関は、TE リンク プロパティを同期させ、TE リンク設定を検証するために使用します。LMP のリンク プロパティ相関関数は、1 つまたは複数のデータ リンクを 1 つの TE リンクに集約し、TE リンクのプロパティを近接ノードに同期させます。この手順は、LinkSummary メッセージを近接ノードに送信することにより開始されます。LinkSummary メッセージには、ローカルおよびリモートの Link Identifier、TE リンクを構成するすべてのデータ リンクのリスト、およびさまざまなリンク プロパティが含まれます。リンク プロパティとの一致または不一致を示す LinkSummary の受信に応答して、LinkSummaryAck または LinkSummaryNack メッセージを送信することは必須です。
(注) 最大 256 個のLMP TE リンクがサポートされます。
障害管理は、制御チャネルがデータ リンクと物理的に異なっている場合に特に役立ちます。障害管理は、1 つまたは複数の TE リンク データ チャネルのステータスに関する高速通知に使用されます。障害管理の使用は、TE リンクの LinkSummary 交換の一部として取り決めます。データ リンクおよび TE リンク障害は高速で分離できるので、障害管理は、単方向および双方向の LSP をサポートします。割り当てられたデータ リンクのヘルスをモニタリングする従来の方法がもはや適切ではないため、透過的な装置が役立ちます。その代わりに、障害検出は、レイヤ 2 またはレイヤ 3 ではなく、物理レイヤ(たとえば、データの光または光モニタリングの損失)に委任されます。障害管理では、ChannelStatus、ChannelStatusAck、ChannelStatusRequest、および ChannelStatusResponse メッセージを使用します。
(注) LMP Channel Activation/Deactivation Indication(LMP チャネル有効化/無効化表示)の手順は、サポートされません。これらの手順については、IETF LMP 文書のセクション 6.4 および 6.5で説明しています。
LMP は、ピア ノード(シグナリングやルーティングで同位であるノード)間のトラフィック処理リンクを管理します。LMP WDM 拡張 3 の目的は、LMP を OXC ノードと隣接 DWDM OLS ノードの間で使用できるようにすることです。図15-28 に、LMP と LMP-WDM の関係を示します。OXC 1 と OXC 2 は、制御チャネルが LMP で管理されるピア ノードです。LMP-WDM は、OXC ノードと OLS ノードの間の制御チャネルを管理します。
2 つの OLS ノードが LMP-WDM を介して設定および光リンクの現在の状態を 2 つのピア ノード(OXC 1 および OXC 2)に通信できる場合、ネットワーク ユーザビリティは、手動による設定の短縮および障害の検出と復旧の機能拡張により向上します。
図15-29 に、ネットワークレベルの LMP の実装を示します。これは、MPLS および GMPLS に基づくエンドツーエンド ルーティングを使用する IP プラス光ネットワークです。主なネットワーク コンポーネントは、次のとおりです。
–Cisco Carrier Router System(CRS)
–Cisco Gigabit Switch Router(GSR)
• Ultra Long-Haul(ULH; 超長距離)DWDM 機器
LMP とほかの機能により、Cisco ONS 15454 DWDM ノードは、ULH DWDM の役割を果たすことができます。図15-29 に、ネットワーク コンポーネント間の関係を示します。
Cisco ONS 15xxx 製品は、Network Address Translation - Protocol Translation(NAT-PT; ネットワーク アドレス変換プロトコル変換)をサポートするインターネット ルータが GNE(ONS 15454 DWDM など)とクライアント ワークステーション間でプロビジョニングされる場合、IPv6 ネットワークで機能できます。NAT-PT は RFC-2766 で定義されています。IPv4 および IPv6 ノードは、IPv6 スタックと IPv4 スタックの両方が IPv6 DCN ネットワークと IPv4 DCC ネットワーク間でインターフェイスできるようにすることにより、NAT-PT を使用して相互に通信します。
NAT-PT は、IPv6 ネットワークのアドレスを IPv4 ネットワークのアドレスにバインドし(その逆もあり)、アドレス タイプ間を移動するパケットに透過的なルーティングを提供します。エンド ノードを変更する必要はなく、IP パケットのルーティングは、エンド ノードに対して完全に透過的です。ただし、NAT-PT はサポートするセッションを追跡する必要があり、セッションに関連する着信および送信データグラムは、同じ NAT-PT ルータを通過する必要があります。プロトコル変換は、アドレス変換をプロトコルの構文およびセマンティックスの変換により拡張するために使用されます。
(注) IPv6 ネットワークとインターフェイスするクライアントでは、Mozilla 1.7 のみがサポートされます。