Cisco 10000 シリーズ ルータ MIB 仕様ガイド Release 12.2(31)SB2
通知のモニタリング
通知のモニタリング
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

通知のモニタリング

SNMP 通知の概要

通知のイネーブル化

シスコの SNMP 通知

環境または機能に関する通知

シスコ製ラインカードに関する通知

フラッシュ カードに関する通知

インターフェイスに関する通知

MPLS サービスに関する通知

ルーティング プロトコル関連の通知

シャーシに関する通知

RTT モニタに関する通知

環境に関する通知

フレームリレーに関する通知

PFE に関する通知

SSG に関する通知

プロトコルに関する通知

通知のモニタリング

この章では、Cisco IOS リリース 12.2xxxx に導入された MIB 拡張機能でサポートされている Cisco 10000 シリーズ ルータの通知について説明します。SNMP は、通知を使用して管理対象デバイス上のイベントをレポートします。通知には、さまざまなイベントに対応してトラップとインフォームがあります。ルータは、他の記載されていない通知もサポートしています。

この章の内容は次のとおりです。

「SNMP 通知の概要」

「シスコの SNMP 通知」

SNMP 通知の概要

SNMP エージェントは、次のような重要なシステム イベントが発生したときに、マネージャに通知することができます。

インターフェイスまたはカードが動作を停止した場合

温度がしきい値を超えた場合

認証エラーが発生した場合

エージェントはアラーム条件を検知すると、次の動作を行います。

その条件の発生時刻、タイプ、および重大度の情報を記録します。

通知メッセージを生成し、所定の IP ホストに送信します。

SNMP 通知は、次のいずれかの形式で送信されます。

トラップ ― SNMP マネージャからの受信確認応答を必要としない、信頼性の低いメッセージ。

インフォーム ― SNMP が応答するまでメモリに保管される、信頼性の高いメッセージ。インフォームはトラップよりも、システム リソースを多く使用します。

システム上で SNMP 通知を使用するには、トラップの送信先を指定する必要があります。この送信先に対し Network Registrar 通知が送信されます。デフォルトでは、すべての通知がイネーブルになっていますが、トラップ送信先は未定義になっています。送信先を定義しないと、通知はいっさい送信されません。

多くのコマンドで traps という語がコマンド構文内に使用されます。トラップかインフォームかを選択するオプションがコマンドに存在する場合を除いて、 traps キーワードが使用された場合は、トラップまたはインフォーム、あるいはその両方を意味します。SNMP 通知の送信にトラップまたはインフォームのどちらかを指定するには、 snmp-server host コマンドを使用します。トラップのタイプは両方のコマンドで指定できます。


) 通知タイプはほどんどのものがデフォルトでディセーブルです。ただし、通知タイプによっては、snmp コマンドで制御できないものがあります。たとえば、ある通知タイプは常にイネーブルになっていますが、他の通知タイプは別のコマンドでイネーブルになります。linkUpDown 通知は、snmp trap link-status コマンドで制御します。このコマンドを notification-type キーワードなしで入力すると、デフォルトではこのコマンドで制御されるすべての通知タイプがイネーブルになります。


全部のトラップは送信したくない場合、トラップ タイプを指定します。次に、複数の snmp-server enable traps コマンドを使用し、それぞれに snmp host コマンドで使用したトラップ タイプを指定します。イベント テーブルには、実行させるアクションを指定したエントリが必要です。

通知および通知タイプの一覧に関する詳細については、次の URL を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_1 /

http://www.cisco.com/warp/public/477/SNMP/SNMPTrapsInImages.html

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf014.htm

通知のイネーブル化

MIB 通知は、次のいずれかの手順でイネーブルにします。

CLI(コマンドライン インターフェイス) ― トラップ メッセージの送信先を指定し、送信するトラップのタイプを指定します。コマンドにはイネーブルにするインフォームのタイプも指定します。

詳細手順については、次の URL を参照してください。

http://www.cisco.com/warp/public/477/SNMP/SNMPTrapsInImages.html

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_1/snmpinfm.htm

setany コマンドを使用して SNMP SET 操作を実行 ― MIB 通知をイネーブルまたはディセーブルにするには、特定のオブジェクトに対し SNMP SET 操作を実行します。

通知をイネーブルにするには、オブジェクトに true(1) を設定します。

