Cisco Transport Manager ユーザ ガイド Release 5.0
トラブルシューティング
トラブルシューティング
発行日;2012/02/01 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 12MB) | フィードバック

目次

トラブルシューティング

トラブルシューティング

この章では、CTM または CTM GateWay の運用に関する高度な問題を解決するためのトラブルシューティング手順について説明します。シスコ テクニカル サポートへ連絡する前に、この章のトラブルシューティング手順を実行してください。

この章では、次のトラブルシューティングについて説明します。

「概要」

「サーバの問題」

「クライアントの接続に関する問題」

「クライアントの動作に関する問題」

「CTM GateWay/TL1 の問題」

「CTM GateWay/CORBA の問題」

「Cisco CRS-1 および Catalyst 6509 の問題」


) CiscoView のトラブルシューティングに関する詳細は、付録F「CiscoView による NE の設定と監視 - ONS 15501、ONS 15530、ONS 15540」「トラブルシューティング」を参照してください。


G.1 概要

トラブルシューティングは、次のとおりです。

1. 問題の原因を特定する:どのデバイスやリンク、インターフェイス、アプリケーションに問題があるか。

2. ネットワーク上の問題を検出する:どの VLAN やサブネットワーク、セグメントで問題が起こっているか。

3. 現在のネットワーク パフォーマンスを、既定の基準と比較する:パフォーマンスは優れているか、劣っているか。

4. 問題が起きたのはいつからか調査する:最初に問題を見つけたのはいつか。繰り返し起こっているか。

5. 問題の範囲を確定する:問題は、どのくらい広範囲に及んでいるか。悪化しているか。


) この章では、サーバとクライアントがデフォルトのディレクトリ(サーバは
/opt/CiscoTransportManagerServer ディレクトリ、クライアントは /opt/CiscoTransportManagerClient ディレクトリ(Solaris の場合)または C:\Cisco\TransportManagerClient ディレクトリ(Windows の場合)にインストールされていることを前提としています。製品をデフォルト ディレクトリ以外にインストールした場合は、デフォルトのパスを実際のインストール先のパスに置き換えて考えてください。


G.2 サーバの問題

ここでは、CTM サーバ関連の問題に対するトラブルシューティング手順を説明します。


) CTM サーバがインストールされている Solaris ワークステーションで操作を実行するには、Solaris ワークステーションに root ユーザとしてログインする必要があります。


G.2.1 CTM サーバが応答しない


ステップ 1 CTM サーバがインストールされている Solaris ワークステーションに、root ユーザとしてログインします。

ステップ 2 次のコマンドを入力し、CTM サーバ プロセスのステータスを表示します。

showctm
 

root ユーザの特権はないが sudo 機能(root 以外のユーザで特別なコマンドを実行する)を使用できる UNIX グループに属している場合は、次のコマンドを入力します。

sudo showctm
 

/CTMServer を含む行が表示された場合、CTM サーバは動作しています。

/CTMServer を含む行が表示されない場合、CTM サーバは動作していません。この場合は、ステップ 3 に進んでください。


) /opt/CiscoTransportManagerServer/log にある ctmop.log ファイルで、サーバが他のユーザによって停止されたのか、異常終了したのかを調べることもできます。異常終了した場合は、ステップ 3 に進んでください。


ステップ 3 getinfo.sh CTM サーバ ツールを実行し、データを弊社代理店にご連絡ください。

root ユーザの特権はないが sudo 機能(root 以外のユーザで特別なコマンドを実行する)を使用できる UNIX グループに属している場合は、次のコマンドを入力します。

sudo getinfo.sh
 

ステップ 4 /opt/CiscoTransportManagerServer/bin ディレクトリにある ctms-start スクリプトを使用して CTM サーバを起動します。

a. root ユーザとしてログインします。

b. /opt/CiscoTransportManagerServer/bin ディレクトリに移動し、次のコマンドを入力します。

ctms-start
 

root ユーザの特権はないが sudo 機能(root 以外のユーザで特別なコマンドを実行する)を使用できる UNIX グループに属している場合は、次のコマンドを入力します。

sudo ctms-start


 

上述の手順で問題が解決しなかった場合は、次の手順を実行してください。


ステップ 1 /opt/CiscoTransportManagerServer/cfg/CTMServer.cfg ファイルが破損していないことを確認します。このファイルの database セクションには、db-config-mode = auto というパラメータがあるはずです。このエントリがない場合は、CTM サーバの設定ファイルが破損しています。CTM サーバを再インストールしてください。

ステップ 2 /var/opt/oracle/oratab ファイルの最初に CTM5_0:/oraclesw9i/product/9.2:Y に類似したエントリがあることを確認します。このエントリがない場合は、Oracle データベースがインストールされていない可能性があります。CTM サーバをインストールするには、Oracle データベースが必要です。


 

G.2.2 CTM サーバに接続できない


ステップ 1 クライアント PC またはワークステーションから、サーバの IP アドレスを指定して ping を実行します。

ステップ 2 ping が失敗した場合は、IP 接続性の問題を解決してから、もう一度実行します。

ステップ 3 サーバに対して Telnet を実行し、root ユーザとしてログインします。

ステップ 4 次のコマンドを入力して、CTM が動作しているかどうかを確認します。

showctm
 

root ユーザの特権はないが sudo 機能(root 以外のユーザで特別なコマンドを実行する)を使用できる UNIX グループに属している場合は、次のコマンドを入力します。

sudo showctm
 

ステップ 5 サーバでは、少なくとも次の 4 つのプロセスを動作させておく必要があります。

root 3778 0.1 0.1567 9592 ? S 16:57:36 0:00 /opt/CiscoTransportManagerServer/bin/CTMServer
root 3771 0.1 0.4 6208 pts/1 S 16:57:34 0:00 /opt/CiscoTransportManagerServer/bin/CTMServer
root 3876 0.5 0.6129464 8648 ? R 16:58:12 SnmpTrapService
root 3798 26.8 4.115732060968 ? S 16:57:37 0:29 SMService
 

ステップ 6 4 つのプロセスに実行されていないものがある場合は、サーバを手動で停止します。次のコマンドを入力します。

ctms-stop
 

ステップ 7 以前にサーバの IP アドレスを変更した場合は、 表4-12 に示した設定ファイルがアップデートされていることを確認します。「CTM サーバの IP アドレス変更後の設定ファイルの更新」を参照してください。

ステップ 8 次の手順を実行して、Oracle データベースに接続できることを確認します。

a. 次のコマンドを入力して、Oracle ユーザとしてログインします。

su-oracle
 

b. 次のコマンドを入力して、SQL*Plus セッションを開きます。

omu-u60-3% sqlplus ctmanager/ctm123!
 

ステップ 9 エラー メッセージが表示されるだけで SQL プロンプトが表示されない場合には、サーバを再度ブートします。サーバがブートするのを待ってから、クライアントを実行します。Oracle が実行されていて、接続を受け入れていれば、SQL プロンプトが表示されます。

ステップ 10 次のコマンドを入力して、CTM を手動で再起動します。

SQL> exit
omu-u60-3% exit
omu-u60-3% logout
ctms-start
 

root ユーザの特権はないが sudo 機能(root 以外のユーザで特別なコマンドを実行する)を使用できる UNIX グループに属している場合は、次のコマンドを入力します。

sudo ctms-start
 

ステップ 11 5 分間待ってから、クライアントを実行します。


 

G.2.3 NE の接続状態が「Unavailable」として表示される

Domain Explorer ウィンドウに NE の接続状態が「Unavailable」と表示される場合は、接続または設定に問題があります。NE を CTM ドメインに追加し、5~10 分間待った後で、次の手順を実行します。


