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

目次

トラブルシューティング

トラブルシューティング

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

次の項目について説明します。

「概要」

「CTM のトラブルシューティング ツール」

「サーバの問題」

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

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

「クライアント デバッグ メッセージ」

「CTMGateWay/TL1 の問題」

「CTM GateWay/CORBA の問題」

「Cisco 7600 の問題」

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

「XR 12000 の問題」

「MGX 音声ゲートウェイ デバイスの問題」


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


K.1 概要

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

1. 問題の原因の特定 -- どのデバイスやリンク、インターフェイス、ホスト、またはアプリケーションに問題があるか。

2. ネットワーク上の問題の検出 -- どの VLAN(仮想 LAN)やサブネットワーク、セグメントで問題が起こっているか。

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

4. 問題の発生時期の調査 -- 最初に問題を見つけたのはいつか。繰り返し起こっているか。

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


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


K.2 CTM のトラブルシューティング ツール

次に示すツールを使用すると、ご使用のシステムのトラブルシューティングを行うことができます。

エラーおよび監査ログ -- CTM ドメインにネットワーク要素を新規に追加した場合に発生するほとんどの NE 通信問題は、エラー ログおよび監査ログを参照して診断できます。詳細については、「監査ログの表示」および「Error Log の表示」を参照してください。

EMS アラーム -- Dashboard を使用して Alarm Browser ウィンドウを起動し、EMS アラームのみを表示します。詳細については、「Dashboard」 を参照してください。

Self Monitor テーブル -- Self Monitor テーブルを起動して、サーバ リソースの履歴データを表示します。詳細については、「Self Monitor テーブルの使用」 を参照してください。

デバッグ オプション -- このツールは、エンジニアリングから推奨された場合以外は使用しないでください。詳細については、「デバッグ オプションの設定」 を参照してください。

Getinfo.sh スクリプト -- UNIX および CTM 設定情報を表示します。次に、getinfo.sh スクリプトの実行例を示します。

#cd /opt/Cis*r/bin
#./getinfo.sh
 

getinfo.sh スクリプトは logtext.tar.Z と techinfo.txt.Z の 2 つのファイルを生成します。これらのファイルは、/opt/CiscoTransportManagerServer ディレクトリに作成されます。

システム パラメータ情報 -- prstat および top などのコマンド出力には、パフォーマンス問題のトラブルシューティングに使用できるシステム パラメータ情報が含まれています。

CTM サーバ ログ ファイル -- サーバ エラー ログのリストについては、「Error Log の表示」 を参照してください。

CTM R4.0 以上では ctmop.log ファイルが作成され、サーバがユーザによって停止されたのか、あるいは異常シャットダウンしたのかを判別する場合に使用されます。サーバが異常シャットダウンした場合は、core_pmon.log ファイルを調べて、重要なサービスが停止しているかどうか確認します。CTM R4.0 以降で重要であると認識されているサービスは、Oracle、SMService、OSAgent、および GateWay/CORBA です。

CTM サーバ ログ ファイルは /opt/CiscoTransportManagerServer/log ディレクトリに格納されています。

パフォーマンス パラメータ -- CTM は重要なパフォーマンス パラメータを定期的にモニタし、定義済みのスレッシュホールド値を超過した場合は、EMS アラームを生成します。パフォーマンス パラメータの一覧については、「アラーム設定パラメータの設定と表示」 を参照してください。

UNIX コマンド

netstat -- すべてのソケット、すべてのルーティング テーブル エントリ、すべての物理/論理インターフェイスの状態を表示します。

snoop -- ネットワーク パケットをキャプチャして、検査します。

/usr/platform/sun4u/sbin/prtdiag -- CPU 数や RAM 数などのシステム診断情報を表示します。

vmstat -- 重要なメモリ統計情報を報告します。

K.3 サーバの問題

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


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


K.3.1 CTM サーバのパフォーマンスに影響する条件

Cisco Transport Manager Installation Guide 』の「System Requirements」の章には、各タイプの CTM に関するサーバ、CPU、CPU 速度、ディスク スペース、および RAM の要件が記載されています。これらの要件は、スケーラビリティ シミュレーション テストに基づくガイドラインから抜粋されたものです。

実際の CTM サーバのパフォーマンスはお客様ごとに異なり、以下の影響を受けます。

CTM によってアクティブに管理された NE の総数

サーバで稼働している NE 関連サービスの数(ノースバウンド サービスなど)

回路のプロビジョニング レートやプロビジョニングに使用する方法

ネットワークの成長率(CTM に一度に 50 の NE を追加するなど)

NE から受信した設定変更の更新レート

スレッシュホールド超過アラート(TCA)を生成する信号を使用しないでプロビジョニングされた回路数

CTM データベース内で認識されていないアラーム数

NE から受信したアラーム バースト レート

CTM データベース内でプロビジョニングされた実際の回路数

次の場合は、ご使用の CTM が性能の限界に達しているか、限界付近で動作しています。

1 日の CPU 利用率が常に 80% を超えている

ノードの Loss Of Connectivity(LOC)がランダムで 1 ~ 5% になる

RAM の使用率が 100% であるか、システムが頻繁にスワップする

NE から多数の設定アップデートが受信される

Java ガベージ コレクションが長期化する


) Java ガベージ コレクション期間は、エンジニアが CPU 利用データを分析したあとに判別されます。


上記の状態が発生した場合は、製品を購入された代理店へお問い合わせください。代理店はシスコの Advanced Services チームを派遣して CTM サーバを監査し、大容量のサーバやリソースを提案できます。

K.3.2 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 ファイルの最初に CTM6_0:/oraclesw9i/product/9.2:Y に類似したエントリがあることを確認します。このエントリがない場合は、Oracle データベースがインストールされていない可能性があります。CTM サーバをインストールするには、Oracle データベースが必要です。


 

K.3.3 CTM サーバに接続できない


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

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

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

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

showctm
 

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

sudo showctm
 

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

root 520 12.0 0.02855219536 Dec_19 14:18 CTM Server
root 489 0.0 0.117384 Dec_19 0:00 CTM Server
root 749 0.6 5.7255104112848 Dec_19 346:27 SnmpTrapService
root 541 0.1 5.8284232115256 Dec_19 15:02 SMService
root 507 0.0 0.2 5512 3496 ? Dec 19 Apache Web Server
 

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

ctms-stop
 

ステップ 7 以前にサーバの IP アドレスを変更した場合は、表4-15 に示したコンフィギュレーション ファイルがアップデートされていることを確認します。「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 分後に、クライアントを実行します。


 

K.3.4 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 追加のための要件」 を参照してください。


 

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

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 社のサポートに連絡してください。


 

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

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

K.3.7 トラップ ポートが使用できない

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


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

netstat -a | grep 162
 

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

*.162 Idle
 

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


 

K.3.8 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 コマンドに対して設定変更トラップがレポートされます。


 

K.3.9 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 )にエントリが作成されます。


 

K.3.10 CRS-1 および XR 12000 の通信問題


ステップ 1 NE に root-system 権限および次のログイン情報が設定されているかどうかを調べます。

ユーザ名:hfrems

パスワード:hfrems

ステップ 2 XML CORBA エージェント サービスが稼働していることを確認します。

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

ステップ 4 Supported NE Table を調べて、ルータで稼働中のソフトウェア イメージのバージョンが CTM でサポートされているかどうかを判別します。


) CTM に NE を追加すると、NE タイプが取得されて、CRS-1 と XR 12000 NE のいずれであるかが判別されます。追加した NE が CRS-1 または XR 12000 でない場合、NE は 通信喪失状態になり、NE タイプ不一致アラームが生成されます。



) DNS または CTM サーバの /etc/hosts ファイルに指定されている NE のホスト名は、NE に設定されているホスト名と一致する必要があります。一致しない場合は、NE が通信喪失状態になります。



 

K.3.11 CTC ベースの NE が検出できない


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

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

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

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

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


 

K.3.12 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 に存在することを確認します。


 

K.3.13 ONS 1530x の通信問題


ステップ 1 同じ名前の ONS 1530x NE が他にないことを確認します。

ステップ 2 サーバから NE に IP で接続できることをテストします。

ステップ 3 CTM サーバから NE に Telnet 接続します。パスワードの入力を求められた場合は、NE が動作しています。

ステップ 4 Cisco Edge Craft を使用して NE に接続し、SNMP がイネーブルであることを確認します。


) NE にログインできるのは、SNMP Community テーブルに記載されたサーバから接続しているユーザのみです。


ステップ 5 接続対象の NE で、CTM がサポートするソフトウェア バージョンが稼働していることを確認します。

ステップ 6 製品名が次のいずれかであることを確認します。

ONS 15302

ONS 15305

AXXEDGE

製品名が認識された名前と一致しない場合は、change-system-name コマンドを入力します。


 

K.3.14 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 によって報告されるエラーのログを確認します。


 

K.3.15 ONS 1580x NE が検出されない

新規に追加された ONS 1580x NE を CTM が検出できない場合は、次の手順を実行します。


ステップ 1 同じ名前の ONS 1580x NE が他にないことを確認します。

ステップ 2 ローカル クラフト ツールを使用して NE を接続し、現在の動作レベルを指定します。CTM と NE との接続を可能にするには、動作レベルを 6 にする必要があります。動作レベルが 3 の場合は、ローカル クラフト ツールによる接続のみが可能です。

ステップ 3 次の手順を実行して、TL1 ソケット(ポート 1000)で使用可能なすべての接続を調べます。


) TL1 エージェントは最大 5 つの同時接続をサポートします。CTM は TL1 接続を NE サービスに 1 つ、PM サービスに 1 つ、GateWay/TL1 に 1 つ(GateWay/TL1 がイネーブルな場合)を使用します。


a. Telnet 接続を開きます。

b. pSOS プロンプトで、netstat コマンドを入力します。

ステップ 4 シェルフ内のボード名およびスロット位置が TL1 Agent の報告内容と一致することを確認します。


 

K.3.16 UNIX CLI からの NE 動作状態の変更

この手順は、NE 接続問題、アラーム同期化、または設定同期化の問題のトラブルシューティングに役立ちます。CTM クライアント GUI(グラフィカル ユーザ インターフェイス)にアクセスする必要はありません。


ステップ 1 vwdata.sh スクリプトを使用して、NE データベース ID 番号を識別します。

ステップ 2 UNIX CLI(コマンドライン インターフェイス)ツールを実行して、サーバに接続します。ツール名は ctm、格納場所は /opt/CiscoTransportManagerServer/bin ディレクトリ内です。

ステップ 3 コマンド set nestate を使用して、NE 動作状態を変更します。


 

K.3.17 回線が表示されない

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


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

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

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

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


 

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

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

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

K.3.19 NE モデル タイプが Unknown と表示される

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

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

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

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

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


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

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

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


 

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


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

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

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


 

K.3.23 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 で報告されています。

この問題を解決するには、/.rhosts ファイルにホスト名を追加します。たとえば、次のようになります。

(omu-e450) #more /.rhosts
omu-e450 +
(omu-e450) #

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

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

K.4.1 データベースが使用できない

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


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

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

sqlplus ctmanager/ctm123!
 

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


 

K.4.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 を実行して、応答時間を確認します。応答が返ってくるまでの往復に時間がかかるようであれば、帯域幅を増やします。


 

K.4.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 クライアントにログインします。


 

K.4.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 パスワードが誤っている場合は、そのユーザに新しいパスワードを設定し、再度ログインします。


 

K.4.5 Cannot Authenticate User というメッセージが表示される

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

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

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

K.5.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 と通信しようとします。


 

K.5.2 NE を削除できない

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

K.5.3 CTC の起動が失敗する

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


ステップ 1 NE Explorer を開くときに、CTC 進行画面と 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 進行画面の表示後、login ダイアログボックスが表示されるまでに時間がかかる場合は、デバイスのネットワーク接続に問題がある可能性があります。

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

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

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

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

ステップ 3 選択した NE の GNE が見つからなかった場合は、デバイスに指定した GNE と有効な GNE が一致していない可能性があります。この場合、データベースのデータが破損しています。シスコ テクニカル サポートに連絡の上、サポートを受けてください。


 

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


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

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

ステップ 3 確認用ダイアログボックスで 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 をクリックします。


 

K.5.5 CRS-1 および XR 12000 NE Explorer アプリケーションがディセーブルである

CTM とルータで XML バージョンが異なる場合は、CRS-1 および XR 12000 NE Explorer アプリケーションがディセーブルです。


ステップ 1 CTM_HOME/cfg/metadata ディレクトリから XML ファイルを収集します。

ステップ 2 CTM_HOME/bin/vwdata.sh スクリプトを実行して、hfr_version_info データベース テーブルのエントリを収集します。

ステップ 3 いずれかのアプリケーションがエラーをスローした場合は、設定に応じて次のいずれかを実行します。

Windows の場合:

CTM_HOME/bin/ctm-small-debug.exe

CTM_HOME/bin/ctm-medium-debug.exe

CTM_HOME/bin/ctm-large-debug.exe

CTM_HOME/bin/ctm-highend-debug.exe

UNIX の場合は、CTM_HOME/bin/ctmcdebug-start を実行してから、以下を実行します。

CTM_HOME/bin/ctm-small-debug.exe

CTM_HOME/bin/ctm-medium-debug.exe

CTM_HOME/bin/ctm-large-debug.exe

CTM_HOME/bin/ctm-highend-debug.exe

ステップ 4 コンソール ログおよび端末メッセージを収集します。


 

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

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


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

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


 

K.5.7 サブネットワーク間で 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 をクリックします。


 

K.5.8 NE がサブネットワークを短時間に変更する

サブネットワークに属する NE は、サブネットワークと接続する特定のリンクまたはすべてのリンクが短時間に変更されると、サブネットワークを短時間に変更することがあります。このようになるのは、サブネットワークの自動グルーピング オプションが CTM でイネーブルになっている場合です。サブネットワークの自動グルーピングをディセーブルにすると、リンクを起動および停止しても、NE はサブネットワークを変更しません。サブネットワークの自動グルーピングをディセーブルにする手順は、次のとおりです。


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

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

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

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


 

K.5.9 ジョブをスケジュールできない

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

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

メモリのバックアップ

メモリの復元

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


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

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


 

K.5.10 CTM が ONS 1530x NE から自律アラームを受信できない

CTM は ONS 1530x NE からアラームを収集したり、自律的な通知を受信できます。アラーム収集は NE を最初に検出したときに実行され、NE から着信した自発的イベントには依存しません。


ステップ 1 CTM サーバが SNMP Community テーブルに格納されていて、トラップがイネーブルに設定されていることを確認します。このようになっていない場合は、NE に接続できますが、CTM はトラップを受信しません。

ステップ 2 CTM サーバおよび NE がそれぞれ異なるサブネットワークに属している場合は、サブネットワーク間のファイアウォールで SNMP パケットがフィルタリングされていないことを確認します。

ステップ 3 Cisco Edge Craft が自律アラームを取得していることを確認します。

ステップ 4 以下を確認します。

SNMP トラップが CTM サーバ マシンに到達している。

コマンド snoop udp およびポート 162 で、着信トラップが表示されない。

ネットワークに問題がない。

ステップ 5 CTM サーバ アプリケーションがトラップを受信していることを確認します。

ステップ 6 ONS 1530x NE サービスが SNMP トラップを受信していることを確認します。


 

K.5.11 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 に戻します。


 

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

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

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

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

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

ip tftp write-retries -- 障害を宣言するまでに TFTP(簡易ファイル転送プロトコル)読み書き要求を再試行する回数の最大値を設定します。

K.5.13 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 との接続を確立してから設定データを検索します。


 

K.5.14 Network Map がカスタマイズできない

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


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

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

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


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



 

K.5.15 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)よりやや粗くなりますが、見た目にはほとんどかわりません。



 

K.5.16 CTM クライアント マシンの表示カラーが正しくない

CTM クライアント ホストとして UNIX マシンを使用している場合は、マシンの表示カラーが正しくないことがあります。この問題は、UNIX システムに 256 色パレットが使用されているにもかかわらず、256 色の色分け方式で使用できないカラーがグラフィックで要求されている場合に発生します。一部の UNIX システムでは使用できないカラーがあっても対処できますが、調整時に問題が発生することがあります。このようなシステムで問題を解決するには、稼働しているその他のグラフィカル アプリケーション(Netscape など)をディセーブルにしたり、システムのグラフィック機能を 24 ビット色表示にアップグレードする(たとえば、ビデオ カードやモニタをアップグレードする)必要があります。

K.5.17 一般的なトポロジー問題


) NE を Out of Service 状態に設定し、これらの NE を経由する(その他の NE に関係しない)回路が CTM Circuit テーブルから削除されるまで待機してから、NE を再び In Service 状態に設定します。


K.5.17.1 作成されたトポロジーが Incomplete 状態になる

トポロジーに関連するレイヤ 1 回路が見つからない場合は、トポロジーが Incomplete 状態になります。


ステップ 1 Circuit テーブルを起動して、トポロジーに関連するすべての回路が適切に検出されているか確認します。

ステップ 2 レイヤ 1 回路が見つからない場合は、Circuit Creation ウィザードを使用して目的の回路を再作成します。レイヤ 1 回路が作成され、CTM が新しい回路を検出すると、トポロジーは Complete 状態になります。

ステップ 3 Circuit テーブルを調べて、新規に作成されたレイヤ 1 回路が適切に検出されていることを確認します。

ステップ 4 それでもトポロジーが Complete 状態にならない場合は、トポロジー検出ロジックに障害があります。次の手順を実行して、検出プロセスを再起動します。

a. 目的の NE に関連する NE サービスをいったん Out of Service として設定してから、In Service に戻します。

b. トポロジーに関連する NE をいったん Out of Service として設定してから、In Service に戻します。

ステップ 5 それでも問題が解決しない場合は、Technical Assistance Center(TAC)に連絡してください。


 

K.5.17.2 作成されたトポロジーが L2ServiceNotReady 状態になる

CTM データベース内のデータと、ML シリーズ カード内のデータが一致しない場合は、トポロジーが L2ServiceNotReady 状態になります。


ステップ 1 Circuit テーブルを起動して、トポロジーに関連するすべての回路が適切に検出されているか確認します。

ステップ 2 Equipment Inventory テーブルを起動して、NE インベントリが収集されているかどうかを確認します。

ステップ 3 次のいずれかを入力します。

L2 Topology テーブルを起動して、L2 サービスをイネーブルにします。CTM データベースおよび ML シリーズのカードが同期します。トポロジーは同期プロセス中に InProgress 状態になり、その後 Complete 状態になります。

NE Explorer を起動してトポロジー内の NE を表示し、NE のリフレッシュを実行して、データベースを強制的に同期させます。同期プロセスが再起動します。NE が起動すると、トポロジーは Complete 状態になります。

ステップ 4 それでもトポロジーが Complete 状態にならない場合は、次のいずれかの手順を実行します。

a. カードに Telnet 接続して、設定が破損していないか確認します。

b. 目的の NE に関連する NE サービスをいったん Out of Service として設定してから、In Service に戻します。

c. トポロジーに関連する NE をいったん Out of Service として設定してから、In Service に戻します。

d. トポロジーを削除し、ML シリーズ カードのコンフィギュレーション ファイルをリロードして、カードをリセットします。ベアボーン コンフィギュレーション ファイルをリロードするには、 write memory コマンドを実行します。

ステップ 5 それでも問題が解決しない場合は、TAC に連絡してください。


 

K.5.17.3 作成されたトポロジーが SyncFailed 状態になる

次のいずれかの条件に該当する場合は、トポロジーが SyncFailed 状態になることがあります。

事前にプロビジョニングされたカードを使用して、トポロジーを作成した。カードが事前にプロビジョニングされているかどうかは、2 つの方法で判別できます。

NE Explorer を起動して、カードが存在することを確認する。

カードに Telnet 接続して、カードが存在することを確認する。

ベアボーン コンフィギュレーション ファイルが存在しないカードがある。

正しい CTM/ML シリーズ カードのログインの詳細が指定されていない。

データベースおよび ML シリーズ カードが同期していない。


ステップ 1 Circuit テーブルを起動して、トポロジーに関連するすべての回路が適切に検出されているか確認します。

ステップ 2 Equipment Inventory テーブルを起動して、NE インベントリが収集されているかどうかを確認します。

ステップ 3 次の同期サイクルまで待機します。データベースが同期され、トポロジーが InProgress 状態になります。トポロジーが L2ServiceNotReady 状態になる場合は、「作成されたトポロジーが L2ServiceNotReady 状態になる」 を参照してください。

ステップ 4 それでもトポロジーが Complete 状態にならない場合は、次のいずれかの手順を実行します。

a. カードに Telnet 接続して、設定が破損していないか確認します。

b. 目的の NE に関連する NE サービスをいったん Out of Service として設定してから、In Service に戻します。

c. トポロジーに関連する NE をいったん Out of Service として設定してから、In Service に戻します。

d. トポロジーを削除し、ML シリーズ カードのコンフィギュレーション ファイルをリロードして、カードをリセットします。ベアボーン コンフィギュレーション ファイルをリロードするには、 write memory コマンドを実行します。

ステップ 5 それでも問題が解決しない場合は、TAC に連絡してください。


 

K.5.17.4 作成されたトポロジーが Partially Complete 状態になる

CTM データベースと同期していないカードがある場合は、トポロジーが Partially Complete 状態になります。


ステップ 1 Circuit テーブルを起動して、トポロジーに関連するすべての回路が適切に検出されているか確認します。

ステップ 2 Equipment Inventory テーブルを起動して、NE インベントリが収集されているかどうかを確認します。

ステップ 3 次の同期サイクルまで待機します。データベースが同期され、トポロジーが Complete 状態になります。トポロジーが L2ServiceNotReady 状態になる場合は、「作成されたトポロジーが L2ServiceNotReady 状態になる」 を参照してください。

ステップ 4 それでもトポロジーが Complete 状態にならない場合は、次のいずれかの手順を実行します。

a. カードに Telnet 接続して、設定が破損していないか確認します。

b. 目的の NE に関連する NE サービスをいったん Out of Service として設定してから、In Service に戻します。

c. トポロジーに関連する NE をいったん Out of Service として設定してから、In Service に戻します。

d. 関連する NE の NE Explorer を起動し、Refresh ボタンをクリックして、強制的に再同期させます。

e. トポロジーを削除し、カードのコンフィギュレーション ファイルをリロードして、カードをリセットします。ベアボーン コンフィギュレーション ファイルをリロードするには、 write memory コマンドを実行します。

f. IOS Users テーブルにリング内にあるすべてのカードのエントリがすべて格納されていることを確認します。

ステップ 5 それでも問題が解決しない場合は、TAC に連絡してください。


 

K.5.17.5 CTM が作成されたトポロジーを検出できない


ステップ 1 次の作業を実行して、検出プロセスを再起動します。

a. Circuit テーブルを起動して、トポロジーに関連するすべての回路が適切に検出されているか確認します。

b. 目的の NE に関連する NE サービスをいったん Out of Service として設定してから、In Service に戻します。

c. トポロジーに関連する NE をいったん Out of Service として設定してから、In Service に戻します。

ステップ 2 それでもトポロジーが検出されない場合は、次の手順を実行して、DataService ログで目的のトレース レベルをイネーブルにします。

a. Domain Explorer ウィンドウで Administration>Control Panel の順に選択します。

b. Control Panel ウィンドウで、NE Service をクリックし、NE Service ペインを開きます。

c. NE Manual Backup タブをクリックします。

d. エラー レベルとして Trace を選択します。

e. Save をクリックします。

ステップ 3 CTM サーバからローカルホストに Telnet 接続します。これにより、サーバでのデータ ログ収集が開始します。DataService ログに入力されていることを確認します。

ステップ 4 DataService ログを調べて、回路追加イベントが適切に受信されているかどうかを判別します。そのためには、ストリング CIRCUIT_ADDED を検索します。回路追加イベントが適切に受信されない場合は、レイヤ 1 回路のプロビジョニングに問題があります。適切に受信されている場合は、回路削除ロジックに問題があり、バグを記録する必要があります。


 

K.5.17.6 CTM が作成されたトポロジーを削除できない


ステップ 1 L2 Topology テーブルを起動して、トポロジーが Deleting 状態であることを確認します。トポロジーが Deleting 状態でない場合は、CTM のトポロジー削除ロジックに問題があります。

ステップ 2 関連するレイヤ 1 回路の状態を調べます。これらの回路も Deleting 状態になっている必要があります。これらの回路が Deleting 状態であるにもかかわらず、最終的に削除されない場合は、レイヤ 1 回路のプロビジョニングに関連する問題があります。

ステップ 3 削除されていない回路が存在し、これらの回路が Deleting 状態でない場合は、CTC を使用して回路を削除します。

ステップ 4 これらの回路を削除しても、トポロジーが削除されない場合は、次の手順を実行してデータ サービスのトレース ログをイネーブルにし、回路削除イベントが適切に受信されているか確認します。

a. Domain Explorer ウィンドウで Administration>Control Panel の順に選択します。

b. Control Panel ウィンドウで、NE Service をクリックし、NE Service ペインを開きます。

c. NE Manual Backup タブをクリックします。

d. エラー レベルとして Trace を選択します。

e. Save をクリックします。

f. CTM サーバからローカルホストに Telnet 接続します。これにより、サーバでのデータ ログ収集が開始します。回路削除イベントが適切に受信されているか確認します。回路削除イベントが適切に受信されない場合は、レイヤ 1 回路のプロビジョニングに問題があります。回路削除イベントが適切に受信されている場合は、CTM のトポロジー削除ロジックに問題があります。L2 Topology テーブルからトポロジーを明示的に削除します。

ステップ 5 それでも問題が解決しない場合は、TAC に連絡してください。


 

K.5.18 VLAN に共通の問題

K.5.18.1 VLAN が検出されない

このエラーは、VLAN 検出プロセスに失敗すると発生します。次の手順を実行します。


ステップ 1 カードに Telnet 接続し、VLAN 設定パラメータ セットがデータベースと一致しないこと、または設定が破損していないかを確認します。

ステップ 2 目的の NE に関連する NE サービスをいったん Out of Service として設定してから、In Service に戻します。

ステップ 3 トポロジーに関連する NE をいったん Out of Service として設定してから、In Service に戻します。

ステップ 4 関連する NE の NE Explorer を起動し、Refresh ボタンをクリックして、強制的に再同期させます。

ステップ 5 それでも問題が解決しない場合は、TAC に連絡してください。


 

K.5.18.2 VLAN が作成または削除されない

問題の原因に応じて、次の手順を実行します。

CTM サーバが再同期している場合は、数秒間待機してから、VLAN を再び作成または削除します。

ブリッジ グループを作成できないことを示すエラー メッセージが表示される場合は、CLI に無効な AV ペア コマンドを入力した可能性があります。IosTransportModule.log で無効なコマンドを検索します。また、サーバ ログで例外も検索します。

K.5.19 CRS-1 および XR 12000 の PM 収集に関する問題

CRS-1 および XR 12000 NE は IOS-XR CLI のユーザが設定したインターバルでデータを収集して、TFTP サーバのバイナリ ファイルにダンプします。パフォーマンス データをダンプしたあと、CRS-1 または XR 12000 NE はファイルの場所を示す通知を送信します。この通知は 15 分おきに Alarm Log に記録されます。通知を受信した CTM は、CRS-1 または XR 12000 NE からパフォーマンス データを収集します。データを 15 分おきに収集するように CRS-1 および XR 12000 NE を設定する必要があります。

CRS-1 または XR 12000 の PM 収集に関する問題が発生した場合は、次の手順を実行します。


ステップ 1 実行コンフィギュレーションに TFTP サーバおよびディレクトリが設定されていることを確認します。

ステップ 2 ルータの実行コンフィギュレーションに PM が適切に設定されているかどうかを調べます。

ステップ 3 Alarm Log で、CRS-1 から送信された通知を調べます。


 

K.5.20 PM データ収集に失敗する

PM データ収集に失敗した場合は、ブラウザを使用して、NE から直接 PM データを収集します。次のいずれかを入力します。

現在の PM データ:

収集期間を 15 分に設定する場合は、http://<NE IP address>/pm/15min/1 を使用します。

収集期間を 1 日に設定する場合は、http://<NE IP address>/pm/day/1 を使用します。

過去の PM データ:

収集期間を 15 分に設定する場合は、http://<NE IP address>/pm/15min/bucket# を使用します。

収集期間を 1 日に設定する場合は、http://<NE IP address>/pm/day/bucket# を使用します。

ここで、bucket# =(現在時刻 - 消失した過去の時刻)/ 900000 + 1 です。

K.5.21 Solaris クライアントのスレッド ダンプの収集方法


ステップ 1 端末セッションを開きます。

ステップ 2 ctmc.sh スクリプトを使用して、クライアントを実行します。ctmc.sh スクリプトは /opt/CiscoTransportManagerClient ディレクトリ内にあります。

ステップ 3 次のコマンドを入力して、Java プロセス ID を取得します。

ps -aef|grep java
 

ステップ 4 次のコマンドを入力します。

kill -QUIT <pid>
 

PID はクライアント Java プロセス ID です。


 

K.5.22 Windows クライアントのスレッド ダンプの収集方法

CTM R5.0.2 以前の場合にスレッド ダンプを収集する手順は、次のとおりです。


ステップ 1 DOS ウィンドウを開きます。

ステップ 2 C:\Cisco\TransportManagerClient ディレクトリにある ctmc.bat ファイルを実行します。

ステップ 3 Ctrl キーを押したまま Break Pause )キーを押して、スレッド ダンプを生成します。

ステップ 4 出力をテキスト ファイルにコピー アンド ペーストします。


 

CTM R6.0.2 以上の場合にスレッド ダンプを収集する手順は、次のとおりです。


ステップ 1 DOS ウィンドウを開きます。

ステップ 2 ネットワーク サイズに応じて、次のいずれかのコマンドを入力します。

ctm-small-debug.exe

ctm-medium-debug.exe

ctm-large-debug.exe

ctm-highend-debug.exe

ステップ 3 Ctrl キーを押したまま Break Pause )キーを押して、スレッド ダンプを生成します。

ステップ 4 出力をテキスト ファイルにコピー アンド ペーストします。


 

K.5.23 サーバ スレッド ダンプの収集方法

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


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

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

thread_dumper [\<Group/Service>\]
 

ここで、

Group は、スレッド ダンプを収集するグループ名です。内容は次のとおりです。

SM

SNMPTRAP

NE

PM

GW

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

SMService

SNMPTrapService

CORBAGWService

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


 

K.5.24 自動 Refresh Data アクションをイネーブルまたはディセーブルにする方法

自動 Refresh Data 機能は、CTM で表示中のすべてのデータを自動的にリフレッシュします。自動リフレッシュがイネーブルな場合は、次のプロンプトが表示されます。

Refresh Data action suggested. This action will result in closing all windows and might take some time. Do you want to continue? {Yes | No}
 

NE が同期をとる、または NE が運用状態を頻繁に変更するような不安定な環境では、前述のプロンプトを継続的に受信する可能性があります。このプロンプトをディセーブルにする手順は、次のとおりです。


ステップ 1 Domain Explorer ウィンドウで Edit > User Preferences の順に選択します。User Preferences ダイアログボックスが表示されます。

ステップ 2 Miscellaneous タブをクリックします。

ステップ 3 プロンプトを無効にするには、 Enable Refresh Data Timer チェックボックスをオフにします。(プロンプトをイネーブルにするには、このチェックボックスをオンにしたままにします)。

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


 

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

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

AIP が故障するとアラームが生成され、NE のファントレイ アセンブリにある LCD ディスプレイには何も表示されなくなります。AIP のイン サービス交換を行う場合は、シスコ テクニカル サポートにお問い合わせください。連絡先については、テクニカル サポート Web サイト http://www.cisco.com/tac をご覧ください。弊社代理店にご連絡ください。

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

K.6 クライアント デバッグ メッセージ

Windows では、CTM クライアントの起動時にコンソール ウィンドウを開いて、例外およびクライアント デバッグ メッセージを表示できます。クライアント問題のトラブルシューティングを実行する場合に、これらのメッセージを使用できます。


ステップ 1 ネットワーク サイズに応じて、次のいずれかのコマンドを入力し、コンソール ウィンドウを開いた状態でクライアントを起動します。

/bin/ctm-small-debug.exe
/bin/ctm-medium-debug.exe
/bin/ctm-large-debug.exe
/bin/ctm-highend-debug.exe
 

ステップ 2 CTM クライアントを終了すると、コンソール ウィンドウが閉じます。クライアントを終了するときにメッセージを取り込んで保存する場合は、出力をファイルにリダイレクトする必要があります。この場合、コンソールには表示されません。例外をファイルに保存するには、ネットワーク サイズに応じて、次のいずれかのファイルを開きます。

/bin/ctm-small-debug.lax

/bin/ctm-medium-debug.lax

/bin/ctm-large-debug.lax

/bin/ctm-highend-debug.lax


) .lax ファイルを修正する前に、元のファイルのコピーを保存しておくことを強く推奨します。


ステップ 3 テキスト エディタを使用して該当する .lax ファイルを開き、次に示す行の「console」をファイル名で置き換えて変更します。

lax.stderr.redirect=console
lax.stdout.redirect=console
 

ファイル名を指定する場合は、エスケープされたバックスラッシュを使用してください(c:\\myfolder\\client.log など)。たとえば、メッセージを C:\myfolder\client.log ファイルに保存するには、目的の行を次のように変更します。

lax.stderr.redirect=c:\\myfolder\\client.log
lax.stdout.redirect=c:\\myfolder\\client.log
 

ステップ 4 .lax ファイルを変更したら、次のいずれかのコマンドを入力して、CTM クライアントを起動します。

/bin/ctm-small-debug.exe
/bin/ctm-medium-debug.exe
/bin/ctm-large-debug.exe
/bin/ctm-highend-debug.exe
 


 

Solaris では、CTM クライアントの起動時に、コンソール ウィンドウを開いて、例外およびクライアント デバッグ メッセージを表示できます。クライアント問題のトラブルシューティングを実行する場合に、これらのメッセージを使用できます。

ネットワーク サイズに応じて、次のいずれかのコマンドを入力し、コンソール ウィンドウを開いた状態でクライアントを起動します。

ctmcdebug-start 穆mall
ctmcdebug-start 卜edium
ctmcdebug-start 僕arge
ctmcdebug-start 防ighend
 
 

K.7 CTMGateWay/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 のユーザ設定と一致していることを確認します。


 

K.8 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 をいったん閉じたあと、再び開いて変更を確認する必要があります。

K.9 Cisco 7600 の問題

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

K.9.1 Cisco 7600 NE の Not In Service and Available 表示

新しい Cisco 7600 NE を追加した場合、NE はIn Service and Available と表示されません。次の手順を実行して、この問題に対処します。


ステップ 1 CTM サーバの hostname-to-IP マッピングが NE に設定されているかを確認します。NE では、次のコマンドを実行します。

show running | include ip
 

マッピングが存在しない場合、次のコマンドを実行します。

config t
ip host <CTM server hostname> <CTM server IP address>
 

ステップ 2 SNMP コミュニティ ストリングが NE に設定されているかを確認します。NE では、次のコマンドを実行します。

show running | include snmp
 

コミュニティが存在しない場合、次のコマンドを実行します。

config t
snmp-server community <community name> RW
 

ここで、< community name > は、Network Elements Properties ペインで指定されたコミュニティ ストリングと同じ値を指定します( Network Element Properties を参照)。

ステップ 3 NE ログインおよび イネーブル EXEC モード認証情報が CTM サーバに設定されているかを確認します。


) デフォルトの NE ログインを設定し、Security Properties ペインのパスワードをイネーブルにできます。Domain Explorer から Administration > Control Panel を選択し、Security Properties をクリックして IOS 7600 タブを選択します。詳細については、「CTM セキュリティ パラメータの設定」 を参照してください。


a. Security Properties ペインの NE パスワードが NE で設定されたパスワードと一致しない場合、Network Element Properties ペインの NE Authentication タブでパスワードを設定します(詳細は、 NE Authentication タブ を参照)。

b. NE Authentication タブでパスワードを設定したあと、NE の動作状態を Out of Service に設定してから In Service に設定します。 Administration > Control Panel を設定し、 NE Service をクリックして正しい IOS 7600 サービス インスタンスを選択します(詳細は、 サービス インスタンス プロパティの表示と修正 を参照)。NE Service Instance ペインで、Stop Service Instance ボタンをクリックして NE サービスを停止します。数秒後、Start Service Instance ボタンをクリックして NE サービスを開始します。


) NE Properties ペインで設定された情報は、Control Panel で設定された情報を上書きします。



 

K.9.2 NE が In Service 状態でハングアップしたあと Unavailable になる

NE が In Service 状態になったあとで、同期設定エラーにより Unavailable になります。次の手順を実行します。