通知をディセーブルにするには、オブジェクトに false(2) を設定します。


) notification-type 引数を指定しないで snmp-server enable traps コマンドを発行すると、ルータはすべてのタイプのイベントを生成しますが、すべては必要ないかもしれません。MIB によっては、さらにオブジェクトを設定して複数の通知をイネーブルにする必要があります。


シスコの SNMP 通知

ここでは表を使用して、MIB イベント、イベントの発生原因、およびイベントに対処する際の推奨処置について説明します。それぞれの表には、次の情報が含まれています。

文字列 ― イベント名

説明 ― イベントの意味

考えられる原因 ― この通知の原因として考えられること

推奨処置 ― 該当する通知が発生した場合にとるべき推奨処置


) 下記の表で、対処不要と記されている箇所では、トラブル チケットなどのアプリケーションが起動される環境になっている場合があります。詳細については、次の URL を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/info_ctr/3_0/install/overview.htm


環境または機能に関する通知

Cisco 10000 シリーズの故障、またはルータの機能に影響を及ぼす可能性のある状況を表すイベントの発生時に生成される通知を、 表4-1 に示します。

 

表4-1 環境および機能に関する通知

イベント
説明
考えられる原因
推奨処置
cefcModuleStatusChange

モジュールの状態が変化しました。

モジュールのステートが不明です。

show module コマンドを入力して、エラー メッセージの詳細を確認します。このイベントに関連付けられた Syslog メッセージについては、「メッセージおよび回復手順」を参照してください。

スロットにラインカードがプロビジョニングされましたが、カードが搭載されていません。

指定のスロットに設定済みのラインカードを挿入します。

モジュールが動作可能です。

対処不要です。

モジュールが何らかの問題で故障しました。

show module コマンドを入力して、エラー メッセージの詳細を確認します。このイベントに関連付けられた Syslog メッセージについては、「メッセージおよび回復手順」を参照してください。

cefcPowerStatusChange

Field Replaceable Unit(FRU; 現場交換可能ユニット)の電源の状態が変化しました。

何らかの問題で FRU の電源がオフになりました。

show power コマンドを入力し、電力の実際の使用状況を確認します。このイベントに関連付けられた Syslog メッセージについては、「メッセージおよび回復手順」を参照してください。

FRU の電源がオンになりました。

対処不要です。

FRU が管理上のオフになりました。

対処不要です。

使用可能なシステム電力の不足により、FRU の電源がオフになっています。

show power コマンドを入力し、電力の実際の使用状況を確認します。

cefcFRUInserted

FRU が挿入されました。

ラインカード、ファン、ポート、電源モジュール、リダンダント電源などの FRU が新たに追加されました。

対処不要です。

cefcFRURemoved

FRU が取り外されました。

ラインカード、ファン、ポート、電源モジュール、リダンダント電源などの FRU が取り外されました。

FRU を交換します。

chassisAlarmOn

FRU の状態が変化しました。この MIB の chassisTempAlarm、chassisMinorAlarm、または chassisMajorAlarm オブジェクトが on (2) ステートに変化しました。

シャーシの温度が高すぎます。マイナー アラームまたはメジャー アラームが検出されました。

表示されたコンポーネントが通常の動作温度の範囲を超える原因と、許容される動作温度の範囲を最終的には超えてしまうのかどうかをよく調べます。

 

リダンダント電源の電源がオフになりました。

FRU を交換します。

 

ルータの冷却ファン系が故障する可能性があります。

システム ファン トレイ内の 1 つまたは複数のファンが故障しました。これはマイナー アラームですが、システム コンポーネントが過熱してシャットダウンする可能性があります。

できるだけ早急にファンを交換しないと、システムがシャットダウンしたり動作が不安定になる可能性があります。

chassisAlarmOff

FRU の状態が変化しました。この MIB の chassisTempAlarm、chassisMinorAlarm、または chassisMajorAlarm オブジェクトが off (1) ステートに変化しました。

リダンダント電源の電源がオンになりました。

対処不要です。

ccCopyCompletion

コンフィギュレーションのコピー操作が完了しました。

ルータがほかの装置との間でコンフィギュレーション ファイルのコピーを終了しました。

 

ciscoConfigManEvent

ルータのコンフィギュレーションが変化しました。

 

 

dsx1LineStatusChange

dsx3LineStatusChange

dsx1 LineStatus は、ループバックの状態とエラーの状態の情報が格納されているビット マップです。

エラーが検出されると、dsx1 LineStatus の対応ビットが変化して障害を示します。たとえば、Receiving LOS エラーが検出されると、対応するビット 64がエラーを示すことになっています。それによって dsx1 LineStatus が変化します。

