Cisco ONS 15454/15454 SDH/Cisco ONS 15327 イーサネット カード ソフトウェア フィーチャ コンフィギュレーション ガイド Release 7.2

RMON のデフォルト設定

RMON はデフォルトでディセーブルに設定されています。アラームやイベントは設定されていません。

RMON アラームおよびイベントの設定

CLI（コマンドライン インターフェイス）または SNMP 互換 Network Management Station（NMS; ネットワーク管理ステーション）を使用することにより、ML シリーズ カードを RMON 用に設定できます。NMS 上で汎用 RMON コンソール アプリケーションを使用し、RMON のネットワーク管理機能を利用することを推奨します。また、RMON MIB オブジェクトにアクセスするため、ML シリーズの SNMP を設定する必要があります。SNMP の設定方法の詳細については、「SNMP の設定」を参照してください。

RMON アラームおよびイベントをイネーブルにするには、特権 EXEC モードを開始して、次の手順を実行します。この手順は必須です。

アラームをディセーブルにするには、設定したアラームごとに no rmon alarm number グローバル コンフィギュレーション コマンドを実行します。特定の番号を指定しないで、設定したアラームをすべてディセーブルにすることはできません。アラームは個別にディセーブルにする必要があります。イベントをディセーブルにするには、 no rmon event number グローバル コンフィギュレーション コマンドを使用します。アラームおよびイベントとその相互作用の詳細については、Request For Comments（RFC; コメント要求）1757 を参照してください。

アラームはいずれの MIB オブジェクトに対しても設定できます。次の例では、 rmon alarm コマンドを使用して RMON アラーム番号 10 を設定します。このアラームは、MIB 変数 ifEntry.20.1 を 20 秒ごとに 1 回モニタし、アラームがディセーブルになるまで、変数の上昇または下降の変化をチェックします。 ifEntry.20.1 値が 15 以上の MIB カウンタの増加を示した場合（たとえば 100000 から 100015）、アラームがトリガーされます。次にアラームは、イベント番号 1 をトリガーします。これは、 rmon event コマンドで設定されます。設定可能なイベントにはログ エントリまたは SNMP トラップを含めることができます。 ifEntry.20.1 値が 0 に変化した場合、アラームはリセットされ、再度トリガーできます。

（注） この例では、下限しきい値が 0 の場合、任意のイベントをトリガーしません。

65539 がインターフェイス POS 0 の SNMP ifIndex である場合、SNMP get の付いた特定のポート用に SNMP ifIndex を取得できます。この出力例では、POS0 の SNMP ifIndex は 65539 です。

次の例では、 rmon event コマンドを使用して RMON イベント番号 1 を作成します。イベントは High ifOutErrors として定義され、アラームによってイベントがトリガーされるときにログ エントリが生成されます。ユーザ jjones は、このコマンドによってイベント テーブルに作成された行を所有します。この例では、イベントがトリガーされたときに SNMP トラップも生成されます。

インターフェイスでのグループ履歴統計情報の収集

収集情報を表示するには、最初に RMON アラームおよびイベントを設定する必要があります。

インターフェイス上でグループ履歴統計情報を収集するには、特権 EXEC モードで次の手順を実行します。この手順は任意です。

	コマンドの説明	目的
ステップ 1	configure terminal	グローバル コンフィギュレーション モードを開始します。
ステップ 2	interface interface-id	履歴を収集するインターフェイスを指定し、インターフェイス コンフィギュレーション モードを開始します。 （注） グループ履歴統計情報は、Packet-over-SONET/SDH（POS）（POS_ interface）では動作せず、イーサネット インターフェイスでのみ動作します。
ステップ 3	rmon collection history index [ buckets bucket-number ] [ interval seconds ] [ owner ownername ]	指定されたバケット数および時間に関する履歴収集をイネーブルにします。 • index には、統計情報の RMON グループを指定します。指定できる範囲は 1 ～ 65,535 です。 • （任意） buckets bucket-number には、統計情報の RMON 収集履歴グループに対する、最大バケット数を指定します。指定できる範囲は 1 ～ 65,535 です。デフォルトは 50 バケットです。 • （任意） interval seconds には、各ポーリング サイクルの秒数を指定します。指定できる範囲は 1 ～ 3600 です。デフォルトは 1800 秒です。 • （任意） owner ownername には、統計情報の RMON グループの所有者名を入力します。
ステップ 4	end	特権 EXEC モードに戻ります。
ステップ 5	show running-config	エントリを確認します。
ステップ 6	show rmon history	ML シリーズ カード履歴テーブルの内容を表示します。
ステップ 7	copy running-config startup-config	（任意）コンフィギュレーション ファイルにエントリを保存します。