ステップ 1 ヘルス ポールが失敗したかどうか確認します。そのためには、IP 接続を確認し、 ping < NE IP address > コマンドを入力します。CTM サーバと NE の間に IP 接続を確立する必要があります。

ステップ 2 1 つまたは複数の設定アップロード要求がタイムアウトになったかどうかを確認します。そのためには、/opt/CiscoTransportManagerServer/log/IOS7600NEService-<id>-<time>.log ファイルでタイムアウトの例外(Timeout Expired ストリング)を確認します。

タイムアウトの例外があって、NE が IP 到達可能な場合、ネットワーク上でトラフィックが重くなり、CLI コマンドが応答するのにさらに時間がかかることがあります。

ステップ 3 /opt/CiscoTransportManagerServer/cfg/csm.properties プロパティ ファイルの各パラメータの各タイムアウト値を増やします。ただし、値が増えるとシステム パフォーマンス全体が低下します。

次のパラメータを変更できます。

# config reply timeout in second for each retry

CONFIG_REPLY_TIMEOUT=3
 

) この値が増えると、設定アップデート要求がタイムアウトするまでの時間が長くなります。


# image reply timeout in second for each retry

IMAGE_REPLY_TIMEOUT=180
 

) この値が増えると、イメージ アップデート要求がタイムアウトするまでの時間が長くなります。


# number of retries

REPLY_RETRIES=20

 

# number of retries for get running config

GET_RUN_RETRIES=2

 

) 実行コンフィギュレーションがアップロードされるので、NE は同期設定モードのままである場合にこの値を増やします。


# http reply timeout in second

HTTP_TIMEOUT=1800000

 

# telnet timeout in second

TELNET_TIMEOUT=120

 

# time in seconds CTM waits after creating a device

WAIT_AFTER_CREATE=20

 


 

K.9.3 NE が通信切断状態になる

NE 設定が変化すると、NE は Loss Of Communication(LOC; 通信の失敗)状態になります。この問題は次のいずれかが原因となります。

ヘルス ポールに障害が発生しました。詳細については、「NE が In Service 状態でハングアップしたあと Unavailable になる」 を参照してください。

1 つまたは複数の設定アップロード要求がタイムアウトになりました。詳細については、「NE が In Service 状態でハングアップしたあと Unavailable になる」 を参照してください。

CTM サーバに、サーバを実行するのに適切なメモリがありません。CTM サーバ要件を確認します。詳細については、『 Installation Guide for Cisco Transport Manager Release 7.1 』を参照してください。

K.9.4 設定に障害が発生し、設定ジョブが事前設定された時間内に終了しない


ステップ 1 エージェント対応デバイスのイベント パイプが切断されているかを確認します。CNS イベントの接続を確認するには、NE で次のコマンドを入力します。

show cns event connection
 

イベントのホスト名は CTM サーバのホスト名と同じである必要があります。そのステータスは「Connection Established」である必要があります。

ステップ 2 CTM サーバのホスト名が正しく設定されているかを確認します。

CTM サーバのホスト名は、/etc/hosts ファイルに設定します。

たとえば、有効な入力は次のとおりです。

<CTM server IP address><hostname>
 

指定されたホスト名も、DNS サーバで設定する必要があります。

ステップ 3 設定要求のタイムアウト値を増やします。

設定要求がタイムアウトし、NE が IP 到達可能である場合、ネットワーク上でトラフィックが重くなり、CLI コマンドが応答するのにさらに時間がかかることがあります。/opt/CiscoTransportManagerServer/cfg/csm. プロパティ ファイルでは、設定アップデート要求がタイムアウトするまで時間がかかるように、タイムアウト値を増やします。そのためには、次のパラメータを変更します。

# config reply timeout in second for each retry
CONFIG_REPLY_TIMEOUT=3
 


 

K.9.5 警告が発行されて、設定が終了する

Cisco 7600 NE の設定が終了したが警告が出された場合、NE の一部が設定される可能性があります。設定を同期化する必要があります。

K.9.6 BGP ネイバと FTP パスワードに特殊な埋め込み文字を使用できない

次の文字のみを使用できます。& < > ! ? . @ # $ % ^ ~ \n \r + - = | * ( ) { } [ ]

K.9.7 CTM が接続された Cisco 7609 デバイスを検出できない


ステップ 1 次のコマンドを実行します。

show cdp neighbor
show bgp neighbor
 

CTM は BGP と CDP を使用して、7600 NE を検出します。 show cdp neighbor および show bgp neighbor コマンドの出力で接続したデバイスが表示されているかを確認します。また、コマンドによって戻された IP アドレスは CTM サーバ マシンから到達可能であることを確認します。

ステップ 2 デバイスで設定されたコミュニティ ストリングの接続デバイスへの SNMP 読み取りアクセス権があるかを確認します。


 

K.9.8 検出されたデバイスの IP アドレスが管理対象の IP アドレスでない

CTM がデバイスを検出したがその IP アドレスが管理 IP アドレスでない場合、CTM はまずデバイスから CDP/BGP プロトコル情報を問い合わせて、接続されたデバイスのホスト名を取得します。それから、CTM はこのホスト名を使用して、IP アドレスを取得するため DNS 検索を実行します。DNS が IP アドレスを返さない場合、CTM は返されたプロトコル情報で指定された IP アドレスを使用します。

接続されたデバイスのホスト名とその管理 IP アドレスを含んだ DNS エントリがあるか確認して、この問題に対処します。

K.9.9 CTM サーバがトラップを受信しない

次の手順を実行します。

CTM サーバが Cisco 7600 NE のトラップを受信しない場合、次のコマンドを実行して SNMP が NE で設定されているか確認します。

sh run | i snmp-server
 

SNMP サーバが NE で設定されていない場合、次のコマンドを実行します。

config t
snmp-server host <CTM server IP address> version 2c <community string used by CTM>
 

CTM サーバがすべての Cisco 7600 NE のトラップを受信しない場合、次のコマンドを実行して SNMP がすべての NE で設定されているかを確認します。

sh run | i snmp
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps module
snmp-server enable traps syslog
 

K.9.10 ソフトウェアのダウンロード、メモリのバックアップ、メモリの復元の失敗


ステップ 1 Domain Explorer ウィンドウから、 Administration > Control Panel . の順に選択します。

ステップ 2 Control Panel では、 Security Properties をクリックし、 IOS 7600 タブを選択します。

ステップ 3 CTM Server - FTP Connection Username フィールドでは、CTM サーバが FTP 接続で使用するユーザ名を入力します。

ステップ 4 Password フィールドでは、CTM サーバが FTP 接続で使用するパスワードを入力します。

ステップ 5 NE サービスを再起動してください。Control Panel では、 NE Service を選択して、正しい IOS 7600 サービス インスタンスを選択します。NE Service Instance ペインで、Stop Service Instance ボタンをクリックして NE サービスを停止します。数秒後、Start Service Instance ボタンをクリックして NE サービスを開始します。


 

K.9.11 Syslog Viewer が障害を表示しない


ステップ 1 次のコマンドを実行します。

sh run | i logging
 

次のような出力が表示されます。

logging <CTM server IP address>
 

次のような出力が表示されない場合、このパラメータを設定します。

ステップ 2 次の行が /etc/syslog.conf ファイルに表示されていつか確認します。

*.debug /var/log/syslog
 

ステップ 3 Syslog デーモンを再起動します。CTM サーバで次のコマンドを入力します。

/usr/sbin/syslogd
 


 

K.9.12 スタートアップ コンフィギュレーション バックアップの失敗

スタートアップ コンフィギュレーションのバックアップに失敗し、デバイスまたはリソースのビジー エラーを受信した場合、次の手順を実行してください。


ステップ 1 次を確認します。

1 つの CTM サーバのみがサブネット内に存在します。

複数の CTM サーバが存在する場合、ある CTM サーバは CNS エージェント対応モードで NE を管理し、別の CTM サーバは IMGW モードでNE を管理します。

ステップ 2 CTM サーバのホスト名が、/etc/hosts ファイルに設定されているか確認します。有効なエントリは、次のように表示されます。

<CTM server IP address><hosttname>
 


 

K.9.13 Cisco 7600 NE でソフトウェアの起動に失敗


ステップ 1 Config Register 値が NE でゼロ以外に設定されているかを確認します。NE では、次のコマンドを実行します。

sh version
 

コマンド出力の最後の行には、ゼロ以外の Config Register 値が表示されていなければなりません。次に例を示します。

Configuration register is 0x2
 

ステップ 2 Config Register 値が 0x0 の場合、NE で次のコマンドを入力してこの値を変更します。

config t
config-register 0x2
 


 

K.9.14 実行コンフィギュレーションの復元に失敗

実行コンフィギュレーションの復元を行う場合、既存のコンフィギュレーション コマンドを追加しようとすると、オペレーションは失敗します。既存の設定には新しいコマンドのみを追加できます。

K.9.15 正しい CTM デバッグ モジュールの使用

問題の診断に使用可能ないくつかの CTM デバッグ モジュールがあります。正しい CTM モジュールを選択するには、次の手順を実行します。


ステップ 1 Domain Explorer ウィンドウから、 Administration > Control Panel の順に選択します。

ステップ 2 NE Service をクリックして、IOS 7600 を選択します。

ステップ 3 Debug タブをクリックします。NE Service ペインの詳細については、 表4-28 を参照してください。

ステップ 4 Overall Logging エリアでは、Enable オプション ボタンを選択してデバッギングをイネーブルにします。Debug Modules エリアの利用可能なリストから、デバッグ モジュールを選択できます。

ステップ 5 問題が発生すると、デバッグするモジュールを選択できます。たとえば、次のようになります。

7600 CSM -- Cisco 7600 NE サービスのトランスポーテーション レイヤ デバッギング情報を提供します。

Initial Poll -- 最初のポーリング中に NE が別のステートから In Service ステートに移行した場合のログを提供します。


 

K.9.16 ログの収集と場所

CTM ログは /opt/CiscoTransportManagerServer/log ディレクトリに格納されています。

他のログには次が含まれます。

IMGW Requests ログ(/var/log/CNSCE/imgw ディレクトリ)

CNS Agent ログ、Exec Requests ログ、および Event Log ログ(/var/log/CNSCE/cfgsrv ディレクトリ)

Image Download ログ(/var/log/CNSCE/imgsrv ディレクトリ)

K.9.17 詳細な CE デバッギングのイネーブル化

次のいずれかを入力します。

ブラウザで、 http://<CTM Server IP address> と入力し、 CTM サーバのインストール時に設定された CE ユーザ名とパスワードを入力します。

GUI から、select Tools > Log Manager > Change log level > Debug > Submit の順に選択します。


) GUI で変更する際は、CE を再起動する必要はありません。ただし、CTM が再起動したあとで CE 設定に行ったすべての変更は失われます。


CE デバッギング レベルを設定し、CE を再起動するには、次のコマンドを入力します。

/opt/CiscoTransportManagerServer/ConfigEngine/CSCOcnsie/bin/setup
 

このコマンドにより、CTM サーバで管理された NE は一時的に Out of Service になります。デフォルトでは、ロギング レベルは error です。デバッギングの詳細なレベルは verbose です。この手順の IMGW セットアップ部分でロギング レベル情報を設定します。

K.10 Cisco CRS-1 および Catalyst 6509 の問題

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

K.10.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 で HTTP が動作していることを確認します。

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 に LOC が報告されます。


 

K.10.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
 


 

K.10.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
 

ステップ 3 ルータに xml エージェント corba が設定されている場合は、 ping コマンドを使用して、ルータおよび CTM サーバ マシンに完全修飾ホスト名で到達できることを確認します。

ステップ 4 CTM サーバ マシンがデュアルホーム マシンの場合に、ルータで設定変更通知を受信するには、CTM サーバ マシンがルータとの通信に使用する IP アドレスをルータに設定する必要があります。たとえば、CTM サーバ マシンが、次のホスト名および IP アドレスを持つデュアルホーム マシンであるとします。

ctmserver1 <172.x.x.x>
ctmserver1-other <10.x.x.x> (IP address used to communicate with the router
 

このルータを次のように設定する必要があります。

domain ipv4 host ctmserver1 <10.x.x.x>
 


 

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


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

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
 


 

K.10.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)

K.10.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 ファイルへの書き込みを許可しますが、新規 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
 


 

K.10.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 分ごとにデータを収集するよう設定する必要があります。

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


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

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

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


 

K.10.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 をクリックします。


 

K.10.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
 


 

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

Out of Sservice 状態の NE を CTM から削除できない場合は、「prune_ne.sh スクリプトを使用したアウト オブ サービス状態にある NE のデータベースからの削除」の手順に従います。

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

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


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

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


 

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

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

K.10.14 CRS-1 で Telnet を設定する方法

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

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

K.10.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
 


 

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

「CRS-1 および XR 12000 のSecure Socket Layer(SSL)の設定」 を参照してください。

K.10.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

K.10.18 Catalyst 6509 で SNMP の設定を表示する方法

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

cat6509 (enable)# show snmp

K.10.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
 


 

K.11 XR 12000 の問題

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

K.11.1 XR 12000 問題の報告

XR 12000 問題を報告する場合は、問題を再現するための詳細手順、および問題が適用される NE のソフトウェア バージョンを含めて報告します。また、XR 12000 に次のルータ CLI コマンドを入力して、データを収集します。

show version
show platform
show inventory
show ipv4 interface brief
show running-config
show events
show log events buffer all-in-buffer
 

Control Panel で該当するサービスのトレース レベル デバッグをオンにし、問題が発生するまで待機してから、/opt/CiscoTransportManagerServer/log から GSRIOXNEService ログを収集します。


) CRS-1 および XR 12000 NE の場合は、プロンプトで admin を入力してから、show platform および show inventory コマンドを入力して、結果を管理モードで表示します。


K.11.2 CTM が XR 12000 ノードを検出できない

CTM が XR 12000 ノードを検出できない場合は、次のステップを実行します。


ステップ 1 NE のユーザ名、パスワード、および権限がそれぞれ「hfrems」、「hfrems」、および「root-system」に設定されていることを確認します。特に何もしていなければ、CTM ではユーザ名とパスワードがともに hfrems であるものとして処理されます。セキュリティ プロパティは Control Panel > Security Properties ペイン > XR 12000 タブで変更できます。CTM は新しいユーザ名およびパスワードを使用して、ドメインの XR 12000 デバイスを認証します。

ステップ 2 XML CORBA エージェント サービスが稼働しているかどうかを確認します。XML CORBA エージェントを設定するには、次のように入力します。

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

) ssl は自由に選択できます。選択すると、SSL CORBA サービスがイネーブルになります。


SSL CORBA サービスがアクティブな場合は、次のコマンドを入力して、SSL で HTTP が動作しているかどうか確認します。

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

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

ステップ 4 ルータ上で動作しているソフトウェア バージョンが CTM でサポートされていることを確認します。CTM リリース ノートには、CTM でサポートされている NE ソフトウェアのバージョンが記載されています。 http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/optnet/ctm/ctmreln/index.htm に移動します。

ステップ 5 CTM に NE を追加すると、NE タイプが検索されて、NE が XR 12000 であるかどうかが確認されます。デバイスの NE タイプが XR 12000 でない場合、NE は CTM 内で LOC 状態に移行し、NE タイプ不一致アラームが生成されます。

ステップ 6 DNS または CTM サーバの /etc/hosts ファイルに指定されている NE のホスト名は、NE に設定されているホスト名と一致する必要があります。ホスト名が一致していないと、NE は CTM 内で LOC 状態に移行します。


 

K.11.3 XR 12000 の状態が Domain Explorer にすぐに反映されない

LAN ケーブルを取り外した場合は、Domain Explorer 内で XR 12000 のステータスが更新されるまでに遅延が生じます。ルータとの接続を解除した場合は、ステータスが unreachable になるまでに数分、あるいはそれ以上かかることがあります。

ステータスを短時間で更新する必要がある場合は、/opt/CiscoTransportManagerServer/openfusion/classes/jacorb.properties ファイルの jacorb.connection.client.pending_reply_timeout パラメータを変更する必要があります。デフォルトのタイムアウトは 5 分(300000 マイクロ秒)です。更新のおおよその所要時間は、ヘルス ポーリング インターバルに jacorb.connection.client.pending_reply_timeout 値の 2 倍を加えた値になります。

K.11.4 XR 12000 のアラームおよびイベント報告の問題

CTM が XR 12000 アラームおよびイベント通知を受信しない場合は、次のステップを実行します。


ステップ 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
 

ステップ 3 ルータに xml エージェント corba が設定されている場合は、 ping コマンドを使用して、ルータおよび CTM サーバ マシンに完全修飾ホスト名で到達できることを確認します。

ステップ 4 CTM サーバ マシンがデュアルホーム マシンの場合に、ルータで設定変更通知を受信するには、CTM サーバ マシンがルータとの通信に使用する IP アドレスをルータに設定する必要があります。たとえば、CTM サーバ マシンが、次のホスト名および IP アドレスを持つデュアルホーム マシンであるとします。

ctmserver1 <172.x.x.x>
ctmserver1-other <10.x.x.x> (IP address used to communicate with the router
 

このルータを次のように設定する必要があります。

domain ipv4 host ctmserver1 <10.x.x.x>
 


 

K.11.5 XR 12000 PM 収集の問題

XR 12000 は、ユーザが CLI を介して設定した間隔でデータを収集し、TFTP サーバのバイナリ ファイルへダンプします。パフォーマンス データをダンプしたあと、XR 12000 はファイルの場所を示す通知を送信します。CTM はこの通知を受信すると、XR 12000 からパフォーマンス データを収集します。したがって、ネットワーク オペレータは 15 分ごとにデータを収集するように XR 12000 を設定する必要があります。


ステップ 1 次のコマンドを入力して、TFTP サーバおよびディレクトリが実行コンフィギュレーション ファイル内に設定されているかどうかを確認します。

performance-mgmt resources tftp-server <server_IP_address> directory <directory_on_TFTP_server>
 

ステップ 2 次のコマンドを入力して、ルータの実行コンフィギュレーションに正しい PM 設定が格納されていることを確認します。

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
!
.
.
.
.
 

ステップ 3 パフォーマンス データをダンプしたあと、XR 12000 はファイルの場所を示す通知を送信します。この通知は 15 分おきに Alarm Log に記録され、TFTP サーバに接続している CTM サーバをトリガーします。Alarm Log で次のような通知を検索します。

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


 

K.11.6 XR 12000 BGP および CDP の近接ディスカバリの問題

CTM はすべての CDP および BGP ネイバ ルータを検出し、このルータで CDP または BGP がイネーブルな場合は、ツリー ビューに追加します。CDP および BGP 近接ディスカバリは、NE の同期後に発生します。ネイバが検出されない場合は、次の CLI コマンドを入力して、CDP または BGP がルータおよびインターフェイスでイネーブルかどうかを調べます。

show bgp neighbors
show cdp neighbors

K.11.7 XR 12000 NE Explorer アプリケーションがディセーブルである

CTM NE Explorer でイネーブルになるのは、CTM およびルータで XML バージョンが一致するアプリケーションのみです。NE Explorer でアプリケーションがディセーブルな場合は、バージョンが一致していない可能性があります。次の手順を実行します。

<CTM_home> /cfg/metadata ディレクトリから XML ファイルを収集します。

<CTM_home> /bin/vwdata.sh スクリプトを実行して、hfr_version_info データベース テーブル エントリを収集します。

Windows で NE Explorer または GUI アプリケーションがエラーを戻した場合は、ネットワーク サイズに応じて次のコマンドを入力して GUI を起動してから、同じ操作を繰り返します。

<CTM_home>/bin/ctm-small-debug.exe
<CTM_home>/bin/ctm-medium-debug.exe
<CTM_home>/bin/ctm-large-debug.exe
 

これにより、すべての例外を記録するコンソールが開きます。デバッグのために、コンソール ログを取り込みます。

UNIX では、 <CTM_home> /bin/ctmcdebug-start コマンドを入力してクライアントを起動し、同じ操作を繰り返します。端末にエラーおよび例外メッセージが生成されます。デバッグのために、端末メッセージを取り込みます。

K.12 MGX 音声ゲートウェイ デバイスの問題

ここでは、MGX 音声ゲートウェイ デバイス関連の問題に対するトラブルシューティング手順を説明します。

K.12.1 検出メカニズム

CTM は Private Network-Network Interface(PNNI)を管理します。ILMITopoc プロセスは SNMP プロトコルを使用して、物理 PNNI ネットワークを検出します。検出されたすべてのノードは MGX NE GUI(Configuration Center、Diagnostics Center、Statistics Report、および Chassis View)に表示されます。CTM には MGX ノードのトラップを介して、ネットワーク内の以降の変更がすべて通知されます。

すべてのノードを検出したあと、ILMITopoc プロセスはすべてのノードを topod プロセスに送信します。topod はこれらのノードおよびトランクを ooemc、NMServer、nts など、CTM 内のその他のプロセスに送信します。

K.12.2.1 ノードが検出されない

CTM データベース内にノードがない場合は、次の手順を実行します。


ステップ 1 ノードに IP で到達できることを確認します。このエラーが表示された場合は、次のステップを実行します。

a. 次の CLI コマンドを入力して、ノードのプライマリ IP アドレスを取得します。

dspndparms
dspipif
 

b. 次のコマンドを入力して、CTM がノードに IP で接続されているかどうかを確認します。

ping <node_IP_address>
 

ステップ 2 CTM がノードに IP で接続されている場合は、ゲートウェイ ノードのコミュニティ ストリングが正しいことを確認します。このエラーが表示された場合は、次のステップを実行します。

a. 検出できないノードのスイッチ CLI で、次のコマンドを入力します。

dspsnmp
 

b. このコミュニティ ストリングと node_info テーブル内のコミュニティ ストリングを比較します。node_info テーブル内のコミュニティ ストリングは暗号化されています。このストリングの暗号を解除して、検証する必要があります。

ステップ 3 MGX ノードに対し、スイッチ ゲートウェイで固定的トポロジーがイネーブル化されているにもかかわらず、ピア グループ内のノードの一部が検出されない場合は、次のステップを実行します。

a. 次の CLI コマンドを入力して、ピア グループ内のゲートウェイで固定的トポロジーがイネーブルになっていることを確認します。

dsptopogw
 

b. ゲートウェイ フラグがイネーブルな場合は、次の CLI コマンドを入力して、ゲートウェイのノード リストに目的のノードが含まれていることを確認します。

dsptopondlist
 


 

障害情報 -- 次の情報を収集して、さらに分析します。

Topod.log および ILMITopoc.log

node_info テーブル内のデータ

MGX ノードの dspndparms、dspsnmp、および dspipif の出力

K.12.2.2 データベース内のノード名が正しくない

スタンドアロン MGX ノードのノード名が正しくない場合は、次の手順を実行します。


ステップ 1 ノード テーブルに正しい名前が格納されている場合は、次のステップを実行します。

a. 次のコマンドを入力して topod および ILMITopoc のキャッシュをダンプします。

kill -USR1 <process>
 

b. 収集データから、不正な情報を含むプロセスを確認します。すべてのプロセスで情報が正しい場合は、GUI の新しいインスタンスを開いて、問題が存在するかどうかを確認します。

ステップ 2 ノード テーブルに正しくない名前が格納されている場合は、ILMITopoc.log ファイルで、不正な情報が収集されたノードを調べます。このエラーが表示された場合は、次のステップを実行します。

a. 次のコマンドを入力します。

snmpget -c <community> <IP_address> 1.3.6.1.2.1.1.5
 

b. 応答として受信された名前が正しいことを確認します。受信した名前が正しくない場合は、スイッチの名前を確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log および topod.log

ILMITopoc および topod のダンプ出力。次のコマンドを入力します。

kill -USR1 signal <process>
 

スイッチ CLI、selnd、および dbnds の出力

K.12.2.3 データベース内のノード IP が正しくない


ステップ 1 ノード テーブルに正しい IP アドレスが格納されている場合は、次のステップを実行します。

a. 次のコマンドを入力して topod および ILMITopoc のキャッシュをダンプします。

kill -USR1 <process>
 

b. 収集データから、不正な情報を含むプロセスを確認します。すべてのプロセスで情報が正しい場合は、GUI の新しいインスタンスを開いて、問題が存在するかどうかを確認します。

ステップ 2 ノード テーブルに IP アドレスが正しく設定されていない場合は、ノードが LAN IP アドレスで管理されているかどうかを確認します。CTM の場合は、ノードに PNNI トランクが設定されていなくて、固定的トポロジー機能がディセーブルであるため、ノードはデフォルトで LAN IP アドレスによって管理されます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log および topod.log

ILMITopoc および topod のダンプ出力。次のコマンドを入力します。

kill -USR1 signal <process>
 

スイッチ CLI、selnd、および dbnds の出力

K.12.2.4 データベース内のノード アラームが正しく表示されない


ステップ 1 次のコマンドを入力して topod および ILMITopoc のキャッシュをダンプします。

kill -USR1 <process>
 

ステップ 2 収集データから、不正な情報を含むプロセスを確認します。

ステップ 3 ノード テーブルにノード アラーム ステータスが正しく設定されていない場合は、ILMITopoc.log ファイルを調べて、次のコマンドを入力します。

snmpget -c <community string> <IP_address> 1.3.6.1.4.1.351.110.1.1.14
 

snmpget コマンドはノードのアラーム状態を戻します。1 = Clear、2 = Minor、3 = Major、および 4 = Critical です。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log および topod.log

ILMITopoc および topod のダンプ出力。次のコマンドを入力します。

kill -USR1 signal <process>
 

スイッチ CLI、selnd、および dbnds の出力

K.12.2.5 到達可能なノードが「Unreachable」と表示される

CTM から到達可能なノードが、Configuration Center、Chassis View、Diagnostics Center、または Statistics Report で unreachable と表示される場合は、次のステップを実行します。


ステップ 1 ノード テーブルで報告されたこのノードのアラーム状態が minor、major、critical、または clear である場合は、次のステップを実行します。

a. 次のコマンドを入力して NMServer、topod、および ILMITopoc のキャッシュをダンプします。

kill -USR1 signal <process>
 

b. /opt/svplus/log ディレクトリで収集されたデータを調べて、ノード アラーム ステータスが正しいかどうかを確認します。キャッシュ ダンプ内のアラーム ステータスが正しい場合は、GUI の新しいインスタンスを開いて、このウィンドウに正しいアラーム ステータスが表示されているかどうかを確認します。

ステップ 2 ノード テーブルに表示された MGX ノードのアラーム状態が unreachable である場合は、次のステップを実行します。

a. CTM からノードに IP で到達できることを確認します。

b. ノードのアクティブ IP アドレスに ping を実行します。アクティブ IP アドレスは、ノード テーブルに読み込まれているノードの IP アドレスです。

c. 次の CLI コマンドを入力して、ノードのコミュニティ ストリングを取得します。

dspsnmp
 

d. node_info テーブル内のコミュニティ ストリングがノードのコミュニティ ストリングと同じであることを確認します。

e. nts ログで、nts がこのノードを到達可能であると宣言しているかどうかを確認します。
「NTS」 を参照してください。nts がノードを到達可能であると宣言している場合は、topod.log でこのノードに対応する「nonRoutingNodeMsg」を検索します。このメッセージ内のアラーム ステータスが正しいことを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log、topod.log、NMServer.*.log、nts.*.log、および ooemc*log

ILMITopoc、topod、および NMServer のダンプ出力。次のコマンドを入力します。

kill -USR1 signal <process>
 

スイッチ CLI、selnd、および dbnds の出力

K.12.2.6 CTM 状態が正しくない

ノードに IP を使用して到達できる場合であっても、ノード テーブルのノードの管理状態(mgmt_state カラム)に DOWN(2)または UNKNOWN(0)が表示されるときは、次のステップを実行します。


ステップ 1 ノードの CTM ステーションのトラップ マネージャ登録を調べます。ノードにログインして、次のコマンドを入力し、CTM ステーションがトラップのためにノードに登録されているかどうかを確認します。この処理は、ノードを管理可能であると宣言する場合に必要です(mgmt_state = UP)。

dsptrapmgr

ステップ 2 Domain Explorer > Network Element Properties ペイン > NE Authentication タブで、ノードのコミュニティ ストリング(SNMP-GET および SNMP-SET)を入力します。node_info テーブルの SNMP ストリングは正しくない場合があります。データベース内の暗号化ストリングに暗号解除ツールを使用できる場合は、このストリングを検証できます。

ステップ 3 nts.log で、ノードのトラップ登録に成功したかどうかを調べます。「NTS」 を参照してください。

ステップ 4 分析するために、ILMITopoc.log、topod.log、および ooemc*.log を保存します。


 

K.12.3.1 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にノードが表示されない

動的に追加されたルーティング ノードが、Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示されない場合は、次のステップを実行します。


ステップ 1 ノード テーブルにノードのエントリが格納されている場合は、次のステップを実行します。

a. 次のコマンドを入力して NMServer、topod、および ILMITopoc のキャッシュをダンプします。

kill -USR1 signal <process>
 

b. /usr/user/svplus/log ディレクトリで収集されたデータを調べて、キャッシュ ダンプ内に目的のノードが存在するかどうかを確認します。目的のノードが存在する場合は、GUI の新しいインスタンスを開いて、この GUI でノードが表示されるかどうかを確認します。

ステップ 2 ノード テーブルにノードのエントリが格納されていない場合は、次のステップを実行します。

a. ILMItopoc ログを調べて、70005 および 70201 トラップが受信されたかどうかを調べます(固定的トポロジー機能がイネーブルな場合)。

b. ログにトラップが記録されている場合は、トラップが正常に受信されたあとに ILMITopoc の SNMP 要求が発行されたかどうかを確認します。SNMP 要求が送信されていない場合は、CTM が新規に追加されたノードと IP および SNMP で接続されているかどうかを確認します。

c. ILMITopoc.log にトラップが記録されていない場合は、「NTS」を参照してください。

ステップ 3 次のステップを実行して、分析のために障害情報を収集します。

a. ILMITopoc.log、topod.log、NMServer.log、および nts.*.log を保存します。

b. 次のコマンドを入力して、ILMITopoc、topod、および NMServer のダンプ出力を収集します。

kill -USR1 signal <process>
 

c. スイッチ CLI、selnd、および dbnds の出力を収集します。

ステップ 4 上記ステップを実行しても問題が解決しない場合は、ネットワークからノードを削除して、追加しなおします。


 

K.12.3.2 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report でノード名の変更が更新されない

ノード名を変更しても、Configuration Center、Chassis View、Diagnostics Center、または Statistics Report でノード名が更新されない場合は、次のステップを実行します。


ステップ 1 ノード テーブルにノードのエントリが正しい名前で格納されている場合は、次のステップを実行します。

a. 次のコマンドを入力して NMServer、topod、および ILMITopoc のキャッシュをダンプします。

kill -USR1 signal <process>
 

b. /usr/user/svplus/log ディレクトリで収集されたデータを調べて、キャッシュ ダンプ内のノード名が正しいかどうかを確認します。ノード名が正しい場合は、GUI の新しいインスタンスを開いて、この GUI のノード名が正しいかどうかを確認します。

ステップ 2 ノード テーブルにノードのエントリが正しい名前で格納されていない場合は、次のステップを実行します。

a. ILMItopoc ログを調べて、60006 および 70202 トラップが受信されたかどうかを調べます。

b. ログにトラップが記録されている場合は、ILMITopoc がトラップに基づいてキャッシュを更新しているかどうかを確認します。ILMITopoc がノード名の更新に失敗した場合は、ILMITopoc.log にメッセージ「%ILMITopoc-3-updateFailed:<Node_c::updateName> Failed to update node name」が格納されます。

c. ILMITopoc.log にトラップが記録されていない場合は、「NTS」を参照してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log、topod.log、NMServer.log、および nts.*.log

ILMITopoc、topod、および NMServer のダンプ出力。次のコマンドを入力します。

kill -USR1 signal <process>
 

スイッチ CLI、selnd、および dbnds の出力

K.12.3.3 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report でノード IP アドレスの変更が更新されない

ノード IP アドレスが Configuration Center、Chassis View、Diagnostics Center、または Statistics Report で動的に更新されない場合は、次のステップを実行します。


ステップ 1 ノード テーブルにノードのエントリが正しい IP アドレスで格納されている場合は、次のステップを実行します。

a. 次のコマンドを入力して NMServer、topod、および ILMITopoc のキャッシュをダンプします。

kill -USR1 signal <process>
 

b. /opt/svplus/log ディレクトリで収集されたデータを調べて、キャッシュ ダンプ内の IP アドレスが正しいかどうかを確認します。IP アドレスが正しい場合は、GUI の新しいインスタンスを開いて、この GUI の IP アドレスが正しいかどうかを確認します。

ステップ 2 ノード テーブルにノードのエントリが正しい IP アドレスで格納されていない場合は、次のステップを実行します。

a. ILMItopoc ログを調べて、60007 および 70202 トラップが受信されたかどうかを調べます。

b. ログにトラップが記録されている場合は、ILMITopoc がトラップに基づいてキャッシュを更新しているかどうかを確認します。

c. ILMITopoc.log にトラップが記録されていない場合は、「NTS」を参照してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log、topod.log、NMServer.log、および nts.*.log

ILMITopoc、topod、および NMServer のダンプ出力。次のコマンドを入力します。

kill -USR1 signal <process>
 

スイッチ CLI、selnd、および dbnds の出力

K.12.4 機器管理の問題

ここでは、Cisco MGXデバイスの Equipment Management(EM)問題に対するトラブルシューティング手順を説明します。

K.12.4.1 ノード モードが 3 の場合に EM でノード再同期に成功したと宣言される

MGX ノードは、CTM の ooemc コンポーネントで管理されます。EM はコールドスタート、ウォームスタート、および定期的再同期を使用して、ネットワーク データを同期します。これらの再同期方式ではそれぞれ、コンフィギュレーション ファイルのアップロード、解析、およびデータベース入力を実行します。ノード テーブル内のノード モードは、同期プロセスの状態を示します。有効なノード モードは 1、2、3、および 5 です。ノードを正常に再同期する場合に想定されるモードは 3 です。ノード モードがそれ以外のモードに長期間とどまっている場合は、再同期に問題があります。同期問題はスイッチ、SNMP、FTP(ファイル転送プロトコル)、または ooemc が原因で発生することがあります。さまざまなエリアを調査して、同期問題の根本原因を特定する必要があります。

次に、ooemc コールドスタート同期プロセスのイベント フローを示します。

1. topo プロセスはネットワーク内のノードを検出します。このプロセスはノード データベース テーブルのノード モードを -1 に変更してから、ooemc コンポーネントに検出を行うよう通知します。ooemc コンポーネントがノードの管理を開始したら、ooemc はノード モードを -1 から 1 に変更します。

2. nts コンポーネントをノードに登録できる場合、このコンポーネントはノードを管理する ooemc にリンク アップ メッセージを送信します。ooemc コンポーネントノード モードを 1 から 2 に変更して、ノードの同期を開始することを表明します。

3. ooemc コンポーネントは SNMP バルク ファイル作成要求をスイッチに送信します。要求が許可されると、スイッチはトラップ 60901 を CTM に送信して、バルク ファイル作成を開始することを表明します。スイッチでバルク ファイル作成が完了すると、トラップ 60902 が CTM に送信されます。CTM はこのトラップを受信すると、コンフィギュレーション アップロード ファイルの FTP 転送を開始します。

4. すべてのコンフィギュレーション ファイルのアップロードおよび解析が問題なく完了した場合、ooemc はノード モードを 2 から 3 に変更します。アップロードまたは解析中にスイッチのサービス モジュールにエラーが発生した場合は、ノードが完全に同期されず、ooemc はノード同期プロセス終了時にノード モードを 2 から 4 に変更します。シェルフ汎用カード ファイル(CARD_01_CC.CF)または pnni ファイル(PNNI_01_CC_CF)にエラーが発生した場合、ooemc はノード モードを 2 から 5 に変更して、ノードの同期アップ中に障害が発生したことを表明します。

K.12.4.2 OOEMC 同期アップ プロセスに必要なネットワーク設定

EM で同期アップ プロセスを開始するには、ネットワーク設定および CTM 設定の前提条件を満たす必要があります。スイッチで次の手順を実行します。

dsptrapmgr CLI コマンドを使用して、トラップ マネージャに CTM IP アドレスが追加されていることを確認します。CTM IP アドレスがスイッチに登録されていない場合は、 addtrapmgr <cwm_ip> 2500 CLI コマンドを入力して、トラップ マネージャに CTM IP アドレスを追加します。ここで、2500 はポート番号、 cwm_ip はご使用の CTM マシンの IP アドレスです。リストが一杯である場合は、トラップ マネージャ リストからその他の IP アドレスを削除しなければならない場合があります。リストが一杯でなければ、CTM がノードを管理するように設定されている場合、登録は自動実行されます。

スイッチにトラップ IP を適切に設定しておく必要があります。スイッチの任意の IP(atm0 IP または lnPci0 IP)をプライマリ IP として使用するようにスイッチを設定した場合、CTM のトポロジー コンポーネントはノード検出にこの IP を使用する必要があります。スイッチのプライマリおよびセカンダリ IP 情報を表示するには、CLI コマンド dspndparms を入力します。プライマリおよびセカンダリ IP アドレスを設定するには、cnfndparms を入力します。オプションの入力を求めるプロンプトが表示されます。プライマリおよびセカンダリ IP アドレスを設定し、CLI コマンド cnftrapip configured_IP を入力して、プライマリ IP をスイッチのトラップ IP として設定する必要もあります。ここで、configured_IP は、CLI コマンド cnfndparms でプライマリ IP として使用するように選択された IP です。

次に、CTM マシンのファイル /opt/svplus/config/emd.conf 内の設定可能なパラメータ リストを示します。問題を適切にロギングする場合は、これらのパラメータを設定する必要があります。

「OODebug」:このデバッグ用パラメータは、レベル 6 以上に設定する必要があります。たとえば、emd.conf 内のログ レベル ステートメントは「OODebug Level 6」のようになります。

「OOKeep」:このデバッグ用パラメータは、保持するログ ファイル数に応じて、特定の値に設定する必要があります。たとえば、emd.conf 内のステートメントは、「OOKeep 100 ooemc log files per oochild」のようになります。


) 別のネットワーク環境では、同じファイル内のその他のパラメータを調整して CTM が正しく機能するように設定する作業が必要になることがあります。