dsx1 LineStatus でエラーがレポートされた場合、エラーの原因となっている状況を修正することが推奨処置です。

シスコ製ラインカードに関する通知

これらの通知は、ラインカードの故障、または全インターフェイスの正常な動作および接続先カスタマーに影響を及ぼす可能性のあるカード上のエラー条件を示しています。

Cisco 10000 シリーズ ルータ ラインカードが生成する ENTITY-MIB を 表4-2 に示します。

 

表4-2 Cisco 10000 シリーズ ルータ カードに関する通知

イベント
説明
考えられる原因
推奨処置
entConfigChange

entPhysicalTable からラインカードのエントリが削除されました(その結果、entLastchangeTime の値が変化)。

ラインカードが取り外されました。

FRU を交換します。

 

entPhysicalTable にラインカードのエントリが追加されました(その結果、
entLastchangeTime の値が変化)。

ラインカードが挿入されました。

対処不要です。

cefcModuleOperStatus

ラインカードの動作状態が変化しました。管理アプリケーションはこのトラップを使用して、管理対象のモジュールの状態を更新します。

スロットにラインカードがプロビジョニングされましたが、カードが搭載されていません。

モジュールを追加します。

entSensorThresholdNotification

センサーの値がしきい値を超えました。この変数でセンサーによる最新の計測値がレポートされます。この変数はしきい値の値を示します。

しきい値を超えたモジュールのセンサー値は entSensorThresholdTable に示されています。この通知はセンサー値がしきい値を超えるごとに 1 回生成されます。

センサーのしきい値超えに起因するモジュール シャットダウンをバイパスしている設定を削除します。設定を削除したあと、モジュールをシャットダウンします。モジュールはセンサーのメジャーしきい値を超えました。


) メジャー センサー アラームのイベント時に、モジュールを
シャットダウンするコマンドが無効にされていたため、指定されたモジュールはシャットダウンしません。
シャットダウンを無効にするために使用されたコマンドは no
environment-monitor
shutdown
です。


 

ローカル CPU がモジュールの温度センサーにアクセスできませんでした。モジュールはモジュール自身をリセットして回復を試行します。

コンソールまたはシステム ログに出力されたエラー メッセージをそのままコピーし、シスコのテクニカル サポート担当者に連絡して、集めた情報を提示してください。

ceAssertAlarm

物理エンティティがアラームをアサートしたときに、エージェントが生成します。

このアラームは、次の理由で送信されます。

ファン障害、ファントレイの紛失

電源入力モジュールの障害

Core Critical Temperature Limit(内部クリティカル温度制限)に達するなど、内部または吸気口温度のしきい値の超過

[Card Stopped Responding OIR] アラームの発生

Path alarm indication signal(パス アラーム表示信号)の発生

Path remote failure indication(パス リモート障害表示)の発生

Path loss of a pointer(パス ポイント喪失)

Line alarm indication signal(ライン アラーム表示信号)

Line remote failure indication(ライン リモート障害表示)

Section Loss of Signal Failure(セクション信号喪失)

Threshold cross alarm(しきい値の超過)

Out of frame failure(フレーム同期外れ障害)

Signal failure(信号喪失)

相手側クロックが動作範囲を逸脱

さまざまな理由でアラームがアサートするので、
entPhysicalDescr タイプを確認し、対応する処置をします。

ceClearAlarm

物理エンティティが以前アサートしたアラームをクリアしたときに、エージェントが生成します。

物理エンティティが以前アサートしたアラームをクリアしたときに、エージェントが生成します。

ラインカード スロットにラインカードが挿入され、[Active Card Removed OIR] アラームがクリアされたときに送信されます。

対処不要です。

フラッシュ カードに関する通知

Cisco 10000 シリーズ ルータ フラッシュ カードが生成する CISCO-FLASH-MIB を 表4-3 に示します。これらの通知は、フラッシュ カードの故障、または全インターフェイスの正常な動作や接続先カスタマーに影響を及ぼす可能性のあるカード上のエラーを示しています。

 

表4-3 フラッシュ カードに関する通知

イベント
説明
考えられる原因
推奨処置
ciscoFlashDeviceChangeTrap

取り外し可能デバイスがルータに挿入されました。

状態が変化しました。

ciscoFlashDeviceTable を参照して、どのフラッシュ カードが挿入されたか確認します。

取り外し可能デバイスがルータから取り外されました。