履歴収集をディセーブルにするには、 no rmon collection history index インターフェイス コンフィギュレーション コマンドを使用します。

次に、所有者 root の RMON 履歴を収集および表示する例を示します。

インターフェイスでのグループ イーサネット統計情報の収集

インターフェイス上でグループ イーサネット統計情報を収集するには、特権 EXEC モードで次の手順を実行します。この手順は任意です。

グループ イーサネット統計情報の収集をディセーブルにするには、 no rmon collection stats index インターフェイス コンフィギュレーション コマンドを使用します。

次に、所有者 root の RMON 統計情報を収集する例を示します。

しきい値およびトリガーされたアクション

設定可能なしきい値は、可変フレーム長およびさまざまな帯域幅のパーセンテージによって、その有用性が損なわれるので、BER は設定されていません。代わりに、CRC エラー レートをトラフィックのパーセンテージとして使用して、より適切な測度を設定します。トリガーするしきい値は次のとおりです。

• 10e-2 または 1% トラフィック（100 パケットで 1 個の CRC エラー）

• 10e-3 または 0.1% トラフィック（1000 パケットで 1 個の CRC エラー）（デフォルト）

• 10e-4 または 0.01% トラフィック（10000 パケットで 1 個の CRC エラー）

デフォルトのしきい値は、トラフィックの CRC エラー レート 0.1% です。音声およびビデオ トラフィックの場合、エラー レート 1% は通常、クリティカルな問題で、0.1% はメジャーな問題です。エラー レートが 0.1%（1000 パケットごとに 1 エラー）を超えると、音声およびビデオはラップをトリガーする必要があります。通常のデータ トラフィックの場合、エラー レート 10% のトラフィックはクリティカルな問題で、ただちに解決する必要があります。1% のトラフィックはマイナーな問題です。

超過 CRC エラーが検出されたあと、次のアクションが発生します。

1. このオプションが設定されている場合、シスコ固有の RPR がラップします。

2. このオプションが設定されている場合、リンクがシャットダウンします。

3. リンクがシャットダウンすると、Path Defect Indication（PDI; パス障害表示）が遠端の ML シリーズ カード ポートに送信されます。これにより、リモート エンドがラップします。

4. ローカル エンドの ML シリーズ カードに対して、CRC-ALARM が発生します（リモート エンドも超過 CRC エラーを受信している場合、CRC-ALARM が遠端の ML シリーズ カード ポートに対して発生します）。

CRC-ALARM の SONET/GFP 抑制

この超過 CRC エラー検出は、SONET/GFP 障害とは別のものです。1 つの問題により、SONET/GFP 障害と CRC-ALARM の両方が引き起こされる可能性があります。この事例では、CRC エラーしきい値検出は遅いプロセスなので、CRC-WRAP アラームの前に SONET/GFP 障害が発生します。SONET/GFP 障害によりリンクがダウンする場合、このリンクダウンは CRC-ALARM が検出される前に発生して CRC-ALARM を抑制します。CRC-ALARM を発生させる SONET/GFP 障害がリンクダウン トリガーではなく、CRC-ALARM によってリンクダウンするよう設定されている場合、CRC-ALARM はリンクダウンを報告してトリガーします。

CRC-ALARM のクリア