ステップ 1 NE の IP アドレスを表示するために、 Domain Explorer ウィンドウで NE を選択します。 Network Element Properties ペインの Address タブをクリックすると、選択した NE の IP アドレスが表示されます。

ステップ 2 CTM サーバから次のコマンドを入力し、CTM サーバから NE に接続できることを検証します。

ping <IP_address>
 

ステップ 3 ping に失敗した場合は、data communications network (DCN; データ通信ネットワーク)に物理的な問題または設定上の問題が発生しています。

a. 以前に接続できていた場合:

DCN のルータまたは CTM サーバの設定に変更を加えていない場合は、物理的な問題が存在します。

設定に変更を加えている場合は、変更内容に問題がある可能性があります。変更後の設定を検証してください。

b. 接続を一度も行っていない場合:

物理的な問題がないかどうかを確認します。

DCN 設定を確認します。

ステップ 4 ping が成功した場合は、NE のソフトウェア バージョンが SUpported NE Table にリストされていることを確認します。「CTM ドメインへの新しい NE ソフトウェア バージョンの追加」を参照してください。

ステップ 5 ONS 15501、ONS 15530、および ONS 15540 の NE の場合は、各 NE で SNMP のリード(read)およびライト(write)コミュニティ ストリングを正しく設定する必要があります。各 NE の実行設定には、次の例のようなエントリが含まれている必要があります。

snmp-server community public RO
snmp-server community private RW
 

サーバで設定したコミュニティ ストリングは、NE で設定したストリングと一致している必要があります。ONS 15501、ONS 15530、および ONS 15540 NE で CTM のコミュニティ ストリングを設定する方法については、「ONS 15501、ONS 15530、および ONS 15540 の NE を追加するための前提条件」 を参照してください。


 

G.2.4 テーブルを起動するとデータベースにエラーが発生する

CTM で使用中の Oracle データベースまたは Oracle リスナーがダウンしている場合は、テーブルを起動するとデータベース エラーが発生します。テーブル起動時のエラーをトラブルシューティングするには、次の手順を実行します。


ステップ 1 Oracle ユーザとしてログインして、次のコマンドを入力します。

sqlplus ctmanager/ctm123!
 

ログインに成功すると、SQL> プロンプトが表示されます。この場合は、Oracle データベースがインストールされており、データベース サーバが起動しています。ログインできない場合は、Oracle データベースがインストールされていないか、またはデータベース サーバが起動していません。

ステップ 2 Oracle データベースを起動するには、Solaris ワークステーションに Oracle ソフトウェアの所有者ユーザとしてログインします。

ステップ 3 シェル プロンプトで次のコマンドを入力し、Oracle データベースを起動します。

dbstart
 

ステップ 4 シェル プロンプトで次のコマンドを入力し、Oracle リスナーを起動します。

lsnrctl start
 

Oracle データベースまたは Oracle リスナーの起動について問題が解決しない場合は、Oracle のマニュアルを参照するか、Oracle 社のサポートに連絡してください。


 

G.2.5 SNMP トラップが NE から転送されない

SNMP トラップが転送されない場合は、トラップ ポートがすでに使用されているか、または NE の設定に誤りがある可能性があります。

G.2.6 トラップ ポートが使用できない

CTM サーバは、NE から SNMP トラップを受け取るために、SNMP トラップ ポートに排他的にアクセスできる必要があります。


ステップ 1 標準の SNMP トラップ ポート(No. 162)が、同じ Solaris ワークステーションで実行中の他のアプリケーションで使用されていないことを確認するために、次のコマンドを入力します。

netstat -a | grep 162
 

次の行が表示される場合は、SNMP トラップ ポートが他のアプリケーションで使用されています。

*.162 Idle
 

ステップ 2 トラップ ポートが他のアプリケーションで使用されている場合は、そのアプリケーションを停止します。


 

G.2.7 ONS 15530 および ONS 15540 の設定に関する問題

トラップを CTM サーバへ送信するには、ONS 15530 および ONS 15540 の NE を正しく設定する必要があります。


ステップ 1 NE の実行設定には、次の例に示すようなエントリが含まれている必要があります。

snmp-server enable traps snmp authentication warmstart
snmp-server enable traps bgp
snmp-server enable traps oscp
snmp-server enable traps config
snmp-server enable traps entity
snmp-server enable traps fru-ctrl
snmp-server enable traps topology throttle-interval 60
snmp-server enable traps optical monitor min-severity not-alarmed
snmp-server enable traps rf
snmp-server enable traps aps
snmp-server enable traps patch
snmp-server enable traps cdl all
snmp-server enable traps alarms
snmp-server enable traps threshold min-severity degrade
 
snmp-server host 172.20.126.214 version 2c public snmp bgp oscp
config entity fru-ctrl topology optical rf aps patch cdl alarms threshold
 

この例では、ホスト 172.20.126.214 が、指定されたトラップを NE から受け取るようになっています。

ステップ 2 CTM サーバとデバイス上で、次のコマンドを実行することもできます。

a. root ユーザとしてログインし、CTM サーバで次のコマンドを入力します。

# snoop udp port 162
 

b. デバイス上で次のコマンドを入力して、設定を変更します。

wr mem
 

デバイスが正しく設定されている場合は、 snoop コマンドに対して設定変更トラップがレポートされます。


 

G.2.8 パフォーマンス モニタリング(PM)データが表示されない


ステップ 1 Domain Explorer NE Property ペインを使用し、選択した NE に対して PM 収集が無効になっていないかどうかを確認します。

ステップ 2 Administration > Control Panel を選択し、 PM Service を展開表示します。NE のタイプを選択して、サービス ステータスが Active か Not Active かを確認します。

ステップ 3 Administration > Audit Log の順にクリックし、選択した NE に対して PM が無効になっていないかどうかを確認します。

ステップ 4 Administration > Control Panel を選択し、 PM Service をクリックします。 PM Data Storage フィールドを調べます。 Optimized を選択し、値 0 以外の値だけをデータベースに保存します。 Optimized を選択すると、値 0 も含めてすべての値を保存する場合より少ないスペースですみます。 PM Data Storage フィールドで Normal を選択すると、値 0 も含めてすべての PM の値がデータベースに保存されます。


) PM データ記憶域を最適化する機能は、CTC ベースおよび ONS 155xx の NE でだけ有効です。


ステップ 5 Administration > Error Log を選択し、PM サービスに対して、クリティカル エラー、メジャー エラー、マイナー エラーがないかどうかを確認します。

ステップ 6 「PM データを収集しているときに NE が到達可能である」ことを確認します。NE が到達可能でない場合は、 Audit Log table Administration > Audit Log )にエントリが作成されます。


 

G.2.9 CTC ベースの NE が検出できない


ステップ 1 NE が起動していて動作していることを確認します。

ステップ 2 NE の IP アドレスとデフォルト ルートが正しく設定されていることを確認します。

ステップ 3 NE で正しいバージョンのシステム ソフトウェアが動作していることを確認するには、NE に対して CTC セッションを開き、NE のソフトウェア バージョンを確認します。

ステップ 4 (このノードが検出された) NE が GNE として CTM に追加されていて、有効になっていることを確認します。

ステップ 5 GNE から CTC を開き、CTC で NE が検出されることを確認します。


 

G.2.10 CTC ベースの NE に到達できない


ステップ 1 NE が起動していて動作していることを確認します。

ステップ 2 NE の IP アドレスとデフォルト ルートが正しく設定されていることを確認します。

ステップ 3 CTM が NE との接続を再確立するまで、ポーリング周期 5 回分の期間だけ待ちます。

ステップ 4 CTM サーバから NE へ IP で接続できることをテストするために、CTM を実行している Solaris ワークステーションから次のコマンドを入力します。

ping <NE_IP_address>
 

ステップ 5 CTM がサポートするバージョンのシステム ソフトウェアが NE で動作していることを確認するために、NE に対して CTC セッションを開き、NE のソフトウェア バージョンを確認します。