K.12.4.3 ノード モードが 1 のままである

CTM のネットワーク トポロジー プロセスでノードが検出され、ノード テーブル エントリ内のノード モードが -1 から 1 に変更されたあと、そのノードが長期間モード 1 にとどまっています。


ステップ 1 CTM コアが開始されたあとも、CTM が長期間モード 1 にとどまっている場合は、スイッチのトラップ マネージャを調べる必要があります。トラップ マネージャおよびトラップ IP の設定については、「OOEMC 同期アップ プロセスに必要なネットワーク設定」 を参照してください。

ステップ 2 ステップ 1 に問題がない場合は、nts から EMD に送信された rtm リンク アップ メッセージを検索します。EMD がooemc にノードがアクティブであることを通知すると、ooemc はノード再同期を開始します。したがって、このモード 1 問題をデバッグする場合は、次に rtm リンク アップ メッセージが EMD で受信されたかどうか、および ooemc に転送されたかどうかを調べます。

たとえば、EMD で受信された rtm リンク アップ メッセージ内で ID が 9 のノードを検出するには、次のコマンドを発行します。

grep RTM_LINK_UP emd* | grep "Node id 9"

ログ内の rtm リンク アップ メッセージの場所を特定し、ログ ファイルを表示して、ooemc への通知に関する詳細を取得します。

ステップ 3 ノードに対する rtm リンク アップ メッセージが見つかり、ooemc に通知が送信されたことがログに示されている場合は、ログ ファイルを収集して、問題を報告します。

ステップ 4 rtm リンク アップ メッセージが見つからない場合は、リンク ダウン メッセージを検索します。emd ログ ファイル内で RTM_LINK_DOWN を grep 検索します。rtm リンク ダウン メッセージが見つかった場合は、nts プロセスがノードに到達できていません。RTM_LINK_UP および RTM_LINK_DOWN メッセージが見つからない場合は、ネットワーク管理者に問い合わせ、さらに「NTS」を参照してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log ディレクトリの ooemc および nts ログ ファイル

有効な代替対処法 -- なし

K.12.4.4 ノード モードが 2 のままである

ノード アクティブ メッセージが ooemc に送信されている場合に、EMD が rtm リンク アップ メッセージを受信すると、ooemc はノード モードを 1 から 2 に変更して、ノード再同期プロセスをトリガーします。ノードの再同期時間は、スイッチの設定およびネットワーク アクティビティによって異なります。ノード モードがノード再同期の標準時間よりも長期間モード 2 にとどまっている場合は、ノード再同期プロセスに問題がある可能性があります。


ステップ 1 この問題のデバッグ プロセスでは、主にログ ファイルを検査します。関連するすべての CTM プロセスのログ レベルが正しいレベルに設定されていることを確認します。詳細については、「OOEMC 同期アップ プロセスに必要なネットワーク設定」 を参照してください。

ステップ 2 /opt/svplus/tmp ディレクトリに移動して、コンフィギュレーション アップロード ファイルを検索します。

ステップ 3 特定のノードにアップロードされたファイルを判別します。たとえば、node_id=9 のノードの場合は、次のコマンドを入力します。

ls -ltr *.9

このノードにファイルがアップロードされている場合は、ノード再同期プロセスが進行中です。これらのファイルのタイムスタンプが現在時刻になっていることを確認します。


) コンフィギュレーション アップロード ファイルのリストについては、ステップ 6 を参照してください。


ステップ 4 ノードにファイルがアップロードされていない場合は、スイッチのトラップ IP アドレスがノード検出に使用される IP アドレスと一致しない可能性があります。また、SNMP 要求障害が発生した可能性もあります。IP アドレスを確認する手順は、次のとおりです。

a. CLI コマンド dbnds を使用して、ノード検出に使用する IP アドレスを表示します。

b. CLI コマンド dsptrapip を使用して、トラップ IP アドレスを表示します。

c. これらのアドレスが一致しない場合は、CLI コマンド cnftrapip を使用して、トラップ IP アドレスを再設定します。CTM で使用された IP アドレスを使用して、ノード検出を実行します。詳細については、「OOEMC 同期アップ プロセスに必要なネットワーク設定」 を参照してください。

ステップ 5 トラップ IP アドレスに問題がない場合は、SNMP 要求に問題があるかどうかを確認します。通常、ノード再同期プロセスがトリガーされると、ooemc はスイッチに SNMP 要求を送信して、コンフィギュレーション アップロード ファイル作成プロセスを開始します。要求に失敗した場合、ooemc は最大再試行回数を超え、ノード モードが 5 になってノード再同期障害が宣言されるまで、SNMP 要求を再送信し続けます。


) SNMP 要求障害が原因でノード再同期障害が宣言されるまでは、あまり時間がかかりません。SNMP 障害があることを確認するには、ooemc および snmpcomm ログ ファイルを調べます。



) ooemc ログ ファイル名の例として、ooemc10.6568.log を使用します。10 は子 ID、6568 は ooemc プロセス ID です。子 ID は次の式で計算されます。(NEDBACCSSID / ooemc の子の数)の剰余 + 1。プロセス ID を取得するには、CLI コマンド psg em を使用します。


ステップ 6 ログ ファイル内で RESYNC を grep 検索します。grep 結果にはノード ID とノード モードが含まれます。ログ ファイル内のログ メッセージを調べて、SNMP 障害が発生したかどうかを判別します。

ステップ 7 次の手順を実行します。

a. ログ ファイルでトラップ 60903 を検索します。見つかった場合は、プラットフォーム チームに連絡して、スイッチのバルク ファイル作成障害を調査します。

通常、ノード モード 2 問題は、スイッチのバルク ファイル作成中断プロセスが原因で発生します。SNMP 要求障害がない場合は、スイッチから ooemc にトラップ 60901 および 60902 が送信されます。トラップ 60901 はスイッチがバルク ファイル作成を開始することを示し、トラップ 60902 はバルク ファイル作成が完了したことを示します。トラップ 60902 を受信すると、ooemc はシェルフ汎用コンフィギュレーション ファイルであるバルク ファイルの FTP 転送を開始します。このファイルは、各再同期モード(コールドスタート、ウォームスタート、または定期的再同期)で最初にアップロードされます。一般的なモード 2 問題は、スイッチがバルク ファイル作成を打ち切り、CTM にトラップ 60903 を送信することです。最大再試行回数を超過していないかぎり、CTM は次の SNMP 要求を再スケジュールします。

b. ログ ファイルでトラップ 60902 を検索します。

CARD_01_CC.CF.10 は、CTM がスイッチからトラップ 60902 を受信したあとに最初にアップロードされるシェルフ汎用ファイルです。ノード ID は 10 です。ログ ファイルにトラップ 60902 が見つかったにもかかわらず、合理的な期間が経過してもコンフィギュレーション ファイルがアップロードされない場合は、FTP に障害がある可能性があります。

FTP 障害が発生したかどうかを調べるには、次の処理を実行します。

a. ログ ファイル内で「to ftp file」とコンフィギュレーション ファイル名、または単に「FTP」を grep 検索します。

b. ログ ファイル内のログ メッセージをトレースします。

SNMP 要求障害および FTP 障害の詳細については、snmpcomm と cwmftpd ログ ファイル、および cwmftp.request_log を参照してください。両方のファイル内で、エラーが発生した時点のファイル名を検索します。cwmftp.request_log には FTP 処理の概要および最終結果が示され、すべてのエラーが報告されます。cwmftp.log には FTP 処理の詳細が示されます。

CTM は一連のコンフィギュレーション ファイルをスイッチからアップロードして、解析します。次のファイルが MGX NE(VISM、AXSM、VXSM、SRM、および RPM/RPM-PR カードで構成)からアップロードされます。

1. CARD_01_CC.CF

2. SM_1_slot#.CF

3. SM_1_slot#.CS

4. SM_CARD_01_slot#.CF

5. SM_CONN_01_slot#.CF

6. SM_ALARM_01_slot#.CF

7. SM_CON_UPDATE_01_slot#.CF

8. SM_CARD_01_SRM.CF

9. SM_CARD_01_RPM.CF

10. PNNI_01_CC.CF

ファイル 1 および 2 は NBSM ごとにアップロードされます。ファイル 4 ~ 7 は AXSM ごとにアップロードされます。ファイル 9 はスイッチのすべての RPM/RPM-PR カードに対してアップロードされます

次のファイルが MGX NE(VISM、AXSM、VXSM、SRM、PM/RPM-PR、および RPM-XF カードで構成)からアップロードされます。

1. CARD_01_CC.CF

2. SM_1_slot#.CF

3. SM_1_slot#.CS

4. SM_CARD_01_slot#.CF

5. SM_CONN_01_slot#.CF

6. SM_ALARM_01_slot#.CF

7. SM_CON_UPDATE_01_slot#.CF

8. SM_SC_slot#_transactionID_date.CF

9. SM_IC_slot#_transactionID_date.CF

10. SM_CARD_01_SRM.CF

11. SM_CARD_01_RPM.CF

12. PNNI_01_CC.CF

上記リストの項目間の違いは、AXSM カードと RPM-XF カードにアップロードされるファイルにあります。リリース 4.0 以上のスイッチ ソフトウェアでは、スタティック ファイル
(SM_SC_slot#_transactionID_date.CF)および差分ファイル(SM_IC_slot#_transactionID_date.CF)がアップロードされます。リリース 3.0 以前のスイッチ ソフトウェアでは、conn、alarm、および conn update ファイルが AXSM ごとにアップロードされます。2 番めのリストのファイル 4 ~ 7 はRPM-XF カードごとにアップロードされ、ファイル 11 はスイッチのすべての RPM/RPM-PR カードに対してアップロードされます。

ステップ 8 ノード モードが長期間 2 のままである別の事例では、特定のコンフィギュレーション アップロード ファイルの解析時間に時間がかかっていて、完了していません。解析プロセスを表示するには、次のコマンドを入力します。

tail -f <ooemc_log_file>
 

ステップ 9 /opt/svplus/log ディレクトリから ooemc、nts、snmpcomm、および cwmftpd ログ ファイルを収集します。


 

有効な代替対処法 -- なし

K.12.4.5 ノード再同期モードが 5 である

ノード モードが 5 の場合は、ノード再同期に失敗しています。この原因として考えられるのは、シェルフ汎用ファイル(CARD_01_CC.CF.13 など)または pnni ファイル(PNNI_01_CC.CF.13 など)のコンフィギュレーション アップロードまたは解析の障害です。一般に、モード 5 は再同期プロセス全体の 1 つまたは複数のステージで問題が発生したことを示します。再同期プロセスは次のステージで構成され、各ステージがモード 5 問題の原因になる可能性があります。

1. ooemc がノード再同期をトリガーします。

2. ooemc がバルク ファイル作成を求める SNMP 要求をスイッチに送信します。

3. ooemc がバルク ファイル作成関連トラップを受信します(60901、60902、および 60903)。

4. 60901 および 60902 をスイッチから受信したあとに、ooemc がスイッチのコンフィギュレーション アップロード ファイルを FTP 転送します。

5. ooemc がコンフィギュレーション アップロード ファイルを解析します。

6. ooemc が同期アップの完了を宣言します。


ステップ 1 問題の原因が SNMP 要求であるかどうかを判別します。

a. ooemc ログ ファイル内で RESYNC を grep 検索します。ooemc はノード 再同期プロセスを開始するときに、ノード モードを 2 に変更します。ログの次のような情報が表示されます。

NOTICE: N17 <EMC_Node_c::InSync> SENDING RESYNC STATUS 2 FOR NODE 17 TO GUI - Node is synchronizing.
 

このメッセージは、ID が17(N17)のノードで ooemc がノード再同期プロセスを開始したことを示します。さらにログを調べる場合は、SNMP 要求および SNMP 応答に関連するログ メッセージを参照します。SNMP 要求に成功すると、スイッチは要求に応答します。ooemc は応答機能を起動して、SNMP 応答を処理します。この機能は何も実行しないことがあります。

<EMC_SnmpFunc_c::ProcFunc_GenNodeBulkFile_1> entering
 

b. ログ メッセージが SNMP エラーを示している場合は、snmpcomm ログ ファイルで障害の詳細を参照してください。

ステップ 2 問題の原因が バルク作成トラップであるかどうかを判別します。ログ ファイル内で 60901、60902、および 60903 を grep 検索します(詳細はノード モードが 1 のままである を参照)。次のような情報が表示されます。

INFO: <EMC_TrapClientImpl::onIncomingTrap> NTS NodeId 17 genericTrap 6 specificTrap 60901
INFO: <EMC_TrapClientImpl::onIncomingTrap> NTS NodeId 17 genericTrap 6 specificTrap 60902
 

ステップ 3 問題の原因がコンフィギュレーション ファイルの FTP であるかどうかを判別します。FTP、または FTP とコンフィギュレーション アップロード ファイル名を調べます。次のような情報が表示されます。

NOTICE: N17 <EMC_NodeFsmHandler_c::LoadShelf> to ftp /opt/svplus/tmp/CARD_01_CC.CF.17
INFO: <ParseFile_c::CheckFile> OOEMC9 CHECKSUM OK FOR FTP FILE /opt/svplus/tmp/CARD_01_CC.CF.17
 

これらのメッセージは、FTP に成功し、ファイルにチェックサム エラーがないことを示します。ログ ファイルから、FTP 問題があるかどうかを判別できます。障害の詳細については、cwmftpd ログ ファイルを参照してください。

ステップ 4 問題の原因がシェルフ汎用ファイルまたは pnni ファイルの解析であるかどうかを判別します。シェルフ汎用ファイル(CARD_01_CC.CF.17 など)または pnni ファイル(PNNI_01_CC.CF.17 など)のチェックサム チェックの実行場所を特定し、引き続きログ メッセージをトレースして、解析エラーが発生したかどうかを確認します。エラーがない場合は、次のように表示されます。

INFO: N17 <EMC_NodeFsmHandler_c::FinishShelf> Parse /opt/svplus/tmp/CARD_01_CC.CF.17 successfully.
 


 

障害情報:

/opt/svplus/log ディレクトリから ooemc、nts、snmpcomm、および cwmftpd ログ ファイルを収集します。

/opt/svplus/tmp ディレクトリからコンフィギュレーション アップロード ファイルを収集します。

有効な代替対処法 -- なし

K.12.4.6 コールドスタート(CTM サーバの停止/開始)または定期的再同期の成功後に CTM データベースとスイッチ データが一致しない

定期的再同期によってトリガーされたノード再同期に成功したあとに、CTM データベースはスイッチ データと一致しなくなります。


ステップ 1 ooemc ログ ファイル、およびノードに対応するすべてのコンフィギュレーション アップロード ファイルを収集します。ooemc にはノードベース キャッシュが実装されています。キャッシュをダンプして、保存できます。

ステップ 2 ノードを管理する ooemc プロセスのプロセス ID を取得します。

ステップ 3 コンフィギュレーション アップロード ファイルおよび ooemc ログ ファイルを保存します。


 

障害情報 -- /opt/svplus/log ディレクトリから ooemc およびコンフィギュレーション アップロード ファイルを収集します。

有効な代替対処法:ノードを手動で再同期します。それでも問題が解決しない場合は、コールドスタートを実行します。まだ問題が解決されない場合は、ログ ファイルを収集して、問題を報告します。

K.12.4.7 ノード再同期および dbroker 同期アップに成功したあとで CTM CM GUI に不完全な接続が表示される

ノード再同期プロセスおよび dbroker 同期プロセスのあとに、CTM に、一部の接続が不完全であることが表示されます。


ステップ 1 ノードを管理する ooemc プロセスを判別します。この ooemc は MGX で終端する接続セグメントを CTM データベース内で管理します。ノードを管理する ooemc プロセスの子 ID を検索します。ooemc プロセスの子 ID を検索する目的は、検査用の正しい ooemc ログ ファイルを見つけることです。この問題のデバッグ プロセスでは、主にログ ファイルを検査します。

ステップ 2 ooemc ログ ファイルを識別したら、ファイル内で NotifyDataBroker を grep 検索し、ログ メッセージの例をいくつか参照してから、grep フォーマットを変更します。このようにすると、接続セグメントの 1 つのエンドポイント(プライマリ エンドポイントまたはセカンダリ エンドポイント)のローカル側およびリモート側に対応するログ メッセージ ペアに grep 検索を効率的に実行できます。つまり、ooemc で管理される接続セグメントのそれぞれの側(プライマリ側またはセカンダリ側)に、1 組のメッセージ(ローカル側とリモート側に 1 つずつ)が記録されてる必要があります。このメッセージ ペアは、データベース内の atm_connection セグメント エントリに対応します。ooemc から dbroker に送信された情報を確認します。dbroker は ooemc から送信されたこれらのメッセージを参照して、user_connection データベース エントリを構築します。CTM Connection Management(CM)GUI には、user_connection データベース エントリに基づく接続情報が表示されます。接続が完全であると表示されるか、または不完全であると表示されるかは、user_connection データベース エントリの情報によって決まります。ooemc が dbroker に正しい情報を送信したか確認することが重要です。セグメント データベース エントリが正しく読み込まれていることも確認してください。

ステップ 3 dbroker に正しい個数のメッセージが転送され、メッセージ内のデータが正しいにもかかわらず、user_connection データベース エントリに無効なデータが含まれる場合は、「データの不整合」で詳細なデバッグ情報を参照するか、または dbroker Development Engineer(DE)に問い合わせてさらに調査してください。セグメント データベース エントリに読み込まれたデータが不正であるために問題が発生した場合は、EM DE によって問題が調査されます。


 

障害情報:

/opt/svplus/log ディレクトリの ooemc および nts ログ ファイルを収集します。

/opt/svplus/tmp ディレクトリからコンフィギュレーション アップロード ファイルを収集します。

有効な代替対処法は、手動でノードを再同期することです。それでも問題が解決しない場合は、コールドスタートを実行します。まだ問題が解決されない場合は、ログ ファイルを収集して、問題を報告します。

K.12.4.8 CTM GUI に GUI ビューとデータベース データの情報が一致しないと表示される

コールドスタート プロセスなどの初期 ooemc ノード再同期が終了すると、Network Monitor ツリー ビュー、Inspector View、Chassis View などの GUI ビューに、新規にプロビジョニングされたデータベース データまたは更新されたデータベース データが一致しないという情報が表示されます。この問題は、あとで手動再同期または定期的再同期を実行しても存続します。


ステップ 1 ノードを管理している ooemc プロセスを判別し、そのプロセスの子 ID を検索します。ooemc プロセスの子 ID を検索する目的は、検査用の正しい ooemc ログ ファイルを見つけることです。この問題のデバッグ プロセスでは、主にログ ファイルを検査します。

ステップ 2 コールドスタートなどの初期ノード再同期を開始します。ooemc は新規にプロビジョニングされたデータベース データまたは更新されたデータベース データを Network Management(NM)サーバに送信し始めます。NM サーバのメッセージ転送のために現在サポートされているデータベース テーブルは、次のとおりです。

node

card

line

ausm_port

cesm_port

frp

rpm_port

svc_port

virtual_port

aps

ima_group

ima_link

linedistribution

au4tug3

controller

license_in_use

mfr_bundle

mfr_link

peripheral

redundantcard

sensor

ステップ 3 新規にプロビジョニングされたデータベース データまたは更新されたデータベース データが ooemc から NM サーバに送信されたかどうかを判別するには、ooemc ログ ファイル内で ComposeNMSMsg を grep 検索します。ステップ 2 のサポート対象データベース テーブルに対応するログ メッセージ内のキーワードは、次のとおりです。

EMC_DBProperty_Node_c::ComposeNMSMsg

EMC_DBProperty_Card_c::ComposeNMSMsg

EMC_DBProperty_Line_c::ComposeNMSMsg

EMC_DBProperty_AusmPort_c::ComposeNMSMsg

EMC_DBProperty_CesmPort_c::ComposeNMSMsg

EMC_DBProperty_FrPort_c::ComposeNMSMsg

EMC_DBProperty_RpmPort_c::ComposeNMSMsg

EMC_DBProperty_SvcPort_c::ComposeNMSMsg

EMC_DBProperty_VtPort_c::ComposeNMSMsg

EMC_DBProperty_Aps_c::ComposeNMSMsg

EMC_DBProperty_ImaGroup_c::ComposeNMSMsg

EMC_DBProperty_ImaLink_c::ComposeNMSMsg

EMC_DBProperty_LineDist_c::ComposeNMSMsg

EMC_DBProperty_AU4TUG3_c::ComposeNMSMsg

EMC_DBProperty_Ctrlr_c::ComposeNMSMsg

EMC_DBProperty_LicenseInUse_c::ComposeNMSMsg

EMC_DBProperty_MfrBundle_c::ComposeNMSMsg

EMC_DBProperty_MfrLink_c::ComposeNMSMsg

EMC_DBProperty_Peripheral_c::ComposeNMSMsg

EMC_DBProperty_RedCard_c::ComposeNMSMsg

EMC_DBProperty_Sensor_c::ComposeNMSMsg


) 初期ノード再同期中は、データベース データが NMServer に送信されません。ooemc が更新されたデータベース データまたは新規にプロビジョニングされたデータベース データを NMServer に送信するのは、初期再同期のあとです。grep で検索された各 ooemc ログ メッセージには、NE オブジェクトの ID に関する詳細、および対応するデータベース テーブルの必須フィールドが含まれています。次に、line テーブルの NMServer メッセージの例を示します。


ooemc10.24370.log.old.5:( 24370: 4) 23:15:17 INFO: N0:C7:B2:L2 <EMC_DBProperty_Line_c::ComposeNMSMsg> (MODIFY::LINE) aNMSEvent.node:0 type:4 subType:1 lpbkType:1 alarmState:1 adminState:1 sectStatus:6 pathState:2
 

この例では、NE オブジェクトの ID は N0:C7:B2:L2 です(ノード ID=0、スロット =7、ベイ =2、行番号 =2)。データベースの処理は更新です。メッセージの残りは、line テーブルの必須フィールドの値を示します。

ステップ 4 grep によって、データが一致することを示すログ メッセージが検索された場合は、NM サーバで調査を継続する必要があります。nmController の詳細については、「CTM Configuration Center、Chassis View、Diagnostics Center、または Statistics Report の基本」 を参照してください。


 

障害情報 -- /opt/svplus/log ディレクトリから ooemc および NMServer ログ ファイルを収集します。

有効な代替対処法 -- ノードを手動で再同期します。それでも問題が解決しない場合は、コールドスタートを実行します。まだ問題が解決されない場合は、ログ ファイルを収集して、問題を報告します。

K.12.4.9 MGX のノード プロビジョニング後に CTM データベースおよびスイッチ データが一致しない問題が発生する

ここで説明する内容は、次のとおりです。

「トラップおよび SNMP アップロードによるデータベース テーブルの読み込み」

「ノード プロビジョニング後にスイッチ データと CTM データベース テーブルが一致しない」

K.12.4.9.1 トラップおよび SNMP アップロードによるデータベース テーブルの読み込み

ノードまたはカードの再同期以外の、CTM ooemc がデータベース テーブル エントリの読み込みに使用する別のメカニズムでは、トラップ処理後に、必要に応じて SNMP アップロードを実行します。スイッチをプロビジョニングするには、スイッチ CLI、CTM GUI、または CTM サーバ エージェントを使用します。どの場合も、ooemc でトラップ処理および SNMP アップロードを実行します。CTM CM GUI でプロビジョニングできるのは、接続のみです。回線やポートなどその他のプロビジョニングには、CTM サービス エージェントを使用する必要があります。MGX スイッチの CLI はすべての処理を実行できます。

K.12.4.9.2 ノード プロビジョニング後にスイッチ データと CTM データベース テーブルが一致しない

スイッチ CLI、CTM GUI、または CTM サーバ エージェントを使用してスイッチをプロビジョニングしたあとに、スイッチ データと CTM データベースが一致しません。


ステップ 1 ログ ファイルを調べて、不一致問題の根本原因を突き止めます。問題の原因がトラップである場合(たとえば、スイッチで、あるいは CTM GUI やサービス エージェントを介して接続をプロビジョニングした場合、CTM はデータベース エントリを読み込まないか、またはデータベース エントリ内の情報がスイッチ データと一致しません)、CTM がトラップを受信しなかったか、トラップを受信したにもかかわらずトラップが ooemc トラップ キューにバッファリングされて、トラップ処理が遅延した可能性があります。一方、CTM データベース内のデータが間違っている場合は、SNMP アップロードで正しいデータをアップロードできなかった可能性もあります。

ステップ 2 トラップが受信されて処理されたかどうかを判別するために、ooemc ログ ファイルには grep 検索可能なキーワードがあります。たとえば、node_id=4、スロット =6、vpi=1、および vci=326 からのチャネル トラップを検索するには、次の例のように「TRAPLIST」を grep 検索します。

cwmult60% grep "TRAPLIST: N4:" ooemc* | grep "Channel Trap" | grep "C6" | grep "vpi 1 vci 326"
ooemc10.5760.log.old.55:( 5760: 10) 23:21:12 INFO: TRAPLIST: N4: Channel Trap 60310 from C6 B2 L1 P20 Ch299 ifIndex 17176597 vpi 1 vci 326 upCntr 0 vpcFlag 2 operS 1 alarm 67
ooemc10.5760.log.old.55:( 5760: 10) 23:21:12 INFO: TRAPLIST: N4: Channel Trap 60310 < PROCESSED > from C6 B2 L1 P20 Ch299 ifIndex 17176597 vpi 1 vci 326 upCntr 0 vpcFlag 2 operS 1 alarm 67
ooemc10.5760.log.old.73:( 5760: 10) 23:23:48 INFO: TRAPLIST: N4: Channel Trap 60310 from C6 B2 L1 P20 Ch299 ifIndex 17176597 vpi 1 vci 326 upCntr 0 vpcFlag 2 operS 1 alarm 66
 

その他の種類のトラップには、次のキーワードを使用して、grep ステートメントの「TRAPLIST」を補足できます。

Port Trap

RscPart Trap

Svc Trap

SonetLn Trap

SctCard Trap

SonetPath Trap

FunMod Trap

LineMod Trap

RedCard Trap

TrapMiss Trap

VsiCtrlr Trap

DS3Line Trap

AtmPhy Trap

Peripheral Trap

CoreSwth Trap

TrapLost Trap

AtmAddr Trap

Restart Trap

Node Trap

SonetAps Trap

LMIPort Trap

Pnni IF Trap

Bulkfile Trap

Vism Trap

Vism Ann Trap

SubIf Trap

NBSMCnfg Trap

NBSMChan Trap

NBSMLine Trap

AusmLine Trap

AusmPort Trap

AusmChan Trap

AusmIma Trap

FrChan Trap

FrPort Trap

CesmPort Trap

CesmChan Trap

HsFrPort Trap

HsFrChan Trap

LineDist Trap

DS3Path Trap

Chan Upload

Party Trap

PrefRoute Trap

CardIma Trap

DS1 Line Trap

SctPort Trap

SvcDerouteGroomTrap

Channel Trap

TUG3Path Trap

Cug Trap

AddrCug Trap

RSC Upload

APS Upload

FrPort State Upload

MPSM Upload

Vism ToneDetect Trap

License Trap

PortAtmIf Trap

VxsmPvcRed Trap

ChanProt Trap

VxsmGwDsp Trap

VxsmGwIp Trap

VxsmGw Trap

VxsmSysRes Trap

VxsmGw1 Trap

VxsmMgc Trap

VxsmMgcIp trap

VxsmMgcGrpParam Trap

VxsmMgcGrpMgc Trap

VxsmMgcGrpProt Trap

VxsmAal2Prof Trap

VxsmCodec Trap

VxsmSvc Trap

VxsmAal2CrossConn Trap

VxsmAal25DataProfileTrap

VxsmSensor Trap

VxsmSensorThrhd Trap

VxsmModule Trap

DS0Grp Trap

VxsmAnnounce Trap

VxsmAudioFile Trap

VxsmDs0XConn Trap

VxsmMegaco Trap

VxsmCrr Trap

VxsmTone Trap

VxsmAs Trap

VxsmAsp Trap

VxsmAs Trap

VxsmLapd Trap

VismABCDBitTemplate Trap

traplist コマンドを使用してログ メッセージを調べ、必要に応じてメッセージの grep 検索方法を決定します。上記の例では、トラップが処理されたことを示す別のキーワード(「PROCESSED」)があります。このキーワードは、ログ メッセージを調査できるログ ファイルの開始点を指定します。データベースが正しく読み込まれていない場合は、以降のログ メッセージに、データベースの不一致問題に関する情報が記載されます。SNMP データ アップロードを起動するトラップ処理もあります。ログ メッセージから、アップロードされたデータが正しいかどうかを確認できます。データベースに不一致が生じるその他の理由として考えられるのは、次のとおりです。

SNMP アップロード障害および最大再試行回数を超過しています。SNMP がタイムアウトするか、スロットル エラーが発生しました。snmpcomm ログ ファイルに問題がないか確認してください。

データベース処理中にエラーが発生しました。ooemc ログ ファイルに問題がないか確認してください。

スイッチから CTM に送信されたトラップ シーケンスが正確にわからない場合は、現用シナリオを実行して、ログ内でトラップ シーケンスを調べる必要があります。あるいは、HPOV を使用してトラップ シーケンスを判別できます。

ステップ 3 スイッチからトラップが着信して ooemc に転送されたかどうかを確認するには、nts ログを参照します。トラップ キューにトラップがバッファリングされている場合は、次の理由が考えられます。

定期的なノード再同期または -2 トラップが原因で、ノードが同期しています。

カードが同期していて、トラップがカードに関連しています。カード再同期が完了するまで、トラップはキューにバッファリングされます。

サマリー アラーム トラップが処理されています。サマリー アラームがアップロードまたは解析されています。ログ ファイルで、サマリー アラーム トラップに関連する情報を grep 検索できます。

トラップがキューに格納されたことを確認するには、次の処理を実行します。

grep EMC_TrapQueue_c::append ooemc_log | grep trap_num
 

次のような情報が表示されます。

INFO: <EMC_TrapQueue_c::append> entering. ======> append trap# 60303 to trap queue; getHdlrLevel=5, getTrapLevel=5, #=174
 


 

障害情報 -- /opt/svplus/log ディレクトリから ooemc、nts、および snmpcomm ログ ファイルを収集します。

有効な代替対処法 -- ノードを手動で再同期します。それでも問題が解決しない場合は、コールドスタートを実行します。まだ問題が解決されない場合は、ログ ファイルを収集して、問題を報告します。

K.12.5.1 CTM Configuration Center、Chassis View、Diagnostics Center、または Statistics Report の基本

CTM は MGX NE を管理します。トポロジー モジュールはノードおよびトランクを検出します。ノードが検出されると、EM モジュールはノードと同期して、カード、回線、ポートなどを検出します。検出されたすべてのノード、トランク、およびノード要素は NMServer からパブリッシュされ、Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示されます。Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にはツリー ビューおよび Inspector View があります。ツリー ビューおよび Inspector View には、NMserver からパブリッシュされたデータが表示されます。

CTM にはトラップを介して、ネットワーク内の以降の変更がすべて通知されます。

次の図は、エンドツーエンド アーキテクチャを示します。

図K-1 CTM エンドツーエンド アーキテクチャ

 

NMServer は、Configuration Center、Chassis View、Diagnostics Center、または Statistics Report 用のインベントリおよびアラーム情報を提供します。ノード情報は topod によって NMServer にプッシュされます。カード、回線、ポートなどの初期インベントリは、データベースから読み取られます。動的アップデートは topod、ooemc、および sdbroker から NMServer にプッシュされます。

NMServer の問題をデバッグするために CTM に付属しているユーティリティは、/opt/svplus/util/ ディレクトリ内にあります。

nmControl -- このユーティリティは NMServer のキャッシュおよび状態を調べます。出力は /opt/svplus/log/nmControl.log に、キャッシュ ダンプは /opt/svplus/log/nmControl.dump にリダイレクトされます。このユーティリティを使用すると、パッシブ モードでタスクを実行する以下の無害な処理が可能になります。


) ノード数が 1000 を超える大規模ネットワークのキャッシュをダンプする場合は、All Cache 処理を使用しないでください。


Resync Node -- ノード(node_id で指定)を再同期します。

All Cache -- キャッシュ内のすべてのデータをダンプ ファイルにダンプします。

Topology Cache -- トポロジー(ノード)データをダンプ ファイルにダンプします。

Node Cache -- ノードのデータ(node_id で指定)をダンプ ファイルにダンプします。

CTM Alarm Cache -- CTM 固有のアラームをダンプ ファイルにダンプします。

Client Manager Cache -- すべてのクライアントに関する情報をダンプ ファイルにダンプします。

Error Statistics -- 同期アップに対応するエラー情報をダンプ ファイルにダンプします。

Sync-Up Status -- 同期アップ状態をダンプ ファイルにダンプします。

Configuration -- 設定データをダンプ ファイルにダンプします。

nmClient -- このユーティリティは、問題をクライアントとサーバに分離する場合に使用します。Configuration Center、Chassis View、Diagnostics Center、または Statistics Report GUI がサーバに問い合わせるのと同じ方法で、NMServer に問い合わせる場合に使用します。出力は /opt/svplus/log/nmClient.log に、キャッシュ ダンプは /opt/svplus/log/nmClient.dump にリダイレクトされます。

他の処理を実行する前に、Register Client 処理を実行する必要があります。クライアントの使用を終了したら、Unregister Client 処理を実行します。

Register Client -- サーバに登録します。

Update Filter -- FDN の送信元サーバでサブスクリプション/フィルタを更新します。

Unregister Client -- サーバから登録を解除します。

Get Topology -- ネットワークおよびノードのトポロジー情報を取得します。

Get Children -- ツリー内の特定のオブジェクトの子のリストを取得します。

Get CwmInfo -- CTM 同期アップ状態情報を取得します。

Get ManagedObject -- ツリー内のオブジェクトに関する詳細情報を取得します。

Subscribe for all events -- サーバのすべてのアップデートにサブスクライブします。

Unsubscribe for all event -- サーバのすべてのアップデートに対してサブスクライブを解除します。

GUI クライアントのログ ファイル(CMSCclient.log)はログ ディレクトリに保存されます。たとえば、Windows の場合は D:Documents and Settings\<username>\log\、UNIX の場合は /opt/svplus/log に保存されます。

K.12.5.2.1 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にどのノードも表示されない


ステップ 1 ノードが検出されているかどうかを調べます。「ノードが検出されない」 を参照してください。

ステップ 2 NMServer のキャッシュにノードおよびトランクが格納されているか調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 3 NMServer キャッシュにノードが格納されている場合は、新しい GUI を開いて、ノードが表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法 -- 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report GUI を開きます。

K.12.5.2.2 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report からサーバに接続できない


ステップ 1 NMServer.log でクライアントが登録されているかどうかを調べます。

ステップ 2 /opt/svplus/log/ ディレクトリに orbix ディレクトリを作成して、orbix ログをイネーブルにします。


 

障害情報 -- 次の情報を収集して、さらに分析します。

CMSCclient.log、NMServer.log

orbix ログ

有効な代替対処法 -- なし

K.12.5.2.3 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に新規に追加されたノードが表示されない


ステップ 1 ノードが検出されているかどうかを調べます。詳細については、「ノードが検出されない」 を参照してください。