トリガー アクションがディセーブルの場合（デフォルト）、一定の時間、エラー レートがしきい値を下回ると CRC-ALARM は自動的にクリアされます。

トリガー アクションがイネーブルの場合、ユーザが手動で CRC-ALARM をクリアする必要があります。アラームによるラップまたはリンクダウンは、トラフィックとポートからのトラフィック内の CRC エラー両方をブロックするので、これが必要になります。CRC エラーがない場合、ファイバの汚れや障害の発生した ML シリーズ カードなどの根本的な問題が存続しても、自動的にクリアされます。この状況では、インターフェイスのフラッピングが発生します。

手動でクリアする前に、CRC-ALARM の根本原因を判別し、解決する必要があります。解決したら、アラームを手動でクリアする方法がいくつかあります。

• Cisco IOS CLI を通じて、EXEC レベルでclear crc alarm interface interface-type interface-number コマンドを入力します。

• Cisco IOS CLI を通じて、リンクされたポートで管理上の shutdown を行ってから、no shutdown を行ってポートをイネーブルにします。

• CTC または TL-1 を通じて、回線をディセーブルにしてから再度イネーブルにします。

• CTC または TL-1 を通じて、SONET/SDH 回線を削除し、同じ送信元と宛先を持った回線を作成します。

同期化のラップ解除

ML シリーズ カードのソフトウェアは、エラー フレームを監視する POS インターフェイスで CRC-ALARM アラームを発生させます。単一方向の FCS エラーの場合、ユーザは、CRC-ALARM アラームが発生したスパンの一方の端の POS ポートで unwrap コマンドを実行するだけです。双方向の障害の場合、スパンの両端で CRC-ALARM アラームが発生するので、スパンの各端で一度にコマンドを実行する必要があります。

リンクの各端の POS ポートはラップされるので、CRC-ALARM がクリアされたときにラップを削除する（ラップ解除）には、調整が必要です。また、ソフトウェアはラッピングを発生させる他のエラーがないことを確認する必要があります。次の例では、単一方向と双方向両方の障害のこの処理の方法を示します。簡単にするために、この例では、超過 CRC エラーはラッピングを引き起こす唯一の条件であることを前提とします。

単一方向エラー

図21-2 に、ノード E の POS ポート 0 での単一方向の超過 CRC エラーによってラップされたシスコ固有の RPR を示します。これは、CRC-ALARM も報告します。これにより、ノード E の POS ポート 1 とノード D の POS ポート 0 がラップします。図のキャプションでは、プロセスをさらに説明します。

図21-2 単一方向の超過 CRC エラーでラップされたシスコ固有の RPR

図21-3 に、図21-2 のラップ解除シーケンスを示します。ラップ解除のためのトラフィック ヒットは、ノード D でクリアされた PDI を宣言するのに必要なソーク時間に依存します。

図21-3 単一方向の超過 CRC エラーでラップ解除されたシスコ固有の RPR

双方向エラー

図21-4 に、双方向の超過 CRC エラーでラップされたシスコ固有の RPR を示します。両方のポートが CRC-ALARM を報告します。図のキャプションでは、プロセスをさらに説明します。

図21-4 双方向の超過 CRC エラーでラップされたシスコ固有の RPR

図21-5 に、図21-4 のラップ解除シーケンスの最初の部分を示します。ノード E で unwrap コマンドが設定されたあと、ラップ解除が行われます。この双方向事例でのラップ解除の場合、リンクの両端の POS ポートにコマンドを設定する必要があります。

図21-5 双方向の超過 CRC エラーでラップ解除されたシスコ固有の RPR の最初の段階

最初の CRC-ALARM クリア コマンドのあと、ノード E は POS ポート 1 をラップ解除しません。ノード D は PDI をノード E に送信し続けるので、CRC-ALARM がクリアされるとノード E は TPTFAIL アラームを発生します。この時点では、シスコ固有の RPR は単一方向障害と同様のステートにいます。図21-5 に示すように、ユーザが 2 回めの unwrap コマンドを実行したらラップ解除は完了です。