ステップ 6 CTM が NE に到達するために使用するユーザ名とパスワードがこの NE に存在することを確認します。


 

G.2.11 ONS 15501、ONS 15540、または ONS 15530 に到達できない


ステップ 1 サーバ上で次のコマンドを入力し、サーバと NE の IP 接続を確認します。

ping <NE_IP_address>
 

ステップ 2 NE が IP で到達可能な場合は、正しいリード(read)コミュニティ ストリングがサーバに設定されていることを確認します。

CTM サーバで Administration > ONS 155XX > ONS155XX SNMP Settings Table を選択し、CTM に設定されているコミュニティ ストリングを表示します。

NE で次のコマンドを入力し、NE に設定されているリード(read)コミュニティ ストリングを表示します。

show run | begin SNMP
 

実行設定では、コミュニティ ストリングが次のようなエントリとして表示されます。

snmp-server community public RO
snmp-server community private RW
 

この例では、リード ストリングは パブリック で、リード/ライト ストリングは プライベート です。

ステップ 3 IP 接続およびコミュニティ ストリングは正しくてもデバイスがまだ動作しない場合は、ONS 155xx NE Service によって報告されるエラーのログを確認します。


 

G.2.12 回線が表示されない

CTM で回線が表示されない場合、または CTC と CTM で表示される情報が異なる場合は、次の手順を実行します。


ステップ 1 CTM サーバが NE と同期するまで、2 分間待ちます。 Circuit Table が自動更新モードに設定されていない場合は、 Refresh Data ツールが点滅したら、このツールをクリックします。

ステップ 2 表示する回線の発信元 NE または着信先 NE から Circuit Table が開くことを確認します。

ステップ 3 回線の一部である NE (発信元、着信先、またはドロップ ポイント)が CTM で使用可能かどうかを確認します。

ステップ 4 別の CTC セッションを開き、新しく開いた CTC セッションの回線情報と CTM で表示される回線情報を比較します。


 

G.2.13 モニタ回線の回線状態が「Duplicate ID」と表示される

CTM は、固有の番号を作成して回線名に付加することで、モニタ回線の名前を固有なものにします。まれに、CTM は、同じ名前のモニタ回線を複数作成する場合があります。これらの回線の状態は、「Duplicate ID」となります。これは既知の問題で、DDTS 番号 CSCdz87566 で報告されています。

回線状態が「Duplicate ID」の場合は、実際の回線状態を確認することができません。この場合、重複している名前を一意の名前に変更することで、回線状態を正しく表示することができます。 Modify Circuit ウィザードを使用して、それぞれのモニタ回線に固有の名前を入力します。

G.2.14 NE モデル タイプが「Unknown」と表示される

イン サービスの NE を Domain Explorer に追加しても、モデル タイプが「unknown」として表示される場合は、NE の正しいソフトウェア バージョンがデータベースにあらかじめ実装されていない可能性があります。つまり、CTM は NE の認識可能なバージョンを検出していません。

NE Software Table を使用して、NE のソフトウェア バージョン文字列を CTM データベースに追加します。「ソフトウェア バージョンの表示と新規のソフトウェア イメージを使用した NE の再起動」を参照してください。

G.2.15 CTC バイナリを CTM サーバにコピーできない

CTC バイナリを CTM サーバにコピーできない場合は、<C TM_install_directory> /cms/ ディレクトリが存在しないか、上書き禁止に設定されている可能性があります。このディレクトリが検出されない場合、書き込み可能な cms ディレクトリを作成します。または、既存の cms ディレクトリに対するアクセス権を、書き込み可に変更します。

G.2.16 メモリのバックアップ、メモリの復元、ソフトウェアのダウンロードが失敗する


ステップ 1 Domain Explorer ウィンドウで、 Administration > Job Monitor の順にクリックします。 Job Monitor Table には、動作のステータスが表示されます。失敗の理由は、 Additional Information 欄に示されます。

ステップ 2 Domain Explorer ウィンドウに戻り、 Administration > Error Log の順に選択します。 Error Log Table に、メモリのバックアップと復元、またはダウンロードの失敗に関する情報が表示されます。

ステップ 3 「エラー メッセージ」を参照して、エラーに対する正しい処置を行います。


 

G.2.17 メモリの自動バックアップ、ソフトウェアのコミット、ソフトウェアの復帰が失敗する


ステップ 1 Domain Explorer ウィンドウで、 Administration > Audit Log の順にクリックします。 Audit Log Table には、動作のステータスが表示されます。

ステップ 2 Domain Explorer ウィンドウに戻り、 Administration > Error Log の順に選択します。 Error Log Table に、失敗の理由が表示されます。

ステップ 3 「CTM サーバ エラー メッセージ」を参照して、エラーに対する正しい処置を行います。


 

G.2.18 getinfo.sh スクリプトが失敗する

次のエラーが原因で getinfo.sh スクリプトが失敗する場合があります。

"Error: permission denied while running 'rsh.' Check the environment and make sure the root is permitted to run .rsh on host <IP_address> ."

getinfo.sh スクリプトは、そのエントリが /.rhosts ファイルに作成されるまで動作しないので、この問題が発生します。この問題は、ローカル サーバおよびデータベースの設定でも発生します。これは既知の問題で、DDTS 番号 CSCin66495 で報告されています。

サーバの IP アドレスを /.rhosts ファイルのエントリに追加して、問題を解決します。

G.2.19 get nestate コマンドの使用

EMS サーバの bin ディレクトリにある ctm ユーティリティでは get nestate CLI コマンドを利用することができます。このコマンドを実行すると、プロビジョニングされている運用状態(NE_Info_Table: NEState)と、その運用状態に対する読み取り専用の修飾子(NE_Info_Table: NEDiscoveryState)を得ることができます。 get nestate コマンドからは、次のいずれかの値が返ります。

Preprovisioned

In Service

Out of Service

Under Maintenance

In Service-Initializing

In Service-Sync Configuration

さらに、 show nelist コマンドは、すべての NE について次の情報を表示します。

NE database ID

NE IP address

Model type

SID

Network partition ID

Operational state

G.3 クライアントの接続に関する問題

さまざまな理由で、CTM クライアントが CTM サーバに接続できない場合があります。問題が解決するまで、次にあげる手順を順に実行してください。

G.3.1 データベースが使用できない

CTM クライアントが CTM サーバに接続できない場合は、データベースが使用できることを確認します。


ステップ 1 Oracle ユーザとして CTM サーバにログインします。

ステップ 2 次のコマンドを入力して、データベースに接続します。

sqlplus ctmanager/ctm123!
 

ステップ 3 「maximum processes exceeded」 というエラー メッセージが表示された場合、データベースの接続が最大数に達しています。この場合、クライアントをいくつか閉じます。または、データベースの最大プロセス数を増やすようにデータベース管理者に依頼します。


 

G.3.2 データベースでタイムアウトが発生する


ステップ 1 Alarm Browser Table Alarm Log Table Audit Log Table 、および PM Table などのテーブルを開く前に、CTM ドメイン全体ではなく、グループまたは NE を 1 つを選択することで、クエリーのスコープを絞ります。

ステップ 2 C:\Cisco\TransportManagerClient\config ディレクトリまたは /opt/CiscoTransportManagerClient/config ディレクトリ内の ems-client.cfg ファイルを編集することで、クライアント データベースのクエリー タイムアウト時間を長くします。

ステップ 3 Oracle データベース サーバにハードウェア リソースを追加します。

ステップ 4 Oracle データベース サーバに対してクライアントから ping を実行して、応答時間を確認します。応答が返ってくるまでの往復に時間がかかるようであれば、帯域幅を増やします。


 