ステップ 2 NMServer のキャッシュにノードが格納されているか調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 3 NMServer キャッシュにノードが格納されている場合は、新しい GUI を開いて、ノードが表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法 -- 新しい GUI を開きます。

K.12.5.3 トポロジー検出の問題

ここで説明する内容は、次のとおりです。

「Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に特定のノードが表示されない」

「Configuration Center、Chassis View、Diagnostics Center、または Statistics Report のノード情報が正しくない」

「Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にネットワークに存在しないノードが表示される」

「Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示されるノードの同期状態が正しくない」

「Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示されるノードが重複している」

K.12.5.3.1 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に特定のノードが表示されない


ステップ 1 ノードが検出されているかどうかを調べます。詳細については、「ノードが検出されない」 を参照してください。

ステップ 2 NMServer のキャッシュにノードが格納されているか調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 3 NMServer キャッシュにノードまたはトランクが格納されている場合は、新しい GUI を開いて、ノードが表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法 -- 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

K.12.5.3.2 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report のノード情報が正しくない


ステップ 1 selnd コマンドを使用して、データベースのノード情報を調べます。

ステップ 2 NMServer のキャッシュ内のノード情報を調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 3 CMSCclient.log でノード情報を検索します。

ステップ 4 nmClient の getTopology オプションを使用してノード情報を取得し、この情報がデータベースおよび GUI と一致するかどうかを確認します。

ステップ 5 NMServer キャッシュ内のノード情報が正しい場合は、新しい GUI を開いて、ノードが正しく表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

selnd o/p

nmControl.dump

CMSCclient.log

有効な代替対処法 -- 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

K.12.5.3.3 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にネットワークに存在しないノードが表示される


ステップ 1 ノードに packet_line テーブルを問い合わせて、データベースのノード情報を調べます。ノードがアクティブかどうかを確認します。

ステップ 2 ノードがアクティブでない場合は、「ノードが検出されない」 を参照してください。

ステップ 3 NMServer のキャッシュ内のノードを調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 4 CMSCclient.log でノード/トランクを検索します。ノードに対する削除メッセージが受信されたかどうかを確認します。

ステップ 5 nmClient の getTopology オプションを使用して、ノード情報を取得し、この情報がデータベースおよび GUI と一致するかどうかを確認します。

ステップ 6 NMServer キャッシュ内にノードが存在しない場合は、新しい GUI を開いて、ノードが表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log、topod.log、および NMServer.log

ILMITopoc、topod、および NMServer のダンプ出力。ダンプをキャプチャするには、kill -USR1 信号をプロセスに送信します。

スイッチ CLI、selnd、および dbnds の出力

K.12.5.3.4 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示されるノードの同期状態が正しくない


ステップ 1 ノード テーブルを問い合わせて、データベースのノード情報を調べます。そのためには、CTM CLI でコマンド selnd を使用します。ステータスを確認します。

ステップ 2 NMServer のキャッシュ内のノードを調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 3 CMSCclient.log でノードを検索します。ノードに対する正しいメッセージが受信されたかどうかを確認します。

ステップ 4 nmClient の getTopology オプションを使用してノード情報を取得し、この情報がデータベースおよび GUI と一致するかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

ILMITopoc.log、topod.log、および NMServer.log

ILMITopoc、topod、および NMServer のダンプ出力。ダンプをキャプチャするには、kill -USR1 信号をプロセスに送信します。

スイッチ CLI、selnd、および dbnds の出力

K.12.5.3.5 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示されるノードが重複している


ステップ 1 ノード テーブル内に重複するノード ID があるかどうかを調べます。

ノード テーブルの問い合わせには、次のコマンドを使用します。

tballraker18% echo "select (*) from node where node_id=2 and slot=1" | dbaccess stratacom
 

ステップ 2 データベース内の両方のノードがアクティブ(1)であるかどうかを確認します。両方のノードがアクティブな場合は、ログを収集します。

ステップ 3 データベースに重複ノードがない場合は、nmControl を使用して NMServer のキャッシュを調べます。

ステップ 4 CMSCclient.log でノードを検索します。

ステップ 5 nmClient の getTopology オプションを使用してノード情報を取得し、この情報がデータベースおよび GUI と一致するかどうかを確認します。

ステップ 6 NMServer キャッシュ内に重複ノードが存在しない場合は、新しい GUI を開いて、ノードが表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log の CMSCclient.log ファイル。PC クライアントの場合は、D:\Documents and Settings\<username>\log の CMSCclient.log ファイルを収集します。

特定のノードのノード テーブルのノード データ

ILMITopoc.log および topod.log(データベースに重複ノードがある場合)

有効な代替対処法 -- なし

K.12.5.4.1 ノードのすべてのカードが表示されない

Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にノードのカードがまったく表示されません。


ステップ 1 ノードが同期しているかどうかを確認します。そのためには、CTM CLI でコマンド selnd を使用します。

ステップ 2 ノードが同期していない場合は、同期するまで待機します。

ステップ 3 ノードが同期している場合は、カード テーブルにカードが読み込まれているかどうかを調べます。カード テーブルが空の場合は、EM ログを収集します。詳細については、「機器管理の問題」 を参照してください。

ステップ 4 NMServer のキャッシュにカードが格納されているか調べます。そのためには、CTM CLI でコマンド nmControl を使用します。

ステップ 5 NMServer キャッシュにカードが格納されていない場合は、ログを収集します。

ステップ 6 NMServer キャッシュにカードが格納されている場合は、nmClient を使用し、ノードの FDN に関する getChildren によって nmClient.<pid>.dump ファイルに目的のカードが戻されるかどうかを確認します。

ステップ 7 NMServer キャッシュにカードが格納されている場合は、新しい GUI を開いて、カードが表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法:

1. 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

2. nmControl を使用し、ノード ID を指定して「Resync Node」を実行します。

K.12.5.4.2 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report にノードのカード、回線、またはポートが表示されない


ステップ 1 ノードが同期しているかどうかを確認します。そのためには、CTM CLI でコマンド selnd を使用します。

ステップ 2 ノードが同期していない場合は、同期するまで待機します。

ステップ 3 ノードが部分的に同期している場合は、カード、回線、またはポートがデータベースに読み込まれているかどうかを調べます。『Cisco Transport Manager Release 7.0 Database Schema』を参照してください。

ステップ 4 データベースにエントリが読み込まれていない場合は、「機器管理の問題」 を参照してください。

ステップ 5 データベースにエントリが存在する場合は、NMServer キャッシュを調べます。そのためには、CTM CLI でコマンド nmControl を使用します。nmControl.<pid>.dump を調べます。

ステップ 6 NMServer キャッシュに目的の要素が格納されていない場合は、nmClient を使用し、FDN に関する getChildren によって nmClient.<pid>.dump ファイルに目的のエンティティが戻されるかどうかを確認します。

ステップ 7 NMServer キャッシュに目的の要素が格納されている場合は、新しい GUI を開いて、表示されなかった要素が表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法:

1. 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

2. nmControl を使用し、ノード ID を指定して「Resync Node」を実行します。

K.12.5.4.3 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report のカード、回線、またはポート情報が正しくない

Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に表示される要素のエンティティ情報が正しくありません。


ステップ 1 ノードが同期しているかどうかを確認します。そのためには、CTM CLI でコマンド selnd を使用します。

ステップ 2 ノードが同期していない場合は、同期するまで待機します。

ステップ 3 カード、回線、またはポートがデータベースに読み込まれているかどうかを調べます。『Cisco Transport Manager Release 7.0 Database Schema』を参照してください。

ステップ 4 データベース内のエントリが GUI と一致する場合は、「機器管理の問題」 を参照してください。

ステップ 5 エントリがデータベースと一致しない場合は、NMServer キャッシュを調べてます。そのためには、CTM CLI でコマンド nmControl を使用します。nmControl.<pid>.dump を調べます。

ステップ 6 nmClient を使用し、FDN に関する getChildren によって nmClient.<pid>.dump ファイルに目的の要素に関する正しい情報が戻されるかどうかを確認します。

ステップ 7 NMServer キャッシュに目的の要素が格納されている場合は、新しい GUI を開いて、表示されなかった要素が表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法:

1. 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

2. nmControl を使用し、ノード ID を指定して「Resync Node」を実行します。

K.12.5.4.4 Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に、ノードにないカード、回線、またはポートが表示される

Configuration Center、Chassis View、Diagnostics Center、または Statistics Report に余分なカード、回線、またはポート要素が不正に表示されます。


ステップ 1 ノードが同期しているかどうかを確認します。そのためには、CTM CLI でコマンド selnd を使用します。

ステップ 2 ノードが同期していない場合は、同期するまで待機します。

ステップ 3 カード、回線、またはポートがデータベースに読み込まれているかどうかを調べます。『Cisco Transport Manager Release 7.0 Database Schema』を参照してください。

ステップ 4 データベース内の目的の要素が格納されているにもかかわらず、GUI の表示内容と一致しない場合は、「機器管理の問題」を参照してください。

ステップ 5 データベースに要素が格納されていない場合は、NMServer キャッシュを調べます。そのためには、CTM CLI でコマンド nmControl を使用します。nmControl.<pid>.dump を調べます。

ステップ 6 nmClient を使用し、FDN に関する getChildren によって nmClient.<pid>.dump ファイルに目的の要素が戻されるかどうかを確認します。

ステップ 7 NMServer キャッシュに目的の要素が格納されていない場合は、新しい GUI を開いて、余分な要素が表示されるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

topod.log、ILMITopoc.log、NMServer.log

nmControl.dump

CMSCclient.log

有効な代替対処法:

1. 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report GUI を開きます。

2. nmControl を使用し、ノード ID を指定して Resync Node を実行します。

K.12.5.5.1 アラーム処理の基本

アラーム処理は NMServer プロセス内で実行されます。次に、アラーム処理に関する重要事項をいくつか示します。

アラーム規則は XML ファイル(/opt/svplus/xml/ruledata.xml)で定義されます。XML スキーマ アラーム規則の詳細については、図K-2 を参照してください。

GUI クライアントは親 FDN を提供して、アラームを登録します。

GUI クライアントは NMServer から初期アラームをプルします。アラームを最初にプルしたあとに発生したすべてのアラームは、NMServer から登録済みクライアントにプッシュされます。

任意の、およびすべてのネットワーク要素のオブジェクト重大度は、XML アラーム規則で判別されます。

アラーム リストにはネットワーク要素のアラーム状態のみが表示され、ネットワーク要素の管理状態は表示されません。

アラーム リストには通常アクティブなアラームが表示されますが、一部のイベントも表示されます。イベントとアラームの詳細については、「アラーム規則の XML スキーマ」 を参照してください。

アラームによっては、ネットワーク要素に実際のアラームと異なるアラーム重大度が設定されることがあります。オブジェクト重大度とアラーム重大度の詳細については、「アラーム重大度とオブジェクト重大度」 を参照してください。

各ネットワーク要素のアラームは、NMServer Object Tree のメモリ キャッシュに格納されます。GUI クライアントはアラーム対象となるネットワーク要素の FDN を提供して、NMServer からのアラームを登録します。登録されている FDN のネットワーク要素のすべてのアラームは、親 FDN が登録されている場合、送信されます。アラームに確認応答済みのフラグを設定したり、手動でアラームを消去することにより、GUI クライアントからアラームを更新することもできます。これらの更新には、NMServer の Alarm Repository コンポーネントを使用します。次の図に、NMServer のアラーム コンポーネントのクライアント/サーバ アーキテクチャを示します。

図K-2 アラーム コンポーネントのクライアント/サーバ アーキテクチャ

 

K.12.5.5.2 アラーム規則の XML スキーマ

アラーム規則は XML、特にファイル $HOME/xml/ruledata.xml で定義されます。これらのアラーム規則は、NMServer の開始時に一回読み込まれます。イベントが処理されるときに、メモリからアラーム規則が照会されて、イベント時に実行されるアラーム関連のアクションが判別されます。XML スキーマで定義されるアラーム規則には、Correlated、Correlated Bitmap、および Transient の 3 つのタイプがあります。これらの 3 つのタイプの仕様はそれぞれ、次のようになります。

1. Correlated アラーム規則タイプ

Correlated アラーム規則タイプは、ruledata.xml 内の最も一般的な規則タイプです。この規則は、ネットワーク要素が複数ある状態のうち、一度に 1 つの状態しかとることができない場合に使用します。エンティティによって状態が変更された場合は、以前のアラーム状態が消去されます。CTM で管理されるほとんどのネットワーク要素は、このカテゴリに分類されます。単純な例は、ノードのデータベース同期アップ ステータスです。同期アップ ステータスは Partial Sync-Up、Sync-Up Failed、または In Sync のうちのいずれかとなります。これらのそれぞれの状態は相互に関係しています。次の図を参照してください。

図K-3 Correlated アラーム規則図

 

CorrelatedRule には以下のアラームが含まれます。

1 つの AlwaysClear(最上位ネットワークなど、所定の要素にアラームがない場合に使用)

0 個以上の ClearAlarmCondIds

1 つの新規アラーム(NewAlarmConditionID、NewAlarmServAffect などで構成)

2. Correlated Bitmap アラーム規則タイプ

Correlated Bitmap アラーム規則タイプは Correlated アラーム規則タイプと異なり、エンティティが任意の時刻にとることができる多くの状態を表すことができます。Correlated Bitmap 規則タイプは、主に回線アラームを表す場合に使用します。回線にはいつでも、Loss of Signal(LOS; 信号損失)や Loss of Frame(LOF; フレーム損失)など複数のアラームを対応付けることができます。次の図を参照してください。

図K-4 Correlated Bitmap アラーム規則図

 

CorrelatedBmRule には以下のアラームが含まれます。

0 個以上の ClearAlarmCondIds

1 つの新規アラーム(NewAlarmConditionID、NewAlarmServAffect などで構成)

3. Transient アラーム規則タイプ

Transient アラーム規則タイプは、アラームからイベントを区別する場合に使用します。アラーム リストにはいくつかのイベントが表示されます。イベントは NMS 自体に対応付けられます。イベントの例は、Process Restarted または Primary Gateway Disconnected です。これらは相関しないにもかかわらず、アラーム リストに表示される NMS イベントです。NMS に関連しない Transient イベントのもう 1 つの例は、カード スイッチオーバーです。Automatic Protection Switching(APS; 自動保護スイッチング)がカードでイネーブルの場合に、APS スイッチオーバーが発生すると、アラーム リストにイベントが表示されます。Transient イベントと Correlated アラームの主な違いは、Transient イベントはネットワークによって消去されませんが、Correlated アラームは消去されることです。次の図を参照してください。

図K-5 Transient アラーム規則図

 

Transient アラーム規則には、新しいアラームを 1 つのみ対応付けることができます。


) Transient 規則には ClearAlarmCondID が対応付けられていません。Transient アラームはユーザが手動で消去したり、同じ Transient アラームが 2 回生じた場合に消去したり、上限スレッシュホールドに到達した場合に NMServer によって消去できます。


K.12.5.5.3 アラーム重大度とオブジェクト重大度

アラーム規則 XML ファイル内のすべてのアラームには、オブジェクトとアラームの 2 つの重大度が割り当てられています。これらの 2 つの重大度はオブジェクト重大度およびアラーム重大度といいます。ほとんどのアラームでは、これらの重大度が一致します。ただし、これらの重大度が異なることがあります。次に、オブジェクト重大度とアラーム重大度が異なる XML アラーム規則の例を示します。

<CorrelatedRule State="1 -1">
<ClearAlarmCondID>10302</ClearAlarmCondID>
<ClearAlarmCondID>10303</ClearAlarmCondID>
<ClearAlarmCondID>10304</ClearAlarmCondID>
<NewAlarmCondID>10301</NewAlarmCondID>
<NewAlarmServAffect>0</NewAlarmServAffect>
<NewAlarmTransient>0</NewAlarmTransient>
<NewAlarmDbPersistent>0</NewAlarmDbPersistent>
<NewAlarmSev>6</NewAlarmSev>
<NewAlarmObjSev>7</NewAlarmObjSev>
<NewAlarmDescrSuffix>Sync-Up has not started yet</NewAlarmDescrSuffix>
</CorrelatedRule>
 

このアラームは、サウスバウンド プロセス(EM)が EM 同期アップ ステータスが 1 または -1 のノード メッセージを送信した場合に発生します。このアラームが発生すると、ツリー ビュー内のノードは到達不可能な重大度(値 7)になります。アラーム リストに到達不可能な重大度はありません。このため、各アラームには重大度が 2 つ設定されます。到達不可能なアラームは、アラーム リスト内で重大度が Critical(値 6)に設定されています。

アラーム重大度およびオブジェクト重大度が一致しない別の例は、アグリゲート ポート アラームです。アグリゲート ポート アラームは、ポート上の接続状態の概要を示すアラームです。これらのアラームはポートの重大度に影響しないため、これらのアラームのオブジェクト重大度は Clear(値 3)です。次に、アグリゲート ポート アラームの XML を示します。

<CorrelatedBmRule StateBm="1">
<NewAlarmCondID>40801</NewAlarmCondID>
<NewAlarmServAffect>0</NewAlarmServAffect>
<NewAlarmTransient>0</NewAlarmTransient>
<NewAlarmDbPersistent>1</NewAlarmDbPersistent>
<NewAlarmSev>5</NewAlarmSev>
<NewAlarmObjSev>3</NewAlarmObjSev>
<NewAlarmDescrSuffix>Aggregate Port alarm, One or more connections on this port are in primary failure</NewAlarmDescrSuffix>
</CorrelatedBmRule>

) アラーム重大度(NewAlarmSev タグ)は Major(値 5)です。


K.12.5.5.4 ツリー ビューに表示される重大度がプラットフォームに表示される重大度と一致しない

ツリー ビューのネットワーク要素の重大度が、同じネットワーク要素に対してスイッチが表示する重大度と一致しません。


ステップ 1 カスタマーが正しい重大度アイコンを比較しているかどうか確認します。

a. ツリー ビューの各オブジェクトには、アグリゲート重大度とセルフ重大度の 2 つの重大度が対応付けられています。アグリゲート重大度は左に、セルフ重大度は右に表示されます。多くの障害がスイッチによって集約されるため、カスタマーはツリー ビュー内のオブジェクトのアグリゲート重大度をスイッチの重大度と比較する必要があります。

b. 正しい重大度アイコンを参照しているにもかかわらず、重大度が一致しない場合は、ステップ 2 に進みます。

ステップ 2 CTM がノードと同期しているかどうかを確認します。

a. CTM サーバにログインし、selnd を入力します。

b. 目的のノードのモードが 3 であることを確認します。

ステップ 3 モードが 3 の場合は、矛盾の原因が、アグリゲート接続アラームであるかどうかを確認します。NMServer はプラットフォームよりも多くのアラームを集約します。たとえば、NMServer はポートより上位の接続アラームを集約しますが、スイッチは集約しません。したがって、ツリー ビューにスイッチよりも上位の重大度が表示された場合は、その原因が 1 つまたは複数のアグリゲート ポート アラームである可能性があります。

a. ツリー ビュー内の NE を右クリックして、show alarms を選択します。この NE のすべてのアラームおよび子がアラーム リストに表示されます。

b. プラットフォームが表示する重大度よりも大きい重大度を持つアラームをフィルタリングします。

c. アラームがアグリゲート ポート アラームであるかどうかを確認します。そうである場合は、これは予測される動作であり、障害ではありません。プラットフォームで表示される重大度よりも大きな重大度を持つアラームがあり、これらのアラームがアグリゲート ポート アラームでない場合は、次のステップに進んで、アラームがデータベース内にあるかどうかを確認します。

ステップ 4 データベースのアラーム状態が正しいかどうかを確認します。この特定のエンティティ タイプを検索するテーブルの詳細については、『Cisco Transport Manager Release 7.0 Database Schema』を参照してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

NMServer.log

nmControl.dump

クライアント マシンの CMSCclient.log

有効な代替対処法 -- 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

K.12.5.5.5 プラットフォームに存在しないアラームがアラーム リストに表示される

NMServer によって相関付けられているにもかかわらず、スイッチで処理されないアラームがいくつかあります。このようになる原因は、NMS がスイッチにのみ関係するアラーム条件でなく、スイッチおよび NMS に関係するアラーム条件を追跡するためです。このようなアラームの 1 つの例は、ノード同期アップ状態です。NMS がスイッチと同期していない可能性があることは、スイッチ自体に関係しませんが、NMS には関係します。したがって、ノードが NMS と同期している場合は、アラーム リストにこのノードのアラームが表示されますが、プラットフォームにはこのようなアラームは存在しません。次に、プラットフォームに存在しないにもかかわらず、アラーム リストに表示される可能性のあるアラームの概要を示します。


ステップ 1 アラームがアラーム リスト内にあり、プラットフォーム上にない場合は、次のいずれかのリストに疑わしいアラームが含まれているか確認してください。

ノード同期アップ ステータス アラーム

ノード データベース同期アップ ステータス アラーム

ノード管理状態ステータス アラーム

ノード アグリゲート アラーム ステータス

Link0/Link1 ノード アラーム

カード同期アップ ステータス アラーム

アグリゲート ポート(接続)アラーム

ステップ 2 疑わしいアラームがステップ 1 のいずれのアラーム リストにも含まれていない場合は、障害である可能性があります。以下の手順を実行します。

a. データベースのアラーム状態が正しいかどうかを確認します。この特定のエンティティ タイプを検索するテーブルの詳細については、『Cisco Transport Manager Release 7.0 Database Schema』を参照してください。

b. 次の情報を収集します。

topod.log、linktopoc.log、ILMITopoc.log、NMServer.log、および fileTopoc.log

nmControl.dump

CMSCclient.log


 

有効な代替対処法 -- 新しい GUI、および新しい Configuration Center、Chassis View、Diagnostics Center、または Statistics Report を開きます。

K.12.5.5.6 Transient イベントが不意に非表示になる

Transient アラームは、エンティティがネットワーク要素によって管理されるのか、あるいは NMS 自体によって管理されるのかに応じて、いくぶん異なる動作を行います。Transient アラームが管理対象ネットワーク要素で発生した場合(FTP 転送障害によって生成されるアラームなど)、アラームは自動的に消去されます。つまり、同じ Transient アラームが 3 回以上発生すると、以前のアクティブ アラームは最新のアラームによって消去されます。

Transient アラームが管理対象ネットワーク要素でなく、NMS 自体で発生した場合、アラームは自動的に消去されず、同じアラーム状態が何度も発生します。NMS に関係するこれらの NMS アラーム(またはイベント)は、NMS で消去されないため、NMS アラームは相関しません。これらのアラームは、オペレータが手動で消去する必要があります。これらのイベントが手動で消去されない場合、リストは NMServer.conf ファイルで指定された MAX_ACTIVE_NMS_EVENTS 値を上限として拡大します。NMS アラームのリストが MAX_ACTIVE_NMS_EVENTS に達すると、NMServer はリスト内の最も古いアラームを自動的に消去して、新しいイベントのスペースを確保します。最大値に達するたびに消去されるイベント数も、NMServer.conf で指定されます。この設定パラメータは EVENTS_TO_CLEAR_WHEN_MAX_REACHED です。

不意に非表示になる Transient イベントがあった場合、通常は NMServer によってイベントが消去されたことが原因です。


ステップ 1 CTM アラームに関するアラーム リストをフィルタリングします。

ステップ 2 アラーム数を調べて、NMserver.conf 内の MAX_ACTIVE_NMS_EVENTS 値と比較します。アラーム数が MAX_ACTIVE_NMS_EVENTS に近ければ、Transient イベントが消去されたことは説明がつきます。

ステップ 3 NMS アラームのアラーム数が MAX_ACTIVE_NMS_EVENTS に達していない場合は、非表示のイベントは手動で消去された可能性があります。イベントが手動で消去されたかどうかは、NMServer ログを参照してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

CMSCclient.log、NMServer.log、および CMSCclient.log

NMServer ダンプをキャプチャして、nmControl を使用します。

有効な代替対処法 -- Alarm List GUI を再起動します。

K.12.5.5.7 ツリー ビューのポートにアグリゲート アラームが表示されるが、そのポートに子が存在しない

CTM クライアント GUI のツリー ビューには、最上位レベルの物理ビューからポートまでのネットワーク要素が表示されます。アラーム重大度は子から親までが集約されます。ポートはツリーの最下位レベルにあるため、子が存在しないポートにアグリゲート アラームがどのようにして発生するのかという疑問が生じることがあります。これに対する回答は、接続はツリー ビュー内のポートの下にある仮想エンティティであるということです。接続がツリー内に実際に表示されることはありませんが、接続アラームはツリー ビューのポートに対して集約されます。


ステップ 1 接続アラームとアグリゲート ポート アラームを比較します。

a. Configuration Center で、Connections タブをクリックします。

b. ツリー ビューのポートを検索し、右ウィンドウ ペインにドラッグアンドドロップします。Connection ビュー ウィンドウが表示されます。

c. Get ボタンをクリックします。接続が表示され、アラーム ステータスがアラーム リスト内のアラーム ステータスと一致します。

ステップ 2 接続アラームが Alarm List GUI のアグリゲート ポート アラームと一致しない場合は、障害がある可能性があります。次の障害情報を収集します。

CMSCclient.log、NMServer.log、sdbroker*.log、xdbroker*.log

NMServer ダンプをキャプチャして、nmControl を使用します。


 

有効な代替対処法 -- なし

K.12.6 Chassis View の問題

ここで説明する内容は、次のとおりです。

「Chassis View の基本」

「シャーシ ビューに回線が表示されない」

「シャーシ ビューにカードが表示されない」

「PXM カードの DCA/DCB ステータスが表示されない」

「PXM カードのイーサネット ステータスが更新されない」

「MGX ノードの HIST、CBRX、および CBTX ステータスが更新されない。」

「RPM カード ステータスが更新されない」

「RPM セカンダリ カードのステータスがブルーで表示される」

「セカンダリ カードの回線が表示されない」

「回線を選択できない」

「間違ったツールチップが表示される」

K.12.6.1 Chassis View の基本

Chassis View は WAN デバイスの物理ビューを提供する読み取り専用アプリケーションです。特定のノードに対して、ノード、カード、および回線を表示します。Chassis View にポートは表示されません。次のイベントを処理できます。

ノード ステータスの変更

カード ステータスの変更

回線ステータスの変更

Chassis View で処理されるアラームは、次のとおりです。

カード アラーム

回線アラーム

サポートされていないカードが表示されている場合、Chassis View にはシャーシの空きスロットが表示されます。予約済みカードの場合は、回線が表示されますが、この回線はディセーブルです。カードがアクティブまたはスタンバイ以外の状態にある場合、Chassis View にはこのカードの回線が表示されません。

Chassis View には XML ファイルの静的データおよびデータベースの動的データを組み合わせて、シャーシが表示されます。デバッグの最初のステップは、データがデータベースに適切に読み込まれているかどうかを判別することです。次のステップは、カードまたは回線が XML ファイルで定義されているかどうかを調べることです。

K.12.6.2 シャーシ ビューに回線が表示されない


ステップ 1 データベース内の回線テーブルに、対応する回線の回線データが読み込まれているかどうかを判別します。

ステップ 2 XML ファイル Chassis View.xml で回線が定義されているかどうかを調べます。

ステップ 3 データベース内の回線番号が 2 以上からでなく 1 から開始することを確認します。

ステップ 4 ノードが同期していることを確認します(モードが 3)。

データベースに詳細が格納されていない場合は、EM に問題がある可能性があります。詳細が見つかった場合は、次の処理を実行します。

a. cwmver を使用して、CTM バージョンを取得します。

b. 次のコマンドを使用してノードのノード テーブル情報を取得してから、ファイルに保存します。

echo "select (*) from the node, where node_id=<NodeId> " | dbaccess
 

c. 次のコマンドを使用してカードのカード テーブル情報を取得してから、ファイルに保存します。

echo "select (*) from the card, where node_id=<NodeId> and slot=<Slot>" | dbaccess

d. 次のコマンドを使用して回線の回線テーブル情報を取得してから、ファイルに保存します。

echo "select (*) from the line, where node_id=<NodeId> and slot=<Slot>" | dbaccess
 

e. ログを CMSCclient.log としてローカル ドライブに保存します。

f. /opt/svplus/java/jars/cwm/ ディレクトリから chassisview.jar のコピーを取得します。回線の描画に使用される gif ファイルがこの jar ファイル内にあることを確認する必要があります。


 

有効な代替対処法 -- ツリー ビューで回線を選択して、その他のアプリケーションを起動します。

K.12.6.3 シャーシ ビューにカードが表示されない


ステップ 1 カード テーブル内にカードのエントリがあることを確認します。

ステップ 2 XML ファイル ChassisView.xml で回線が定義されているかどうかを調べます。

ステップ 3 ノードが同期していることを確認します(モードが 3)。

データベースに詳細が格納されていない場合は、EM に問題がある可能性があります。詳細が見つかった場合は、次の処理を実行します。

a. cwmver を使用して、CTM バージョンを取得します。

b. 次のコマンドを使用してノードのノード テーブル情報を取得してから、ファイルに保存します。

echo "select (*) from the node, where node_id=<NodeId> " | dbaccess
 

c. 次のコマンドを使用してカードのカード テーブル情報を取得してから、ファイルに保存します。

echo "select (*) from the card, where node_id=<NodeId> and slot=<Slot>" | dbaccess
 

d. ログを CMSCclient.log としてローカル ドライブに保存します。

e. /opt/svplus/java/jars/cwm/ ディレクトリから chassisview.jar のコピーを取得します。回線の描画に使用される gif ファイルがこの jar ファイル内にあることを確認する必要があります。


 

有効な代替対処法 -- ツリー ビューでカードを選択して、その他のアプリケーションを起動します。

K.12.6.4 PXM カードの DCA/DCB ステータスが表示されない

DCA/DCB ステータスは Chassis View 内で常にグレー表示されます。スイッチから DCA/DCB ステータス情報が受信されないため、ステータスは表示または更新されません。

K.12.6.5 PXM カードのイーサネット ステータスが更新されない

イーサネット ステータスが表示されるのは、Chassis View の起動時のみです。イーサネット ステータスの状態を動的に変更しても、Chassis View は更新されません。

K.12.6.6 MGX ノードの HIST、CBRX、および CBTX ステータスが更新されない。

MGX ノードの場合、Chassis View で更新されるのは CPUOK LED ステータスのみです。Chassis View は HIST、CBRX、または CBTX の LED を管理しません。

K.12.6.7 RPM カード ステータスが更新されない

MGX PXM1 ベース ノードの RPM カードの場合は、動的イベント アップデートが生成されないため、RPM カードにホット挿入または削除を実行しても、Chassis View はイベント アップデートを取得しません。コールドスタートを実行すると、カードが識別されます。

K.12.6.8 RPM セカンダリ カードのステータスがブルーで表示される

RPM カードは他のカードと異なり、カードのステータスを表示する LED(CPUOK)が 1 つしかないため、スタンバイ状態ではカード ステータスがブルーで表示されます。その他のタイプのカードでは、スタンバイ状態はイエローの LED で識別されます。

K.12.6.9 セカンダリ カードの回線が表示されない

2 つのカードが冗長関係にある場合は、プライマリ スロットがスタンバイになったときでも、プライマリ カード(論理スロットなど)を使用して子が表示され、アクティビティに関するすべてのプロビジョニングやトラブルシューティング作業が実行されます。セカンダリ スロットがアクティブになっても、その下に子は表示されません。すべてのアプリケーションの階層ビューはこのように動作します。同様に、ASP ペアの現用回線が現在アクティブであるかどうかに関係なく、プロビジョニングはこの回線でのみ実行できます。ただし、モニタリングは現用回線と保護回線の両方で実行されます。

K.12.6.10 回線を選択できない

回線を選択できなくなることがあります。たとえば、回線 3 を選択すると回線 1 が選択されたり、その逆になることがあります。

回線の間隔は十分にとる必要あります。そうしないと、回線が重複して、選択できなることがあります。

障害情報 -- 次の情報を収集して、さらに分析します。

使用している ChassisView.xml ファイルのコピーを取得します。

/opt/svplus/java/jars/cwm/ ディレクトリから chassisview.jar のコピーを取得します。この回線を描画するために使用された gif ファイルを確認します。

有効な代替対処法 -- ツリー ビューから選択します。

K.12.6.11 間違ったツールチップが表示される

カーソルを回線上に置くと、間違ったツールチップが表示されます。たとえば、カーソルをカード内の最後の回線の下に移動すると、カードのツールチップでなく、最後の回線のツールチップが表示されます。

回線の間隔は十分にとる必要あります。そうしないと、回線が重複して、間違ったツールチップが表示されることがあります。

障害情報 -- 次の情報を収集して、さらに分析します。

使用している XML ファイルのコピーを取得します(MGX ノードの場合は ChassisView.xml、BPX/IGX ノードの場合は BPXIGX.xml)。

/opt/svplus/java/jars/cwm/ ディレクトリから chassisview.jar のコピーを取得します。この回線を描画するために使用された gif ファイルを確認します。

有効な代替対処法 -- ツリー ビューから選択します。

K.12.7 Configuration Center の管理

Configuration Center 管理機能は次のカテゴリに分類されます。

ネットワーク要素 -- ノードおよびそれらのコンポーネントを管理します。ネットワーク要素を管理する場合、Configuration Center は Config Server プロセスと通信します。

接続 -- ノード間の接続を管理します。接続を管理する場合、Configuration Center は CM Server プロセスと通信します。

ここでは、要素管理(Configuration Center、Elements タブ)セクションに関するトラブルシューティングの注意事項を示します。Connection Management(Configuration Center、Connections タブ)セクションには、CM に関連するトラブルシューティングの注意事項が記載されています。

ここで説明する内容は、次のとおりです。

「Configuration Center のフレームワーク」

「Configuration Center --要素管理」

K.12.7.1 Configuration Center のフレームワーク

Configuration Center は CTM フレームワークおよびワークフロー メカニズムを使用して、アプリケーションを起動し、アプリケーション内でオブジェクトをドラッグアンドドロップします。

ツリー ビュー内でネットワーク要素を選択し、Configuration Center(Elements タブ)を起動して、選択したオブジェクトを表示または変更できます。

別のアプリケーションから Configuration Center の Elements タブにネットワーク要素をドラッグアンドドロップして、変更できます。

ここで説明する内容は、次のとおりです。

「Configuration Center を起動できない」

「Configuration Center から別のアプリケーションを起動できない」

「Configuration Center の起動時に例外が発生する」

「Configuration Center から別のアプリケーションを起動したときに例外が発生する」

「Element タブ--内部フレームが起動しない」

「Element タブ--ドラッグアンドドロップ機能を使用しても内部フレームが起動しない」

「Element タブ-- Create、Details、Modify、および Refresh ボタンの問題」

「要素管理-- Configuration Center 内のドラッグアンドドロップ」

「クロス アプリケーション-- Configuration Center をドラッグ元として使用」

「クロス アプリケーション-- Configuration Center の Element タブをドロップ先として使用」

「Element タブ--内部フレームに不正なオブジェクトまたはオブジェクト データが表示される」

「Configuration Center の Element タブが応答しない(GUI がグレー表示になる)」

K.12.7.1.1 Configuration Center を起動できない

次のいずれかの方法で Configuration Center を起動できません。

Launch Center または任意のアプリケーションで Configuration Center アイコンをクリックする。

任意のアプリケーションで Tools > Configuration Center を選択する。

階層ツリーで選択したノードを右クリックして、Configuration Center を選択する。


ステップ 1 configcenter.jar ファイルを調べます。configcenter.jar ファイルがターゲット マシンの /opt/svplus/java/jars/cwm ディレクトリにあることを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.2 Configuration Center から別のアプリケーションを起動できない

次のいずれかの方法を使用しても、Configuration Center から別のアプリケーションは起動されません。

Tools メニュー項目で、アプリケーションを選択する。

階層ツリーで選択したオブジェクトを右クリックして、ターゲット アプリケーションを選択する。


ステップ 1 ターゲット アプリケーションの jar ファイルを調べます。ターゲット アプリケーションの jar ファイルがターゲット マシンの /opt/svplus/java/jars/cwm ディレクトリにあることを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.3 Configuration Center の起動時に例外が発生する

次のいずれかの方法を使用して Configuration Center を起動した場合、例外が起動され、Java Console に例外トレース情報が表示されます。

Tools メニュー項目で、アプリケーションを選択する。

階層ツリーで選択したオブジェクトを右クリックして、ターゲット アプリケーションを選択する。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.4 Configuration Center から別のアプリケーションを起動したときに例外が発生する

次のいずれかの方法を使用して Configuration Center から別のアプリケーションを起動した場合、例外が起動され、Java Console に例外トレース情報が表示されます。

Tools メニュー項目で、アプリケーションを選択する。

階層ツリーで選択したオブジェクトを右クリックして、ターゲット アプリケーションを選択する。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.5 Element タブ--内部フレームが起動しない