図21-6 双方向の超過 CRC エラーでラップ解除されたシスコ固有の RPR の第 2 段階

クリア CRC エラー コマンドを使用した CRC-ALARM ラップの解除

Cisco IOS CLI の clear crc alarm interface interface-type interface-number コマンドは、対応する SONET/SDH エラーに対応するエラーがなく、FCS エラーによってシスコ固有の RPR ラップが発生したときにこれを解除します。SONET/SDH 障害またはキープ アライブ（KA）障害などの他の原因によるラップの解除は行いません。FCS エラーがなくても SONET/SDH または KA 障害が存在する場合、ソフトウェアはエラー メッセージを出してコマンドを拒否します。FCS エラーが存在し、SONET/SDH または KA 障害が存在する場合、コマンドはソフトウェアによって受け入れられますが、ノードは障害が解決してからのみラップ解除します。この場合、SONET/SDH または KA 障害がクリアされたあと、コマンドを再度実行する必要はありません。

（注） ラップ解除はただちに行われませんが、条件が満たされれば行われます。

ML シリーズ カードの CRC-ALARM をクリアするには、特権 EXEC モードで次の手順を実行します。

ML シリーズ カードの CRC しきい値の設定の注意事項

NMS PM アラートを生成するインターフェイス CRC エラー（ifInErrors）のしきい値を決定するための注意事項です。

• SONET/SDH ビット エラーは POS CRC エラーも作成します。SONET/SDH エラーと POS エラー間にはアラーム抑制階層がないので、各エラー セットは個別のアラートを作成します。

• インターフェイスの実際のパケット レートは、予測不可能です。高帯域幅のインターフェイスでは、低いデータ トラフィックが続く特定の時間に、分単位でわずかなパケットのみを転送する可能性があります。これは、比較的少ない CRC エラー数でも 100% の損失であることを意味します。低帯域幅のインターフェイスは、特定の時間に、分単位で高パケット カウント（100 万単位）を転送します。したがって、比較的少ない CRC エラー数の場合には、エラー レート 10 ^-9 を意味します。この状況により、非パケットベースの PM にしばしば使用される最大 BER を単純に判別できなくなります。

• モニタリング問題または主要な問題の兆候を示す ML シリーズ カードの CRC エラーのモニタリングも設定できます。マイナーな問題のモニタリングの場合、60 秒間に 10 個のエラーなど、比較的速くて影響されやすいエラー レートのトリガーを設定します。この方法は、インターフェイスがアップ状態またはダウン状態になるか、ファイバ エラーが発生するか、あるいは SONET/SDH 保護イベントが発生する（保護が 50 ms 以内に発生しても）たびに NMS アラートを発生します。主要な問題のみをモニタリングし、アラート数を減らすには、300 秒間に 1000 個のエラーなど比較的高いしきい値を設定します。

SNMP を通じた CRC エラーへのアクセス

各インターフェイスの CRC エラーは、IF-MIB オブジェクトの ifInErrors（OID 1.3.6.1.2.1.2.2.1.14）で報告されます。SNMP get 要求により、ifInErrors の現在値を確認できます。各 MLシリーズ カードは、SNMP のインスタンスを個別に実行します。SNMP 要求は、コミュニティ ストリングに基づいて各 ML シリーズ カードにリレーされます。コミュニティ ストリングは次の形式を使用します。

Cisco IOS を使用した CRC エラーしきい値の SNMP トラップの設定

ML シリーズ カードは、Cisco IOS の RMON トラップ機能をサポートします。Cisco IOS CLI を使用して、ifInErrors をモニタリングし、しきい値を超過した場合に NMS に対しトラップを生成するよう RMON を設定する必要があります。ONS 15454 SONET/SDH の ML シリーズ カードは、SNMP set 要求による RMONトラップの設定をサポートしません。この要求は、一般にネットワーク装置上のアクションを開始します。

ifInErrors をモニタリングし、しきい値を超過した場合に NMS に対しトラップを生成するよう RMON を設定するには、特権 EXEC モードで次の手順を実行します。