G.3.3 CTM クライアントと CTM サーバが接続されていないようである

データベースが使用可能な場合は、CTM クライアントと CTM サーバの接続を調べます。


ステップ 1 CTM サーバの動作している Solaris ワークステーションで次のコマンドを入力して、サーバの IP アドレスを表示します。

ifconfig -a
 

コマンドの実行結果が次のように表示されます。

hme0:flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>mtu 1500
inet 192.168.120.93 netmask ffffff00 broadcast 192.168.120.255
 

IP アドレスは、inet フィールドの後ろに示されています。

ステップ 2 CTM クライアントで次のコマンドを入力して、CTM クライアントと CTM サーバの物理的な接続に問題がないことを確認します。

ping <IP_address>
 

ここで、IP address には、CTM サーバが動作している Solaris ワークステーションの IP アドレスを指定します。

ステップ 3 ping コマンドが失敗した場合は、物理的に接続しなおし、CTM クライアントにログインします。


 

G.3.4 プロビジョニング担当者またはオペレータとしてログインできない


ステップ 1 次のデフォルトのユーザ名とパスワードを使用して、CTM クライアントにログインします。

ユーザ名: SysAdmin

パスワード: Ctm123!

ステップ 2 SysAdmin としてはログインできるが、プロビジョニング担当者またはオペレータとしてはログインできない場合は、そのプロビジョニング担当者またはオペレータが存在しているかどうかと、無効になっていないかどうかを確認します。 Domain Explorer ウィンドウで、 Administration > CTM Users の順にクリックし、設定されているすべての CTM ユーザのテーブルを表示します。

ステップ 3 CTM Users テーブルにそのプロビジョニング担当者またはオペレータが表示されない場合、そのユーザはプロビジョニング担当者またはオペレータとして設定されていません。プロビジョニング担当者またはオペレータとして設定し、そのユーザとしてログインします。

ステップ 4 そのプロビジョニング担当者またはオペレータが CTM Users テーブルに表示される場合は、そのユーザに対応する行を選択し、 Modify User Properties ツールをクリックして、 Modify CTM User Properties ウィザードを起動します。 Login State フィールドが Enabled になっていることを確認します。ログイン状態が無効になっている場合は有効にし、プロビジョニング担当者またはオペレータとしてログインします。ログイン時にユーザが誤ったパスワードでログインしようとしたために、無効になっている可能性があります。

ステップ 5 パスワードが誤っている場合は、そのユーザに新しいパスワードを設定し、再度ログインします。


 

G.3.5 「Cannot Authenticate User」 というメッセージが表示される

CTM クライアントにログインしたときに「Cannot authenticate user」 というエラー メッセージが表示された場合は、CTM サーバが初期化中である可能性があります。CTM サーバの初期化が終了するまで 5 分間ほど待った後で再度ログインしてください。または、ユーザ名とパスワードをチェックしてから、もう一度入力してください。ユーザ名とパスワードでは、大文字と小文字が区別されます。

G.4 クライアントの動作に関する問題

ここでは、CTM クライアントの動作に関する問題に対するトラブルシューティング手順を説明します。

G.4.1 モデル インデックスが「Unknown」である

新しい NE を CTM ドメインに追加して In Service 状態に設定したにもかかわらず、モデル インデックスが不明である場合は、次の手順を実行します。


ステップ 1 IP アドレスおよびその他のパラメータが正しく入力されていることを確認します。

ステップ 2 CTM サーバは、その NE の GNE に接続できない可能性があります。その NE の GNE が In Service 状態に設定されていて、GNE が CTM ドメインに正しく実装されていることを確認します。

ステップ 3 GNE が NE に DCC で接続されていることを確認します。

ステップ 4 CTM サーバが NE のソフトウェア バージョンを認識していない可能性があります。
Domain Explorer ツリーで NE を選択し、 Fault > Test NE Connectivity の順にクリックします。NE が使用可能な場合は、弊社代理店に問い合わせ、NE のソフトウェア バージョンと使用中の CTM サーバの間に互換性があることを確認してください。 Supported NE Table を使用して、CTM サーバが認識できる NE のソフトウェア バージョンをインストールします。

ステップ 5 CTM サーバが間隔をおいて新しい NE と通信するように設定されている可能性があります。 次の手順を実行して、ヘルス ポールの頻度を変更します。

a. Domain Explorer ウィンドウで、 Administration > Control Panel の順にクリックし、 NE Service をクリックします。

b. NE Poller タブで、 NE Health Poll Interval フィールドを確認します。デフォルト値は、240 秒です。値が大きいと、CTM と NE の通信が遅れることがあります。通常、CTM サーバは、 Health Poll Interval フィールドで指定した秒数の 2 倍の時間が過ぎるまでに新しい NE と通信しようとします。


 

G.4.2 NE を削除できない

NE を削除できない場合は、ユーザがプロビジョニング担当者またはオペレータとしてではなく、スーパーユーザまたはネットワーク管理者としてログインしていることを確認します。プロビジョニング担当者とオペレータは NE を削除できません。ユーザがプロビジョニング担当者またはオペレータとしてログインしている場合は、CTM クライアント セッションを再起動し、スーパーユーザとしてログインします。

G.4.3 CTC の起動が失敗する

CTC ベースの NE で CTC を起動できない場合は、次の手順を実行します。


ステップ 1 NE Explorer を開くときに CTC progress screen login ダイアログ ボックスが表示されてもエラーが発生するようであれば、CTC のユーザ名またはパスワードが間違っている可能性があります。

a. Administration > CTM Users の順にクリックします。

b. CTM Users テーブルで、 Edit > Modify の順にクリックします。 Modify CTM User Properties ウィザードが表示されます。

c. Next をクリックして CTC/Craft User Properties パネルへ移り、CTC ユーザ名とパスワードをそのデバイスの設定に合わせます。 Finish をクリックします。

ステップ 2 CTC progress 画面の表示後、 login ダイアログボックスが表示されるまでに時間がかかる場合は、デバイスのネットワーク接続に問題がある可能性があります。

a. DOS のコマンド ウィンドウまたは Sun Solaris の端末からデバイスに対して ping を実行します。

b. 応答がない場合は、デバイスが使用できるようにルートを設定して、CTC を再起動します。CTC が起動しない場合は、ワークステーションのリソースに制約がある可能性があります。

c. 開いているアプリケーションを閉じて、もう一度試みます。

d. CTC ベースの NE が属する別のグループを管理している CTC インスタンスをいくつか閉じて、もう一度試みます。

ステップ 3 選択した NE の GNE が見つからなかった場合は、デバイスに指定した GNE と有効な GNE が一致していない可能性があります。この場合、データベースのデータが破損しています。弊社代理店にご連絡ください。


 

G.4.4 間違った NE への新しいソフトウェア バージョンの追加


ステップ 1 Domain Explorer ウィンドウで Administration > Supported NE Table の順にクリックします。

ステップ 2 Supported NE Table で、間違ったエントリを選択し、 Edit > Delete の順にクリックします。

ステップ 3 confirmation ダイアログボックスで OK ボタンをクリックします。

ステップ 4 Supported NE Table で、正しい NE の行を選択します。

ステップ 5 正しいソフトウェア バージョンを追加します。

ステップ 6 Domain Explorer ウィンドウの Network Element Properties ペインで、間違って動作している NE の運用状態をすべて Out of Service に設定します。

ステップ 7 Save をクリックします。

ステップ 8 Network Element Properties ペインで、NE の運用状態をすべて In Service に戻します。

ステップ 9 Save をクリックします。


 

G.4.5 サブネットワークを削除できない

Subnetwork Explorer でサブネットワークを削除できない場合は、次の手順を実行します。