状態が変化しました。

ciscoFlashDeviceTable を参照して、どのフラッシュ カードが挿入されたか確認します。

ciscoFlashCopyCompletionTrap

フラッシュのコピー操作が終了しました。

 

 

ciscoFlashPartitioningCompletionTrap

フラッシュのパーティショニング操作が終了しました。

 

 

ciscoFlashMiscOpCompletionTrap

フラッシュ カードの副次的な操作が終了しました。

 

 

インターフェイスに関する通知

表4-4 に、リンク関連(インターフェイス)のイベントに関してルータが生成する通知を示します。

 

表4-4 インターフェイスに関する通知

イベント
説明
考えられる原因
推奨処置
linkDown

リンクが Down ステートに移行しようとしています。これはトラフィックの送受信ができないことを意味します。ifOperStatus オブジェクトにリンクの以前のステートが示されます。値は down(2) です。

内部ソフトウェア エラーが発生している可能性があります。

インターフェイス上でリンク トラップがイネーブルまたはディセーブルになっているかどうかを確認するには、インターフェイスの
ifLinkUpDownTrapEnable(IF-MIB)を確認します。リンク トラップをイネーブルにするには、
ifLinkUpDownTrapEnable
に enabled(1) を設定します。

CLI コマンドの snmp-server trap link ietf を発行して、リンク トラップの IETF(RFC 2233)形式をイネーブルにします。

linkUp

リンクのステートが Down ではなくなりました。
ifOperStatus にリンクの新しいステートが示されます。値は up(1) です。

ポート マネージャが、スイッチオーバー時にポートのリンクダウン ステートを再びアクティブにしました。

対処不要です。

MPLS サービスに関する通知

表4-5 に、サービスの状況を表すためにルータが生成する、サービスに関する通知を示します。

 

表4-5 MPLS サービスに関する通知

イベント
説明
考えられる原因
推奨処置
mplsTunnelUp

設定されているトンネルの mplsTunnelOperStatus オブジェクトが、Down ステートから NotPresent 以外のステートに移行しようとしています。

設定されているトンネルが、Down ステートから NotPresent 以外のステートに移行しました。

トンネルの管理上または操作上のステータス チェックが原因であると考えられます。

対処不要です。

mplsTunnelDown

設定されている MPLS トラフィック エンジニアリング トンネル の mplsTunnelOperStatus オブジェクトがそれぞれ up(1) または down(2) に移行しようとしています。

設定されているトンネルが Down ステートに移行中です。

トンネルの管理上または操作上のステータス チェックが原因であると考えられます。

 

mplsTunnelRerouted

MPLS トラフィック エンジニアリング トンネルのシグナリング パスが変化しました。

トンネルの再ルーティングまたは再最適化が行われました。

実際のパスを使用する場合は、通知が発行されたあとに新しいパスを mplsTunnelRerouted に書き込みます。

VpnThreshCleared

ネットワーク管理者にルートの数が変化したことを通知します。

VRF 内のルート数がしきい値を下回りました。

ルーティング プロトコル関連の通知

Cisco 10000 シリーズ ルータがルーティング プロトコルおよびサービスのエラー状況を表すために生成する BGP4-MIB に関する通知のうち、Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)ステートの変化に関するものを 表4-6 に示します。

 

表4-6 ルーティング プロトコル関連の通知

イベント
説明
考えられる原因
推奨処置
bgpEstablished

BGP FSM が ESTABLISHED ステートに移行しました。BGP FSM はルータ上でアクティブになります。

BGP ルーティング プロトコルの状態が変化しました。

対処不要です。

bgpBackwardTransition

BGP プロトコルが上位ステートから下位ステートに移行します。BGP セッション上のアドレス ファミリーのプレフィクス カウントが設定されているしきい値を超えました。

BGP ルーティング プロトコルの状態が変化しました。

このしきい値は、CLI コマンドの neighbor <nbr_addr> <max_prefixes> [ theshold] [warning-only] を使用して設定します。

シャーシに関する通知

表4-7 に、シャーシ モジュールがアクティブになったか、または応答を停止したことを示すためにルータが生成する CISCO-STACK-MIB に関する通知を示します。これらの通知は、Cisco 10000 シリーズ ルータによりサポートされています。

 

表4-7 シャーシに関する通知

イベント
説明
考えられる原因
推奨処置
moduleDown

モジュールの状態が OK ステートから別のステートに移行します。