Element タブを選択し、サポート対象ネットワーク要素をダブルクリックしても、内部フレームが作成されないか、または既存の内部フレームの内容がリサイクルされません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.6 Element タブ--ドラッグアンドドロップ機能を使用しても内部フレームが起動しない

Element タブを選択し、サポート対象ネットワーク要素を Element タブのコンテンツ ペインにドラッグアンドドロップしても、内部フレームが作成されないか、または既存の内部フレームの内容がリサイクルされません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.7 Element タブ-- Create、Details、Modify、および Refresh ボタンの問題

Element タブを選択して、内部フレームにオブジェクトが表示された場合に、Create、Details、Modify、および Refresh ボタンをクリックしても、別の内部フレームが起動しないためさらにプロビジョニングできないか、または選択した操作に対応するデータによってユーザ インターフェイスが更新されません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.8 要素管理-- Configuration Center 内のドラッグアンドドロップ

Configuration Center ツリー ビューから Element タブのコンテンツ ペインにネットワーク要素をドラッグアンドドロップすると、次のいずれかになります。

内部フレームのオープンに失敗する。

既存フレームの内容をリサイクルして、オブジェクトの属性を表示できない。

Operation Not Supported メッセージ ボックスが表示される。


ステップ 1 ドロップされたオブジェクトに対してドラッグアンドドロップ機能がサポートされているかどうかを判別します。

ツリー ビューからコンテンツ ペインにドロップできるオブジェクトは、次のとおりです。

Element タブの場合、Network、Node、Card、Line、Port、IMA、および IMA リンク オブジェクトはサポートされていますが、Folder オブジェクトはサポートされていません。

Connection タブの場合、Node、Card、Line、および Port オブジェクトはサポートされていますが、Folder、IMA、および IMA リンク オブジェクトはサポートされていません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.9 クロス アプリケーション-- Configuration Center をドラッグ元として使用

Configuration Center のツリー ビューまたは Element タブをドラッグ元として、そこから別の CTM アプリケーションにオブジェクトをドラッグアンドドロップしても、選択したオブジェクトはターゲット アプリケーションに表示されません。


ステップ 1 選択されたオブジェクトに対してドラッグアンドドロップ機能がサポートされているかどうかを判別します。

ステップ 2 ドロップされたオブジェクトに対してターゲット アプリケーションがドラッグアンドドロップ機能をサポートしているかどうかを判別します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.10 クロス アプリケーション-- Configuration Center の Element タブをドロップ先として使用

別の CTM アプリケーションから Configuration Center の Element タブのコンテンツ ペインにネットワーク要素をドラッグアンドドロップすると、次のいずれかになります。

内部フレームのオープンに失敗する。

既存フレームの内容をリサイクルして、ドロップされたオブジェクトの属性を表示できない。

Operation Not Supported メッセージ ダイアログボックスが表示される。


ステップ 1 ドロップされたオブジェクトに対してドラッグアンドドロップ機能がサポートされているかどうかを判別します。

ツリー ビューからコンテンツ ペインにドロップできるオブジェクトは、次のとおりです。

Element タブの場合、Network、Node、Card、Line、Port、IMA、および IMA リンク オブジェクトはサポートされていますが、Folder オブジェクトはサポートされていません。

Connection タブの場合、Node、Card、Line、および Port オブジェクトはサポートされていますが、Folder、IMA、および IMA リンク オブジェクトはサポートされていません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.11 Element タブ--内部フレームに不正なオブジェクトまたはオブジェクト データが表示される

Element タブに内部フレームが正常に作成されますが、別のオブジェクトに関連する情報が表示されるか、またはオブジェクトの属性値が無効です。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.1.12 Configuration Center の Element タブが応答しない(GUI がグレー表示になる)

Configuration Center の Element タブが応答しないで、GUI がグレー表示になります。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.7.2 Configuration Center --要素管理

Configuration Center を使用して、さまざまなネットワーク要素オブジェクトを設定できます。Configuration Center の Element タブは、ネットワーク要素を作成、変更、および表示するためのメイン ウィンドウです。Element タブは CTM Internal Frame メカニズムを使用して、特定のネットワーク要素に対応付けられた属性(グループおよびカテゴリ)を表示します。ここでは、ネットワーク要素の作成、変更、および表示に関連した問題のトラブルシューティングに関する注意事項を示します。

K.12.7.2.1 XML 解析エラー

XML 解析エラーは、(ドラッグアンドドロップ方法や右クリック方法を使用して)ネットワーク要素に対して Configuration Center を起動している間に表示されます。ポップアップ ウィンドウに次のように表示されます。

Internal Error:XML Parsing Error

ステップ 1 Configuration Center を起動する必要があるネットワーク要素が、使用中の CTM バージョンでサポートされているかどうかを確認します。サポート対象のノード/カードでこのエラーが発生する場合は、ステップ 2 に進みます。

ステップ 2 /opt/svplus/log/configserver.log ファイルを開いて、このエラーの発生時期を示すメッセージ情報を調べます。ログ内の一般的なメッセージは、次のとおりです。

ERR: Fatal Error at file, line 0, char 0, Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not be opened. Id=/opt/svplus/xml/configcenter/XXX/XXX-XXX.xml
( <someNumber>: <x>) <someTime Stamp> ERR: InternalError: XML Parsing Error

上記の .xml ファイル名に連続する 2 つのハイフンが含まれている場合(ABC--XYZ.xml など)、またはハイフンが先頭に付加されているか(-ABC.xml など)、ハイフンのあとにファイル拡張子が続く場合(ABC-.xml など)は、ステップ 4 に進みます。

ステップ 3 ログ メッセージに記載された .xml ファイルが存在するかどうかを調べます。このファイルが存在しない場合は、TAC に連絡してください。

ステップ 4 次のステップを実行して、不正な形式の XML ファイル名ストリングを調べます。XML ファイル名のフォーマットは <Platform>-<Card>-<InterfaceType>-<SomeEntityName>.xml です。このフォーマットはいくつかの例外を除いて一般に使用されます。Platform および InterfaceType はオプションであり、多くのファイルでは省略されます。たとえば、ABC-Card.xml は有効な XML ファイル名です。

a. XML ファイル名の Platform 部分が不正であるか、省略されている場合は、Node テーブルでこのファイルが正しく読み込まれているかどうかを調べます。

b. XML ファイル名の Card 部分が不正であるか、省略されている場合は、Card テーブルでこのファイルが正しく読み込まれているかどうかを調べます。

c. XML ファイル名の Interface Type 部分が不正であるか、省略されている場合は、該当するテーブルでこのファイルが正しく読み込まれているかどうかを調べます。このテーブルは一般に、このエラーが発生したカードの Line または Port テーブルに対応します。

d. XML ファイル名の Entity Name 部分が不正である場合は、TAC に連絡して、必要な障害情報を提供します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

/opt/svplus/log/configserver.log.

このエラーが発生したコントローラ カードおよびサービス モジュールに対してスイッチから実行された dspcd コマンドの出力

ddspln または dspport コマンド出力(このエラーが回線またはポートに対して発生した場合)

有効な代替対処法 -- なし

K.12.7.2.2 SNMP No Data エラー

SNMP NO DATA エラーは、(ドラッグアンドドロップ方法や右クリック方法を使用して)ネットワーク要素に対して Configuration Center を起動している間に表示されます。

このエラーが発生したネットワーク要素がアクティブであるかどうか、およびノードが同期していることを確認します。そのためには、CTM マシンで selnd コマンドを使用します。

正しいコミュニティ ストリングが使用されているかどうかを調べます。アクティブ要素上の適切に同期されたノードに対してこのエラーが発生した場合は、次の処理を実行します。


ステップ 1 SNMP Manager ツールを使用して、スイッチが SNMP クエリーに応答しているかどうかを判別します。

特定のダイアログボックスで照会する SNMP MIB(管理情報ベース)オブジェクトは、/svplus/log/configserver.log ファイルから取得できます。このエラーが発生した場合はこのログ ファイルのエントリを参照して、次の処理を実行します。

a. HP-OV SNMP 処理を使用して、/opt/OV/bin/snmpwalk -c public nodeName system として調査を実行します(この例では、public コミュニティ ストリングを使用して、「system」 MIB テーブル上で実行します)。

b. (SNMP マネージャ ツールから)SNMP 処理を実行している間にエラーが発生した場合は、スイッチを調べて、この情報が実際に存在するかどうかを確認します。存在する場合は、ステップ 2 に進みます。

ステップ 2 このエラーが表示されたら、/svplus/log/configserver.log ファイルから情報を収集します。以下の手順を実行します。

a. configserver.log ファイルから、エラーの原因となった MIB オブジェクトを識別します。

b. これらのオブジェクトが属している MIB を識別します。

c. これらの MIB オブジェクトがこのリリースでサポートされていることを確認します。オブジェクトがサポートされているにもかかわらず、SNMP エージェントが SNMP クエリーに応答していない場合は、TAC に連絡してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドの完全なスクリーン スナップショット

configserver.log.

スイッチの関連情報

有効な代替対処法 -- なし

K.12.7.2.3 Details、Create、Delete、および Refresh ボタンがイネーブルでない

Details、Create、Delete、および Refresh ボタンは、表形式ビューの要件に基づいてイネーブルまたはディセーブルになります。対応する処理がサポートされていない場合、これらのボタンはディセーブルになります。


ステップ 1 MIB の /opt/svplus/log/configserver.log ファイルを開きます。

ステップ 2 Create ボタンがディセーブルな場合は、SNMP ツールを使用して SNMP SET 処理を実行し、オブジェクトを作成します。

SNMP SET 処理が正常に実行された場合は、TAC に連絡してください。

SNMP SET 処理に失敗した場合は、CLI に SSH または Telnet で接続し、要素を追加します。この処理に成功した場合は、TAC に連絡してください。

ステップ 3 Delte ボタンがディセーブルな場合は、SNMP ツールを使用して SNMP SET 処理を実行し、オブジェクトを削除します。

SNMP SET 処理が正常に実行された場合は、TAC に連絡してください。

SNMP SET 処理に失敗した場合は、CLI に SSH または Telnet で接続し、要素を削除します。この処理に成功した場合は、TAC に連絡してください。

ステップ 4 Details ボタンがディセーブルになるのは、要素に関連するすべての情報が表形式ビューにすでに表示されている場合のみです。configserver.log ファイルを調べて、要素に適した MIB エントリが使用可能かどうかを判別します。MIB エントリが使用可能な場合は、SNMP ツールを使用して、その MIB エントリに SNMP 調査を実行します。タブ形式ビューに表示された内容のほかに情報があり、この情報をフレームに表示することが重要な場合は、TAC に連絡してください。

ステップ 5 Refresh ボタンがディセーブルになるのは、フレームに表示されるすべての情報が読み取り専用である場合のみです。編集可能なフィールドがあるにもかかわらず、Refresh ボタンがディセーブルである場合は、TAC に連絡してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドの完全なスクリーン スナップショット

configserver.log

有効な代替対処法 -- 要素を作成または削除する場合は、CTM マシンで SNMP SET 処理を使用するか、またはスイッチで CLI コマンドを使用します。

K.12.7.2.4 SNMP タイムアウト エラー

このエラーは、SNMPCOMM に値を設定したり、そこから値を取得しようとすると発生します。この値は、次のようになります。

Check the sync-up, link0, link1 status of the Node in the inspectorview.

ステップ 1 ステータスが Unmanaged、Unreachable、Failed in Sync、または Partially Synced の場合は、ping、Telnet、またはその他のユーティリティを使用してノードが接続されているか調べます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドの完全なスクリーン スナップショット

configserver.log

有効な代替対処法 -- なし

K.12.7.2.5 SNMP SET エラー

このエラーは、編集不可能な MIB オブジェクトに SNMP SET 処理が実行された場合、または無効な値を使用した場合に発生します。


ステップ 1 /opt/svplus/log/configserver.log ファイルを開きます。

ステップ 2 文書名の最後の部分を検索します。

たとえば、文書名が AAA-BBB-CCC.xml の場合、この文書は /opt/svplus/xml/configcenter/CCC/ ディレクトリ内にあります。

ステップ 3 ファイルを入手できない場合は、TAC に連絡してください。

ステップ 4 ステップ 2 で取得した文書を開いて、次の処理を実行します。

XML ファイル内の MIB オブジェクトの Access フィールドを調べます。

/opt/svplus/mibs ディレクトリ内の Access フィールドを調べます。

XML ファイルと MIB 定義の Access フィールドが異なる場合は、TAC に連絡してください。

ステップ 5 XML ファイルおよび MIB 定義内の MIB オブジェクトの Range フィールドを調べます。これらが異なる場合は、TAC に連絡してください。

ステップ 6 HP-OV を使用して、GUI で表示されるのと同じ値および適切なコミュニティ ストリング
(/opt/svplus/log/configserver.log の表示に従う)を指定して、MIB オブジェクトでSNMP SET 処理を実行します。SNMP SET 処理の構文は次のとおりです。

/opt/OV/bin/snmpset -c private nodeName MIBVariable MIBDataType MIBValue

ステップ 7 SNMP SET 処理が正常に実行された場合は、TAC に連絡し、該当する障害情報を提供してください。

ステップ 8 スイッチに SSH または Telnet で接続し、同じパラメータに、GUI および SNMP ツールで指定された値を設定します。CLI がエラーを報告しない場合は、TAC に連絡し、障害情報を提供してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドの完全なスクリーン スナップショット

configserver.log

有効な代替対処法 -- なし

K.12.7.2.6 ツリー ビューにオブジェクトが表示されない

このエラーは、Configuration Center の表形式ビューからネットワーク要素を起動した場合に発生します。


ステップ 1 起動中のオブジェクトの情報を収集します。そのための方法は 2 つあります。

表形式ビューを参照します。このビューには、ノード名、スロット番号、回線番号、トランク番号、ポート番号などの最小限の情報が表示されます。

ウィンドウのタイトルを参照します。タイトルには、起動中のオブジェクトに関する最小限の情報の一部が次のいずれかの形式で表示されます。

ノードの場合、ウィンドウ タイトルには <NodeName> が付加されます。

スロットの場合、ウィンドウ タイトルには <NodeName>.<SlotNumber> が付加されます。

回線の場合、ウィンドウ タイトルには <NodeName>.<SlotNumber>.<LineNumber> が付加されます。

ポートの場合、ウィンドウ タイトルには <NodeName>.<SlotNumber>.<PortNumber> が付加されます。

ステップ 2 ステップ 1 で取得した情報を使用して、このオブジェクトがツリー ビューに表示されるかどうかを調べます。

表示される場合は、ステップ 3 に進みます。

表示されない場合は、表形式ビューを 2、3 回リフレッシュして、表形式ビュー内にオブジェクトがあるかどうかを調べます。それでも同じエラーが発生する場合は、TAC に連絡して、該当する障害情報を提供します。

ステップ 3 起動中のオブジェクトがノードまたはカードの場合は、特定のノードまたはカードが、使用中の CTM バージョンでサポートされているかどうかを確認します。

ステップ 4 ノードまたはカードがサポートされている場合は、/opt/svplus/log/CMSCclient.log ファイルをを開いて、起動中のオブジェクトの FDN がステップ 1 の情報と一致するかどうかを調べます。TAC に連絡して、適切な障害情報を提供します。一般的なログの例は、次のとおりです。

[DD Mon YYYY HH:MM:SS] DEBUG - [appsConfigCenter] :: CcElementInternalFrame : modifyActionPerformed()
[DD Mon YYYY HH:MM:SS] DEBUG - [appsConfigCenter] CcTabularView : modify()
[DD Mon YYYY HH:MM:SS] INFO - [appsConfigCenter] Selected fdn = /NW=X/RND=XX/CD=X/LN=X/PT=X
 


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

/opt/svplus/log/configserver.log ファイルの内容

有効な代替対処法 -- なし

K.12.7.2.7 要素データがスイッチと一致しない

GUI とスイッチに表示される情報が異なります。


ステップ 1 起動したウィンドウが GUI の要素に正しく対応していることを確認します。正しく対応していない場合は、TAC に連絡し、障害情報を提供してください。

ステップ 2 スイッチに SSH または Telnet で接続し、パラメータをいくつか変更し、変更が GUI に反映されているか調べます。If not, contact the TAC.

ステップ 3 /opt/svplus/log/configserver.log ファイルを開き、一致しないデータが表示された要素の MIB OID を検索します。

ステップ 4 MIB OID が、検索対象情報を示しているかどうかを確認します。示していない場合は、Tac に連絡します。

ステップ 5 SNMP ツールを使用して、一致しないデータが表示された MIB オブジェクトに SNMP GET 処理を実行します。SNMP GET 処理を使用して取得された値と GUI に表示された値が異なる場合は、TAC に連絡してください。次に、HP-OV の SNMP GET 処理の構文を示します。

snmpget [-Cf] [options...] <hostname> {<community>} [<objectID> ...]

ステップ 6 一致しないデータが表示される MIB オブジェクトのデータ タイプを調べます。configserver.log 内の MIB オブジェクトのデータ タイプが、MIB オブジェクト定義(/opt/svplus/mibs/ ディレクトリ)で定義されたデータ タイプと異なる場合は、TAC に連絡し、障害情報を提供します。

ステップ 7 MIB オブジェクトのデータ タイプを調べます。

a. MIB オブジェクトのデータ タイプが Bitmap の場合は、MIB オブジェクトの 10 進値を 2 進値に変換し、ビット SET/RESET を、MIB オブジェクト定義で定義され GUI に表示された値と比較します。TAC に連絡し、障害情報を提供してください。

b. MIB オブジェクトのデータ タイプが IpAddress の場合は、値のフォーマットが適切であるかどうかを確認します(<aaa.bbb.ccc.ddd> など)。値が適切なフォーマットでない場合は、TAC に連絡してください。


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドのスクリーン スナップショット

/opt/svplus/log/configserver.log

有効な代替対処法 -- なし

K.12.7.2.8 Config Server がエラー メッセージを報告する

ここでは、Config Server に発生する可能性のあるさまざまな種類のエラーについて説明します。


ステップ 1 /opt/svplus/log/configserver.log ファイルを開きます。

ステップ 2 データ タイプが一致しない場合は、GUI にエラー メッセージが表示され、configserver.log ファイル内の対応するエラー メッセージは次のようになります。

( 24560: 9) 07:49:14 CRIT: %SnmpCommException-2-NOT_INTEGER_VALUE: SnmpVar::getInteverValue() incorrectly called for ASN type [4].

この場合、XML ファイルで定義された MIB オブジェクトのデータ タイプは、MIB オブジェクト定義のデータ タイプと異なります。TAC に連絡し、障害情報を提供してください。

ステップ 3 無効な値を入力した場合は、GUI にエラー メッセージおよびパラメータ名が表示されます。configserver.log ファイル内の対応するエラー メッセージは、次のとおりです。

( 17252: 6) 08:31:20 ERR: %SnmpCommException-3-ERR_BADVALUE: Snmp Error[3]: Bad Value; object [] (index[2]) :
 

ステップ 4 複数の要素をアップ/追加しようとすると、GUI にエラー メッセージがスローされ、対応する次のようなエラー メッセージが /opt/svplus/log/configserver.log ファイルにスローされます。

( 23868: 6) 14:01:09 ERR: %SnmpCommException-3-ERR_GENERR: Snmp Error[5]: General Error; object [] (index[0])
 


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドの完全なすべてのスクリーン スナップショット

/opt/svplus/log/CMSCclient.log ファイルの内容

有効な代替対処法 -- なし

K.12.8.1 Configuration Center GUI --フレームワークの問題

Configuration Center 管理機能は次のカテゴリに分類されます。

接続 -- 接続を管理します。


) 接続を管理する場合、Configuration Center は CM Server プロセスと通信します。


NE -- ノードおよびそれらのコンポーネントを管理します。


) ネットワーク要素を管理する場合、Configuration Center は Config Server プロセスと通信します。


Configuration Center の Connection タブはネットワーク接続を作成、変更、および表示するためのメイン ウィンドウです。Connection タブのコンテンツ ペインには、接続を作成するためのタブ(Advanced Mode および Quick Mode タブ)や、既存接続のリストを取得するためのタブ(Connection タブ)が追加されています。

Configuration Center は CTM フレームワークおよびワークフロー メカニズムを使用して、アプリケーションを起動し、接続情報を作成および表示します。

CTM アプリケーションで接続を選択したり、Configuration Center(Connection タブ)を起動して、選択された接続を表示/変更できます。

別のアプリケーションから Configuration Center の Connection タブに接続をドラッグアンドドロップして、変更できます。

ここでは、Configuration Center を使用したネットワーク接続の作成、変更、および表示に関連した問題のトラブルシューティングに関する注意事項を示します。

K.12.8.1.1 Connections タブ--ツリー ビューでダブルクリックを実行しても 接続の内部フレームが起動しない

Connection タブのツリー ビューでネットワーク要素をダブルクリックしても、(a)内部フレームを開くことができない、(b)既存内部フレームの内容をリサイクルして、ダブルクリックれた接続属性を表示できない、または(c)Operation Not Supported メッセージ ダイアログボックスが表示されます。


ステップ 1 選択されたオブジェクトに対してダブルクリック操作がサポートされているかどうかを判別します。

Connection タブは Node、Card、Line、および Port オブジェクトの接続管理をサポートしています。Folder、IMA、および IMA リンク オブジェクトのドラッグアンドドロップ機能は、サポートされていません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.2 Connections タブ--ドラッグアンドドロップ機能を使用しても接続の内部フレームが起動しない

Configuration Center ツリー ビューから Connections タブのコンテンツ ペインにネットワーク要素をドラッグアンドドロップしても、(a)内部フレームを開くことができない、(b)既存フレームの内容をリサイクルして、ドロップされたオブジェクトの属性を表示できない、または(c)「Operation Not Supported」メッセージ ダイアログボックスが表示されます。


ステップ 1 ドロップされたオブジェクトに対してドラッグアンドドロップ機能がサポートされているかどうかを判別します。

Connection タブは Node、Card、Line、および Port オブジェクトのドラッグアンドドロップ機能をサポートしています。Folder、IMA、および IMA リンク オブジェクトのドラッグアンドドロップ機能は、サポートされていません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.3 Connection List タブ--内部フレームを起動して既存接続を変更できない

Details ボタンをクリックしても、内部フレームを起動して、取得された接続の詳細を表示できません。


ステップ 1 接続ステータスが Incomplete 状態であることを確認します。

Connection タブの Details ボタンを使用して起動できるのは、OK および Fail 状態の接続のみです。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.4 Advanced Mode タブ-- Details ボタンを使用して Connection Details ダイアログボックスを起動できない

Advanced Mode タブの Details ボタンをクリックしても、Connection Details ダイアログボックスを起動できません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.5 Advanced Mode タブ-- Template Details ボタンを使用して Template Details ダイアログボックスを起動できない

Advanced Mode タブの Template Details ボタンをクリックしても、Template Configuration ダイアログボックスを起動できません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.6 クロス アプリケーション--接続リストから他のアプリケーションを起動できない

Connection タブの取得済み接続のポップアップメニューを右クリックしても、この接続用に選択されたターゲット アプリケーションが起動しないか、または Operation Not Supported メッセージ ダイアログボックスが表示されます。


ステップ 1 ターゲット アプリケーションでこの処理がサポートされているかどうかを判別します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.7 アプリケーション間--接続リストをドラッグ元として使用

Configuration Center の接続リストをドラッグ元として、そこから別のアプリケーションに接続をドラッグアンドドロップしても、選択したオブジェクトはターゲット アプリケーションに表示されません。


ステップ 1 ターゲット アプリケーションが接続オブジェクトのドロップ操作をサポートしているかどうかを判別します。

ステップ 2 ターゲット アプリケーションが接続オブジェクトのドラッグアンドドロップ機能をサポートしているかどうかを判別します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.8 クロス アプリケーション-- Connection タブのコンテンツ ペインをドロップ先として使用

別のアプリケーションから Configuration Center の接続タブのコンテンツ ペインに接続オブジェクトをドラッグアンドドロップしても、(a)内部フレームを開くことができない、(b)既存フレームの内容をリサイクルして、新規にドロップされた接続オブジェクトを表示できない、または(c)「Operation Not Supported」メッセージ ダイアログボックスが表示されます。


ステップ 1 ドラッグ元およびドラッグ先アプリケーションが Java VM(仮想マシン)の同じインスタンスに属しているかどうかを確認します。CTM フレームワークは、異なる Java VM に属するアプリケーション間でのドラッグアンドドロップ機能をサポートしません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.1.9 Configuration Center の Connection タブが応答しない

Configuration Center の Connection タブが応答しないで、GUI がディセーブルになります。


ステップ 1 問題を再現し、Java DOS ウィンドウを使用してその他の Java 関連データを収集します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.2 Configuration Center GUI -- CM Server によって報告されたエラー

接続管理の場合、Configuration Center は CM Server プロセスと通信して、(a)接続を作成、変更、削除、または取得したり、(b)接続テンプレートを作成、変更、削除、または取得したりします。CM Server は、要求された処理を正常に完了できない場合、アプリケーション例外をスローします。CM Server 例外には、エラー状態を示すエラー メッセージなどがあります。Configuration Center に報告されたエラー メッセージが表示され、さらに分析できます。この場合、問題は CM Server 側で調査する必要があります。CM Server のトラブルシューティング セクションには、CM Server 関連の問題をさらに分析するために必要なステップが記載されています。「接続管理の問題」 を参照してください。このセクションでは、Configuration Center に関連した必須の確認手順およびデータ収集手順を示します。

K.12.8.2.1 接続の作成、変更、削除、および取得時のエラー

接続の作成、変更、削除、および取得を実行すると、CM Server がエラーを検出し、エラーを示す情報が含まれたアプリケーション例外エラーをスローして、Configuration Center に通知することがあります。この処理が実行されると、Configuration Center にはエラー メッセージが表示されます。次に、CM Server 関連の例外の一部を示します。

DATABASE_ERROR:"Database error [%s]."
UNKNOWN_EXCEPTION: "Program Error. Unknown Exception is caught in [%s]."
SUBSYSTEM_EXCEPTION:"Program Error. Subsystem exception [%s] caught in [%s]"
INTERNAL_ERROR: "Program or System Error. Function [%s] reports: [%s]"
CONNECTION_LOST: "Connection from host [%s] application [%s] lost during request."
UNKNOWN_PARAM_VALUE_TYPE: "Unknown parameter value type [%d] is processed in [%s]."
PARAM_TYPE_VALUE_MISMATCH: "Parameter value [%s] is does not match type [%d]"
VALUE_OUT_OF_RANGE: "Value [%d] is outside of the valid [%d] - [%d] range"
NO_SUCH_CONNECTION_TYPE_ENUM: "No such connection type enum [%d]"
NO_SUCH_SERVICE_TYPE_ENUM: "No such service type enum [%d]"
NO_SUCH_ENDPOINT_TYPE_ENUM: "No such endpoint type enum [%d]"
NO_PORT_TABLE_INFO_FOR_CARD: "No port table information for card family [%d]"
NO_LINE_TABLE_INFO_FOR_CARD: "No line table information for card family [%d]"
FILTER_REQUIRED:"Filter [%s] is required"
UNEXPECTED_PARAMSET: "CM Server does not expect parameter set [%d]."
UNSUPPORTED_ENDPOINT: "CM Server does not support end point with card type [%s], vs[%s], interface type [%s], node platform [%s], controller type [%s] for connection type [%s] service type [%s], endtoend type [%s]."
UNSUPPORTED_PARAMETER_FOR_VISM: "Unsupported parameter setting on the [%s] end. CM Server does not support [%s] + [%s] PVC's for VISM cards with firmware revision less than [%s] and card mode set to [%s]."
PROTECTED_CONNECTION: "[%s] end of the connection is protected. Protected connections cannot be deleted."
UNSUPPORTED_NODE_PLATFORM: "CM Server does not support node platform [%d]."
UNSUPPORTED_CONN_TYPE: "CM Server does not support Connection of type [%d]."
UNSUPPORTED_SERV_TYPE: "CM Server does not support Connection type [%s] , Service type [%s] and Endtoend type [%s] between Card type [%s] and [%s]."
UNSUPPORTED_SERV_TYPE_ONE_END: "CM Server does not support Connection type [%s] , Service type [%s] and Endtoend type [%s] on Card type [%s]."
UNSUPPORTED_CARD_PAIR: "Connection between card type [%s] and card type [%s] is not supported."
NO_SUCH_NODE_ID_IN_DB: "Node id [%d] not found in table [node]."
NO_SUCH_NODE_NAME_IN_DB: "Node name [%s] not found in table [node]."
NO_SUCH_CARD_IN_DB: "Card : Node[%d], Slot[%d] not found in table [card]."
NO_SUCH_LOG_PORT_IN_DB: "Card : Node[%d], Slot[%d], LogPort[%d] (%d - in database), not found in table [%s]."
NO_SUCH_PHY_PORT_IN_DB: "Card : Node[%d], Slot[%d], Line[%d], PhyPort[%d] (%d - in database), not found in table [%s]."
NO_SUCH_LINE_IN_DB: "Card : Node[%d], Slot[%d], Line[%d] not found in table [%s]."
NO_SUCH_CONNECTION_IN_DB: "Connection [%s] not found in database"
UP_CONN_FAILED: "Upping Connection Failed. Test Result from switch [%s]"
DOWN_CONN_FAILED: "Downing Connection Failed. Test Result from switch [%s]"
NO_ONE_SEGMENT_HYBRID: "Cannot create one segment hybrid connection."
INCORRECT_LINE_SUBTYPE: "Incorrect Line SubType. Line: Node[%d],slot[%d],ifindex[%d] is [%d] not [%d]."
INVALID_LINE_NUMBER: "func [%s]:Invalid Line Number(s)."
NO_CONTROLLER_IN_PORT: "node[%s] slot[%d] port[%d] does not have controller of type [%s]";
INVALID_FDN: "The given FDN format or value is invalid. [%s]"
INVALID_PORT: "Provisioning operations are not allowed on feeder trunk/routing trunk and XLMI trunk ports. [%s]"

ステップ 1 コマンドラインに psg sdbroker および psg cmserver を入力して、CM サーバおよび sdbroker が起動および稼働していることを確認します。

ステップ 2 cmsvr.log を調べ、ストリング「START OF THE PROCESS」を検索して、処理の実行中に CmServer が再起動したかどうかを確認します。処理の実行中にサーバ プロセスのタイム スタンプが再起動したことを確認します。/opt/svplus/corefilesdir/ ディレクトリで、cmsvr コアダンプも検索します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.2.2 接続テンプレートの作成、変更、削除、および取得時のエラー

接続テンプレートの作成、変更、削除、および取得を実行すると、CM Server がエラーを検出し、エラーを示す情報が含まれたアプリケーション例外エラーをスローして、Configuration Center に通知することがあります。この処理が実行されると、Configuration Center にはエラー メッセージが表示されます。次に、CM Server 関連の接続テンプレート例外の一部を示します。

CONN_TEMPLATE_ALREADY_PRESENT:"The Connection Template[%s] is already present in the conn_template table."

CONN_TEMPLATE_NOT_PRESENT:"The Connection Template[%s] is not present in the conn_template table."

CONN_TEMPLATE_TABLE_INCONSISTENT:"The Connection Template table contains more than one entry for the template[%s]."

CONN_TEMPLATE_PARAMS_NOT_PRESENT:"The Connection Template[%s] is not present in the conn_templ_param table."

DATABASE_ERROR:"Database error [%s]."

UNKNOWN_EXCEPTION:"Program Error.Unknown Exception is caught in [%s]."

SUBSYSTEM_EXCEPTION:"Program Error.Subsystem exception [%s] caught in [%s]."

INTERNAL_ERROR:"Program or System Error.Function [%s] reports:[%s]."


ステップ 1 コマンドラインに psg sdbroker、psg xdbroker、および psg cmserver を入力して、CM Server、sdbroker、および xdbroker が起動および稼働していることを確認します。

ステップ 2 cmsvr.log を調べ、ストリング「START OF THE PROCESS」を検索して、処理の実行中に CM Server が再起動したかどうかを確認します。処理の実行中にサーバ プロセスのタイム スタンプが再起動したことを確認します。/opt/svplus/corefilesdir/ ディレクトリで、cmsvr コアダンプも検索します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報(特に、Java によって生成された例外)

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの configserver.log ファイル

有効な代替対処法 -- なし

K.12.8.3 Cmsvr エラー

次に、プロビジョニング要求を送信した場合に表示される最も一般的なエラーの一部を示します。

「PNNI セグメントと接続する場合にエンドツーエンド タイプを PVC に設定できない」

「PNNI/SPVC エンドポイントの外部接続のサービス タイプがサポートされていない」

「CE/CE 接続ポート速度が両方のエンドポイントで同じでなければならない」

「単一セグメントのハイブリッドを作成できない」

「チェーン タイプ NIW および NIW を交換する場合に 4 バイト ポート ヘッダーと 2 バイト ポート ヘッダー間に接続を追加できない」

「サービス タイプがサポートされていない--一般的なノード/スロット/ポート/バージョン」

「変更処理中にいずれかの接続テーブルにエンドポイントが格納されていない」

「cmsvr --接続診断の問題」

「TestConn または TestDelay に失敗してスイッチ エラーが発生する」

「接続の起動/終了/再ルーティングに失敗する」

「接続トレースの障害」

K.12.8.3.1 PNNI セグメントと接続する場合にエンドツーエンド タイプを PVC に設定できない

接続を追加しようとすると、cmsvr は接続のエンドポイントおよびエンドツーエンド タイプを調べて、接続がサポートされていることを確認します。「EndtoEndType cannot be PVC for connections with a PNNI segment.」というエラー メッセージが表示されます。

この問題は、接続の追加中に CM GUI で修正する必要があります。


ステップ 1 接続の追加に使用されているエンドポイントが、PNNI ノード上にないこと、または PNNI ノードへの送信元でないことを確認します。

ステップ 2 CM GUI でエンドツーエンド タイプを SPVC または Hybrid に変更します。


 

障害情報 -- /opt/svplus/log ディレクトリから cmsvr ログを収集します。

有効な代替対処法 -- なし

K.12.8.3.2 PNNI/SPVC エンドポイントの外部接続のサービス タイプがサポートされていない

接続の追加中に、「CM Server does not support Connection type[], Service type[], and Endtoend type []between Card type and [].」というエラー メッセージが表示されることがあります。カッコには該当する値が挿入されます。


ステップ 1 サービス タイプをエンドポイントに適用できるかどうかを判別します。

ステップ 2 接続を追加しているカード、および GUI で指定したサービス タイプを判別します。


 

このエラーは、サービス タイプが abr-fs または atfst(PVC、SPVC、または Hybrid エンドツーエンド タイプの場合)、カードが pxm、axsm、rpm、または frsm12 カードの場合にスローされます。

障害情報 -- /opt/svplus/log ディレクトリから cmsvr ログを収集します。

有効な代替対処法 -- エンドポイントまたはサービス タイプを変更して、接続を追加します。

K.12.8.3.3 CE/CE 接続ポート速度が両方のエンドポイントで同じでなければならない

CE/CE 接続を追加すると、次のエラー メッセージがスローされることがあります。

「For Ce-Ce Connection Port Speed should be same on both sides.Port Type should be same except for Structured 8T1 and E1.」


ステップ 1 ローカル エンドポイントとリモート エンドポイントでポート速度が同じであることを確認します。

ステップ 2 構造化された 8T1 および 8E1 を除き、両方のエンド タイプでポート タイプが同じであることを確認します。


 

障害情報 -- /opt/svplus/log ディレクトリから cmsvr ログ ファイルを収集します。

有効な代替対処法 -- エンドポイントを適切に変更して、接続を追加します。

K.12.8.3.4 単一セグメントのハイブリッドを作成できない

単一セグメント接続を追加するときに、この接続がハイブリッド接続でないことを確認します。接続がハイブリッドである場合は、次のエラー メッセージが表示されます。

「Cannot create one segment hybrid connection.」


ステップ 1 単一セグメント接続のエンドツーエンド タイプが Hybrid でないことを確認します。


 

障害情報 -- /opt/svplus/log ディレクトリから cmsvr ログ ファイルを収集します。

有効な代替対処法 -- エンドツーエンド タイプを Hybrid 以外に変更します。

K.12.8.3.5 チェーン タイプ NIW および NIW を交換する場合に 4 バイト ポート ヘッダーと 2 バイト ポート ヘッダー間に接続を追加できない

2 つの FRSM_12 ポート間に接続を追加する間に、cmsvr は両方のエンドポイントでポート ヘッダーが同じ(4バイトまたは 2 バイト)であるかどうかを確認します。同じでない場合は、エラーがスローされます。

「Cannot add Connection between 4 byte port header to 2 byte port header for chan type NIW or NIW-replace.」