ステップ 1 ユーザがプロビジョニング担当者またはオペレータとしてではなくスーパーユーザとしてログインしていることを確認します。プロビジョニング担当者とオペレータは、サブネットワークを削除できません。ユーザがプロビジョニング担当者またはオペレータとしてログインしている場合は、CTM クライアント セッションを再起動し、スーパーユーザとしてログインしてください。

ステップ 2 削除対象のサブネットワークに NE が含まれていないことを確認します。すべての NE を別のサブネットワークに移動した後で、空のサブネットワークを削除します。


 

G.4.6 サブネットワーク間で NE を移動できない

サブネットワークで NE の自動グルーピングが有効になっているときは、サブネットワーク間で NE を移動することができません。サブネットワーク間で NE を移動するには、次の手順を実行します。


ステップ 1 Domain Explorer ウィンドウで、 Administration > Control Panel の順にクリックします。

ステップ 2 Control Panel で、 UI Properties をクリックします。

ステップ 3 Subnetwork Grouping で、 Automatically group NEs in subnetworks チェックボックスのチェックを外します。

ステップ 4 Save をクリックします。


 

G.4.7 ジョブをスケジュールできない

CTM クライアントは、次の 3 種類の管理タスクをスケジュールすることができます。

ソフトウェアのダウンロード

メモリのバックアップ

メモリの復元

CTM では、潜在的な問題を追跡するためのエラー ログおよび監査ログを管理しています。エラー ログまたは監査ログを表示するには、次の操作を実行します。


ステップ 1 Domain Explorer ウィンドウで Administration > Audit Log または Error Log の順にクリックします。

ステップ 2 ソフトウェアのダウンロード、メモリのバックアップ、またはメモリの復元に関するエラーを検索します。


 

G.4.8 ONS 15800、ONS 15801、または ONS 15808 の NE でアラームが大量に発生する

ONS 15800、ONS 15801、および ONS 15808 の NE で、CTM クライアントが処理しきれないほど大量のアラームが発生することがあります。次の手順を実行してNE の運用状態を Under Maintenance に設定し、アラームが大量に発生する原因をデバッグします。


ステップ 1 CTM Domain Explorer ウィンドウで、アラームが大量に発生している ONS 15800、ONS 15801、または ONS 15808 を右クリックし、 Mark Under Maintenance をクリックします。

ステップ 2 ONS 15800、ONS 15801、または ONS 15808 の NE をデバッグして、エラーのあるカードを検索します。アラームが発生しているカードを見つけ、 Under Maintenance のマークを付けます。

ステップ 3 デバッグのためにエラー カードをメンテナンス状態にしたら、ONS 15800、ONS 15801、または ONS 15808 の NE を In Service に戻します。


 

G.4.9 帯域幅を多く必要とする操作がブロックされる

DCN のボトルネックは、ソフトウェアのダウンロードなど、帯域幅を多く必要とする操作に影響を与えることです。DCN のパフォーマンスに合わせて、タイムアウトと再試行回数の値を調整してください。NE にログインして、次のコマンドを入力します。

ip tftp min-timeout :読み書き要求を再試行するまでの最小待ち時間を秒単位で設定します。

ip tftp max-timeout :読み書き要求を再試行するまでの最大待ち時間を秒単位で設定します。

ip tftp backoff-delay :読み書き要求がタイムアウトした場合の延長ち時間を秒単位で設定します。

ip tftp write-retries :障害を宣言するまでに TFTP 読み書き要求を再試行する回数の最大値を設定します。

G.4.10 NE が不正な設定管理データを表示する


ステップ 1 Domain Explorer ウィンドウで Administration > Service Monitor の順にクリックし、NE サービスが動作しているかどうかを確認します。動作していない場合は、NE サービスを起動します。

ステップ 2 NE の接続をテストします。

a. Domain Explorer ツリーで NE を選択し、 Fault > Test NE Connectivity の順にクリックします。「< NE_name> ( <IP_address> ) is available」 というメッセージが表示されます。

b. NE が使用できない場合は、NE との接続を確立してから設定データを検索します。


 

G.4.11 Network Map がカスタマイズできない

Network Map の背景、またはノード アイコンを変更する際にイメージ ファイルが表示されない場合は、次の手順を実行します。


ステップ 1 他のイメージ ファイルを選択します。ファイルが破損している可能性があります。

ステップ 2 イメージ ファイルのサイズを確認します。サイズが 100 KB を超えるイメージ ファイルは、ロードできません。その場合は、100 KB 以下のイメージ ファイルを使用してください。

ステップ 3 イメージ ファイルが、\images\mapbkgnds\shapefiles ディレクトリまたは \images\mapicons ディレクトリに存在することを確認します。ファイルが存在しない場合は、削除されています。CTM クライアントを再インストールしてください。


) CTM クライアントは、主にシェイプ ファイル(*.shp)およびいくつかのマップ背景 GIF ファイルとともにバンドルされています。



 

G.4.12 Sun Ultra 5 ワークステーション上で CTM クライアントを実行しているときのカラーの設定方法

クライアントを Sun Ultra 5 ワークステーション上で実行する場合は、カラー マップを 8 ビットから 24 ビットに変更する必要があります。カラーが正しく表示されない場合は、次の手順を実行して、カラー マップを 8 ビット(デフォルト)から 24 ビットに変更します。


ステップ 1 現在のカラー設定を表示するために、次のコマンドを入力します。

/usr/sbin/m64config -prconf
 

コマンドの実行結果が次のように表示されます。

--- Hardware Configuration for /dev/fbs/m640 ---
ASIC: version 0x7c004750
DAC: version 0x0
PROM: version 104
Card possible resolutions: 720x400x88, 640x480x60, 640x480x72, 640x480x75, 800x600x56, 800x600x60, 800x600x72, 800x600x75, 1024x768x87, 1024x768x60, 1024x768x70, 1024x768x75, 1280x1024x75, 1280x1024x60, 1152x900x66, 1152x900x76, 1280x1024x67, 1280x800x76, 1280x1024x85
1280x1024x76, 1152x864x75, 1024x768x77, 1024x800x84, vga, svga, 1152, 1280, 800x600, 1024x768, 1280x1024, 1152x900
Monitor possible resolutions: 720x400x70, 720x400x88, 640x480x60, 640x480x67, 640x480x72, 640x480x75, 800x600x56, 800x600x60, 800x600x72, 800x600x75, 832x624x75, 1024x768x60, 1024x768x70, 1024x768x75, 1280x1024x75, 1152x870x75, 1152x900x66, 1152x900x76, 1280x1024x67, 1280x1024x76, vga, svga, 1152, 1280, 800x600, 1024x768, 1280x1024, 1152x900
Possible depths: 8, 24
Current resolution setting: 1280x1024x76
Current depth: 8
 

ステップ 2 カラーの設定を 24 ビットに変更するために、root ユーザとしてログインし、次のコマンドを実行します。

su
Password: <password>
/usr/sbin/m64config -depth 24 -res 1152x900x76
 

ステップ 3 新しいカラー設定を有効にするために、ワークステーションを再度ブートします。


) 24 ビット カラーの場合の表示解像度(1152 × 900 × 76) は、8 ビット カラーの場合の表示解像度(1280 × 1024 × 76)よりやや粗くなりますが、見た目にはほとんどかわりません。



 

G.4.13 スレッド ダンプの収集方法

スレッド ダンプは、CTM プロセスをデバッグするときに役に立つ参照データです。次の手順を実行して、スレッド ダンプを収集します。


ステップ 1 サーバのワークステーションに root ユーザとしてログインします。

ステップ 2 コマンドラインで次のコマンドを入力します。

thread_dumper [\<Group/Service>\]
 

ここで、

Group は、スレッド ダンプを収集するグループ名です。次のグループがあります。

SM

SNMPTRAP

NE

PM

GW

Service は、スレッド ダンプが必要なサービス名です。次のサービスがあります。