モジュールのいずれかについて、この MIB の moduleStatus オブジェクトが ok (2) ステートに移行したことをエージェント エンティティが検出しました。このトラップの生成は、この MIB の sysEnableModuleTraps オブジェクトを使用して制御できます。

show module command を入力して状態を確認します。

moduleUp

モジュールの状態が OK ステートに移行します。

モジュールのいずれかについて、この MIB の moduleStatus オブジェクトが ok (2) ステートから別の状態に移行したことをエージェント エンティティが検出しました。このトラップの生成は、この MIB の sysEnableModuleTraps オブジェクトを使用して制御できます。

対処不要です。

RTT モニタに関する通知

表4-8 に、Round-Trip Time(RTT)モニタリング中に発生する可能性のある CISCO-RTTMON-MIB に関する通知を示します。

 

表4-8 RTT モニタに関する通知

イベント
説明
考えられる原因
推奨処置
rttMonConnectionChangeNotification

rttMonCtrlOperConnectionLostOccurred の値が変化すると送信されます。

ターゲットとの接続の確立に失敗したか、接続が切断されて再確立された場合に発生します。

ターゲットとの接続性を確認します。異なるホップを通過するターゲットへのリンクの問題の可能性があります。

rttMonTimeoutNotification
 

タイムアウトが発生したか、クリアされました。

RTT プローブが発生し、
rttMonCtrlOperTimeoutOccurred の値が変化したとき、システムによりこの通知が送信されます。

この通知の
rttMonCtrlOperTimeoutOccurred が true を返した場合は、エンドツーエンドの接続性を確認します。

rttMonCtrlOperTimeoutOccurred が false の場合は対処不要です。

rttMonThresholdNotification

しきい値超過が発生しました。

RTT プローブが発生したか、後続の RTT 動作で以前のしきい値超過が正常なレベルに戻りました。

この通知の
rttMonCtrlOperOverThresholdOccurred が true の場合は、エンドツーエンドの接続性を確認します。true でない場合は対処不要です。

環境に関する通知

Cisco 10000 シリーズの故障、またはルータの機能に影響を及ぼす可能性のある状況を表すイベントの発生時に生成される、CISCO-ENVMON-MIB に関する通知を 表4-9 に示します。

 

表4-9 環境に関する通知

イベント
説明
考えられる原因
推奨処置
ciscoEnvMonShutdownNotification

ciscoEnvMonShutdown 通知は、環境モニタが重大な状態に達したテストポイントを検出してシャットダウンしようとしている場合に送信されます。可能な限り短時間で符号化して通知を送信できるように、この通知にはオブジェクトが含まれていません。シャットダウンが完了する前に通知を送信できるとは限らないので、管理アプリケーションはこの通知に依存することは避けてください。

計測値がクリティカルな状態に近づいて、ルータがシャットダウンしようとしているときに送信されます(たとえば、自動シャットダウンがイネーブルになったり、シャーシ内部または吸気口の温度がクリティカルな状態になったまま 2 分以上が経過した場合など)。

システムには、システムの動作温度が温度しきい値を超えた場合にモジュールをシャットダウンするためのコンフィギュレーションがあります。このコンフィギュレーションはパイバスされており、モジュールは過熱状態になっても動作します。過熱状態で動作すると、ハードウェアが損傷することがあります。

過熱時に作動するセンサー アラームは無効にしないでください。 environment-monitor shutdown temperature コマンドを入力して、システムを標準の温度検出環境に戻します。

ciscoEnvMonFanNotification

 

システムのファン トレイ内の 1 つまたは複数のファンが故障しました。これはマイナー アラームですが、システム コンポーネントが過熱してシャットダウンする可能性があります。

システムのファン トレイを交換します。

ciscoEnvMonRedundantSupplyNotification

リダンダント電源(ある場合)が故障すると送信されます。

環境面の問題、過熱状態、またはモジュールへの電圧変動が発生しました。通常、この通知はシャットダウン ステートされる前に生成されるので、
ciscoEnvMonShutdownNotification の場合よりも多くのデータを伝送することが可能になり、送信される確率も高くなります。

システムの電源モジュールが最適な冗長構成であることを確認します。同一の出力定格の電源モジュールを使用するか、またはシステムの電力消費を低減します。

ciscoEnvMonTempStatusChangeNotif

内部または吸気口の温度が正常な範囲を超え、ciscoEnvMonState が警告またはクリティカルのいずれかの状態になっています。