ステップ 1 該当するポートの作成中に使用されたポート ヘッダーを判別します。次に、ポート ヘッダーが一致するポートを使用して、接続を作成します。


 

障害情報 -- /opt/svplus/log ディレクトリから cmsvr ログを収集します。

有効な代替対処法 -- なし

K.12.8.3.6 サービス タイプがサポートされていない--一般的なノード/スロット/ポート/バージョン

接続の追加中に、cmsvr はノード、スロット、およびポート バージョンを調べて、そのバージョンのノード、カード、およびポートでサービス タイプがサポートされていることを確認します。


ステップ 1 そのバージョンのノード、スロット、またはポートが、CTM の該当するサービス タイプをサポートしていることを確認します。

ステップ 2 ConnGroupService.mib で、バージョンおよびサポート対象パラメータをさらに検索します。


 

障害情報 -- /opt/svplus/log ディレクトリから cmsvr ログを収集します。

有効な代替対処法 -- なし

K.12.8.3.7 変更処理中にいずれかの接続テーブルにエンドポイントが格納されていない

接続変更の試行中に、次のエラー メッセージが表示されます。

「Connection [] not found in database.」


ステップ 1 user_connection に、接続に対応する行(エントリ)が存在することを確認します。次のクエリーを実行します。

%> echo "select (*) from user_connection where l_node_id = A and l_slot = B and l_port = C and l_subchnl_1 = D and l_subchnl_2 = E" | dbaccess stratacom

ステップ 2 目的の行が存在しない場合は、対応する接続テーブルで、接続が存在するかどうかを調べます。接続エントリは次のとおりです。

FR の接続

atm_connection(atm セグメント用)

cesm_connection(cesm セグメント用)

rpm_connection(rpm セグメント用)

voice_conn(vism セグメント用)

ステップ 3 接続が存在しない場合は、dbkr_temp テーブルで目的の接続のエントリを検索します。


 

障害情報 -- 次のログ ファイルを収集する必要があります。

/opt/svplus/log ディレクトリ内の cmsvr、sdbroker、および対応する em ログ

セグメント テーブルおよび user_connection テーブル内のエンドポイントのデータベース エントリの出力

有効な代替対処法 -- ノードを再同期するか、または同期アップが完了するまで待機します。

K.12.8.3.8 cmsvr --接続診断の問題

cmsvr プロセスは CM GUI からの接続プロビジョニング要求を検証して、処理します。

接続要求の追加、変更、または削除中に、ILOG(IPC)要求を介して要求が cmgrd プロセスに転送されます。要求が testdelay や testconn(conntrace を除く)などの接続診断用である場合、cmsvr は要求を snmpcomm プロセスに送信して、スイッチに転送します。

K.12.8.3.9 TestConn または TestDelay に失敗してスイッチ エラーが発生する

接続診断(testdelay/testcon/up/down/reroute)に失敗し、次のいずれかのエラー メッセージが表示されます。

TestDelay failed with Switch error

TestConn failed with Switch error


ステップ 1 user_connection テーブルに、目的の接続に関する接続情報を問い合わせます。可能な場合は、ConnProxy(Service Agent)から同じ接続に関する testdelay/testcon 診断を実行して、結果を検証します。

ステップ 2 スイッチ CLI から接続情報を問い合わせて、接続ステータスを検証します(dspcon または dspchan)。

ステップ 3 スイッチ CLI から testdelay/testcon 診断を実行して、結果が CTM の報告内容(tstdelay、tstconn)と一致することを確認します。


 

障害情報 -- 次の処理を実行します。

selnd 出力のキャプチャ

/opt/svplus/logs ディレクトリのすべての cmsvr ログのコピー

指定されたエンドポイントに対する CTM データベースからの user_connection テーブル クエリー出力(要求が追加要求でない場合)

同じ接続に関する testdelay/testconn 診断のスイッチ CLI 出力

有効な代替対処法 -- 接続のステータスを調べて、回線/ポート問題(ループバックの追加、物理ポート接続の検証による物理ケーブル問題の解決など)が原因で発生したアラームをすべて消去します。接続が起動して、Clear 状態になったら、testdelay/testconn 診断に戻ります。


) testcon は単一エンドの SPVC 接続および AXSM カード タイプには適用できません。



) testdelay/testcon 診断を実行する場合は、接続ステータスが Clear または Fail でなければなりません。これらのステータスでない場合は、cmsvr によってテストがブロックされます。



) testconn/testdelay 診断は RP/RPM 接続では実行できません。



) testdelay 診断は音声およびデータ接続に適用できません。



) どの接続でも、接続のローカル端が特定の診断をサポートしない場合は、診断がリモート端から実行できるかどうかが cmsvr によって確認されます。診断が接続の両方のエンドポイントでサポートされていない場合は、該当するエラー メッセージが表示されます。


K.12.8.3.10 接続の起動/終了/再ルーティングに失敗する

接続の起動/終了/再ルーティング診断に失敗し、スイッチ エラーが表示されます。


ステップ 1 user_connection テーブルに、目的の接続に関する接続情報を問い合わせます。

ステップ 2 スイッチ CLI から接続情報を問い合わせて、接続ステータスを検証します(dspcon または dspchan)。

ステップ 3 スイッチ CLI から起動/終了/再ルーティング診断を実行して、結果が CTM の報告内容(upcon、dncon、rrtcon)と一致することを確認します。


 

障害情報 -- 次の処理を実行します。

selnd 出力のキャプチャ

/opt/svplus/logs ディレクトリのすべての cmsvr ログのコピー

指定されたエンドポイントに対する CTM データベースからの user_connection テーブル クエリー出力(要求が追加要求でない場合)

同じ接続に関する起動/終了/再ルーティング診断のスイッチ CLI 出力

有効な代替対処法:

a. 接続のステータスを調べて、回線/ポート問題(ループバックの追加、物理ポート接続の検証による物理ケーブル問題の解決など)が原因で発生したアラームをすべて消去します。接続が起動して、Clear 状態になったら、起動/終了/再ルーティング診断に戻ります。

b. 接続ステータスを確認して、終了処理の試行時に接続がすでにダウン状態であるか、あるいは起動処理の試行時に接続がすでにアップ状態であるかを調べます。


) 接続再ルーティングを実行すると、接続はしばらくの間 Fail 状態になることがあります。


K.12.8.3.11 接続トレースの障害


ステップ 1 接続が Fail 状態でないことを調べます。接続トレースは障害のある接続では機能しません。また、CTM はこの要求をブロックしません。

ステップ 2 user_connection テーブルに、目的の接続に関する接続情報を問い合わせます。

ステップ 3 スイッチ CLI から接続情報を問い合わせて、接続ステータスを検証します(dspcon または dspchan)。

ステップ 4 スイッチ CLI から接続トレース診断を実行して、結果が CTM の報告内容(conntrc、dsptrcbuffer)と一致することを確認します。


 

障害情報 -- 次の処理を実行します。

selnd 出力のキャプチャ

/opt/svplus/logs ディレクトリのすべての cmsvr ログのコピー

/opt/svplus/logs ディレクトリのすべての cmgrd ログのコピー

指定されたエンドポイントに対する CTM データベースからの user_connection テーブル クエリー出力(要求が追加要求でない場合)

同じ接続に関するトレース診断のスイッチ CLI 出力

有効な代替対処法:

a. 接続のステータスを調べて、回線/ポート問題(ループバックの追加、物理ポート接続の検証による物理ケーブル問題の解決など)が原因で発生したアラームをすべて消去します。接続が起動して、Clear 状態で正常に稼働したら、トレース診断に戻ります。

b. 接続ステータスを確認します。接続ステータスが Down の場合は、この接続でトレースを実行できません。接続ステータスが Failed の場合は、トレース結果が空のストリングであることがあります。


) 不完全な接続、または DAX PNNI セグメント接続では接続トレースを実行できません。


K.12.8.4 CMGRD

ここで説明する内容は、次のとおりです。

「高度な Connection Management Subsystem アーキテクチャ」

「cmgrd -- sdbroker のエラー」

「cmgrd -- sdbroker の追加/変更/削除エラー:接続を追加すると、「Fail to Communicate with sDatabroker」エラーが表示される」

「cmgrd -- sdbroker の追加、変更、および削除エラー:接続をプロビジョニングすると、「sDatabroker process busy.Please retry」エラーが表示される」

「cmgrd -- sdbroker の追加エラー:接続を追加すると、「CTM sync-up in progress」エラーが表示される」

「cmgrd -- sdbroker の追加エラー:接続を追加すると「No more vpi/vci available for local trunk end」エラーが表示される」

「cmgrd -- sdbroker の追加エラー:接続を追加すると「EndPoint Exists Local/Remote/Both end of the connection already exists」エラーが表示される」

「cmgrd -- sdbroker 変更/削除エラー:接続を変更または削除すると、「sDatabroker Could not lock connection entry」エラーが表示される」

「cmgrd エラー」

「cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると、「Fail due to Switch Timeout」エラーが表示される」

「cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると、「Agent not responding, request timed-out; or Fatal error, Snmpcomm is not running」エラーが表示される」

「cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると、「Outstanding request exists for same object」エラーが表示される」

「cmgrd --追加/変更/削除エラー:接続をプロビジョニングすると、「Fatal error, IOSMGR is not running, may need to be manually started」エラーが表示される」

「cmgrd --追加エラー:接続をプロビジョニングすると、「Vpi/vci ranges retrieval from svc_operation failed」メッセージが表示される」

「cmgrd --追加/変更/削除エラー:接続をプロビジョニングすると、「Can't get segment info from Database」エラーが表示される」

「cmgrd --スイッチのエラー」

「cmgrd --追加および変更エラー:接続をプロビジョニングすると、「Agent reported bad/wrong value for one of the variables in the request」エラーが表示される」

「cmgrd --追加エラー:接続をプロビジョニングすると、「Object Exists on the Agent or Specified VPI/VCI not available」エラーが表示される」

「cmgrd --追加/変更エラー:接続をプロビジョニングすると「Requested cell rate (lscr/lpcr or rpcr/rscr ) is too high」エラーが表示される」

「cmgrd --追加エラー:接続をプロビジョニングすると、「SPVC is not allowed on this interface」エラーが表示される」

「cmgrd --追加エラー:接続をプロビジョニングすると「Local Channels not enough」エラーが表示される」

「cmgrd --追加および変更エラー:接続をプロビジョニングすると「Error in Traffic Parameters」エラーが表示される」

「cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると「Network Busy, try later」エラーが表示される」

「cmgrd --変更エラー:接続を変更すると「Connection does not exist in CproDb/Agent returned no such name」エラーが表示される」

K.12.8.4.1 高度な Connection Management Subsystem アーキテクチャ

次の図に、Connection Management Subsystem の詳細を示します。

図K-6 Connection Management Subsystem

 

関連する主なインデックスエントリは、connproxy、cmserver、xcmgrd、cmgrd です。

Connection Management Subsystem は次のモジュールで構成されます。

ConnProxy -- CM の SNMP エージェント インターフェイス

CmServer -- CM GUI にバックエンド機能を提供します。

cmgrd -- ConnProxy、CmsServer Clients から要求を受信し、SNMP VarBinds をスイッチに送信して、追加、変更、および削除を行うバックエンド モジュール。以降に追加、変更、削除処理を実行すると、cmgrd は sdbroker に特定の要求のステータスを通知し、sdbroker は CTM データベースを更新します。

次のエラーはすべてのタイプの接続に適用できます(PVC、SPVC、XPVC、および Hybrid)。

K.12.8.4.2 cmgrd -- sdbroker のエラー

追加要求中に、cmgrd は sdbroker から受信したエラーを戻すことがあります。次に、プロビジョニング要求を送信した場合に表示される最も一般的なエラーの一部を示します。

K.12.8.4.3 cmgrd -- sdbroker の追加/変更/削除エラー:接続を追加すると、「Fail to Communicate with sDatabroker」エラーが表示される

関連する主なインデックスエントリは、cmgrd、sdbroker です。

接続の追加、変更、および削除の要求が行われると、cmgrd は sdbroker との ILOG 接続を調べます。このエラーは、sdbroker を使用して要求を処理できるかを cmgrd が確認できない場合に発生します。つまり、cmgrd と sdbroker 間の ILOG 接続が切断されています。

この問題は、sdbroker 側で調査する必要があります。


ステップ 1 sdbroker が起動していて動作していることを確認します。コマンドラインで psg sdbroker を実行します。

ステップ 2 ILOG エラーの sdbroker ログを表示します。マシンで複数の sdbrokers が稼働していることがあります。特定の要求に関して cmgrd が通信する sdbroker を調べるには、次の手順を実行します。

a. cmgrd.log ファイルに vi を実行して、ファイルの末尾に移動します。ストリング sdbroker の後方検索を実行します。このストリングは、cmgrd が通信できない sdbroker の番号(#)を示します。

b. psg sdbroker を実行して、この sdbroker の対応するログ ファイルを調べます。


 

障害情報 -- 次の情報を収集します。

sdbroker プロセス pstack <pid of sdbroker> のスタック トレース

sdbroker および cmgrd ログ

有効な代替対処法 -- なし

K.12.8.4.4 cmgrd -- sdbroker の追加、変更、および削除エラー:接続をプロビジョニングすると、「sDatabroker process busy.Please retry」エラーが表示される

関連する主なインデックスエントリは、cmgrd、sdbroker です。

エラー メッセージ「sDatabroker process busy.Please retry」が表示されます。このメッセージは、cmgrd コマンドで要求を処理することができて、要求が sdbroker に送信されたにもかかわらず、sdbroker が cmgrdの要求のタイムアウト前に応答しなかったことを示します。ただし、cmgrd と sdbroker 間では要求が機能していると認識されます。

障害情報:

sdbroker がプロビジョニング要求中に多くのトラップ(1 秒間に 20 を超える)を処理している場合は、sdbroker に障害はありません。指定時刻にあまり多くの要求が発生しないと予測される場合は、スイッチ、NTS、または EM を調査します。

sdbroker が休止していると認識される場合は、sdbroker の現在のステータスをキャプチャする必要があります。pstack <pid> コマンドを 2 回実行して、出力を保存します。

有効な代替対処法 -- プロビジョニング中に試行を繰り返す必要があります。多くのアラームを送信するスイッチが存在する場合は、そのスイッチの問題を解決することが最適なソリューションです。sdbroker が長期間休止している場合は、sdbroker を強制終了して、再起動する必要があります。

K.12.8.4.5 cmgrd -- sdbroker の追加エラー:接続を追加すると、「CTM sync-up in progress」エラーが表示される

関連する主なインデックスエントリは、cmgrd、sdbroker、sync-up です。

システムが同期プロセス中の場合は、接続をプロビジョニングできません。「CTM sync-up in progress」というエラーが表示されます。

システムが実際に同期しているかどうかを判別する必要があります。システムがまだ同期中の場合、この動作は適切です。


ステップ 1 /opt/svplus/log/.DBKR_SYNCHUP_MESSAGE にある同期ログを表示します(ファイル名の前のピリオド [.] があることに注意してください)。最新の「xxx Start Begin at」行を検索します(xxx は Warm または Cold です)。コールドスタートでは所要時間が数時間になることがありますが、ウォームスタートでは所要時間が短縮されます。ファイルの末尾に「Declare Sync-Up Complete」または「Warmstart Cache Rebuild Complete」で開始する行がある場合は、同期が終了していて、DMD に問題があります。

ステップ 2 同期が完了していない場合は、同期の開始時刻を表示します。この時刻をキーワード SYNCHUP_ALL_NODES_SYNC_WAIT_LIMIT の横にある /usr/user/svplus/config/dmd.conf ファイルで識別された最大同期時間と比較します。同期に要した時間が dmd.conf ファイルで識別された時間よりも長い場合は、DMD に問題があります。

ステップ 3 システムがまだ同期中の場合、システムは正しく動作しています。


 

障害情報 -- DMD に問題がある場合は、DMD、cmgrd、sdbroker、およびメッセージ ログと、/opt/svplus/log ディレクトリ内にある .DBKR_SYNCHUP_MESSAGE および .DMD_SYNCHUP_MESSAGE* ファイルを保存します。

有効な代替対処法 -- DMD に強制同期信号を送信して、強制的にシステムに同期を宣言させます。このようにしても、ノードはモード「3」に短時間で移行しませんが、一部のノードをプロビジョニングし、その他のノードに同期プロセスを実行できます。


ステップ 1 CWM コマンドラインでコマンド selnd を実行します。ノードはモード 3 です。強制同期後にプロビジョニングされた接続は、モードが 3 のノードのみを経由できます。

ステップ 2 コマンド kill -ALRM dmd を入力して、同期信号を DMD に送信します。

ステップ 3 .DBKR_SYNCUP_MESSAGE ファイルを表示して、同期を完了します。


 

K.12.8.4.6 cmgrd -- sdbroker の追加エラー:接続を追加すると「No more vpi/vci available for local trunk end」エラーが表示される

関連する主なインデックスエントリは、cmgrd、sdbroker、vpi/vci です。

プロビジョニングに失敗し、次のエラー メッセージが表示されます。

「No more vpi/vci available for local trunk end」および「Remote trunk」

「Local end of the connection already exists」、「Remote end」、および「Both end」

「Vpcon already exists for Local Vpi」、「Remote Vpi」、および「Both ends」

これらの各エラー メッセージは、プロビジョニングの失敗理由を識別します。これらはエラー中に表示されることがあります。エラーの原因は、スイッチと DMD のキャッシュの不一致です。不一致が発生したかどうかを調べるには、コマンドpkill -USR1 dmd を使用して DMD キャッシュをダンプし、エラーに対応付けられたエンドポイントで、キャッシュ内の値とスイッチの値を比較します。

障害情報 -- スイッチおよび DMD キャッシュが同期していない場合は、該当するノードの DMD ログ、メッセージ ログ、DMD キャッシュ ダンプ、および EM ログが必要です。該当する接続のスイッチ CLI のスクリーンショットも必要です。

有効な代替対処法 -- キャッシュに不一致が存在する場合は、キャッシュを再同期する必要があります(/opt/svplus/tools/CacheResync)。DMD キャッシュに不一致が存在しない場合は、この動作が通常動作です。別の接続追加パラメータを選択する必要があります。

K.12.8.4.7 cmgrd -- sdbroker の追加エラー:接続を追加すると「EndPoint Exists Local/Remote/Both end of the connection already exists」エラーが表示される

関連する主なインデックスエントリは、cmgrd、sdbroker、endpoint exists です。

追加接続要求中に、cmgrd は sdbroker から中間エンドポイント vpi/vci を要求します。sdbroker がスイッチですでに使用されているエンドポイントを誤って選択した場合、cmgrd はこれらのエンドポイントをプロビジョニングして、エラー「endpoint exists」をユーザに戻します。


ステップ 1 スイッチにすでに存在しているエンドポイントを判別します(すでに存在しているエンドポイントが中間エンドポイントの場合は、sdbroker に問題があります)。

a. ハイブリッド 接続をプロビジョニングすると、CMGRD は sdbroker から中間エンドポイントを要求します。次に、sdbroker は DMD から中間エンドポイントを要求して、CMGRD に戻します。最初に dbcmap コマンド(/opt/svplus/tools/dbcmap)を使用して、ノード処理に使用される DMD を識別します。その後、目的の DMD のキャッシュをダンプします。DMD のキャッシュに該当するエンドポイントが格納されていることを確認します。

b. DMD に、スイッチ上にあるエンドポイントの情報が格納されていない理由を判別します。最初に、EM から DMD に追加メッセージが送信されたかどうかを判別する必要があります。「スイッチと GUI 間の接続の不整合」 を参照してください。追加メッセージが見つからず、ログがコールドスタートに戻らない場合は、EM がこのエンドポイントの処理を実行したかどうかを調べる必要があります。xxx_Connection テーブルでエンドポイントを検索します。エンドポイントが格納されている場合は、EM を調べて、エンドポイントが処理されなかった理由を判別します。エンドポイントが xxx_connection テーブル内にある場合は、EM によってエンドポイントが処理されていますが、エンドポイントが DMD に転送されたかどうかは不明です。


 

障害情報:

スイッチ上の中間エンドポイントに問題があるにもかかわらず、EM で処理されなかったか、または DMD にメッセージが送信されなかった場合は、/opt/svplus/log の EM ログおよび nts ログを調べます。

問題が DMD 内にある場合は、DMD ログ、DMD メッセージ ログ、および DMD キャッシュ ダンプが必要です。

有効な代替対処法 -- なし

K.12.8.4.8 cmgrd -- sdbroker 変更/削除エラー:接続を変更または削除すると、「sDatabroker Could not lock connection entry」エラーが表示される

関連する主なインデックスエントリは、cmgrd、sdbroker、lock connection です。

変更または削除接続要求中に、sdbroker がキャッシュ内に目的の接続を検出できない場合は、このエラーが発生することがあります。

変更または削除接続障害が発生する場合はすべて、同じエラーが表示されます。発生内容を正確に特定するには、/opt/svplus/log/sdbrokerX.XXXX.log ファイルを表示する必要があります。


ステップ 1 ファイル末尾付近にあるエラー「<sDbkr_CmgrdModConn_c::Process> INTERFACE ERROR」を検索します。同じ行のあとの方に、エラーの詳細理由が記載されています。


) 削除接続要求の場合は、
sDbkr_CmgrdDelConn_c::Process instead of sDbkr_CmgrdModConn_c::Process を検索します。



 

障害情報:

スイッチ上の中間エンドポイントに問題があるにもかかわらず、EM で処理されなかったか、または DMD にメッセージが送信されなかった場合は、/opt/svplus/log の EM ログおよび nts ログを調べます。

問題が DMD 内にある場合は、DMD ログ、DMD メッセージ ログ、および DMD キャッシュ ダンプが必要です。

有効な代替対処法 -- なし

K.12.8.4.9 cmgrd エラー

追加要求中に、cmgrd は snmpcomm またはスイッチ自体から受信したエラーを戻すことがあります。

K.12.8.4.10 cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると、「Fail due to Switch Timeout」エラーが表示される

関連する主なインデックスエントリは、cmgrd、timeout です。

追加、変更、または削除接続要求を行うと、cmgrd は SET または GET のいずれかの SNMP コミュニティ ストリングを含む要求をスイッチに送信します。これらのコミュニティ ストリングはプロセス snmpcomm によって上書きされます。このプロセスでは、node_info テーブル内にあるストリング値を使用します。したがって、スイッチからのプロビジョニング要求がタイムアウトした場合、問題として考えられるのは、node_info 内にあるノードのコミュニティ ストリングがノード自体のストリングと一致しないことです。

この問題を調査するには、ノードおよび node_info テーブルのコミュニティ ストリングを調べます。


ステップ 1 コマンド dsnmp を発行して、ノード上のコミュニティ ストリングを調べます。

ステップ 2 node_id に基づいて、node_info テーブル内のコミュニティ ストリングを調べます。このストリングは暗号化されているため、ストリングをクリア形式で表示する暗号解除バイナリを使用します。

ステップ 3 ストリングを相互に参照して、確かに異なっている場合は、次のいずれかの方法でストリングを変更します。

ノード上でコマンド cnfsnmp を発行し、コミュニティ ストリングを CTM に合わせて変更します。

RunConfigurator プロセスを使用して、CTM のストリングをスイッチに合わせて変更します。


 

障害情報 -- これらの方法が機能しない場合は、次の情報を収集します。

/opt/svplus/cmgrd.log ディレクトリ内の cmgrd.log

クエリー「select (*) from node_info where node_id = X」の出力

K.12.8.4.11 cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると、「Agent not responding, request timed-out; or Fatal error, Snmpcomm is not running」エラーが表示される

関連する主なインデックスエントリは、cmgrd、snmpcomm です。

追加、変更、または削除接続要求を行うと、cmgrd はスイッチに要求を送信しますが、この要求は実際はプロセス snmpcomm に最初に送信され、そこからノードに SNMP SET/GET が送信されます。この場合は、これらのエラーがプロセス snmpcomm によって戻されるか、または snmpcomm プロセスからのタイムアウト エラーや ILOG 通信エラーが発生することがあります。

snmpcomm がタイムアウト エラーを送信できるのは、snmpcomm が要求を処理していて極端にビジーであり、その時点で要求をこれ以上受け入れられないためです。「SnmpComm not Running」エラーの原因は、cmgrd が ILOG の接続を確立できなかったことです。


ステップ 1 コマンド psg snmpcomm を発行して、プロセスが確かに稼働していることを確認します。

ステップ 2 corefilesdir ディレクトリで snmpcomm コアダンプを検索します。

数分間待機してから要求を再発行して、タイムアウト エラーに対処します。

snmpcomm プロセスが稼働していないことを確認した場合は、ウォームスタートを実行して、プロセスを起動する必要があります。プロセスが起動すると、cmgrd との ILOG 接続が確立されます。


 

障害情報:

要求を再発行しても同じタイムアウト エラーが発生する場合は、cmgrd.log および snmpcomm.log を収集します。

ウォームスタート後に snmpcomm プロセスが稼働しない場合は、watchdog.log ファイルを収集します。

有効な代替対処法 -- しばらく待機してから、要求を再発行します。しばらく待機すると、snmpcomm によって保留中の要求をクリアできます。ウォームスタートを実行して、snmpcomm プロセスを起動します。

K.12.8.4.12 cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると、「Outstanding request exists for same object」エラーが表示される

関連する主なインデックスエントリは、cmgrd、outstanding request です。

追加、変更、または削除接続要求が行われると、cmgrd プロセスはこれらの要求をマルチスレッド方式で処理します。スイッチが応答するシナリオが複数あるため(タイムアウトなど)、要求の処理に要する時間が 3 分を超えることがあります。CM GUI からの要求の処理時間が 3 分を超えた場合、GUI はタイムアウトし、ユーザに通知します。Connection Proxy パスからのタイムアウト値は 2 分であり、その時間が過ぎるとタイムアウト エラーになります。

この要求を即座に再発行すると、cmgrd はエラー「Outstanding requests exists for the same object」を戻すことがあります。

このエラーが戻されるのは、クライアント(CM GUI および Connection Proxy)がタイムアウトした初期要求を cmgrd がまだ処理しているためです。典型的な例は、マルチセグメント構成においてスイッチ タイムアウトが受信され、cmgrd が別のセグメントから撤退し、他のセグメントのタイムアウト応答を待機していて、ビジー状態である場合です。cmgrd がまだ稼働していることを確認するには、次のコマンドを発行します。


ステップ 1 コマンド psg cmgrd を発行して、プロセスが確かに稼働していることを確認します。

ステップ 2 corefilesdir ディレクトリで cmgrd コアダンプを検索します。コア ダンプが存在した場合は、コアファイルを収集します。

ステップ 3 logs ディレクトリで tail -f cmgrd.log を実行して、cmgrd が要求を処理しているかどうかを確認します。

数分間待機してから、要求を再発行します。


 

障害情報 -- 要求を再発行しても同じタイムアウト エラーが発生する場合は、cmgrd.log を収集します。

有効な代替対処法 -- しばらくあとに要求を再発行します。しばらく待機すると、cmgrd によって保留中の要求をクリアできることがあります。

K.12.8.4.13 cmgrd --追加/変更/削除エラー:接続をプロビジョニングすると、「Fatal error, IOSMGR is not running, may need to be manually started」エラーが表示される

関連する主なインデックスエントリは、cmgrd、iosmgr です。

Popeye1 RPM Card が搭載された状態で追加、変更、または削除接続要求を行うと、cmgrd はスイッチに要求を送信しますが、この要求は実際はプロセス iosmgr に送信され、そこから予定されたスクリプト セッションを介してノードに要求が送信されます。この場合、cmgrd が ILOG 接続を介して iosmgr と通信できない場合に、このエラーが戻されることがあります。

このエラーの原因は、cmgrd が iosmgr との ILOG 接続を確立できなかったことです。


ステップ 1 コマンド psg iosmgr を発行して、プロセスが確かに稼働していることを確認します。

ステップ 2 corefilesdir ディレクトリで iosmgr コアダンプを検索します。

iosmgr プロセスが稼働していないことを確認した場合は、ウォームスタートを実行して、プロセスを起動する必要があります。プロセスが起動すると、cmgrd との ILOG 接続が確立されます。


 

障害情報 -- ウォームスタート後に iosmgr プロセスが起動しない場合は、runiosmgr.log ファイルを収集します。

有効な代替対処法 -- なしPop1 RPM カードで iosmgr をプロビジョニングするには、iosmgr が稼働している必要があります。

K.12.8.4.14 cmgrd --追加エラー:接続をプロビジョニングすると、「Vpi/vci ranges retrieval from svc_operation failed」メッセージが表示される

関連する主なインデックスエントリは、cmgrd、svc_operation です。

このエラーが表示されるのは、ハイブリッド接続追加要求の場合のみです。cmgrd は送信側トランク ポートの svc_operation テーブルに vpi/vci 範囲を問い合わせます。次にこれらの範囲が sdbroker に渡され、sdbroker は cmgrd がこの送信側トランク ポートに設定するために使用できる vpi/vci を戻します。

このエラーの原因は、cmgrd が svc_operation テーブルに送信側トランク ポートの vpi および vci 範囲を問い合わせた場合に、テーブル内にエントリがないことです。


ステップ 1 ハイブリッド接続追加要求を再発行し、cmgrd.log の末尾に追加します。

ステップ 2 このログでは、クエリーは「SELECT MIN_SVCC_VPI, MAX_SVCC_VPI, MIN_SVCC_VCI, MAX_SVCC_VCI FROM SVC_OPERATION WHE RE NODE_ID = X AND SLOT = X AND PORT + 1 = X」の形式で記載されます。これは実際に失敗したクエリーです。

ステップ 3 コマンドラインまたは dbaccess stratacom プロンプトからクエリーを実行して、svc_operation テーブルに格納されていないポートの情報を特定します。ポートがテーブルに格納されない理由は、ポートのリソース パーティションを CLI で設定できないことなどです。CLI を起動して、このポートに対してコマンド addpart を発行します。

ステップ 4 CLI でコマンド addpart を発行したら、CTM テーブル svc_operation データベースで該当する行があることを確認します。該当する行が存在する場合は、接続要求を再発行できます。該当する行が svc_operation に存在しない場合は、EM に問題がある可能性があります。


 

障害情報 -- CLI でリソース パーティションを設定しても、svc_operation テーブルが読み込まれない場合は、「機器管理の問題」を参照して、適切な ooemc ログを収集します。

有効な代替対処法 -- なし

K.12.8.4.15 cmgrd --追加/変更/削除エラー:接続をプロビジョニングすると、「Can't get segment info from Database」エラーが表示される

関連する主なインデックスエントリは、cmgrd、segment info です。

cmgrd がいずれかの CTM データベース テーブルから現在の接続要求に対応する行を取得できない場合は、このエラーが戻されます。要求が追加された場合は、ノードまたは bis_object テーブルからの中間エンドポイントのクエリーに失敗することがあります。要求が変更または削除要求の場合は、ノードおよび bis_object テーブルへのクエリーに失敗するだけでなく、user_connection テーブルに接続が見つからない可能性もあります。

この場合は、追加要求と、変更または削除要求で異なる、複数の障害理由が存在する可能性があります。ただし、通常は、現在の要求に対応するノード、bis_object、および user_connection テーブルに対するクエリーの 1 つが失敗した場合に、このエラーが戻されます。基本的なチェック作業は、該当するノードおよび中間ノードが CTM と実際に同期しているかどうかを判別することなどです。また、CM GUI および Connection Proxy の両方のパスから同じ要求を実行する必要もあります。

このエラーの性質により、CTM DE を調査することが最適です。

障害情報 -- cmgrd.log、cmsvr.log、ConnProxy*.log、および sdbroker*.log を収集します。

有効な代替対処法 -- なし

K.12.8.4.16 cmgrd --スイッチのエラー

追加、変更、または削除要求中に、cmgrd はスイッチに SNMP 要求を送信します。スイッチが SNMP 要求を拒否した場合、cmgrd は Error MIB テーブルに問い合わせて、表示するエラー ストリングを取得します。

K.12.8.4.17 cmgrd --追加および変更エラー:接続をプロビジョニングすると、「Agent reported bad/wrong value for one of the variables in the request」エラーが表示される

関連する主なインデックスエントリは、cmgrd、bad value です。

追加または変更接続要求を発行すると、cmgrd を介してスイッチに SNMP VarBind が設定されます。スイッチはこのエラーを表示して、VarBind を拒否できます。

このエラーの原因は、cmgrd がいずれかの MIB オブジェクトに無効な値を送信したことです。このエラーが、cmgrd がクライアントから受信したデータ、または接続の反対側から内部的にマッピングされたデータに問題があることを示している場合、CTM DE はこのエラーを調査する必要があります。

Connection Proxy および CM GUI インターフェイスから同じ接続を試行して、両方のクライアントから動作を観察します。両方のクライアントからのプロビジョニング結果が同じである場合は、通常、cmgrd または sdbroker vpi/vci に問題があります。

障害情報 -- cmgrd.log、ConnProxy*、cmsvr.log、および sdbroker*.logs を収集する必要があります。

有効な代替対処法 -- デフォルト値を使用して追加を実行している場合は、対処法はありません。ただし、変更を実行している場合は、変更中のオブジェクト値を変更して、接続を再試行できます。また、sdbroker は古い vpi/vci の組み合わせを再利用しないため、sdbroker vpi/vci に問題がある場合は、接続を再試行してください。

K.12.8.4.18 cmgrd --追加エラー:接続をプロビジョニングすると、「Object Exists on the Agent or Specified VPI/VCI not available」エラーが表示される

関連する主なインデックスエントリは、cmgrd、object exists です。

追加接続要求を発行すると、cmgrd を介してスイッチに SNMP VarBind が設定されます。スイッチはこの VarBind を拒否することがあるため、スイッチ エラー テーブルに今後 cmgrd クエリーを実行すると、これらのエラーが戻されることがあります。

このエラーの原因は、CTM が追加しようとしている接続がスイッチ上にすでに存在することです。これが、ユーザ エンドポイントまたは中間エンドポイントになることがあります。


ステップ 1 同じ操作を再試行します。2 回めの試行に成功した場合は、中間エンドポイントの vpi/vci がスイッチに存在しています。この場合は、cmgrd-sdbroker エラー「EndPoint Exists Local/Remote/Both end of the connection already exists」を調べます。

ステップ 2 スイッチが 2 回めの試行で同じエラーを戻した場合は、CTM データベースとスイッチに矛盾があり、CTM DE でデバッグする必要があります。


 

障害情報 -- cmgrd.log、ConnProxy*.log、cmsvr.log、および sdbroker*.log を収集します。

有効な代替対処法 -- 接続追加を複数回再試行します。それでも失敗する場合は、CTM DE で問題を調べる必要があります。

K.12.8.4.19 cmgrd --追加/変更エラー:接続をプロビジョニングすると「Requested cell rate (lscr/lpcr or rpcr/rscr ) is too high」エラーが表示される

関連する主なインデックスエントリは、cmgrd、cell rate です。

追加または変更接続要求中に、接続を設定しているポートに、現在の SNMP SET が要求しているトラフィック パラメータを受け入れるためのリソースがない可能性があります。この時点でスイッチは要求を拒否して、このエラーを戻します。


ステップ 1 ユーザ エンドポイントの場合は、コマンド dsppnportrsrc を使用して CLI でユーザ ポートを調べます。このコマンドはポートごとに使用可能なリソースを示します。

ステップ 2 ユーザ エンドポイント ポートでなく、中間ポート(マルチセグメント接続の場合など)で障害が発生している場合は、ローカルおよびリモート エンドポイントの送信側トランク ポートを判別します(そのためには、Network Topology GUI を使用します)。

ステップ 3 CLI で、dsppnportrsrc コマンドを実行して、送信側トランク ポートを検索します。


 

障害情報 -- これらの接続を追加するために必要な帯域幅がポートにあることを確認したあとも、このエラーが引き続き表示される場合は、cmgrd.log を保存します。

有効な代替対処法 -- 接続を追加するための帯域幅が必要なポート上でリソースを解放するか、接続要求内のトラフィック パラメータ値を小さくします。

K.12.8.4.20 cmgrd --追加エラー:接続をプロビジョニングすると、「SPVC is not allowed on this interface」エラーが表示される

関連する主なインデックスエントリは、cmgrd、interface です。

追加接続要求中に、接続を設定しているユーザ エンドポイント ポートに不正な信号が設定されている可能性があります。このエラーは、この状態を示しています。

非トランキング ポートの場合は、ポートの信号を PNNI にすることはできません。


ステップ 1 ユーザ エンドポイントの場合は、次の手順を実行します。

a. dsppnport コマンドを使用して、インターフェイスが PNNI ポートまたはコントローラ ポートであることを確認します。

b. ポートを UNI ポートに変更します。この処理を実行する前に、このインターフェイスを通過中のコールがないことを確認します。