SMService

SNMPTrapService

CORBAGWService

ONS15200NEService

ONS15216NEService

ONS15302NEService

ONS15305NEService

ONS15310NEService

ONS15327NEService

ONS15454NEService

ONS15454SDHNEService

ONS15501NEService

ONS15530NEService

ONS15540NEService

ONS15600NEService

ONS15600SDHNEService

ONS15800NEService

ONS15801NEService

ONS15808NEService

UnmanagedNEService

ONS15216PMService

ONS15302PMService

ONS15305PMService

ONS15310PMService

ONS15327PMService

ONS15454PMService

ONS15454SDHPMService

ONS15501PMService

ONS15530PMService

ONS15540PMService

ONS15600PMService

ONS15600SDHPMService

ONS15800PMService

ONS15801PMService

ONS15808PMService


 

G.4.14 アラーム インターフェイス パネルの交換方法

Alarm Interface Panel (AIP; アラーム インターフェイス パネル)は、CTC ベースの NE を電気的なサージから保護します。このパネルには不揮発性のメモリ チップがあり、MAC アドレスと呼ばれる一意のノード アドレスが格納されています。MAC アドレスは、回線をサポートしているノードの識別に使われます。CTM では、MAC アドレスによって回線の発信元、送信先、およびスパンを判別します。

AIP が故障するとアラームが生成され、NE のファントレイ アセンブリにある LCD ディスプレイには何も表示されなくなります。AIP のイン サービス交換を行う場合は、弊社代理店にご連絡ください。

回線修復機能を使用すれば、トラフィックに影響を与えることなくイン サービス状態でシステムの AIP を交換できます。「回線の修復」を参照してください。

G.5 CTM GateWay/TL1 の問題

OSS から CTM GateWay/TL1 に接続できない場合、または OSS で応答が受信できない場合は、ケーブル、アドレス バインディング、および設定を調べます。


ステップ 1 接続がタイムアウトする場合は、ケーブルと接続状態を調べます。

ステップ 2 OSS と、CTM GateWay/TL1 サービスを実行する Solaris ワークステーションとの間でアドレス バインディングが正しいことを確認します。

ステップ 3 ping コマンドを使用して、OSS と、CTM GateWay/TL1 サービスを実行する Solaris ワークステーションとの間の接続を確認します。

ステップ 4 OSS ポートと CTM GateWay/TL1 ポートの間で TCP/IP のソケット接続が開いていることを確認します。

ステップ 5 Administration > Control Panel の順にクリックします。 GateWay/TL1 Service をクリックし、サービス ステータスがアクティブであることを確認します。

ステップ 6 Control Panel > Security Properties のユーザ名とパスワードが、CTM GateWay/TL1 が管理している NE のユーザ設定と一致していることを確認します。

ステップ 7 Domain Explorer > Network Element Properties > NE Authentication タブのユーザ名とパスワードが、CTM GateWay/TL1 が管理している NE のユーザ設定と一致していることを確認します。


 

G.6 CTM GateWay/CORBA の問題

CTM GateWay/CORBA オプションを最初の段階ではなく後から CTM サーバにインストールした場合は、 Control Panel が自動更新されないため、CTM GateWay/CORBA のインストールが表示されません。

この問題は、CTM GateWay/CORBA のインストール スクリプトで、CTM GateWay/CORBA がインストールされたことを CTM サーバではなく、データベースに通知するために起こります。

Control Panel Refresh Data ボタンをクリックして、この問題に対処します。CTM GateWay/CORBA がインストールされていることが Control Panel に表示されるまで少し時間がかかる場合があります。そのような場合は、 Control Panel をいったん閉じた後、再び開いて変更を確認する必要があります。

G.7 Cisco CRS-1 および Catalyst 6509 の問題

ここでは、Cisco CRS-1 および Catalyst 6509 関連の問題に対するトラブルシューティング手順を説明します。

G.7.1 デバイスを In Service にしても CRS-1 の通信状態が「Unavailable」のままである


ステップ 1 CRS-1 のユーザ名、パスワード、および特権がそれぞれ「hfrems」、「hfrems」、および「root-system」に設定されていることを確認します。特に何もしていなければ、CTM ではユーザ名とパスワードがともに「hfrems」であるものとして処理されます。ユーザ名とパスワードは、 Control Panel > Security Properties > CRS-1 タブで変更することができます。

ステップ 2 次のコマンドを入力して、XML CORBA エージェントのサービスが動作していることを確認します。

Router(config)# xml agent corba [ssl]
Router(config)# commit
 

) SSL は自由に選択できます。選択すると、SSL CORBA サービスが有効になります。


ステップ 3 SSL CORBA サービスが動作している場合は、次のコマンドを入力して、SSL で HTTPS が動作していることを確認します。

Router(config)# http server ssl
Router(config)# commit
 

ステップ 4 ルータ上の CORBA エージェントは、接続がホスト名で行われたときだけ接続を許可します。デバイスの IP アドレスが DNS 内のエントリにあることを確認します。ない場合は、/etc/hosts ファイルにエントリを追加します。

ステップ 5 ルータ上で動作しているソフトウェア イメージがCTM でサポートされていることを確認します。 Domain Explorer で、 Administration > Supported NE Table の順にクリックし、ソフトウェア バージョンがサポートされていることを確認します。

ステップ 6 CRS-1 を CTM に追加すると、NE から NE のタイプが検索され、その NE が CRS-1 であることが確認されます。デバイスから報告される NE タイプが CRS-1 でないと、CTM から NE に対して loss of communication (LOC; 通信の失敗)が報告され、NE タイプ不一致のアラームが発生します。

ステップ 7 DNS または CTM サーバの /etc/hosts ファイルに指定されている NE のホスト名が、NE に設定されているホスト名と一致していることを確認します。ホスト名が一致していないと、CTM から NE に対して通信の失敗が報告されます。


 

G.7.2 デバイスを In Service にしても Catalyst 6509 の通信状態が「Unavailable」のままである


ステップ 1 CTM で入力した IP アドレスが Catalyst 6509 に設定されていることを確認します。次のコマンドを入力して、IP アドレスを設定します。

cat6509 (enable)# set interface <logical_interface_name_like_sc0/sc1> <IP_address_of_the_Catalyst_6509> <mask>
 

ステップ 2 次のコマンドを入力して、デバイスがデフォルトのルートで正しく設定されていることを確認します。

cat6509 (enable)# set ip route default <gateway_IP_address>
 

ステップ 3 Catalyst 6509上で動作しているソフトウェア イメージがCTM でサポートされていることを確認します。 Domain Explorer Administration > Supported NE Table の順にクリックし、ソフトウェア バージョンがサポートされていることを確認します。


) Catalyst 6509 でサポートされているソフトウェア バージョンは、Release 6.3(7)以上です。


ステップ 4 Domain Explorer> Address タブに表示されているコミュニティ ストリングがデバイスのコミュニティ ストリングと同じであることを確認します。一致しない場合は、次のコマンドを入力して、デバイスの SNMP コミュニティ ストリングを変更します。

cat6509 (enable)# set snmp community read-only <community_string>
 

たとえば、次のとおりです。

cat6509 (enable)# set snmp community read-only public
 


 

G.7.3 CTM が CRS-1 から設定変更通知を受信しない


ステップ 1 次のコマンドを入力して、CTM サーバのホスト名および 「logging-events-level」が実行設定ファイル内に設定されていることを確認します。

Router# sh run | include domain ipv4 host
Router# sh run | include logging events level informational
 

ステップ 2 CTM サーバのホスト名および「logging-events-level」が実行設定ファイル内に設定されていない場合は、次のコマンドを入力します。

Router# conf t
Router(config)# domain ipv4 host <CTM_server_hostname> <IP_address>
Router(config)# logging events level informational
Router(config)# commit
 


 