次に、CRC エラーしきい値の SNMP トラップを設定する例を示します。

この例で、rmon alarm コマンドに使用される 10 進表記の ML シリーズ カード インターフェイスの ifIndex 番号は、 ifInErrors.983043 です。この変数は、ML シリーズ カード インターフェイスの ifIndex 番号と組み合わせてモニタリングする MIB オブジェクトです。ML シリーズ カード インターフェイスの ifIndex 番号の決定に関する詳細は、「ML シリーズ カードの ifIndex 番号の判別」を参照してください。

次に、5 分間にしきい値 1000 を超過する 1002 ifInErrors によって生成された上昇しきい値トラップの例を示します。

ML シリーズ カードの ifIndex 番号の判別

NMS がパフォーマンス データについて ML シリーズ カードをポーリングする場合、NMS は内部で ifIndex 番号を使用して、複数の MIB からのインターフェイス データを統合し、このデータとインターフェイス名を関連付けます。インターフェイス名は信頼できるので、実際の ifIndex 番号を知る必要はありません。

Cisco IOS CLI を使用してトラップを直接、生成するよう MLシリーズ カードを設定する場合、この関連付けた名前は使用しません。トラップを設定している各インターフェイスの実際の ifIndex 番号を使用する必要があります。実際の ifIndex 番号を決定するには、NMS を使用して各 ML シリーズ カード インターフェイスと VLAN（仮想 LAN）サブインターフェイスの ifIndex 番号を取得するか、またはインターフェイスの ifIndex 番号を計算します。

また、MIB ブラウザ（SNMP MIB 定義の検索サービス）を使用して、適切な ifIndex 番号の ifDescr を検証できます。ifDescr からの ifIndex 番号は、希望の ifIndex 番号でなければなりません。

ML シリーズ カードでは、イーサネットおよび POS インターフェイスの ifIndex 番号は、次の 2 種類のカードの情報からコンパイルされています。

• カードのシャーシ スロット番号 ― スロット番号は、ML シリーズ カードが常駐するシェルフの物理的なスペースの番号です。ONS 15454 SONET/SDH シェルフの場合、有効な範囲はスロット 1 ～ 6、またはスロット 12 ～ 17 です。この情報は、CTC のシェルフ スロットのグラフ表示、あるいは物理シェルフの前面で見つけることができます。

• カード内のローカル ポート番号 ― ONS 15454 SONET/SDH の ML シリーズ カードのポート番号は、ファースト イーサネット インターフェイスおよびギガビット イーサネット インターフェイスのインターフェイス番号と一致します。POS ポート番号はインターフェイス番号と一致せず、イーサネット ポートを連続してナンバリングしません。連続値は、最後のイーサネット ポート番号と最初の POS 番号（POS ポート 0）の間ではスキップされます。インターフェイスのポート番号を 表21-1 に示します。

次の公式を使用して、スロットおよびポートを組み合わせて ifIndex を出します。

ifIndex = (slot * 10000h) + (port)

10000h は、16 進数を示し 65536 に相当します。その結果の ifIndex は 16 進数で有意味な 2 値数字ですが、10 進数では紛らわしく、明確でない数字です。たとえば、ifIndex E0002h はポート 2 のスロット 14 です。10 進表記での同じ番号は 917506 になります。rmon alarm コマンドは、10 進数表記の ifindex 番号を必要とします。

rmon alarm コマンドを使用して正確な ifindex 値を算出するための参照として、 表21-1 にスロット 1 ～ 17 のベース ifindex 番号を示します。希望のポート番号をスロット ベース番号に足すと正しい ifIndex 番号をすばやく決定できます。

ML シリーズ カードでの手動による CRC エラー検証

show interface コマンドを使用して、インターフェイス上の ML シリーズ カードの現在の CRC エラー カウントも検証できます。次に、6 つの総入力エラーの例を示します。これはすべての CRC エラーで、出力の最後の行にあります。