dnpnport <portID>
cnfpnportsig <portID> -univer uni30

ステップ 2 設定を変更したら、接続要求を再試行します。


 

障害情報 -- 該当なし。このエラーはスイッチ設定に関する問題です。

K.12.8.4.21 cmgrd --追加エラー:接続をプロビジョニングすると「Local Channels not enough」エラーが表示される

関連する主なインデックスエントリは、cmgrd、channels です。

追加接続要求中に、接続を設定しているユーザ エンドポイント ポートまたはカードが許容できる接続数の上限にすでに達している可能性があります。

CLI でユーザ エンドポイントのポートまたはカードを調べます。


ステップ 1 dsppnportrsrc を使用して、エンドポイントのポート リソースを調べます。

ステップ 2 LCN 数がゼロの場合は、このインターフェイスから接続をいくつか削除します。

ステップ 3 設定を変更したら、接続要求を再試行します。


 

障害情報 -- 該当なし。このエラーはスイッチ設定に関する問題です。

K.12.8.4.22 cmgrd --追加および変更エラー:接続をプロビジョニングすると「Error in Traffic Parameters」エラーが表示される

関連する主なインデックスエントリは、cmgrd、traffic parameters です。

追加または変更接続要求中に、ローカル エンドポイントのリモート パラメータが、リモート エンドポイントのローカル パラメータと一致しない場合は、スイッチによってこのエラーが表示されます。特定のパラメータは、接続のサービス タイプに依存します。


) このエラーはデバッグが困難です。このエラーは、スイッチに設定されているローカル/リモート(またはリモート/ローカル)マッピングの値に問題があることを示しているため、Connection Management DE で調べる必要があります。



ステップ 1 CM GUI および Connection Proxy の両方のインターフェイスから接続を再試行します。

ステップ 2 両方のインターフェイスの結果が同じである場合は、cmgrd のバグである可能性があります。いずれかのインターフェイスから要求に成功した場合は、クライアントに問題がある可能性があります。


 

障害情報 -- cmgrd.log、ConnProxy*.log、および cmsvr.log を収集します。

有効な代替対処法 -- 接続要求内のトラフィック パラメータ値をいくつか変更して、接続を再試行します。

K.12.8.4.23 cmgrd --追加、変更、および削除エラー:接続をプロビジョニングすると「Network Busy, try later」エラーが表示される

関連する主なインデックスエントリは、cmgrd、network busy です。

追加または変更接続要求中に、スイッチがこのエラーを戻した場合は、コントローラ カードに CPU 中心のアクティビティがいくつか発生しています。cmgrd 要求は他のセグメントから撤回され、このエラーが戻されます。ただし、削除処理は有害なコマンドであるため、この場合は処理が撤回されません。

このエラーの対処法はありません。待機してから、要求を再試行する必要があります。待機および再試行を何回か繰り返してもエラーが表示される場合は、スイッチ側で問題を調べる必要があります。

障害情報 -- 該当なし

有効な代替対処法 -- 待機し、あとで接続を再試行します。

K.12.8.4.24 cmgrd --変更エラー:接続を変更すると「Connection does not exist in CproDb/Agent returned no such name」エラーが表示される

関連する主なインデックスエントリは、cmgrd、cprodb です。

変更接続要求中に、接続がスイッチ上に実際に存在しない場合は、このエラーが戻されることがあります。

user_connection テーブル内の接続を確認します。このエントリで、すべてのセグメントがスイッチ CLI 上に存在することを確認します。すべてのセグメントがスイッチ CLI 上に実際に存在する場合は、スイッチ側で問題を調べる必要があります。ただし、スイッチ上にセグメントが存在しない場合は、sdbroker または EM に問題がある可能性があります。

障害情報 -- sdbroker または EM に問題があると考えられる場合は、該当するログおよび cmgrd.log を収集します。接続のすべてのセグメントがスイッチ上にある場合でも、このエラーが戻される場合は、スイッチの DE に連絡してください。

有効な代替対処法 -- なし

K.12.9 Diagnostics Center の問題

Diagnostics Center は、次のネットワーク要素レベルごとに異なる診断処理を実行します。

ネットワーク診断

ネットワーク内にあるすべてのノードの現在の同期ステータスおよびアラーム ステータスを取得します。

ネットワーク/ノード ヘルス統計情報および管理性チェックをサポートします。ネットワーク レベルでは、ノード管理性チェックの結果のみがサポートされます。

ノード診断

現在の同期ステータス、ノード アラーム ステータス、IP アドレス、およびその他のノード属性を取得します。

ノード内のすべてのカードの同期ステータスを取得します。

ノード再同期を要求します。

VSI パーティション データを要求し、ノードに VSI 一貫性チェックも実行します。

SNMP 成功数や FTP/TFTP 成功/失敗数などのノード ヘルス統計情報をサポートします。

IP の到達可能性や SNMP コミュニティ ストリング チェックなど、ノード管理性チェックを実行します。

カード診断

カードレベル情報(同期ステータス、カード ステータス、ファームウェア バージョンなど)を取得します。

この機能をサポートするカードのカード CPU 使用率を取得します。

この機能をサポートするカードのメモリ プール使用率情報を取得します。

この機能をサポートするカードのメモリ バッファ プール使用率情報を取得します。

カードレベルのリアルタイム統計情報があれば、取得します。

カードでループバックされているすべての回線およびパスの情報を取得します。

カードで現在稼働している BERT テストの情報を取得します。

現在稼働している IMA リンク テストの情報を取得します。

ポート診断

ポート ステータスなどのポートレベル属性を取得します。

ループバックを実行します。

開始/停止/変更 BERT を実行します。

BERT の結果または現在のステータスを取得します。

スケジュールされたグルーミング結果をモニタします。

オンデマンド グルーミングを設定します。

ポートレベルのリアルタイム統計情報を取得します。

回線診断

回線ステータスやループバック ステータスなどの回線レベル属性を取得します。

ループバックを実行します。

開始/停止/変更 BERT を実行します。

BERT の結果または現在のステータスを取得します。

回線レベルのリアルタイム統計情報を取得します。

パス診断

パス ステータスなどのパスレベル属性を取得します。

ループバックを実行します。

パスレベルのリアルタイム統計情報を取得します。

トランク診断

トランクローカルおよびリモート側のリアルタイム統計情報を取得します。

IMA グループ診断

IMA グループ ステータスなどの IMA グループレベル属性を取得します。

IMA グループのすべての IMA リンクに関する累積遅延を取得します。

IMA グループのすべての IMA リンクに関する累積遅延をクリアします。

IMA グループを再起動します。

IMA グループ ATM セル レイヤ入力/出力カウンタを取得します。

IMA グループレベルのリアルタイム統計情報を取得します。

IMA リンク診断

IMA リンク ステータスなどの IMA リンクレベル属性を取得します。

IMA リンク テストを開始または停止します。

IMA リンク テスト パターンを変更します。

IMA リンクレベルのリアルタイム統計情報を取得します。

接続診断

接続ステータスなどの接続レベル属性を取得します。

A ビット、AIS、OAM などのローカルおよびリモート エンドポイント属性を取得します。

ローカルおよびリモート エンドポイントのリアルタイム統計情報を取得します。

CM Server との Diagnostics Server インターフェイスは、次の接続関連診断処理をサポートします。

接続ループバック

アップ状態の接続

ダウン状態の接続

接続トレース

テスト接続

テスト遅延

テスト接続セグメント

テスト ping OAM

K.12.9.1 Diagnostics Center のフレームワーク

ここで説明する内容は、次のとおりです。

「Diagnostics Center を起動できない」

「Diagnostics Center から別のアプリケーションを起動できない」

「Diagnostics Center の起動時に例外が発生する」

「Diagnostics Center ツリー ビューでダブルクリックを実行しても 内部フレームが起動しない」

「Diagnostics Center でのドラッグアンドドロップ機能エラー」

「Diagnostics Center とその他のアプリケーション間のドラッグアンドドロップ」

「ターゲットをドロップすると不正なオブジェクトまたはオブジェクト データが表示される」

「Diagnostics Center が応答しない(GUI がグレー表示になる)」

K.12.9.1.1 Diagnostics Center を起動できない

次のいずれかの方法を使用しても、Diagnostics Center を起動できません(メイン ウィンドウが表示されません)。

Launch Center または任意のアプリケーションで Diagnostics Center アイコンをクリックする

任意のアプリケーションで Tools > Diagnostics Center を選択する

階層ツリーで選択したノードを右クリックして、Diagnostics Center を選択する


ステップ 1 /opt/svplus/java/jars/cwm ディレクトリの diagcenter.jar ファイルを調べます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCSserver.log ファイル

有効な代替対処法 -- なし

K.12.9.1.2 Diagnostics Center から別のアプリケーションを起動できない

次のいずれかの方法を使用しても、Diagnostics Center から別のアプリケーションを起動できません。

Tools メニュー項目でターゲット アプリケーションを選択する。

階層ツリーで選択したオブジェクトを右クリックして、ターゲット アプリケーションを選択する。


ステップ 1 ターゲット アプリケーションの jar ファイルを調べます。ターゲット アプリケーションの jar ファイルがターゲット マシンの /opt/svplus/java/jars/cwm ディレクトリにあることを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.1.3 Diagnostics Center の起動時に例外が発生する

次のいずれかの方法を使用して Diagnostics Center を起動した場合、例外が起動され、Java Console に例外トレース情報が表示されます。

Tools メニュー項目でターゲット アプリケーションを選択する。

階層ツリーで選択したオブジェクトを右クリックして、ターゲット アプリケーションを選択する。

障害情報 -- 次の情報を収集して、さらに分析します。

Java Console 情報

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.1.4 Diagnostics Center ツリー ビューでダブルクリックを実行しても 内部フレームが起動しない

Diagnostics Center ツリー ビューでオブジェクトをダブルクリックしても、コンテンツ ウィンドウの内部フレームは起動しないため、コンテキスト ペイン(内部フレーム)内にオブジェクトは開かれません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

Java Console 情報

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.1.5 Diagnostics Center でのドラッグアンドドロップ機能エラー

Diagnostics Center ツリー ビューからコンテンツ ペインにネットワーク要素をドラッグアンドドロップしても、(a)内部フレームを開いたり、既存フレームの内容をリサイクルしてオブジェクトの属性を表示できない、または(b)「Operation Not Supported」メッセージ ダイアログボックスが表示されます。


ステップ 1 ドロップされたオブジェクトに対してドラッグアンドドロップ機能がサポートされているかどうかを判別します。

ツリー ビューから Diagnostics Center コンテンツ ペインにドロップできるオブジェクトは、次のとおりです。

Element タブの場合、Network、Node、Card、Line、Port、IMA、および IMA リンク オブジェクトはサポートされていますが、「Folder」オブジェクトはサポートされていません。

Connection タブの場合、Node、Card、Line、および Port オブジェクトはサポートされていますが、Folder、IMA、および IMA リンク オブジェクトはサポートされていません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.1.6 Diagnostics Center とその他のアプリケーション間のドラッグアンドドロップ

Diagnostics Center をドロップ元として、そこから別の CTM アプリケーションにオブジェクトをドラッグアンドドロップしても、選択したオブジェクトはターゲット アプリケーションに表示されません。

Diagnostics Center のコンテンツ ペインをドラッグ先として、他のアプリケーションからそこにドラッグアンドドロップしても、(a)内部フレームを開いたり、既存フレームの内容をリサイクルして、ドロップされたオブジェクトの属性を表示できない、または(b)「Operation Not Supported」メッセージ ダイアログボックスが表示されます。


ステップ 1 選択されたオブジェクトに対してドラッグアンドドロップ機能がサポートされているかどうかを判別します。

ステップ 2 ドロップされたオブジェクトに対してターゲット アプリケーションがドラッグアンドドロップ機能をサポートしているかどうかを判別します。

ステップ 3 ドラッグ元およびドラッグ先アプリケーションが Java VM の同じインスタンスに属しているかどうかを確認します。CTM フレームワークは、別の Java VM に属するアプリケーション間でのドラッグアンドドロップ機能をサポートしません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.1.7 ターゲットをドロップすると不正なオブジェクトまたはオブジェクト データが表示される

Diagnostics Center の内部フレームが正常に開きますが、別のオブジェクトに関連する情報が表示されるか、またはドロップされたオブジェクトの属性値が正しくありません。

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.1.8 Diagnostics Center が応答しない(GUI がグレー表示になる)


ステップ 1 Java DOS ウィンドウがイネーブルであるかどうかを判別します。

a. WebStart アプリケーションを起動します。

b. File > Preferences を選択します。

c. Java タブを選択します。

d. 選択した Java エントリの Command カラム エントリを調べて(必要に応じてカラムを展開して、すべての情報を表示します)、このエントリが javaw.exe または java.exe に設定されているかどうかを判別します。

e. Command カラムの設定値が java.exe の場合は、Java DOS ウィンドウがすでにイネーブルであり、DOS ウィンドウ タスクをマシン上で実行する必要があります。それ以外の場合は、Java DOS ウィンドウがディセーブルです(Command カラム エントリは javaw.exe に設定されています)。

ステップ 2 Java DOS ウィンドウがすでにイネーブルである場合は、障害情報を収集します。

ステップ 3 Java DOS ウィンドウがディセーブルである場合は、現在のログ情報だけでは根本原因を特定できません。

a. 現在使用可能なログ情報を収集します。

b. 「javaw.exe」を「java.exe」に変更して、Java DOS ウィンドウをイネーブルにします。

c. WebStart/Java DOS がイネーブルであることを確認します。

d. PC クライアントを使用して GUI アプリケーションを起動し、DOS ボックスが起動したことを確認します。

e. 問題を再現し、WebStart/Java DOS ウィンドウを使用してその他の Java 関連データを収集します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

Java DOS ウィンドウ データ

Java DOS ボックスを選択します。

Ctrl および Break コマンドを発行します。Ctrl キーを押したまま、Break(Pause) キーを押します。このようにすると、DOS ウィンドウに Java スレッド関連情報が表示されます。

データをログ ファイルにコピーして、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSCclient.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

/opt/svplus/log ディレクトリの cmsvr.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.2.1 XML パーサー エラー

XML 解析エラーは、(ドラッグアンドドロップや右クリックを使用して)ネットワーク要素に対して Diagnostics Center を起動している間に表示されます。ポップアップ ウィンドウに「Internal Error:XML Parsing Error」と表示されます。


ステップ 1 このエラーの原因となるエンティティ(ノード、カード、回線、またはポート)が、使用中の CTM バージョンでサポートされているかどうかを確認します。サポート対象のノードあるいはカードでこのエラーが発生する場合は、ステップ 2 に進みます。

ステップ 2 /opt/svplus/log/DCServer.log ファイルを開いて、このエラーの発生時期を示すメッセージ情報を調べます。

a. ログ内の一般的なメッセージは、次のとおりです。

ERR: Fatal Error at file, line 0, char 0, Message: An exception occurred! Type:RuntimeException, Message:The primary document entity could not be opened. Id=/opt/svplus/xml/diagcenter/XXX/XXX-XXX.xml ( <someNumber>: <x>) <someTime Stamp> ERR: InternalError: XML Parsing Error

b. 上記の .xml ファイル名に連続する 2 つのハイフンが含まれている場合(ABC--XYZ.xml など)、またはハイフンが先頭に付加されているか(-ABC.xml など)、ハイフンのあとにファイル拡張子が続く場合(ABC-.xml など)は、ステップ 3 に進みます。このステップでは、不正なフォーマットの XML ファイル名の調査方法を示します。

c. ログ メッセージ内の .xml ファイル(上記ステップを参照)が /opt/svplus/xml/diagcenter ディレクトリ内にあるかどうかを調べます。このディレクトリ内にない場合は、TAC に連絡し、障害情報を提供しください。

ステップ 3 次のステップを実行して、不正な形式の XML ファイル名ストリングを調べます。XML ファイル名のフォーマットは <Platform>-<Card>-<InterfaceType>-<SomeEntityName>.xml です。このフォーマットはいくつかの例外を除いて一般に使用されます。Platform および InterfaceType はオプションであり、多くのファイルでは省略されます(たとえば、ABC-Card.xml は有効な XML ファイル名です)。

a. XML ファイル名の Platform 部分が不正であるか、省略されている場合は、Node テーブルでこのファイルが正しく読み込まれているかどうかを調べます。

b. XML ファイル名の Card 部分が不正であるか、省略されている場合は、Card テーブルでこのファイルが正しく読み込まれているかどうかを調べます。

c. XML ファイル名の InterfaceType 部分が不正であるか、省略されている場合は、該当するテーブルでこのファイルが正しく読み込まれているかどうかを調べます。このテーブルは一般に、このエラーが発生したカードの回線またはポート テーブルに対応します。

d. XML ファイル名の EntityName 部分が不正である場合は、TAC に連絡して、必要な障害情報を提供します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

この問題のデバッグに使用する調査コマンドの完全なスクリーン スナップショット

ログ ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.2.2 MIB オブジェクトのポーリング中の SNMPCOMM_TIMEOUT エラー

Diagnostics Center によるリアルタイム カウンタのポーリング中に、SNMP タイムアウト エラーが発生します。


ステップ 1 ノードのステータスを調べます。

ステップ 2 ノードに到達できる場合は、コミュニティ ストリングが適切に設定されているかどうかを調べます。

ステップ 3 DCServer.log ファイルを調べて、オブジェクトのクエリーに使用しているコミュニティ ストリングが正しく設定されているかどうかを判別します。

ステップ 4 クエリーがスイッチに送信されたかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

D:\Documents and Settings\<username>\log ディレクトリの CMSClient.log ファイル

/opt/svplus/log ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.2.3 Diagnostics Center でノード同期アップ ステータスが表示されない

ネットワーク要素に対して Diagnostics Center が起動されている場合に、ネットワーク内のすべてのノードにノード同期アップ ステータスが表示されません。


ステップ 1 selnd を svplus として実行し、すべてのノードのステータスを調べます。これらが適切に表示されない場合は、EM プロセスに問題がある可能性があります。EM ログを調べます。

ステップ 2 すべてのノードのノード テーブル エントリを調べます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

対応するノードのノード テーブル エントリ

ログ ディレクトリの DCServer.log ファイル

有効な代替対処法 -- なし

K.12.9.2.4 ノードの再同期に失敗する

Diagnostics Center からのノード再同期に失敗します。


ステップ 1 ノードに到達できるかどうかを確認します。

ステップ 2 DCServer.log ファイルに例外があるか調べます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

対応するノードのノード テーブル エントリ

ログ ディレクトリの DCServer.log ファイル

ログ ディレクトリの Emd.log

有効な代替対処法 -- なし

K.12.9.2.5 リアルタイム カウンタのポーリングに失敗する


ステップ 1 ノードに到達できるかどうか、およびコミュニティ ストリングが適切に設定されているかどうかを調べます。

ステップ 2 リアルタイム カウンタを適用できるかどうかを調べます。CLI の該当するコマンドを調べます。

ステップ 3 SNMP ツールを使用して、MIB オブジェクトが取得されているかどうかを調べます。

ステップ 4 カウンタを 1 つずつ選択して、ポーリングに失敗したカウンタを判別し、問題を絞り込みます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log ディレクトリの DCServer.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

該当するカードの dspcd <slot No> の CLI 出力。使用した該当 CLI コマンドの出力

ステップ 4 を実行した場合は、ポーリングに失敗したカウンタのリストを作成します。

有効な代替対処法 -- CLI を使用して、リアルタイム カウンタをモニタします。

K.12.9.2.6 一部のリアルタイム カウンタが表示されない

一部のリアルタイム カウンタが Diagnostics Center で表示されません。


ステップ 1 カウンタをカードに適用できるかどうか(適用できる場合は、バージョン/モード)を調べます。

ステップ 2 CLI の該当するコマンドを調べます。

ステップ 3 SNMP ツールを使用して、MIB オブジェクトが取得されているかどうかを調べます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log ディレクトリの DCServer.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

該当するカードの dspcd <slot No> の CLI 出力

特定のノード/カードの非表示カウンタのリスト

有効な代替対処法 -- CLI を使用して、リアルタイム カウンタ値を取得します。

K.12.9.2.7 BERT 処理を開始、停止、または変更できない

Diagnostics Center から BERT 処理を開始、停止、または変更できません。


ステップ 1 ノードに到達できるかどうか、およびコミュニティ ストリングが適切に設定されているかどうかを調べます。

ステップ 2 カードがアクティブ状態であるかどうかを確認します。

ステップ 3 snmpset に正しい VarBinds が送信されたかどうかを調べます。

ステップ 4 開始、停止、および変更 BERT に設定されたオプションが適用可能であるかどうかを調べます。

ステップ 5 Diagnostics Center で選択されたオプションを使用して、CLIで BERT 処理に成功するかどうかを調べます。

ステップ 6 snmpset で Diagnostics Center が Diagnostics Center サーバに送信するのは、必須の値および変更された値のみです。SNMP ツールとこれらの値のみを組み合わせて、BERT 処理を実行します。この処理に成功した場合、問題の原因は Diagnostics Center にあります。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log ディレクトリの DCServer.log ファイル

スクリーン スナップショット(特に Diagnostics Center BERT ウィンドウ、エラー/情報メッセージ/ダイアログボックス)

有効な代替対処法 -- BERT 処理に CLI/DiagProxy を使用します。

K.12.9.2.8 IMA Link Test パターンを開始/テストできない

Diagnostics Center から IMA Link Test パターンを開始、停止、または変更できません。


ステップ 1 ノードに到達できるかどうか、およびコミュニティ ストリングが適切に設定されているかどうかを調べます。

ステップ 2 カードがアクティブ状態であるかどうかを確認します。

ステップ 3 snmpset に正しい VarBinds が送信されたかどうかを調べます。

ステップ 4 IMA Link Test パターンを CLI から実行できるかどうかを調べます。

ステップ 5 SNMP ツールを使用して、DCServer.log ファイルに表示されているオブジェクトを設定します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log ディレクトリの DCServer.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

有効な代替対処法 -- CLI を使用して、IMA Link Test パターンを処理します。

K.12.9.2.9 接続診断を実行できない

接続診断は CM Server アプリケーションを通して実行されます。Diagnostic Server はすべての接続診断要求を CM Server に転送します。接続診断エラーが発生した場合は、通常、CM Server アプリケーションに問題があります。


ステップ 1 同期アップが完了しているかどうかを確認します。

ステップ 2 ノードに到達できるかどうか、およびコミュニティ ストリングが適切に設定されているかどうかを調べます。

ステップ 3 カードがアクティブ状態であるかどうかを確認します。

ステップ 4 snmpset に正しい VarBinds が送信されたかどうかを調べます。

ステップ 5 DCServer.log ファイルに特定の例外があるか調べます。

ステップ 6 DCServer.log ファイルに例外がない場合、問題の原因は Connection Manager にあります。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log ディレクトリの DCServer.log および cmsvr.log ファイル

スクリーン スナップショット(特に、エラー/情報メッセージ/ダイアログボックス)

有効な代替対処法 -- CLI または SNMP conn プロキシ を使用して、接続を診断します。

K.12.9.2.10 Diagnostics Center のその他の問題

その他の問題が発生した場合は、TAC に連絡し、障害情報を提供しください。


ステップ 1 CLI を通して同様な処理を正常に実行できるかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

問題が発生した操作の説明

/opt/svplus/log ディレクトリの DCServer.log および cmsvr.log ファイル

スクリーン スナップショット

この処理の CLI ダンプ(適用可能な場合)

有効な代替対処法 -- なし

K.12.10 PM の収集および解析の問題

PM 収集はノード全体で実行され、ノード上の適用可能なすべてのカードから統計情報ファイルがアップロードされます。

Stats Parser はこれらの統計情報ファイルを解析して、データベースに統計情報データを格納します。

K.12.10.1 PM 収集の問題

ここで説明する内容は、次のとおりです。

「pmcollector --一般的なトラブルシューティング」

「ノードでの PM 収集の失敗--ログ ファイルに「Node not discovered」と表示される」

「ノードでの PM 収集の失敗--ログ ファイルに「Card not discovered」と表示される」

「ノードでの PM 収集の失敗--ログ ファイルに「Time not synchronized」と表示される」

「ノードでの PM 収集の失敗--ログ ファイルに「Snmp failed」と表示される」

「ノードでの PM 収集の失敗--ログ ファイルに「Ftp failed」と表示される」

「ノードでの PM 収集に失敗する--ログ ファイルに「Polling failed and wait for major retry」、「Major retry failed and wait for critical retry」、「Critical retry failed and wait for history retry」、「History retry failed and wait for next retry」、または「No more retry」が表示される」

K.12.10.1.1 pmcollector --一般的なトラブルシューティング

一般的なトラブルシューティングを実行する場合は、必ず次の手順を実行します。

psg pmcollector コマンドを実行し、結果を調べて、pmcollector プロセスが稼働していることを確認します。

統計情報ファイルが CTM の /opt/svplus/purge ディレクトリ内にあることを確認します。すべての統計情報ファイルを検索します。失われているファイルや、/opt/svplus/spool ディレクトリに蓄積されているファイルがあってはなりません。

file_err_log テーブルでファイル収集に関するすべての障害を検索します。

collsvr_err_log テーブルで、収集の開始、または停止中に発生した障害を検索します。

coll_err_log テーブルで、収集サーバ全体の障害を検索します。

「/opt/svplus/cache/scm/scmcollout.log」で、完了した統計情報ファイルの要求を検索します。

「/opt/svplus/cache/scm/scmcollin.log」で、統計情報ファイルの収集が完了したかどうかを確認します。

「/opt/svplus/cache/scm/scmcollout.log」で、統計情報ファイルの収集に関するエラーを検索します。

K.12.10.1.2 ノードでの PM 収集の失敗--ログ ファイルに「Node not discovered」と表示される

このエラーは、ノードが モード 3 でない場合に発生することがあります。


ステップ 1 次のコマンドを実行して、node_info テーブルを調べます。

echo "select node_not_discovered from node_info where node_id=<node_id> and slot=<slot>" | dbaccess
 

node_not_discovered が 1 に設定されている場合は、ノードが検出されていません。

ステップ 2 次のコマンドを実行して、ノードの統計情報を調べます。

echo "select (*) from node where node_name=<node-name>" | dbaccess
 

ステップ 3 出力でノードのモードを調べます。モードは 3 でなければなりません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

pmcollector.log、selnd の出力、または以下の出力

echo "select (*) from node where node_name = '<node-name>' " | dbaccess
 

関連する主なインデックス エントリ

pmcollector

有効な代替対処法 -- ノードがモード 3 でない場合は、EM モジュールのトラブルシューティング手順を参照してください。

K.12.10.1.3 ノードでの PM 収集の失敗--ログ ファイルに「Card not discovered」と表示される

このエラーは、カードがアクティブ状態でない場合に発生することがあります。


ステップ 1 次のコマンドを実行して、node_info テーブルを調べます。

echo "select card_not_discovered from node_info where node_id=<node_id> and slot=<slot>" | dbaccess
 

card_not_discovered が 1 に設定されている場合は、カードが検出されていません。

ステップ 2 次のコマンドを実行して、カード テーブルを調べます。

echo "select fc_state, fc_type, slot from card where node_id = <node-id> and slot = <slot-num> " | dbaccess
 

カードの fc_state は 3 でなければなりません。


 

障害情報 -- 次の情報を収集して、さらに分析します。

pmcollector.log、以下の出力

echo "select fc_state, fc_type, slot from card where node_id = <node-id> and slot = <slot-num> " | dbaccess
 

関連する主なインデックス エントリ

pmcollector

有効な代替対処法 -- カードが fc_state 3 でない場合は、EM モジュールのトラブルシューティング手順を参照してください。

K.12.10.1.4 ノードでの PM 収集の失敗--ログ ファイルに「Time not synchronized」と表示される

このエラーは、CTM とコレクタ間、またはコレクタとノード間でタイムスタンプが同期していない場合に発生することがあります。


ステップ 1 次のコマンドを実行して、sync_info テーブルを調べます。

echo "select offset from sync_info where sync_node_id=<node_id>" | dbaccess
 

ステップ 2 CTM、Collector およびノードの時刻を調べて、直前のクエリーからのオフセットが時間差(秒単位)になっていることを確認します。

ステップ 3 送信側で、CTM と送信側のルーティング ノード間の時間差を調べます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

pmcollector.log

関連する主なインデックス エントリ

pmcollector

有効な代替対処法 -- CTM、Collector とノードの時刻を同じタイムスタンプになるように設定します。

K.12.10.1.5 ノードでの PM 収集の失敗--ログ ファイルに「Snmp failed」と表示される

このエラーは、不正なコミュニティ ストリングまたはタイムアウトによって SNMP 障害が引き起こされた場合に発生することがあります。


ステップ 1 node_info テーブルで get_str および set_str を調べて、これらがノードのコミュニティ ストリングであることを確認します。コマンド dsnmp を使用して、ノードの SNMP コミュニティ ストリングを調べます。

ステップ 2 ログ ファイルでエラーの詳細を検索するには、"snmp" scm* を grep 検索します。エラーがタイムアウト エラーである場合は、タイムアウト設定を変更し、/opt/svplus/config/pmcollector.conf の設定値を再試行します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

pmcollector.log

関連する主なインデックス エントリ

pmcollector、手動 SNMP の結果

有効な代替対処法 -- コミュニティ ストリングが CTM とノードで異なる場合は、Topology モジュールのトラブルシューティング手順を参照してください。

K.12.10.1.6 ノードでの PM 収集の失敗--ログ ファイルに「Ftp failed」と表示される

このエラーは、さまざまな理由で発生することがあります。一般的な原因は、不正なユーザ名/パスワード、またはタイムアウトです。


ステップ 1 node_info テーブルで node_id、node_name、および IP アドレスを調べて、これらが正しいことを確認します。

ステップ 2 収集開始中に使用される IP ルーティングのタイプを調べます。IP ルーティングで使用される IP アドレスに到達できるかどうか、またはこのアドレスが有効かどうかを確認します。

ステップ 3 stratacom データベースの coll_info テーブルの ftp_user_name と ftp_user_passwd、および node_info テーブルの ftp_user_name とftp_user_passwd が一致していて、有効であることを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

stratacom の pmcollector.log、coll_info テーブルのダンプ、node_info テーブルのダンプ

関連する主なインデックス エントリ

pmcollector

有効な代替対処法 -- 到達可能な atm または LAN IP を使用します。

K.12.10.1.7 ノードでの PM 収集に失敗する--ログ ファイルに「Polling failed and wait for major retry」、「Major retry failed and wait for critical retry」、「Critical retry failed and wait for history retry」、「History retry failed and wait for next retry」、または「No more retry」が表示される

これらのエラーはさまざまな原因によって発生することがありますが、主な原因は FTP または TFTP の障害です。


ステップ 1 nw_ip_address または lan_ip_address が設定されたノードに到達できること(ping 可能であること)を確認します。

nw_ip_address にのみ到達できて、lan_ip_address に到達できない場合は、統計収集の IP ルーティングに帯域内が使用されいてます。

lan_ip_address にのみ到達できて、nw_ip_address に到達できない場合は、統計収集の IP ルーティングには帯域外が使用されています。

dspifip コマンドを使用して、lan_ip_address および nw_ip_address を調べます。

ステップ 2 pmcollector.log を調べて、統計情報収集に正しい ip_address を使用しているかどうかを確認します。

ステップ 3 統計情報を収集しているスロットに接続が確立されているか調べます。また、統計情報のフラグも検索します。ノードでコマンド sumDBShow または sfmDBShow を使用します。

ステップ 4 stratacom データベースの coll_info テーブルの ftp_user_name と ftp_user_passwd、および node_info テーブルの ftp_user_name とftp_user_passwd が一致していて、有効であることを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

Pmcollector.log、node_info および coll_info のダンプ

関連する主なインデックス エントリ

pmcollector

有効な代替対処法 -- 到達可能な atm または LAN IP を使用します。

K.12.10.2.1 StatsParser --一般的なトラブルシューティング

StatsParser は統計情報ファイルからデータを読み取って、データベースにデータを挿入します。

一般的なトラブルシューティングを実行する場合は、必ず次の手順を実行します。


ステップ 1 psg statsparser コマンドを実行し、結果を調べて、statsparser プロセスが稼働していることを確認します。

ステップ 2 statsparser のログ レベルを調べます。ログ レベルを増加させるには、コンフィギュレーション ファイル ~/config/statsparser.conf を編集し、LOG_LEVEL フィールドの値を 7 に変更します。


 

K.12.10.2.2 StatsParser --ファイルが解析されたにもかかわらず BadFileList に表示される

統計情報ファイルを解析し、データベースにデータを挿入している間に、StatsParser が統計情報ファイルのデータ解析またはファイルのフォーマットに関する問題を検出した場合は、ファイルが BadFileList に格納されます。

scmnode テーブルではノード エントリを使用できません。次のクエリーを実行して、以下を確認します。

Collection 状態のすべてのノードが出力に表示されているかどうか。以下も判別します。

ノード エントリが重複しているかどうか。クエリーは次のとおりです。

% echo " SELECT * from scmnode" | dbaccess

ファイルが破損しているかどうか。statsreader を使用して、ファイルを手動で読み取ります。

% statsreader <stats filename>
 

) 出力が正常でない場合、または破損している場合は、通常、スイッチ側に問題があります。CTM チームおよびスイッチ チームに問題を報告してください。


さらに挿入するためのスペースがマシンに残されているかどうか。スペースがない場合は、問題をただちに報告してください。

障害情報 -- 次の情報を収集して、さらに分析します。

statsparser.log、df -k およびマウントの出力

関連する主なインデックス エントリ

BadfileList

K.12.11.1 Statistics Report

Statistics Report を使用して、スイッチから収集される統計情報データのレポートを表示します。

SRT GUI には、統計情報履歴レポートを生成して表示する機能があります。Raw Statistics や Top Utilization などのレポートは表形式で表示され、パフォーマンス データ レポートはグラフおよび表形式で表示されます。

K.12.11.2 データを収集したにもかかわらずデータを使用できない


ステップ 1 データが収集されて、解析されたことを確認します。

ステップ 2 対応するテーブルに指定期間内のデータが存在することを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log/srtserver.log

有効な代替対処法 -- なし

K.12.11.3 レポートを生成したにもかかわらず、長期間データ表示されない

レポートを生成しようとしたにもかかわらず、長期間データが表示されず、メッセージ「Retrieving data」のみが表示される場合は、srtserver.log ログでエラー メッセージを検索します。

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log/srtserver.log

有効な代替対処法 -- なし

K.12.11.4 レポートを生成すると別のエントリの FDNが表示される

特定のカードのトランク データに関する未処理のレポートを生成すると、別のカードのトランク データも表示されることがあります。これは、テーブルの一部にスロット情報が設定されていないために、ノード情報のみを使用してデータが取得されることが原因です。

これはエラーではありません。余分なデータが表示されます。

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log/srtserver.log

有効な代替対処法 -- なし

K.12.11.5 未処理レポートに不正な FDN が表示される

報告された FDN に不正な値またはジャンク値が含まれています。

これは、FDN のフォーマット中にサーバに発生するエラーです。

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log/srtserver.log

有効な代替対処法 -- なし

K.12.11.6 Utilization レポート値が 100% を超えている

Utilization レポート値が 100% を超えています。

エラーです。

障害情報 -- 次の情報を収集して、さらに分析します。

/opt/svplus/log/srtserver.log

有効な代替対処法 -- なし

K.12.12 Service Agent の問題

RtmProxy は CTM で使用される Service Agent 内の唯一のコンポーネントです。Service Agent は SNMP を通して要求を処理し、スイッチ エージェントに伝達して、最終的にユーザに結果を戻します。

K.12.12.1 RtmProxy

RtmProxy は、すべてのスイッチからのトラップをカスタマー アプリケーションに提供する、CTM のノースバウンド SNMP インターフェイスです。このインターフェイスを通して、トラップ用のカスタマー アプリケーションが登録されます。カスタマー アプリケーションは SNMP を使用して RtmProxy に登録します。次の図は、情報の流れを示します。

図K-7 RTMProxy

 

OSS/マネージャは SNMP 要求を CTM マシンのポート 8161 に送信します。この要求内で、OSS/マネージャは OSS/マネージャが待ち受けるポートを指定します。上記の例では、マネージャはポート 162 からトラップを送信します。登録、登録解除などのスクリプトは、CTM マシンの
/opt/svplus/scripts/proxyscripts/rtmproxy 内にあります。これらのスクリプトを使用すると、RtmProxy への登録および登録解除を参照できます。これらのスクリプトは内部専用です。

K.12.12.1.1 RtmProxy への登録に失敗する

RtmProxy への登録を求めるマネージャの SNMP 要求に対して、エラーが戻されました。


ステップ 1 CTM マシンで ps -ef | grep RtmProxy を実行して、CTM コアが起動し、稼働していることを確認します。