G.7.4 CTM が Catalyst 6509 からトラップを受信しない


ステップ 1 次のコマンドを入力して、Catalyst 6509 のトラップ レシーバを CTM サーバに設定します。

cat6509 (enable)# set snmp trap <CTM_server_IP_address> <community_string>
 

ステップ 2 次のコマンドを入力して Catalyst 6509 を設定し、特定のトラップだけを有効にします。

cat6509 (enable)# set snmp trap enable <specific_trap>
 

ここで <specific_trap> には auth、bridge、chassis、config、entity、ippermit、module、stpx、syslog、systemp、vmps または vtp を指定します。

ステップ 3 次のコマンドを入力して Catalyst 6509 を設定し、すべてのトラップを有効にします。

cat6509 (enable)# set snmp trap enable all
 

set snmp trap enable all コマンドは、物理ポートでだけトラップを有効にします。sc0 や sc1 のような論理ポートでは、トラップを個別に有効にする必要があります。ステップ 4 に進みます。


ステップ 4 次のコマンドを入力して、論理ポートのトラップを有効にします。

cat6509 (enable)# set interface trap <logical_port_name> enable
 

たとえば、論理インターフェイス sc0 でトラップを有効にするには、次のコマンドを入力します。

cat6509 (enable)# set interface trap sc0 enable
 


 

G.7.5 CTM が Catalyst 6509 から syslog イベントを受信しない

Catalyst 6509 は、トラップの重大度が次の両方を満たしている場合にだけ、syslog トラップを送信します。

ファシリティの重大度と同じかそれより低い値( set logging level コマンドで設定)

ヒストリの重大度と同じかそれより低い値( set logging history severity コマンドで設定)

ヒストリの重大度は、デバッグ(7)に設定することをお勧めします。

show logging コマンドを実行すると、ヒストリの重大度とすべてのファシリティの重大度が両方とも表示されます。たとえば、次の出力では、ヒストリの重大度が 7 で、ファシリティの重大度が 5 になっています。重大度 X の syslog イベントは、 X の値がファシリティの重大度(5)と同じかそれより低くて、しかもヒストリの重大度(7)と同じかそれより低いときにはじめて、デバイスから出されます。

Cat6509 (enable)# show logging
 
Trace logging: disabled
Logging buffer size: 500
timestamp option: enabled
Logging history:
size: 1
severity: debugging(7)
Logging console: enabled
Logging telnet: enabled
Logging server: enabled
{10.77.56.151, 172.19.75.86}
server facility: SYSLOG
server severity: debugging(7)
Current Logging Session: enabled
Callhome Functionality: disabled
Callhome Severity: LOG_CRIT(2)
 
SMTP servers are not configured for callhome messages.
 
Destination addresses are not configured for callhome messages.
 
From Address is not configured for callhome messages.
Reply-To Address is not configured for callhome messages.
 
Facility Default Severity Current Session Severity
------------- ----------------------- ------------------------
acl 5 5
callhome 2 2
cdp 4 4
cops 3 3
...
...
sys 5 5
...
vmps 2 2
vtp 2 2
 
0(emergencies) 1(alerts) 2(critical)
3(errors) 4(warnings) 5(notifications)
6(information) 7(debugging)
 

G.7.6 CTM が CRS-1 の履歴 PM データを収集していない


ステップ 1 CRS-1 の PM 収集が有効になっていることを確認します。確認するには、 Network Element Properties > Status タブをクリックして PM Collection エリアで 15 Min チェックボックスにチェックを付け、 Save をクリックします。また、 Control Panel ウィンドウで、 CRS-1 PM Service Status Active になっていることを確認します。

ステップ 2 次のコマンドを入力して、CRS-1 の実行設定ファイルに PM が正しく設定されていることを確認します。

Router(config)# show run perf
 
performance-mgmt resources tftp-server <IP_address_of_server> directory <directory_on_TFTP_server>
performance-mgmt statistics bgp template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics mpls ldp template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics node cpu template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics interface generic-counters template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics interface data-rates template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics mpls TE-link template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics node memory template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics node process template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics mpls TE-tunnel template default
sample-size 1
sample-interval 15
!
performance-mgmt statistics mpls interface template default
sample-size 1
sample-interval 15
!
 

ステップ 3 ファイルが TFTP サーバのターゲット ディレクトリにダンプされていない場合は、TFTP サーバで正しい tftpd (tftp デーモンのバイナリ)が使用されていることを確認します。tftpd のバージョンは、CRS-1 が指定ディレクトリに新規ファイルを作成できるバージョンである必要があります。デフォルトの tftpd は、既存の TFTP への書き込みを許可するだけです。デフォルトの tftpd は、新規 TFTP ファイルを作成しません。

ステップ 4 ファイルが TFTP サーバに表示されるのにもかかわらず PM テーブルに表示されない場合は、PM TFTP ファイルのダンプ イベントが CTM サーバに通知されていることを確認します。確認するには、 Fault > Alarm Log を順にクリックして、次のように 15 分ごとに発生するイベントを確認します。

pm_collector[301]: %PM_COLLECTOR-6-TFTP_SEND : Successfully dumped file:tftp://<IP_address><TFTP_directory><NE_name>_node_process_1100886887.212000
 

ステップ 5 15 分たってもイベントが表示されない場合は、設定変更通知が有効になっていることを確認します。「CTM が CRS-1 から設定変更通知を受信しない」を参照してください。

ステップ 6 イベントが表示される場合は、TFTP サーバが CTM サーバから到達可能であることを確認します。確認するには、イベント通知に表示される IP アドレスに対して ping を実行します。IP アドレスが到達可能でない場合は、ルートを設定し、到達可能にします。あるいは、次のマッピングを含むマッピング ファイルを /opt/CiscoTransportManagerServer/cfg/hfr/IPAddressMapping.cfg ディレクトリに置きます。

<IP_address_in_event_notification> <reachable_IP_address_of_the_same_TFTP_server>
 

たとえば、次のとおりです。

172.19.64.51 223.255.254.254
 


 

G.7.7 CRS-1 の PM テーブルに間違った収集間隔でデータが収集される

PM データの収集間隔は 15 分に設定されていますが、 CRS-1 の PM テーブルには、より頻繁に(または、より少ない頻度で)データが収集されるという問題が発生することがあります。

CRS-1 は、ユーザが IOS-XR CLI に基づいて設定した間隔でデータを収集し、TFTP サーバのバイナリ ファイルへダンプします。PM データをダンプした後、CRS-1 は CTM にファイルの場所を通知します。次に、CTM は CRS-1 から PM データを収集します。そのため、CRS-1 が 15 分ごとにデータを収集するよう設定する必要があります。

G.7.8 CRS-1 でメモリのバックアップと復元が失敗する


ステップ 1 NE が In Service で、通信状態が Available であることを確認します。

ステップ 2 NE から CTM サーバを ping できることを確認します。NE は、設定ファイルをダウンロードするための TFTP クライアントとして使用します。

ステップ 3 /etc/inetd.conf ファイルを調べて、TFTP サーバが CTM サーバ上で有効になっていることを確認します。また、指定された tftpboot ディレクトリに正しいアクセス権があることを確認します。


 

G.7.9 ルータ上で設定を変更したときに CRS-1 の設定ファイルが自動的にバックアップされるようにする方法


ステップ 1 Domain Explorer ウィンドウで、 Administration > Control Panel の順にクリックします。

ステップ 2 NE Service をクリックします。

ステップ 3 NE AutoBackup タブを選択し、NE モデルとして Cisco CRS-1 を選択します。あるいは、 All NE Models を選択します。

ステップ 4 Enable Auto Backup チェックボックスにチェックを付けます。