通常、この通知はシャットダウン ステートされる前に生成されるので、
ciscoEnvMonShutdownNotification の場合よりも多くのデータを伝送することが可能になり、送信される確率も高くなります。

以前のリロード時、このモジュールは温度センサーをアクセスしてタイムアウトを検出しました。それ以降の温度センサーへのアクセスは、すべてディセーブルにされます。この状態は、温度センサーに問題がある可能性を示しています。

コンソールまたはシステム ログに出力されたエラー メッセージをそのままコピーし、シスコのテクニカル サポート担当者に連絡して、集めた情報を提示してください。

 
* リダンダント電源がディセーブルになっていると、cefcFRUPowerAdminStatus は on(1) です。リダンダント電源があると、リダンダント電源がディセーブルかどうかにかかわらず、両方の電源モジュールの cefcFRUPowerAdminStatus は常に on(1) です。

フレームリレーに関する通知

表4-10 に、ルータのフレームリレーのイベント時に発生する通知を示します。

 

表4-10 フレームリレーに関する通知

イベント
説明
考えられる原因
推奨処置

frDLCISStatusChange

Virtual Circuit(VC; 仮想回線)の状態が変化しました。

フレームリレーの VC の状態が変化すると送信されます。たとえば、回線が作成された場合や破棄された場合、または回線の状態がアクティブと非アクティブの間で変動する場合が該当します。

 

PFE に関する通知

表4-11 に、Packet Fowarding Engine(PFE)のイベント時に発生する通知を示します。

 

表4-11 PFE に関する通知

イベント
説明
考えられる原因
推奨処置
cePfeThldEvent

PFE 利用率または効率の状態が変化しました。

PFE 利用率または効率がしきい値に達するか、またはしきい値を超えると送信されます。たとえば、現在の PFE 利用率(cePfePerfCurrentUtilization)が、しきい値の cePfePerfConfigThldUtilization に達するか、または超えると、SNMP は thldUtilizationEvent を生成します。

cePfeHistType は、発生したイベント タイプを示します。イベント タイプの詳細については、この MIB オブジェクトの HistEventType を参照してください。

CLI を使用するか、または cePfeHistNotifiesEnable to notify(3) もしくは logAndNotify(4) をセットしてこの通知をイネーブルにします。

cePfeHistRestartEvent

PFE プロセッサの状態が変化しました。

PFE プロセッサが再起動されました。

対処不要です。

SSG に関する通知

表4-12 に、Service Selection Gateway(SSG)のイベント時に発生する通知を示します。

 

表4-12 SSG に関する通知

イベント
説明
考えられる原因
推奨処置

 

SSG の状態が変化しました。

RADIUS クライアントが再起動したことを、SSG が検出すると送信されます。(SSG は RADIUS サーバを使用して加入者を認証します)。

 

プロトコルに関する通知

表4-13 に、プロトコルのイベント時に発生する通知を示します。

 

表4-13 プロトコルに関する通知

イベント
説明
考えられる原因
推奨処置

frDLCISStatusChange

casState オブジェクトの状態が変化しました。

casState オブジェクトの状態が変化すると送信されます。casState の値は次のように、ルータが要求を Authentication,
Authorization, and Accounting(AAA)サーバに送信するかどうかを示します。

up(1) ― 要求をサーバに送信する

up(2) ― 要求をサーバに送信しない。次に使用可能なサーバに要求を送信します。

casState オブジェクトは、サーバの現在の状態を必ずしも示しているわけではありません。それは、casState は AAA 要求に失敗しないかぎり、常に up(1) を示すからです。要求に失敗した場合は、casState が dead(2) に設定されてから、up(1) が再設定されるのでルータが障害のあとでも要求の送信が可能になります。

casState が dead(2) の状態を保つ時間(分)は、 radius-server deadtime minutes コマンドで指定します。たとえば、この値を 5 分に設定し、AAA 要求が失敗した場合、casState に dead(2) が設定されて通知が生成されます。5 分が経過すると、サーバがダウンしたままであっても、casState に up(1) が設定されてもう 1 つの通知が生成されます。

 

oamLoopbackPingCompletionTrap

 

OAM ループバック テストが完了すると送信されます。

 

cPppoeSystemSessionThresholdTrap

 

アクティブな PPPoE セッション数が
cPppoeSystemThresholdSessions の値を超えると送信されます。

 

cPppoeVcSessionThresholdTrap

 

VC 上のアクティブな PPPoE セッション数が cPppoeVcThresholdSessions の値を超えると送信されます。