ステップ 2 snmpset 要求がポート 8161 に送信されたことを確認します。

ステップ 3 snmpset のコミュニティ ストリングが private に設定されていることを確認します。

ステップ 4 設定している MIB オブジェクトが正しいことを確認します。

マネージャの登録用に設定する必要がある MIB オブジェクトは、次のとおりです。

stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerRowStatus

mstratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.trapFilterRegisterCategory

stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerPortNumber

ステップ 5 snmpset 要求の送信先 IP アドレスが正しいことを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

RtmProxy.log* および snmpd.log*

有効な代替対処法 -- なし

K.12.12.1.2 トラップが受信されない

マネージャが登録したポートにトラップが着信していません。


ステップ 1 RtmProxy への登録が正常に実行されたことを確認します。登録が正常に実行されなかった場合は、「RtmProxy への登録に失敗する」 を参照してください。

ステップ 2 次の手順を使用して、RtmProxy がトラップを送信しているポートの番号が、トラップ受信ユーティリティまたはマネージャが待ち受けているポートの番号と同じであることを確認します。

tballraker29% /opt/OV/bin/snmpget -d -v1 -p8161 -t 3000 -r 0 -cpublic 172.28.131.137 stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerPortNumber.172.28.131.158

ここで、172.28.131.137 は CTM IP アドレス、172.28.131.158 はマネージャ IP アドレス(またはトラップ受信ユーティリティが稼働しているステーションの IP アドレス)です。

ステップ 3 次の手順を使用して、マネージャが RtmProxy にまだ登録されていることを確認します。

tballraker29% /opt/OV/bin/snmpget -d -v1 -p8161 -t 3000 -r 0 -cpublic 172.28.131.137 stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerRowStatus.172.28.131.158

ここで、172.28.131.137 は CTM IP アドレス、172.28.131.158 はマネージャ IP アドレス(またはトラップ受信ユーティリティが稼働しているステーションの IP アドレス)です。

SNMP は 1 を戻します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

RtmProxy.log* および snmpd.log*

有効な代替対処法 -- RtmProxy に登録します。

K.12.12.1.3 マネージャが登録解除される

マネージャは、しばらく稼働してから登録解除されます。


ステップ 1 キープアライブ スクリプトが動作していることを確認します。RtmProxy のどのテーブルにも SNMP が実行されていない場合、マネージャは自動的に登録解除されます。マネージャを常に RtmProxy に登録しておくには、次のようにキープアライブ スクリプトをバックグラウンドで実行します。

#!/bin/sh
Usage="$0 <Agent Ip Address> <Manager IP address>"
if [ $# -lt 2 ]
then
echo "Usage :$Usage"
exit 1
fi
managerRowStatus=.1.3.6.1.4.1.351.120.1.1.1.3
managerPortNumber=.1.3.6.1.4.1.351.120.1.1.1.2
lastseq=.1.3.6.1.4.1.351.120.1.3.0
while true
do
sleep 60
CMD="/opt/OV/bin/snmpget -cpublic -p8161 -t3000 -r0 $1 $managerRowStatus.$2 $lastseq"
echo $CMD
$CMD
done
exit 0
 

ステップ 2 マネージャが稼働しているステーションから CTM ステーションへの IP 到達可能性が失われていないかどうかを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

RtmProxy.log* および snmpd.log*

有効な代替対処法 -- RtmProxy にマネージャを登録します。

K.12.12.1.4 ノード コミュニティ ストリングが機能しない

ノード コミュニティ ストリングを使用して snmpwalk を実行すると、エラーが戻されます。


ステップ 1 SNMP 要求がポート 8161 に送信されていることを確認します。

ステップ 2 コミュニティ ストリングが正しいことを確認します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

RtmProxy.log* および snmpd.log*

有効な代替対処法 -- なし

K.12.12.2 監査証跡ロギング メカニズムの問題

監査証跡ロギングを使用すると、CTM は固定的ファイルにモジュール間のユーザ アクティビティを記録できます。すべての CTfM Java フロント GUI アプリケーションは、ユーザ アクティビティに関する情報を CORBA インターフェイスを介して Audit Logger サーバに送信します。Audit Logger サーバはデータを固定のログ ファイルに書き込みます。

ここで説明する内容は、次のとおりです。

「AuditLogger.conf の使用」

「監査証跡ログ ファイルの命名規則」

「CTM GUI でダイアログボックスを開いた場合、監査証跡ログ ファイルにレコードがない」

K.12.12.2.1 AuditLogger.conf の使用

コンフィギュレーション ファイルには次の情報を設定できます。

ログ ファイルの場所 -- デフォルトは /opt/svplus/log/AL です。

日数 -- 監査証跡ログ ファイルを保管する日数を定義することにより、その他の古い監査証跡ログはすべて自動的に削除されます。

監査証跡ログ ファイルを参照できるメンバーが属するユーザ グループの名前。このグループは標準の UNIX ユーザ グループです。

K.12.12.2.2 監査証跡ログ ファイルの命名規則

監査証跡ログ ファイルは 1 日に 1 つ作成されます。ファイル名の変換は、AuditTrail.<mmddyyyy>.log のように定義されています。

2001 年 10 月 10 日の監査証跡ログ ファイルは、AuditTrail.10102001.log のようになります。

K.12.12.2.3 CTM GUI でダイアログボックスを開いた場合、監査証跡ログ ファイルにレコードがない


ステップ 1 CTM Security Manager GUI を開いて ユーザに対応付けられたセキュリティ プロファイル内で該当する CTM GUIの Audit-Read 権限を調べます。Audit-Read 権限がオンでない場合は、通常、レコードが表示されません。それ以外の場合は、ステップ 2 に進んでください。

ステップ 2 Audit Logger サーバが稼働していることを確認します。CTM マシンで psg AuditLogger を使用します。AuditLogger サーバが稼働していない場合は、このことが問題の原因です。障害情報に移動してステップに従い、すべての情報を収集します。

ステップ 3 CORBA 関連の例外がコンソールにスローされているかどうかを調べます。例外がスローされている場合は、これらのエラー メッセージを収集するか、またはスタックを呼び出します。


 

障害情報 -- 次の情報を収集して、さらに分析します。

CTM GUI の完全なスクリーン スナップショット

コンソールにスローされたエラー/例外(これらが存在する場合)

ログ:/opt/svplus/log/AuditLogger.log*、/opt/svplus/log/LogServer.log*、AuditTrail*.log(ファイル場所は/opt/svplus/config/AuditLogger.conf で設定)、/opt/svplus/log/watchdog.log

/opt/svplus/corefilesdir にあるコア ダンプ ファイル(特に AuditLogger コア ダンプ ファイル)

K.12.13 その他の問題

ここで説明する内容は、次のとおりです。

「NTS」

「データの不整合」

「CTM FTP デーモン」

K.12.13.1.1 コールドスタート後もノードがモード 1 のままである

nts は特定のスイッチを正常に管理できません。つまり、nts はスイッチが Unreachable または Unregistered 状態であると宣言し、その結果、nts はクライアントに LINK_DOWN メッセージを通知しました。ノードの Trap Manager List 内にあり、SNMP 処理を正常に実行できるノードは、nts によって OK 状態であると宣言します。


ステップ 1 ping が到達できるかどうかを調べます。ntsControl を実行し、プロンプトで ni を入力します。次に q を入力して ntsControl を終了します。これで、nts ノード情報が表示されます。CTM がノードとの同期を開始するには、ノードが OK 状態でなければなりません。ノードが OK 状態でない場合は、最初に ping を行う必要があります。ping <ip_address> を実行します。ping に成功した場合は、ステップ 2 に進みます。失敗した場合は、スイッチと CTM ステーション間のネットワーク到達可能性を修復します。

ステップ 2 CTM IP アドレス設定を調べます。この設定は、複数の IP インターフェイスを持つ CTM ワークステーションにのみ適用されます。/opt/svplus/config/svplus.conf 内の NMS_IP_ADDRESS 設定は、ユーザが CTM 用に選択したインターフェイスと一致する必要があります。IP インターフェイスを確認するには、ifconfig -a を実行します。IP インターフェイスが 1 つのみ装備された CTM ステーションには、NMS_IP_ADDRESS を設定する必要はありません。

ステップ 3 スイッチの Trap Manager List を調べます。SSH または Telnet でスイッチに接続します。dsptrapmgr コマンドを実行して、Trap Manager List を表示します。CTM がテーブルに格納されているかどうかを確認します。格納されている場合は、ステップ 4 に進みます。格納されていない場合、テーブルがすでにいっぱいであれば、deltrapmgr コマンドを使用して不要なエントリを削除します。nts は CTM を数分以内にテーブルに登録する必要があります。数分以内に登録できない場合は、ステップ 4 に進んでください。

ステップ 4 SNMP コミュニティ ストリングを調べます。スイッチの SNMP コミュニティ ストリングがデフォルト設定から変更されている場合は、CTM の SNMP コミュニティ ストリングをスイッチの新しいコミュニティ ストリングに一致させる必要があります。スイッチの SNMP コミュニティ ストリングを表示するには、dspsnmp コマンドを使用します。CTM の設定は Domain Explorer で表示できます。


 

障害情報 -- 次の情報を収集して、さらに分析します。

Selnd および dbnds コマンド出力

該当するノードの nts ログおよび EM ログ

有効な代替対処法 -- コミュニティ ストリングが一致しない場合は、CTM Configurator GUI を実行して、訂正します(/opt/svplus/java/bin/runConfigurator)。

関連する主なインデックスエントリは、nts、traps です。

K.12.13.1.2 コンフィギュレーションの変更またはプロビジョニング アクティビティが CTM に反映されない

nts が実際にトラップを生成した場合、nts は特定のスイッチからトラップを受信しません。


ステップ 1 ノードが OK 状態であることを確認します。ntsControl ノード情報に、特定のノードが OK 状態でないことが示されている場合は、「スイッチと GUI 間の接続の不整合」を参照してください。ノードが OK 状態の場合は、ステップ 2 に進みます。

ステップ 2 スイッチの Trap IP アドレス設定を調べます。Trap IP アドレスには、スイッチのプライマリ IP アドレスを設定する必要があります。そうしないと、nts はトラップと CTM ノード情報を相関させることができず、該当するトラップを廃棄しなければならなくなります。SSH または Telnet でスイッチに接続します。プライマリ IP アドレスを検索するには、dspndparms および dspifip コマンドを使用します。dsptrapip を入力して、現在の Trap IP アドレス設定を表示します。cnftrapip を使用して訂正します。詳細については、「NTS ログの解釈方法」 を参照してください。


 

障害情報 -- なし

有効な代替対処法 -- なし

関連する主なインデックスエントリは、nts、traps です。

K.12.13.1.3 NTS ログの解釈方法

nts ログで、特定のノードからの特定のトラップを検索します。


ステップ 1 トラップ処理を確認します。

nts ログには、特定のクライアントに配信されたトラップの情報が格納されています。nts はデフォルトで、現在のログの他に過去ログを 20 個維持できます。grep コマンドにノード ID、トラップ番号、クライアント名、PID などのキー フィールドを指定できます。たとえば、次のようになります。

( 21359: 63) 19:24:40 WARNING: N42 Trap(6, 50017, #15668881) to EMC-5-24596
 

上記の行は、nts がノード 42、トラップ 50017、シーケンス番号 15668881 を EMC の子 5(PID 24610)に配信したことを示します。

通常は、nts ログのトラップごとに次のクラスタが表示されます。

( 21359: 46) 01:46:49 WARNING: N15 Trap(6, 60303, #25278)
( 21359: 46) 01:46:49 WARNING: N15 Trap #25278 buffered
( 21359: 48) 01:46:49 WARNING: N15 Trap(6, 60303, #25278) to CSA
( 21359: 50) 01:46:49 WARNING: N15 Trap(6, 60303, #25278) to RtmProxy
( 21359: 60) 01:46:49 WARNING: N15 Trap(6, 60303, #25278) to ooemc-24610
( 21359: 58) 01:46:49 WARNING: N15 Trap(6, 60303, #25278) to EMD
( 21359: 49) 01:46:49 WARNING: N15 Trap(6, 60303, #25278) to HPOV
 

ここで、

行 1 は nts で「Trap(6, 60303, #25278)」が受信されたことを意味します。

行 2 は トラップが nts で正常にバッファされたことを意味します。

行 3 ~ 7 は、トラップを受信するために XML フィルタ設定に登録されたクライアントに、トラップが配信されたことを意味します。

ステップ 2 特定のトラップを検索できない場合は、スイッチが不正なトラップ IP アドレスを持つトラップを送信していないかどうかを確認します。スイッチのトラップ IP が間違っている場合は、そのスイッチからのトラップが非管理対象ノードから着信したとして宣言され、廃棄されます。Trap IP アドレスには、スイッチのプライマリ IP アドレスを設定する必要があります。そうしないと、nts はトラップと CTM ノード情報を相関させることができず、該当するトラップを廃棄しなければならなくなります。詳細については、「コンフィギュレーションの変更またはプロビジョニング アクティビティが CTM に反映されない」 を参照してください。

トラップが管理されていない(node_id が不明な)ノードから着信した場合、nts は次のように、異なるメッセージを出力します。

nts.7275.log.old.2:( 7275: 45) 03:32:39 WARNING: Trap unmanaged 172.28.140.16
 

この場合、nts は IP アドレスのみを出力して、廃棄します。


 

障害情報 -- なし

有効な代替対処法 -- なし

関連する主なインデックスエントリは、nts、log です。

K.12.13.2.1 スイッチと GUI 間の接続の不整合

ここでは、スイッチと CTM GUI 間の不整合をデバッグするための戦略を示します。ここに記載された不整合は、プロビジョニングに直接関連しません。不整合問題はコールドスタート、ウォームスタート、またはプロビジョニングが原因で発生することがありますが、この問題が表面化するまで認識されないことがあります。たとえば、システムを調べて、はじめて不整合があることに気づくことがあります。

ここでは、不整合の原因をより正確に突き止めるための一連のステップを示します。これらのステップは順に実行する必要があります。

1. ノードの同期状態を確認します。

2. データベース クエリーを使用して、接続の不整合の原因を特定します。

3. メッセージ フローを使用して、接続の不整合の原因を特定します。


ステップ 1 起動後のノードの状態を調べます。ノードの状態が異常な場合は、不正なカウントが表示されたり、不完全な接続が存在することがあります。

a. 同期が完了したかどうかを確認します。

b. システムが同期アップを宣言した場合は、CTM CLIコマンド selnd を使用して、不整合が検出されたノードがモード 3 であることを確認します。second-to-last カラムは、指定されたノードのモードを識別します。

ステップ 2 user_connection テーブルおよびセグメント テーブルで問題を検索します。Connection Manager GUI に表示された情報は、user_connection テーブルから直接取得されます。Connection Manager に問題が発生することはめったにありません。この手順では、データベース アクセス クエリーを使用して問題を特定します。user_connection テーブル内に問題が見つかり、セグメント テーブルが不正な場合は、通常、EM に問題があります。user_connection テーブルが間違っているにもかかわらず、セグメント テーブルが正しい場合は、調査を継続して、根本原因を突き止める必要があります。


) データベース内のすべてのポートおよびメッセージは 0 ベース、スイッチ CLI のすべてのポートは 1 ベースです。したがって、スイッチにポート 3 が表示される場合は、ポート 2 に問い合わせる必要があります。


a. user_connection テーブルに該当する接続を 1 つ問い合わせます。たとえば、接続のノード エンドポイント = n、スロット = s、論理ポート = p、vpi/dlci = s1、vci = s2 の場合、クエリーは次のようになります。

SELECT * from user_connection where l_node_id = n, l_slot = s, l_logical_port = p, l_subchnl_1 = s1, l_subchnl_2 = s2
 

ローカル側およびリモート側が不明な場合は、l_node_id = n および r_node_id = n(およびスロット、ポートなど)を指定してクエリーを実行します。データベース内のこの行がスイッチの同じ情報と矛盾する場合は、さらに調査する必要があります。

b. databroker が EM からすべてのトラップを受信したことを確認します。そのためには、カラム inseg_tbl_1、inseg_tbl_2、および inseg_tbl_3 を表示します。フラグが「1」に設定されている場合は、指定されたセグメントのすべてのトラップが受信されています。フラグは、databroker が指定セグメントに対する追加メッセージを受信したかどうかを示します。フラグが 0 に設定されている場合は、セグメント トラップ databroker で処理されていません。フラグ 2 または 3 に設定されている場合は、セグメントの一端のみが処理されています。


) 接続に 3 つのセグメントが含まれていない場合は、未使用のセグメントがデフォルトで 1 になります。


c. EM 接続テーブルで該当する接続を検索してください。セグメント テーブルが正しくて、
user_connection テーブルが不正な場合、または inseg_tbl_x フラグの一部が「1」でない場合は、テストを継続する必要があります。「接続のステータスの不整合」 を参照してください。セグメント テーブルも正しくない場合は、ステップ 3 に進みます。

ステップ 3 場合によっては、EM、DMD、および sdbroker 間のメッセージ フローを詳細に調べて、エラーの原因を判別する必要があります。

a. DMD が EM からメッセージを受信したことを確認します。メッセージ ログで接続を検索します。この検索は最初に DMD に実行され、次に sdbroker および xdbroker(xpvc のみ)に実行されます。検索基準はオブジェクト ID またはノード/スロット/ポート/vpi/vci です。DMD ログが調べられ、メッセージが見つからない場合は、ooemc またはその他の EM プロセスが調べられます。メッセージが見つかった場合、またはログが不完全な場合は、databroker プロセスをさらに詳細に調査する必要があります。DMD または EM ログが完全で、メッセージが DMD に送信されなかった場合は、通常、EM に問題があります。

コマンド /opt/svplus/dbcmap -d <node_id> を使用して、DMD を検出します。ログを問い合わせる必要がある DMD が出力されます。

grep "node <node_id> slot <slot #> .* port <logical_port> .* sCh1 <vpi or dlci> sCh2 <vci>" dmd<dmd_id #>Msg*
 

各出力行は次のようになります。

( 7) 21:49:43 1058910582 MsgType=100 connObjId 65665 connStatus 1 secStatus 1 upperLevelAlrm0 oamStatus 0 channelNo -4272512 termination 1 masterFlag 0 wildCardFlag 0 controllerType 0 subType 55 lPercUtil 100 rPercUtil 100 persistentSlave 1 prefRouteId 0 directRouteFlag 0 Local node 11 slot 15 line -1 port 0 logPort 0 sCh1 1 sCh2 37 type 1 subType 0 nni -1 netprefix Remote node 11 slot 14 line -1 port 0 logPort 0 sCh1 32 sCh2 234 type 1 subType 0 nni 0 netprefix
 

上記の例で関係のある項目は、次のとおりです。

21:49:43 -- イベントの発生時刻

Local node11 slot 15 .... sCh1 1 sCh2 37 -- ローカル エンドポイント

Remote node 11 .... -- リモート エンドポイント

MsgType=100 -- メッセージ タイプ。マッピングは次のとおりです。

FEEDER_ADDUPD = 100、

MASTER_SPVC_ADDUPD = 101、

SLAVE_SPVC_ADDUPD = 102、

SINGLEENDSPVC_ADDUPD = 103、

PTOMPSPVC_ADDUPD = 104、

MASTER_PVC_ADDUPD = 105、

SLAVE_PVC_ADDUPD = 106、

MASTER_LOCALDAX_ADDUPD = 107、

SLAVE_LOCALDAX_ADDUPD = 108、

FEEDER_DEL = 109、

MASTER_SPVC_DEL = 110、

SLAVE_SPVC_DEL = 111、

SINGLEENDSPVC_DEL = 112、

SLAVE_SPVC_DEL = 111、

SINGLEENDSPVC_DEL = 112、

PTOMPSPVC_DEL = 113、

MASTER_PVC_DEL = 114、

SLAVE_PVC_DEL = 115、

MASTER_LOCALDAX_DEL = 116、

SLAVE_LOCALDAX_DEL = 117、

WILDCARD_DEL = 121、

grep conObjId xxxxxx dmd<dmd_id>Msg*

grep <NotifyDataBroker> .*node x slot y .* sub1 v sub2 w ooemc* < for more EM queries see EM>

b. DMD がメッセージを受信したにもかかわらず、データベースに反映されない場合は、エラーの原因となった databroker モジュールを識別します。DMD を調べて、DMD からメッセージが転送されたかどうかを調べます。DMD からメッセージが転送されていない場合は、理由を確認します。フォーマットが間違っているか、またはその他の同様な問題がある可能性があります。ノード/スロット/ポート/vpi/vci を検索するか、grep で検索します。この出力は、キャッシュ クエリーを実行するたびに出力されます。

grep "DROP MSG:validation error" dmd<dmd_id>.<pid>.* - 廃棄されたメッセージを出力します。

c. メッセージが DMD に到達した場合は、sdbroker がこのメッセージを受信したかどうかを調べる必要があります。

grep "node <node_id> slot <slot#> .* port <logical port> sCh1 <vpi/dlci> sCh2 <vci>" sdbroker*Msg*

d. メッセージが sdbroker で受信されたにもかかわらず、データベースに変更が反映されない場合は、databroker キャッシュとデータベース間に矛盾があるかどうか確認する必要があります。キャッシュをダンプするには、次のように入力します。

$ psg sdbroker
 

sdbroker のプロセス ID が戻されます。

$ kill -USR1 <process ID returned from the previous command>
 

キャッシュ ダンプは /opt/svplus/log/sdbkrCache.dump 内のファイルに書き込まれます。該当する接続がキャッシュ内で正しいことを確認します。


 

障害情報 -- メッセージが廃棄されたインターフェイスの両側で、プロセスのログが必要です。この接続のセグメント テーブルだけでなく、不正な特定の user_connection テーブル エントリのダンプも役立ちます。該当する接続の両端の特定のノード、スロット、論理ポート、vpi、および vci も役立ちます。キャッシュ ダンプを実行した場合は、このダンプも参照してください。

有効な代替対処法 -- sdbroker キャッシュとデータベース間に問題がある場合は、キャッシュを再同期できます。そのためには、コマンド /usr/usrs/svplus/tools/CacheResync [-t <time in seconds>] を実行します。それでも問題が存在する場合は、障害情報を収集します。

関連する主なインデックスエントリは、inconsistency、connection、databroker です。

K.12.13.2.2 接続のステータスの不整合

GUI 画面の Status には、user_connection テーブルの状態フィールドの値が表示されます。このフィールドは、接続内のセグメントの中で最も悪い状態を示します。このフィールドの値は次のとおりです。

1 = Clear(正常)

2 = Fail(障害)

3 = Down(ダウン)

4 = Incomplete(不完全)

5 = Error(エラー)


ステップ 1 値が予測したとおりでない場合は、各セグメントの接続レベル データベースで、これらが正しいか調べます。該当するセグメントに関する最後のメッセージが重要です。

ステップ 2 ステータスが不完全な場合は、接続のセグメントの 1 つが user_connection テーブル内にありません。この接続に対応する user_connection テーブル エントリの in_seg フラグを調べてください。データベースおよびメッセージ内でフラグが 0 のセグメントを検索します。

2 つのプライマリ エンドポイントがそれぞれ同じセカンダリ エンドポイントを持つ場合は、接続にエラーが発生します。最初に確立された接続のステータスは Error になり、セカンダリに接続された別のプライマリ エンドポイントのステータスは Incomplete になります。


 

障害情報 -- 「スイッチと GUI 間の接続の不整合」 を参照してください。

有効な代替対処法 -- 「スイッチと GUI 間の接続の不整合」 を参照してください。

関連する主なインデックスエントリは、inconsistency、connection です。

K.12.13.2.3 接続のセカンダリ ステータスの不整合

GUI 画面の Secondary Status には、user_connection テーブルの Secondary_status フィールドの値が表示されます。このフィールドは、接続内のセグメントの中で最も悪い状態を示します。このフィールドはビット マップであり、セカンダリ ステータスにはそれぞれ 2 ビットが使用されます。各ステータス エントリの値は、次のとおりです。

0 = unknown(不明)

1 = ok

2 = fail(障害)

ビット パターンは次のとおりです。

ビット 1、2 -- ローカル abit

ビット 2、4 -- ローカル AIS

ビット 5、6 -- ローカル OAM

ビット 7、8 -- ローカル調整済み

ビット 9、10 -- リモート abit

ビット 11、12 -- リモート AIS

ビット 13、14 -- リモート OAM

ビット 15、16 -- リモート調整済み


ステップ 1 値が予測したとおりでない場合は、各セグメントの接続レベル データベースで、これらが正しいか調べます。「スイッチと GUI 間の接続の不整合」 を参照してください。該当するセグメントの最後のメッセージが重要です。


 

障害情報 -- 「スイッチと GUI 間の接続の不整合」 を参照してください。

有効な代替対処法 -- 「スイッチと GUI 間の接続の不整合」 を参照してください。

関連する主なインデックスエントリは、inconsistency、connection です。

K.12.13.2.4 不完全な接続

よくある問題は、指定されたカードに設定された接続が多すぎることです。この問題が発生すると、接続が不完全になることがあります。たとえば、3 つのセグメントからなる接続の送信側セグメントが databroker で処理されなかった場合は、この不完全接続のエンドポイントが、失われた送信側のエンドポイントでなく、ルーティング ノードのエンドポイントになります。また、ルーティング ノードの接続数が過剰になります。user_connection テーブル内の状態が 4 の場合は、接続が不完全であると識別されます。


ステップ 1 user_connection テーブルで該当する接続のセグメント数および inseg フラグの数を調べます。

ステップ 2 l_node_id = x、l_slot=y、l_port=z、l_subchnl_1 = v、および l_subchnl_2 = w である user_connection から、num_segs,、status、inseg_tbl_1、inseg_tbl_2、inseg_tbl_3 を選択します。


 

障害情報 -- メッセージが廃棄されたインターフェイスの両側で、プロセスのログが必要です。不正な user_connection テーブル エントリのダンプも役立ちます。該当する接続の両端の特定のノード、スロット、論理ポート、vpi、および vci も役立ちます。

有効な代替対処法 -- sdbroker キャッシュとデータベース間に問題がある場合は、キャッシュを再同期できます。そのためには、コマンド /usr/usrs/svplus/tools/CacheResync [-t <time in seconds>] を実行します。

関連する主なインデックスエントリは、inconsistency、incomplete connection です。

K.12.13.3.1 FTP デーモンの概要

cwmftpd プロセスは、CTM モジュールからネットワーク ノードまたはその他の CTM に対して FTP の put、get、またはディレクトリ待ち受けサービスを要求できる、ILOG サーバです。このサービスは FTP 通信の観点からは FTP クライアントとして機能し、インタラクティブば FTP プログラムと同様のサービスを実行します。

次のプロセスでは、cwmftpd を使用してファイルを FTP 転送します。

ooemc

PM コレクタ

関連する主なインデックスエントリは、FTP

K.12.13.3.2 一般的なトラブルシューティング

一般的なトラブルシューティングを実行する場合は、必ず次の手順を実行します。

cwmftpd プロセスが起動していて動作しているかどうかを調べます。

psg cwmftpd
 

ディスクの空きスペースを確認します。

df -k /opt/svplus
 

ターゲット スイッチ、CTM に到達できるかどうかを確認します。

デバッグ レベルを確認します。ログに詳細情報が格納されていない場合は、~svplus/config/cwmftpd.conf を編集して、デバッグ レベルを増加させます。

詳細ログを取得するには、設定パラメータ LOG_LEVEL を 7 に設定します。

関連する主なインデックスエントリは、FTP

K.12.13.3.3 FTP ユーザ名およびパスワード

コマンド cwmftpd は stratacom データベースの node_info テーブルを使用して、FTP のユーザ名およびパスワードを取得します。SCM 要求の場合、scmcollsvr は要求と一緒にパスワードを送信します。

関連する主なインデックスエントリは、FTP、username、password です。

K.12.13.3.4 cwmftpd --ユーザ名/パスワードが間違っているためファイルが転送されない

ユーザ名またはパスワードが間違っているため、CTM とスイッチ間あるいは CTM と CTM 間でファイルが転送されません。

ユーザ名またはパスワードが間違っているため、CTM とスイッチ間あるいは CTM と CTM 間でファイルが FTP 転送されません。


ステップ 1 FTP のユーザ名およびパスワードが正しいかどうかを調べます。

ステップ 2 cwmftpd.log に、FTP ユーザ名およびパスワードが間違っている、次のような例外がないかどうかを調べます。

(22589:204248) 10:12:27 ERR: %FtpException-3-LOGIN_FAILED: Login failed.
[login,host=172.23.30.111,user=superuser]


 

障害情報 -- ユーザ名およびパスワードが正しいにもかかわらず、ログに LOGIN_FAILED が表示される場合は、cwmftpd.log、cwmftpd.request_log、および cwmftpd によって転送されなかったファイルのプロセスに関するログを収集します。

関連する主なインデックスエントリは、login failed です。

K.12.13.3.5 cwmftpd --スイッチでファイルを使用できない

ファイルを使用できないために、ファイルが転送されません。


ステップ 1 ターゲット スイッチでファイルが使用可能かどうかを調べます。

ステップ 2 cwmftpd.log に次のような例外が含まれていないかどうかを調べます。

FtpException-3-FTPERR_550: Requested action not taken. File unavailable (e.g., file not found, no access). [550 File "/stat/1-05-Con-062020031215" not found or permission problem]


 

障害情報 -- ファイルを使用できるにもかかわらず、FTP 転送されずに、FTPERR_550 例外がスローされた場合は、cwmftpd.log、cwmftpd.request_log、および cwmftpd によって転送されなかったファイルのプロセスのログを収集して、問題を報告します。

有効な代替対処法 -- なし

関連する主なインデックスエントリは、file unavailable、ftperr_550、requested action not taken です。

K.12.13.3.6 スイッチの FTP セッション

スイッチで実行できる FTP セッションは 4 つのみです。cwmftpd がセッションを開く要求を送信した場合、スイッチがセッションの上限に達したために要求を処理できないか、またはファイルがロックされていれば、スイッチは次のエラー メッセージで応答します。「499 Session limit reached, queuing <IP address> key <Nodename/XXXXXXXX>」

key は、セッションがあとで使用可能になった場合に使用される、ノードの一意のストリングです。CTM は接続先スイッチの TCP ポート 5120 で待機します。セッションが使用可能になると、スイッチは定義されたポートに接続し、データとしてキーを CTM に送信します。CTM はこのキーを使用して、セッションを開く場合に使用する必要があるスイッチを識別します。これによりセッションは問題なく開き、cwmftpd は FTP 要求を継続できます。

スイッチは CTM ステーションのセッションを 30 秒間予約します。その期間が過ぎると、その他のステーションを処理します。CTMftpd は単一の FTP セッション内で複数のファイルを取得します。セッションごとの最大数が設定されます。

この機能は、MGX 8850 Release 4.0 以上が搭載された CTM でサポートされています。MGX 8850 Release 4.0 より前の Switch Software(SWSW)の場合、スイッチは「421 Session limit reached, closing control connection」で応答します。

スイッチで現在開かれている FTP セッション数を判別するには、スイッチ コマンド dsptasks を実行します。FTP セッションごとの dsptasks 出力には、次のようなエントリが含まれます。

FtpdServ1 0x9a00a1 0x82d8a8a0

2 つのセッションがある場合は、2 つのエントリが含まれます。

関連する主なインデックスエントリは、switch FTP session です。

K.12.13.3.7 421 のセッション制限への到達

MGX8850 Release 4.0 より前の SWSW で、FTP セッション数の上限(4)に到達した場合、スイッチは「421 Session limit reached, closing control connection」で応答します。


ステップ 1 スイッチに対して FTP セッションを手動で開くか、またはスイッチ コマンド dsptasks を実行して、4 つのセッションがすべて開かれているかどうかを確認します。


 

障害情報 -- FTP セッションを手動で正常に開くことができたか、または dsptasks コマンドで表示された FtpdServ のエントリ数が 4 未満であるにもかかわらず、 cwmftpd が FTPERR_421 をスローする場合は、cwmftpd.log、cwmftpd.request_log、および cwmftpd によって転送されなかったファイルのプロセスに関するログを添えて、問題を報告します。

有効な代替対処法 -- なし

関連する主なインデックスエントリは、service not available、closing control connection、421、session limit reached、ftperr_421 です。

K.12.13.3.8 499 のセッション制限への到達

SWSW MGX8850 Release 4.0 以上で、FTP セッションの上限(4)に達した場合、スイッチは「499 Session limit reached, queuing <IP address> key <Nodename/XXXXXXXX>」で応答します。

エラー「499 Session limit reached, queuing <IP address> key <Nodename/XXXXXXXX>」で応答したスイッチに接続しようとした場合、cwmftpd コマンドは例外 FTPERR_499 をスローします。


ステップ 1 スイッチに対して FTP セッションを手動で開くか、またはスイッチ コマンド dsptasks を実行して、4 つのセッションがすべて開かれているかどうかを確認します。


 

障害情報 -- FTP セッションを手動で正常に開くことができたか、または dsptasks コマンドで表示された FtpdServ のエントリ数が 4 未満であるにもかかわらず、cwmftpd が FTPERR_499 をスローする場合は、cwmftpd.log、cwmftpd.request_log、および cwmftpd によって転送されなかったファイルのプロセスに関するログを添えて、問題を報告します。

関連する主なインデックスエントリは、499、session limit reached、key、ftperr_499 です。

K.12.13.3.9 スイッチとのセッションを取得できない

MGX 8850 Release 4.0 以上で、「499 Session limit reached」エラーが受信された場合、CTM は定義されたポートで待機して、セッションを取得します。この待機時間はデフォルトで 1 分であり、変更できます。CTM がこの待機時間内にスイッチから応答を取得しない場合は、タイムアウトして、次の例外をスローしてから、セッションの再開を試みます。

( 9583: 6) 08:37:29 ERR: %CwmFtpDaemonException-3-SESSION_TIMEOUT: Session [Id[28], ClientSeq#[6521], Host[172.25.69.218], User[superuser], Priority[3]:get /stat/1-04-Con-052920030730 /opt/svplus/spool/MGX98101-1-04-Con-052920030730-2] timeout in 3 minutes and needs to be retried.

再試行回数はデフォルトで 5 回です(この値は変更できます)。すべての再試行に失敗した場合、cwmftpd は次の例外をスローします。

( 9583:172473) 08:37:58 ERR: %CwmFtpDaemon-3-SESSION_FAIL: Thread [Host [172.2
5.69.218] User[superuser] NoRequest] failed to acquire session after 5 retries. Session wait time[5].

関連する主なインデックスエントリは、switch、session、FTP です。

K.12.13.3.10 すべての再試行後もセッションを取得できない

cwmftpd コマンドのすべての再試行後も、スイッチとのセッションを取得できません。


ステップ 1 スイッチに対して FTP セッションを手動で開いて、4 つのセッションが開かれているかどうかを確認します。


 

障害情報 -- FTP セッションを手動で正常に開くことができたにもかかわらず、cwmftpd が SESSION_FAIL 例外をスローする場合は、cwmftpd.log、cwmftpd.request_log、および cwmftpd によって転送されなかったファイルのプロセスに関するログを添えて、問題を報告します。

有効な代替対処法 -- なし

関連する主なインデックスエントリは、session_timeout、session_fail です。

K.12.13.3.11 一般的なログ情報

cwmftpd.request_log ファイルには要求ごとに 1 つのエントリが含まれます。このエントリには、要求が成功したか、または失敗したか、および要求の所要時間に関する情報が格納されます。情報は短い簡潔なフォーマットで保管されます。要求ごとのデータ量は多くないため、ファイルには期間内に多くのデータを格納できます。

cwmftpd はノードの IP アドレスに基づいて情報を保管します。特定のノードに対する要求を追跡するには、cwmftp.log および cwmftpd.request_log 内で IP アドレスをキーワードとして grep 検索します。

FTP 要求を送信した ooemc は、宛先ファイルの一部として、要求とともにノード ID も送信します。このノード ID は、node_info テーブルから FTP のユーザおよびパスワードを取得する場合に使用されます。ユーザおよびパスワードの検証にも使用できます。

次のキーワードは、cwmftpd.log ファイルのものです。

TRANSFER_STARTED -- cwmftpd がファイル転送を開始したことを示します。

TRANSFER_COMPLETED -- ファイルが完全に転送されたことを示し、ローカルおよびリモート ファイル サイズに関する情報も示します。

TRANSFER_RATE -- 転送速度、および転送バイト数や転送時間を示します。

TRANSFER_RETRY -- 転送要求を再試行する必要があることを示します。

TRANSFER_FAILED -- cwmftpd がファイルを転送できなかったことを示します。

CONTROL_CONN_TIMEOUT -- この例外は、FTP セッションが開かれたときに X 秒間情報が転送されなかった場合にスローされます。

関連する主なインデックスエントリは、FTP log です。