ステップ 5 バックアップ コピーの数とバックアップの時間を指定します。

ステップ 6 Save をクリックします。


 

G.7.10 CTM が隣接 NE として CRS-1 を自動検出しない


ステップ 1 2 つの NE が物理的にリンクされていることを確認します。

ステップ 2 設定に応じて、次のオプションのいずれかを実行します。

イーサネット リンクの場合は、両方の NE でインターフェイスを立ち上げます。たとえば、次のコマンドを最初のルータに入力します。

Router-1(config)# int GigabitEthernet0/2/0/0
Router-1(config-if) ipv4 address <IP_address> <mask>
Router-1(config-if) no shutdown
Router-1(config-if) commit
 

次のコマンドを 2 番目のルータに入力します。

Router-2(config)# int GigabitEthernet0/1/0/0
Router-2(config-if) ipv4 address <IP_address> <mask>
Router-2(config-if) no shutdown
Router-2(config-if) commit
 

POS リンクの場合は、次のコマンドを最初のルータに入力します。

Router-1(config)# int POS 0/2/0/0
Router-1(config-if) ipv4 address <IP_address> <mask>
Router-1(config-if) no shutdown
Router-1(config-if) commit
 

次のコマンドを 2 番目のルータに入力します。

Router-2(config)# int POS 0/1/0/0
Router-2(config-if) ipv4 address <IP_address> <mask>
Router-2(config-if) no shutdown
Router-2(config-if) commit
 

SONET コントローラが動作していることを確認します。たとえば、次のコマンドを入力します。

Router-1(config)# controller SONET 0/2/0/0
Router-1(config-sonet)# no shutdown
Router-1(config-sonet)# commit
 
Router-2(config)# controller SONET 0/1/0/0
Router-2(config-sonet)# no shutdown
Router-2(config-sonet)# commit
 

ステップ 3 次のコマンドを入力し、両方の NE で CDP を有効にします。

Router-1(config)# cdp
Router-1(config)# commit
 
Router-2(config)# cdp
Router-2(config)# commit
 


 

G.7.11  Out of Service 状態の NE を CTM から削除できない

Out of Service 状態の NE を CTM から削除できない場合は、CTM サーバの <CTM_ROOT> /bin ディレクトリで次のコマンドを入力して、NE を強制的に削除します。

./prune_ne.sh <NE_name_as_shown_in_CTM>

G.7.12 ソフトウェア バージョンが Domain Explorer に表示されず、しかも NE Software Table テーブルが空である

Domain Explorer > Identification タブにソフトウェア バージョンが表示されず、しかも NE Software Table が空の場合は、次の手順を実行します。


ステップ 1 NE が In Service で、通信状態が Available であることを確認します。

ステップ 2 デバイスが Telnet SSH のどちらかに設定されていることを確認します。


 

G.7.13  CRS-1 NE Explorer から Configuration > Telnet/SSH を使用できない

CRS-1 NE Explorer から Configuration > Telnet/SSH を使用できない場合は、CTM クライアントから NE を ping します。CTM サーバとクライアントが異なったサブネットにあると、クライアントからではなく CTM サーバから NE に到達できる可能性があります。

G.7.14 CRS-1 で Telnet を設定する方法

CRS-1 に Telnet を設定するには、コンソールを介してルータにログインし、次のコマンドを入力します。

Router# conf t
Router(config)# telnet ipv4 server
Router(config)# commit

G.7.15 CRS-1 で SSH を設定する方法


ステップ 1 次のコマンドを入力して、PIE(k9)セキュリティがルータにインストールされてアクティブになっていることを確認します。PIE(k9)は、暗号化、復号化、IPSec、SSH、SSL、および PKI に必要です。

Router# sh install active
 

ステップ 2 次のコマンドを入力して、DSA キーがルータに表示されることを確認します。

Router# crypto key generate dsa
 

ステップ 3 次のコマンドを入力して、RSA キーがルータに表示されることを確認します。

Router# crypto key generate rsa
 

ステップ 4 次のコマンドを入力して、SSH がルータ上で有効になっていることを確認します。

Router# crypto key generate rsa
 

ステップ 5 次のコマンドを入力して、ルータ上の SSH サーバを有効にします。

Router(config)# ssh server enable
 


 

G.7.16 SSL の設定された CRS-1 NE で証明書を作成/付与する方法

「CRS-1 に Secure Socket Layer を設定する」を参照してください。

G.7.17 Catalyst 6509 から linkDown トラップまたは linkUp トラップのトリガーをかける方法

次のオプションのいずれかを実行します。

次のコマンドを入力して、Catalyst 6509 から linkDown トラップをトリガーします。

cat6509 (enable)# set port disable <module_number/port_number>
 

たとえば、次のとおりです。

cat6509 (enable)# set port disable 5/1
 

次のコマンドを入力して、Catalyst 6509 から linkUp トラップをトリガーします。

cat6509 (enable)# set port enable <module_number/port_number>
 

たとえば、次のとおりです。

cat6509 (enable)# set port enable 5/1

G.7.18 Catalyst 6509 で SNMP の設定を表示する方法

次のコマンドを入力して、Catalyst 6509 で SNMP の設定を表示します。

cat6509 (enable)# show snmp

G.7.19 Catalyst 6509 でソフトウェア イメージをロードする方法

次の手順を実行します。


ステップ 1 次のコマンドを入力して、Catalyst 6509 ですべてのソフトウェア イメージを表示します。

cat6509 (enable)# dir bootflash:
 

たとえば、次のような出力が表示されます。

-#- -length- -----date/time------ name
2 5849256 Aug 09 2004 14:41:25 cat6000-sup2.6-3-7.bin
3 8801412 Aug 09 2004 15:30:57 cat6000-sup2k8.8-3-2.bin
4 5713736 Aug 11 2004 13:08:02 cat6000-sup2.6-3-2a.bin
5 8182352 Aug 12 2004 09:15:00 cat6000-sup2k8.8-2-1.bin
17 1786 Aug 23 2004 14:16:30 6509svt-171-180
19 1688 Sep 24 2004 15:26:40 6509svt-171-180.cfg
 
3346628 bytes available (28634940 bytes used)
 

ステップ 2 次のコマンドを入力して、デバイス上に現在あるイメージを検索します。

cat6509 (enable)# whichboot
 

たとえば、次のような出力が表示されます。

Boot image name is 'bootflash:cat6000-sup2.6-3-7.bin'.
 

ステップ 3 次のコマンドを入力して、既存のイメージを削除します。

cat6509 (enable)# del <image_name>
 

ステップ 4 次のコマンドを入力して、削除したイメージを移動します。

cat6509 (enable)# squeeze bootflash:
 

ステップ 5 次のコマンドを入力して、フラッシュ メモリにイメージをコピーします。

cat6509 (enable)# copy tftp flash
IP address or name of remotehost[]? <TFTP_server_IP_address>
Name of file to copy from []? <Full_path_name_and_filename_of_the_image_location>
 

たとえば、次のとおりです。

tftpboot/cat6k/7-2/<image_name>
 

ステップ 6 次のコマンドを入力して、ダウンロードしたイメージがデバイス上に存在することを確認します。

cat6509 (enable)# dir bootflash:
 

ステップ 7 次のコマンドを入力して、ダウンロードが成功したことを確認します。

cat6509 (enable)# verify <image_name>
 

ステップ 8 次のコマンドを入力して、フラッシュ システムを消去します。

cat6509 (enable)# clear boot system flash bootflash:<previous_image_name>
 

ステップ 9 次のコマンドを入力して、起動システム フラッシュに新しいイメージ名を設定します。

cat6509 (enable)# set boot system flash bootflash:<new_image_name> prepend
 

ステップ 10 次のコマンドを入力して、デバイスをリセットします。

cat6509 (enable)# reset