Cisco ASR 1000 シリーズ アグリゲーション サービス ルータ MIB 仕様ガイド

冗長性のレベル

ここでは、Cisco ASR 1000 シリーズ ルータでサポートされている冗長性のレベルおよびこの機能を使用できることを確認する方法について説明します。Cisco ASR 1000 シリーズ ルータでは、アクティブなスーパーバイザ エンジンが故障した場合にシスコの冗長スーパーバイザ エンジン（SE）が処理を引き継ぐようにすることによって、障害耐性をサポートします。冗長性は、装置の障害によってサービスが停止することを防止し、中断のないメンテナンスとアップグレードのアクティビティをサポートします。インターフェイスおよびサブインターフェイスの状態は、ラインカードやさまざまなパケット処理ハードウェアの状態とともに保持されます。

冗長システムは 2 台のルート プロセッサをサポートします。1 台はアクティブなルート プロセッサとして動作し、もう一方はスタンバイ ルート プロセッサとして動作します。

Route Processor Redundancy 機能は、次のいずれかの状況が発生した場合に、スタンバイ ルート プロセッサへの切り替えによって Cisco ルータにハイ アベイラビリティを提供します。

• Cisco IOS ソフトウェア障害

• Cisco ASR 1000 シリーズ ルート プロセッサ（RP）のハードウェア障害

• ソフトウェア アップグレード

• メンテナンス手順

Cisco ASR 1000 シリーズ ルータは、次の 2 つの冗長モードのいずれかで動作できます。

• Route Processor Redundancy（RPR）モード

• Nonstop Forwarding/Stateful Switchover（NSF/SSO）モード

すべてのモードで、アクティブ RP に障害が発生するとスタンバイ RP が処理を引き継ぎます。

Route Processor Redundancy

ここでは、Cisco ASR 1000 シリーズ ルータの Route Processor Redundancy（RPR）モードについて説明します。

スイッチの電源投入時に、2 つのシスコ スーパーバイザ エンジン間で RPR が稼働します。最初に起動するスーパーバイザ エンジンは、RPR アクティブスーパーバイザ エンジンになります。

Cisco ASR 1000 シリーズ ルータでは、アクティブなスーパーバイザ エンジンが故障した場合に冗長スーパーバイザ エンジンが処理を引き継ぐようにすることによって、障害耐性をサポートします。

Cisco Nonstop Forwarding and Stateful Switchover

ここでは、Cisco Nonstop Forwarding and Stateful Switchover モードについて説明します。NSF/SSO を使用すると、Cisco ASR 1000 シリーズ ルータは、ほとんどすぐにアクティブからスタンバイ ルート プロセッサにフェールオーバーし、パケットを転送し続けます。このプラットフォームの Cisco IOS ソフトウェア NSF/SSO のサポートは、即時のフェールオーバーをイネーブルにします。

NSF/SSO が動作するネットワーキング デバイスでは、アクティブ RP に障害が発生した後、スタンバイ RP がいつでも制御を引き継げるように、両方の RP で同じコンフィギュレーションを実行する必要があります。起動時およびアクティブ RP のコンフィギュレーションに変更が生じるたびに、アクティブ RP からスタンバイ RP にコンフィギュレーション情報が同期されます。

2 つのプロセッサ間の初期同期後に、NFS/SSO は転送情報などの両者間の RP ステート情報を維持します。

Cisco Nonstop Forwarding（NSF）とステートフル スイッチオーバー（SSO）を組み合わせることにより、デュアル RP を搭載したルータにおけるルータ プロセッサ（RP）のフェールオーバー後に、ユーザがネットワークを使用できない時間が最小限に抑えられます。NSF/SSO 機能を使用すると、ルータは、スイッチオーバーを検出し、ネットワーク トラフィックを転送し続けてピア デバイスからルート情報を回復するために必要なアクションを実行できます。

Cisco IOS ソフトウェアで Cisco NSF とステートフル スイッチオーバー（SSO）機能を組み合わせることにより、スイッチオーバー後に、ユーザがネットワークを使用できない時間が最小限に抑えられます。Cisco NSF/SSO の主な目的は、ルーティング プロトコル情報がルートのスイッチオーバー後に復元される間、既知のルートでデータ パケットの転送を継続することです。

（注） Nonstop Forwarding 機能に関する詳細については、次を参照してください。
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsnsf20s.html

（注） ステートフル スイッチオーバー機能に関する詳細については、次を参照してください。
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fssso20s.html

ソフトウェア冗長性

RP スロットが 1 つだけ搭載された Cisco ASR 1004 ルータは、ハードウェア冗長性をサポートしていません。代わりに、これらのルータには、2 つの IOSD プロセスを実行することによるソフトウェア冗長性というオプションがあります。IOSD は、必要に応じて冗長構成で実行できます。1 つの IOSD インスタンスがアクティブで、他のインスタンスはホット スタンバイ モードで維持されます。ステート情報は IPC 上の標準の SSO サポートを使用してインスタンス間で交換されます。ソフトウェア冗長性のオプションは、2 番目の RP がシャーシに追加されている場合は使用できず、非アクティブになります。アクティブ RP がアクティブとスタンバイの両方の FP およびすべての I/O（キャリア）カードを制御します。アクティブ IOSD インスタンスが失敗した場合、バックアップが処理を引き継ぎ、FP および I/O カードと状態を再同期します。

Cisco ASR 1000 シリーズ ルータの冗長性の確認

Cisco ASR 1000 シリーズ ルータにインストールされたアクティブおよびスタンバイ スーパーバイザ エンジンに関する情報を表示するには、 show redundancy コマンドおよび show redundancy states コマンドを使用します。R0 スロットのルータ プロセッサの場合、ユニット ID の値は、ASCII の「0」と同じ 48（16 進で 30）です。R1 スロットのルータ プロセッサの場合、ユニット ID の値は 49、ASCII の「1」（16 進で 31）です。

例 A-1 アクティブ プロセッサからの冗長状態の表示

例 A-2 スタンバイ プロセッサからの冗長状態の表示

例 A-3 ソフトウェア冗長性の冗長状態の表示：ASR 1004

関連情報および有益なリンク

次の URL から、シスコの冗長性機能に関する有用な情報にアクセスできます。

• Cisco Nonstop Forwarding に関する詳細情報：
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsnsf20s.html

• ステートフル スイッチオーバー機能に関する詳細情報：
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fssso20s.html

• Route Processor Redundancy 機能に関する詳細情報：
http://www.cisco.com/en/US/docs/ios/12_1/12_1ex/feature/guide/12e_rpr.html

インベントリ管理の実行

ルータのエンティティに関する情報を取得するには、ENTITY-MIB entPhysicalTable に対する MIB ウォークを実行します。

ENTITY-MIB entPhysicalTable のサンプル エントリを検証する場合は、次の点を考慮します。

• entPhysicalIndex：シャーシの各エンティティを一意に識別します。このインデックスは、他の MIB のエンティティに関する情報へのアクセスにも使用されます。

• entPhysicalContainedIn：コンポーネントの親エンティティの entPhysicalIndex を示します。

• entPhysicalParentRelPos：同じ entPhysicalContainedIn 値を持つ同じタイプのエンティティ（たとえば、シャーシ スロット、およびラインカード ポート）の相対的な位置を示します。

（注） コンテナは、物理エンティティ クラスに 1 つ以上の着脱可能な物理エンティティを含めることができる場合に適用できます。たとえば、シャーシの各（空または完全な）スロットは、コンテナとしてモデル化されます。すべての着脱可能な物理エンティティは、現地交換可能なモジュール、ファン、電源などのコンテナ エンティティ内でモデル化する必要があります。

ENTITY-MIB entPhysicalTable のサンプル エントリ

ここに挙げるサンプルは、情報が entPhysicalTable にどのように保存されているかを示します。entPhysicalTable エントリを調べて、アセットのインベントリを実行できます。

（注） この章全体で示すサンプルの出力と値は、MIB を使用する場合に表示できるデータの例です。

次の表示は、カードに挿入されたルータ シャーシおよび 4 つの SPA に取り付けられている ASR1000 SIP-10 カードの ENTITY-MIB entPhysicalTable のサンプル エントリを示しています。

ENTITY-MIB entPhysicalTable のエントリ

entPhysicalVendorType は、物理エンティティの一意のベンダー固有のハードウェア タイプを識別します。

entPhysicalContainedIn は、コンポーネントの親エンティティの entPhysicalIndex を示します。

entPhysicalClass は、ハードウェア デバイスの一般的なタイプを示します。

entPhysicalParentRelPos は、他のエンティティ間におけるこの 子 の相対的な位置を示します。

entPhysicalName は、物理エンティティのテキスト名を指定します。

entPhysicalHardware は、物理エンティティのベンダー固有のハードウェア リビジョン番号（string）を提供します。

entPhysicalSerialNumber は、物理エンティティのベンダー固有のシリアル番号（string）を提供します。

entPhysicalMfgName は、物理コンポーネントの製造元の名前を提供します。

entPhysicalModelName は、物理コンポーネントのベンダー固有のモデル名文字列を提供します。

entPhysicalIsFRU は、物理エンティティが現場交換可能ユニット（FRU）と見なされるかどうかを示します。

サンプル設定に関して、次の点に注意してください。

• すべてのシャーシ スロットにおよびラインカードのポートは entPhysicalContainedIn 値が同じです。

– シャーシ スロットの場合、entPhysicalContainedIn = 1（シャーシの entPhysicalIndex）。

– SPA ポートの場合、entPhysicalContainedIn = 1280（SPA カードの entPhysicalIndex）。

• 各シャーシ スロットにおよびラインカードのポートは、親オブジェクト内の相対位置を示す entPhysicalParentRelPos が異なります。

物理ポートの ifIndex 値の確認

ENTITY-MIB entAliasMappingIdentifier は、ポートの entPhysicalIndex を IF-MIB ifTable の対応する ifIndex 値にマッピングして、物理ポートをインターフェイスにマッピングします。次のサンプルは、entPhysicalIndex が 35 である物理ポートが ifIndex 値が 4 であるインターフェイスに関連付けられていることを示します。（考えられる MIB 値の詳細については、MIB を参照してください）。

FRU のステータスのモニタリングと設定

電源やラインカードなどの FRU の管理ステータスおよび動作ステータスを確認するには、CISCO-ENTITY-FRU-CONTROL-MIB cefcModuleTable のオブジェクトを表示します。

• cefcModuleAdminStatus：FRU の管理状態。cefcModuleAdminStatus を使用して、FRU をイネーブルまたはディセーブルにします。

• cefcModuleOperStatus：FRU の現在の動作状態。

図 A-1 に、entPhysicalIndex が 1000 である SIP カードの cefcModuleTable エントリを示します。

図 A-1 サンプル cefcModuleTable エントリ

FRU 状態の変更を示す通知をルータがどのように生成するかについては、「FRU ステータスの変更」を参照してください。

ENTITY-ALARM-MIB を使用したエンティティ アラームのモニタ

ENTITY-MIB

エンティティの物理的なテーブルには、ルータの物理エンティティを管理するための情報が含まれます。また、階層と相互の関係を示す包含ツリーにエンティティを編成します。エンティティ階層については、 付録 A「エンティティの包含ツリー」 の項を参照してください。次のサンプル出力は、電源ベイ 0 の ASR1002 AC 電源に関する情報が含まれています。

この MIB の詳細については、「ENTITY-MIB（RFC 4133）」を参照してください。

CISCO-ENTITY-ALARM-MIB

CISCO-ENTITY-ALARM-MIB は、シャーシ、スロット、モジュール、ポート、電源などのシステムに含まれる物理エンティティによって生成されたアラームのモニタリングをサポートします。物理エンティティによって生成されたアラームをモニタするには、エンティティが entPhysicalTable の行で表されている必要があります。

この MIB の詳細については、「CISCO-ENTITY-ALARM-MIB」を参照してください。

アラームの説明のマッピング テーブル

（entPhysicalVendorType OID によって表される）エンティティのタイプごとに、このテーブルには、一意の ceAlarmDescrIndex と entPhysicalvendorType OID 間のマッピングが含まれます。

ceAlarmDescrMapEntry は、CeAlarmDescrMapEntry によってインデックスが作成されます。

（注） ceAlarmDescrIndex と entPhysicalvendorType OID 間のマッピングは、エンティティのタイプがアラームのモニタリングをサポートする場合にのみ存在し、デバイス起動時からデバイスにあります。

次に、サンプル出力例を示します。

ASR1000 モジュール（RP、FP、CC、および PEM）の温度センサーには、entPhysicalvendorType OID として cevSensorModuleDeviceTemp が含まれます。上記のサンプル出力で、インデックス（ceAlarmDescrIndex）9 は、cevSensorModuleDeviceTemp にマッピングされ、インデックス 19 は、エンティティの物理ベンダー タイプ OID が cevPowerSupplyASR1002AC である AER10002 電源にマッピングされます。

（注） SPA はすべての ASR1000 モジュールに含まれません。その独自のベンダー タイプ OID がセンサーに定義されています。

（注） ASR1000 snmp エージェントがセンサー タイプを特定できない場合は、汎用ベンダー OID の cevSenor が使用されます。

アラーム説明テーブル

アラーム説明テーブルには、システムで採用されている各ベンダー タイプによって定義された各アラーム タイプの説明が含まれます。各アラーム説明エントリ（ceAlarmDescrEntry）は、ceAlarmDescrIndex および ceAlarmDescrAlarmType によってインデックスが作成されます。

次に、ASR1000 モジュールのエンティティの温度タイプすべてに定義されているすべてのアラーム タイプのサンプル出力を示します。 インデックス 9 は、前の項の ceAlarmDescrMapTable から取得されます。

『Bellcore Technical Reference TR-NWT-000474 Issue 4, December 1993, OTGR Section 4. Network Maintenance: Alarm and Control - Network Element』を参照してください。重大度は次のように定義されます。

• critical(1)

• major(2)

• minor(3)

• info(4)

次に、センサーに定義されているアラームのリストを示します。

これらのアラーム タイプは、すべてのセンサー物理エンティティ タイプに対して定義されます。唯一の違いは、センサー物理タイプごとに ceAlarmDescrText が異なる点です。アラームの説明テキストで、温度センサーには「TEMP」、電圧センサーには「Volt」があります。

次に、すべてのアラーム タイプのサンプル出力を示します。cevPowerSupplyASR1002AC がベンダー タイプ OID であり、ceAlarmDescrIndex 19 にマッピングされた ASR1002 AC 電源に対して定義されます。

アラーム テーブル

アラーム テーブルは、システムに含まれている各物理エンティティに関するアラームの制御およびステータス情報を示します。テーブルには、アラームを生成できる各物理エンティティによって現在アサートされているアラームが含まれます。アラームを生成できるエンティティ物理テーブル内の物理エンティティごとに、このテーブルにエントリがあります。アラーム エントリ（ceAlarmEntry）は、エンティティ物理インデックス（entPhysicalIndex）によってインデックスが作成されます。次に、アラーム エントリの MIB オブジェクトのリストを示します。

• ceAlarmFilterProfile
アラーム フィルタ プロファイル オブジェクトには、対応する物理エンティティに関連付けられたアラーム フィルタ プロファイルを一意に識別する整数値が含まれます。アラーム フィルタ プロファイルは、エージェントが対応する物理エンティティについてモニタおよびシグナリングするアラーム タイプを制御します。このオブジェクトのデフォルト値は 0 で、エージェントは、対応する物理エンティティに関連付けられたすべてのアラームをモニタおよびシグナリングします。

• ceAlarmSeverity
このオブジェクトは、対応する物理エンティティによって現在アサートされている最大の重大度のアラームを示します。
値が「0」の場合、対応する物理エンティティは現在アラームをアサートしていません。

• ceAlarmList
このオブジェクトは、対応する物理エンティティによって現在アサートされているアラームを示します。 アラームが物理エンティティによってアサートされている場合、アラーム リスト内の対応するビットは 1 に設定されます。アラーム リストは、オクテット文字列として定義され、そのサイズの範囲は 0 ～ 32 です。

– 物理エンティティが現在アラームをアサートしていない場合、リストの長さはゼロです。それ以外の場合、長さは 32 です。

– オクテット文字列はアラーム リストを表し、各ビットはアラーム タイプを表します。

オクテット 1：

オクテット 2：

オクテット xx

オクテット 32：

エンティティ物理テーブル（ENTITY-MIB の entPhysicalTable）から、電源ベイ 0 の ASR1002 AC 電源の entPhysicalIndex が 4 であることがわかります。

次に、PS ベイ 0 内の電源のアラーム リストのサンプル出力を示します。

オクテット 1：09

「アラーム説明テーブル」の項のサンプル出力およびアラーム マッピング テーブルより、ベイ 0 の ASR1002 AC 電源で次のアラームがアサートされています。

タイプ タイプ 0：電源の障害

タイプ タイプ 3：ファン 0 の障害

entPhysiclIndex が 14 であるベイ 1 の ASR1002 AC 電源：

ceAlarmList.14 =

ベイ 1 の電源について戻されたアラーム リストの長さが 0 であるため、ベイ 1 の電源にはアサートされるアラームがありません。

次に、「show facility-alarm status」CLI コマンドの出力を示します。デバイスで現在アサートされているすべてのアラームが表示されます。

アラーム履歴テーブル

アラーム履歴テーブル ceAlarmHistTable には、エージェントによって生成されたアラームのアサートおよびクリアの履歴が含まれます。ceAlarmHistTableSize は、アラーム履歴テーブルのサイズを制御するために使用されます。値が 0 の場合、履歴はこのテーブルに保持されません。ceAlarmHistTable の容量がこのオブジェクトで指定された値に達すると、エージェントは新しいエントリを格納するために最も古いエンティティを削除します。

ceAlarmHistLastIndex オブジェクトには、デバイスの snmp のエージェントによってテーブルに追加された最後のエントリに対応する最後のインデックスが含まれます。管理クライアントは、 CISCO-ENTITY-ALARM-MIB モジュールで定義された 付録 A「アラーム通知」 に示されている通知を使用する場合、このオブジェクトをポーリングして、エージェントが送信した通知を見失ったかどうかを確認できます。

次に、ceAlarmHistIndex でインデックスが作成された ceAlarmHistEntry に定義されている MIB オブジェクトのリストを示します。

• ceAlarmHistIndex
これは、テーブルのエントリを一意に識別する整数値です。このオブジェクトの値は「1」から始まり、アラームがアラーム履歴テーブルに対して追加（アサートまたはクリア）されるごとに単調に増加します。このオブジェクトの値が「4294967295」の場合、次のアラーム状態遷移をモニタするときに「1」にリセットされます。

• ceAlarmHistType
このオブジェクトは、アラームがアサートまたはクリアされた結果としてエントリが追加されたことを示します。

• ceAlarmHistEntPhysicalIndex
このオブジェクトには、アラームを生成した物理エンティティの entPhysicalIndex が含まれます。

• ceAlarmHistAlarmType
このオブジェクトは、生成されたアラームのタイプを示します。

• ceAlarmHistSeverity
このオブジェクトは、生成されたアラームの重大度を示します。

• ceAlarmHistTimeStamp
このオブジェクトは、アラームが生成されると、sysUpTime オブジェクトの値を示します。

例 A-4 アラーム履歴のサンプル出力の表示

ceAlarmHistTableSize.0 = 200 the size of alarm history table

ceAlarmHistLastIndex.0 = 21 the index for the last alarm added

例 A-5 アラーム履歴テーブルに対して（アサートまたはクリア）追加された最後のアラーム アクションの表示

ceAlarmHistType.21 = cleared(2) alarm cleared

ceAlarmHistEntPhysicalIndex.21=4 it is for physical entity indexed by 4

ceAlarmHistAlarmType.21 = 3 alarm type is 3

ceAlarmHistSeverity.21 = major(2) the alarm severity is major(2)

この時点で、EMS アプリケーションには、物理エンティティおよび物理エンティティに対して定義されたエンティティ アラーム タイプに関するすべての情報をすでに持っている必要があります。

例 A-6 entPhysicalIndex の値が 4 である物理エンティティの表示

例 A-7 cevPowerSupplyASR1002AC に定義されているアラーム タイプの表示

cevPowerSupplyASR1002AC に定義されているアラーム タイプから、アプリケーションはアラーム履歴テーブルの最後のエントリを次のように容易に解釈できます。ファン 0 の障害アラームが電源ベイ 0 の Cisco ASR1002 AC 電源でクリアされました

アラーム通知

CISCO-ENTITY-ALARM-MIB は、アラーム アサート通知（ceAlarmAsserted）およびアラーム クリア通知（ceAlarmCleared）をサポートします。通知は、snmp SET による ceAlarmNotifiesEnable オブジェクトの設定でイネーブルにできます。ceAlarmNotifiesEnable には、アラーム通知の重大度または値 0 が含まれます。

重大度 4 では、すべての重大度の通知がイネーブルになります。

重大度 3 では、重大度 1、2、および 3 の通知がイネーブルになります。

重大度 2 では、重大度 1 および 2 の通知がイネーブルになります。

重大度 1 では、重大度 1 の通知のみがイネーブルになります。

値 0 では、アラーム通知がディセーブルになります。

アラーム通知は CLI コマンドでイネーブルまたはディセーブルにできます。アラーム通知をディセーブルにするには、「NO」形式を使用します。

アラーム通知には、アラーム履歴エントリで説明したものとまったく同じ情報が含まれます。MIB オブジェクトおよび受信したアラーム通知の解釈については、「アラーム履歴テーブル」の項を参照してください。

例 A-8 受信したサンプル通知の表示

エンティティの包含ツリー

次に、ASR1002 デバイスのサンプル エンティティ階層、Mib Variables printed : <entPhysicalName entPhysicalClass> を示します。

SNMP 通知の生成

ここでは、ルータのイベントや条件に応じて生成される SNMP 通知に関する情報を提供し、通知を受信するホストを指定する方法について説明します。

• 通知を受信するホストの指定

• 設定の変更

• FRU ステータスの変更

通知を受信するホストの指定

CLI または SNMP を使用して、SNMP 通知を受信するホストを指定したり、受信する通知のタイプを指定したりできます。CLI の手順については、「通知のイネーブル化」を参照してください。SNMP を使用してこの情報を設定するには、次の MIB オブジェクトを使用します。

ターゲット ホストを選択し、そのホストのために生成する通知のタイプを指定するには、次のような SNMP-NOTIFICATION-MIB オブジェクトを使用します。

• snmpNotifyTable：ホストと通知タイプを選択するオブジェクトが含まれます。

– snmpNotifyTag は、SNMP 通知を受信するホストを指定するために使用される任意のオクテット文字列（タグ値）です。ターゲット ホストに関する情報は snmpTargetAddrTable（SNMP-TARGET-MIB）で定義され、各ホストに 1 つ以上のタグ値が関連付けられます。snmpTargetAddrTable のホストにこの snmpNotifyTag 値と一致するタグ値がある場合、ホストは snmpNotifyType で指定された通知タイプを受信するように選択されます。

– snmpNotifyType は、送信する SNMP 通知のタイプ（notification(1) または inform(2)）です。

• snmpNotifyFilterProfileTable および snmpNotifyFilterTable：通知フィルタを作成してターゲット ホストに送信される通知のタイプを制限するには、これらのテーブルのオブジェクトを使用します。

通知を受信するホストに関する情報を設定するには、SNMP-TARGET-MIB オブジェクトを使用します。

• snmpTargetAddrTable：SNMP 通知を受信するホストの転送アドレス。各エントリは、タグ値のリストを含むホスト アドレスに関する情報を提供します。

– snmpTargetAddrTagList：ホスト アドレスに関連付けられた一連のタグ値。ホストのタグ値が snmpNotifyTag と一致する場合、ホストは snmpNotifyType で定義された通知タイプを受信するように選択されます。

• snmpTargetParamsTable：SNMP 通知を生成するときに使用する SNMP パラメータ。

特定の SNMP 通知をイネーブルおよびディセーブルにするには、適切な MIB の通知イネーブル オブジェクトを使用します。たとえば、mplsLdpSessionUp または mplsLdpSessionDown 通知を生成するには、MPLS-LDP-MIB オブジェクト mplsLdpSessionUpDownTrapEnable を enabled(1) に設定する必要があります。

設定の変更

エンティティ通知がイネーブルの場合、ルータは、次のテーブル内のいずれかの情報が変更されたときに（ルータ コンフィギュレーションの変更を示す）entConfigChange 通知（ENTITY-MIB）を生成します。

• entPhysicalTable

• entAliasMappingTable

• entPhysicalContainsTable

（注） 設定変更を追跡する管理アプリケーションは、スロットリングまたは送信ロスの結果として失われた entConfigChange 通知を検出するために、entLastChangeTime オブジェクトの値を確認します。

設定変更の通知のイネーブル化

設定変更のたびに entConfigChange 通知を生成するようにルータを設定するには、CLI から次のコマンドを入力します。通知をディセーブルにするには、コマンドの no 形式を使用します。

FRU ステータスの変更

FRU 通知がイネーブルの場合、ルータは FRU ステータスの変更に応じて次の通知を生成します。

• cefcModuleStatusChange：FRU の動作ステータス（cefcModuleOperStatus）が変更されました。

• cefcFRUInserted：FRU がシャーシに挿入されました。通知は、FRU の entPhysicalIndex および FRU が挿入されたコンテナを示します。

• cefcFRURemoved：FRU がシャーシから取り外されました。通知は、FRU の entPhysicalIndex および FRU が取り外されたコンテナを示します。

（注） これらの通知の詳細については、CISCO-ENTITY-FRU-CONTROL-MIB を参照してください。

FRU 通知のイネーブル化

FRU イベントの通知を生成するようにルータを設定するには、CLI から次のコマンドを入力します。通知をディセーブルにするには、コマンドの no 形式を使用します。

SNMP を介して FRU 通知をイネーブルにするには、cefcMIBEnableStatusNotification を true(1) に設定します。通知をディセーブルにするには、cefcMIBEnableStatusNotification を false(2) に設定します。

CISCO-CLASS-BASED-QOS-MIB の概要

CISCO-CLASS-BASED-QOS-MIB は、モジュラ Quality of Service コマンドライン インターフェイス（モジュラ QoS CLI）をサポートするシスコ プラットフォームに、Quality of Service（QoS）の設定情報および統計情報への読み取り専用アクセスを提供します。

CISCO-CLASS-BASED-QOS-MIB のオブジェクト関係

CISCO-CLASS-BASED-QOS-MIB テーブル内の移動方法を理解するには、さまざまな QoS オブジェクト間の関係を理解することが重要です。QoS オブジェクトの構成要素は次のとおりです。

• match ステートメント：分類の目的でパケットを識別する特定の一致基準。

• クラス マップ：さまざまなカテゴリにパケットを分類するために使用する 1 つまたは複数の match ステートメントが含まれているユーザ定義のトラフィック クラス。

• 機能アクション：QoS 機能。機能には、ポリシング、トラフィック シェーピング、キューイング、ランダム検出、およびパケット マーキングが含まれます。トラフィックの分類後、各トラフィック クラスにアクションを適用します。

• ポリシー マップ：ユーザ定義のクラス マップに QoS 機能のアクションを関連付けるユーザ定義のポリシー。

• サービス ポリシー：インターフェイスに関連付けられたポリシー マップ。

MIB は、次のインデックスを使用して QoS 機能を識別し、その機能のインスタンスを区別します。

• cbQosObjectsIndex：ルータの各 QoS 機能を識別します。

• cbQoSConfigIndex：QoS 設定のタイプを識別します。このインデックスは、同一の設定を持つ QoS オブジェクトで共有されます。

• cbQosPolicyIndex：固有のサービス ポリシーを識別します。

QoS MIB 情報ストレージ

CISCO-CLASS-BASED-QOS-MIB 情報は、次の場所に保存されます。

• 設定インスタンス：すべてのクラス マップ、ポリシー マップ、match ステートメント、および機能アクションの設定パラメータが含まれます。同一のインスタンスが複数ある場合があります。同じ QoS 機能の複数のインスタンスは、cbQosConfigIndex で識別される 1 つの設定オブジェクトを共有します。

• 実行時統計情報インスタンス：任意の設定済み QoS ポリシーが適用される前後のトラフィック クラスによるサマリーおよびレートが含まれます。また、詳細な機能固有の統計情報をポリシー マップ機能の選択に使用できます。それぞれに一意の実行時インスタンスがあります。QoS 機能の複数のインスタンスに個別の統計情報オブジェクトがあります。QoS オブジェクトの実行時インスタンスそれぞれに、一致する設定を持つ複数のオブジェクトを区別する一意の識別子（cbQosObjectsIndex）が割り当てられます。

CISCO-CLASS-BASED-QOS-MIB を使用した QoS 設定の表示

ここでは、QoS 設定が CISCO-CLASS-BASED-QOS-MIB テーブルに保存される方法の例を示します。サンプルは、QoS オブジェクトによってグループ化された情報を示します。ただし、SNMP クエリーの実際の出力は、次のような QoS 情報を示すことがあります。

（注） これはすべての QoS 情報の一部の表示です。

CISCO-CLASS-BASED-QOS-MIB を使用した QoS のモニタリング

ここでは、CISCO-CLASS-BASED-QOS-MIB テーブルの QoS 統計情報を確認してルータの QoS をモニタする方法について説明します。

（注） CISCO-CLASS-BASED-QOS-MIB には、CLI の show コマンドの出力に表示される内容よりも多くの情報が含まれている場合があります。

表 A-1 に、QoS 統計情報テーブルのタイプを示します。

QoS 統計情報の処理に関する考慮事項

ルータは、ほとんどの QoS 統計情報の 64 ビット カウンタを保持します。ただし、一部の QoS カウンタは、1 ビット オーバーフロー フラグが設定された 32 ビット カウンタとして実装されます。以降のサンプルでは、これらのカウンタは 33 ビット カウンタとして示されています。

QoS カウンタ統計情報にアクセスするときは、次の点を考慮します。

• SNMPv2c または SNMPv3 アプリケーション： cbQosxxx64 MIB オブジェクトを通じて QoS カウンタの 64 ビット全体にアクセスします。

• SNMPv1 アプリケーション：次のように MIB の QoS 統計情報にアクセスします。

– cb Qosxxx MIB オブジェクトを通じてカウンタの下位 32 ビットにアクセスします。

– cbQosxxxOverflow MIB オブジェクトを通じてカウンタの上位 32 ビットにアクセスします。

サンプル QoS 統計情報テーブル

ここに挙げるサンプルは、CISCO-CLASS-BASED-QOS-MIB 統計情報テーブルのカウンタを示しています。

• 図 A-2 は、cbQosCMStatsTable のカウンタおよびこれらのカウンタや他の統計情報にアクセスするためのインデックスを示しています。

• 図 A-3 は、cbQosMatchStmtStatsTable、cbQosPoliceStatsTable、cbQosQueueingStatsTable、cbQosTSStatsTable、および cbQosREDClassStatsTable のカウンタを示しています。

使いやすいように、次の図は、カウンタが 3 個のオブジェクトとして実装されている場合でも、そのカウンタを 1 つのオブジェクトとして示しています。たとえば、 cbQosCMPrePolicyByte は次のオブジェクトとして実装されています。

• cbQosCMPrePolicyByteOverflow

• cbQosCMPrePolicyByte

• cbQosCMPrePolicyByte64

図 A-2 QoS クラス マップの統計情報およびインデックス

図 A-3 QoS 統計情報テーブル

サンプル QoS アプリケーション

ここでは、CISCO-CLASS-BASED-QOS-MIB から QoS 課金操作で使用する情報を取得する方法を示すコード例を示します。課金アプリケーションを開発する場合には、これらの例を使用できます。内容は、次のとおりです。

• サービス ポリシーのカスタマー インターフェイスの確認

• QoS 課金情報の取得

サービス ポリシーのカスタマー インターフェイスの確認

ここでは、CISCO-CLASS-BASED-QOS-MIB でサービス ポリシーが設定されたカスタマー インターフェイスを確認し、さらにアプリケーションで処理（QoS サービスの課金など）するようにこれらのインターフェイスにマークを付けるサンプル アルゴリズムを示します。

アルゴリズムでは、カスタマー インターフェイスごとに 2 つの SNMP get-next 要求を使用します。たとえば、ルータに 2000 のカスタマー インターフェイスがある場合、これらのインターフェイスに送受信サービス ポリシーが関連付けられているかどうかを確認するには、4000 の SNMP get-next 要求が必要です。

（注） このアルゴリズムは情報提供だけを目的としています。アプリケーションのニーズとは異なる可能性があります。

MIB を確認して、どのインターフェイスがカスタマーに関連付けられているかを調べます。サービス ポリシーがカスタマー インターフェイスの送信および受信方向に関連付けられているかどうかを示すフラグのペアを作成します。非カスタマー インターフェイスに TRUE のマークを付けます（したがって、これらのインターフェイスにこれ以上の処理は不要です）。

cbQosServicePolicyTable を調べてし、それに関連付けられたサービス ポリシーがある各カスタマー インターフェイスにマークを付けます。また、インターフェイスの方向に注意してください。

カスタマー インターフェイスにサービス ポリシーが関連付けられていないケースを管理します。

QoS 課金情報の取得

ここでは、QoS 課金操作に CISCO-CLASS-BASED-QOS-MIB を使用するサンプル アルゴリズムについて説明します。アルゴリズムは、定期的にポストポリシー入出力統計情報を取得し、それらを組み合わせて、結果を課金データベースに送信します。

このアルゴリズムでは、次が使用されます。

• カスタマー インターフェイスごとに 1 つの SNMP get 要求：ifAlias を取得するため。

• カスタマー インターフェイスごとに 2 つの SNMP get-next 要求：サービス ポリシー インデックスを取得するため。

• ポリシーの各オブジェクトのカスタマー インターフェイスごとに 2 つの SNMP get-next 要求：ポストポリシー バイトを取得するため。たとえば、ポリシーに 100 個のインターフェイスと 10 個のオブジェクトがある場合、アルゴリズムは 2000 個の get-next 要求（2 x 100 x 10）を必要とします。

（注） このアルゴリズムは情報提供だけを目的としています。アプリケーションのニーズとは異なる可能性があります。

顧客の課金情報を設定します。

課金情報を取得します。

ポストポリシー バイトの数を課金目的で決定します。

インターフェイスの linkUp/linkDown 通知のイネーブル化

ルータ インターフェイスの状態がアップ（ready）またはダウン（not ready）に変わったときに通知を送信するように SNMP を設定するには、次の手順を実行して、linkUp および linkDown 通知をイネーブルにします。

ステップ 1 次の CLI コマンドを発行して、ほとんど（ただし、すべてとは限らない）インターフェイスの linkUp および linkDown 通知をイネーブルにします。

ステップ 2 linkUp および linkDown 通知がそのインターフェイスに対してイネーブルになっているか、またはディセーブルになっているかを確認するには、各インターフェイスの ifLinkUpDownTrapEnable オブジェクト（ifXTable IF-MIB）の設定を表示します。

ステップ 3 インターフェイスで linkUp および linkDown 通知をイネーブルにするには、ifLinkUpDownTrapEnable を enabled(1) に設定します。インターフェイスの最下位レイヤに対してだけ linkDown 通知を送信するようにルータを設定するには、「linkDown 通知の SNMP 通知フィルタリング」を参照してください。

ステップ 4 linkUp および linkDown 通知についてインターネット技術特別調査委員会（IETF）標準をイネーブルにするには、次のコマンドを発行します。（IETF 標準は RFC 2233 に基づいています）。

ステップ 5 通知をディセーブルにするには、適切なコマンドの no 形式を使用します。

linkDown 通知の SNMP 通知フィルタリング

メイン インターフェイスがダウンした場合にだけ SNMP が linkDown 通知を送信するように linkDown 通知をフィルタリングするには、SNMP 通知フィルタリング機能を使用します。インターフェイスがダウンすると、そのすべてのサブインターフェイスがダウンするため、サブインターフェイスごとに多数の linkDown 通知が発生します。この機能では、これらのサブインターフェイス通知が除外されます。

この機能はデフォルトでオフになっています。SNMP 通知フィルタリング機能をイネーブルにするには、次の CLI コマンドを実行します。機能をディセーブルにするには、コマンドの no 形式を入力します。

入力および出力インターフェイス カウント

ルータは、入力インターフェイス上で受信され、出力インターフェイスで送信されるパケットとバイトの数に関する情報を保持します。

IF-MIB カウンタのサポートに関する詳細な制約事項については、「IF-MIB（RFC 2863）」を参照してください。

IF-MIB カウンタのサポートに関する次の重要な情報を参照してください。

• 特に明記していない限り、すべての IF-MIB カウンタは、Cisco ASR 1000 シリーズ ルータ インターフェイスでサポートされています。

• IF-MIB の大容量カウンタのサポートについては、シスコは RFC 2863 標準に準拠しています。RFC 2863 標準では、次のように動作するインターフェイスについて規定しています。

– 20,000,000 bps 以下で、32 ビット バイトおよびパケット カウンタがサポートされている 必要があります 。

– 20,000,000 bps 以下、650,000,000 bps 未満で、32 ビット パケット カウンタおよび 64 ビット オクテット カウンタがサポートされている 必要があります 。

– 650,000,000 bps 以上で、64 ビット パケット カウンタ および 64 ビット オクテット カウンタがサポートされている 必要があります 。

• QoS サービス ポリシーがインターフェイスに関連付けられている場合、ルータはインターフェイス上のトラフィックにポリシー ルールを適用し、インターフェイスのパケットおよびバイト カウントを増やします。

次の CISCO-CLASS-BASED-QOS-MIB オブジェクトは、インターフェイス カウントを提供します。

• cbQosCMDropPkt および cbQosCMDropByte（cbQosCMStatsTable）：ユーザがサービス ポリシーによって設定された制限を超過したためにドロップされたパケットおよびバイトの総数。これらのカウントには、サービス ポリシーの制限を超過したためにドロップされたパケットおよびバイトのみが含まれます。他の理由でドロップされたパケットとバイトは含まれません。

• cbQosPoliceConformedPkt および cbQosPoliceConformedByte（cbQosPoliceStatsTable）：サービス ポリシーの制限に適合し、送信されたパケットおよびバイトの総数。

お客様に課金するトラフィック量の決定

特定のお客様に課金可能なインターフェイス上のトラフィック量を判断するには、次の手順を実行します。

ステップ 1 お客様に適用するインターフェイス上のサービス ポリシーを決定します。

ステップ 2 お客様のトラフィックを定義するために使用されるサービス ポリシーとクラス マップのインデックス値を決定します。次の手順でこの情報が必要です。

ステップ 3 トラフィック ジェネレータを使用してトラフィックを生成します。データ レートは、そのポリシーの適合バースト（bc）/超過バースト（BE）に設定された値より大きくする必要があります。

ステップ 4 （任意）サービス ポリシー数制限を超過したためにドロップお客様のトラフィックの量を判断するには、お客様の cbQosCMDropPkt オブジェクト（cbQosCMStatsTable）にアクセスします。

QoS トラフィック ポリシングを示すシナリオ

ここでは、SNMP QoS 統計情報を使用して特定のお客様に課金可能なインターフェイス上のトラフィック量を判断するシナリオについて説明します。サービス ポリシーをインターフェイス上のトラフィックに適用するとパケット カウントがどのような影響を受けるかも示します。

シナリオを作成するには、以降の項で説明する次の手順に従ってください。

1. サービス ポリシーを作成し、インターフェイスに関連付けます。

2. サービス ポリシーをインターフェイス上のトラフィックに適用する前にパケット カウントを表示します。

3. ping コマンドを発行して、インターフェイスのトラフィックを生成します。サービス ポリシーがトラフィックに適用されることに注意してください。

4. お客様に課金するトラフィック量を判断するには、サービス ポリシーが適用された後のパケット カウントを表示します。

• 適合したパケット：サービス ポリシーで設定された範囲内のパケット数で、これに対してお客様に課金できます。

• 超過またはドロップされたパケット：サービス ポリシーの範囲外であるために送信されなかったパケットの数。これらのパケットは、お客様に課金できません。

（注） 上記のシナリオでは、Cisco ASR 1000 シリーズ ルータは中間デバイスとして使用されます（つまり、トラフィックは他の場所で発生し、別のデバイスを宛先とします）。

サービス ポリシー コンフィギュレーション

このシナリオは、次のポリシーマップ コンフィギュレーションを使用します。ポリシー マップを作成する方法については、『 Cisco ASR 1000 Series Router Software Configuration Guide 』の「Configuring Quality of Service」を参照してください。

サービス ポリシーの適用前のパケット カウント

次の CLI および SNMP の出力は、サービス ポリシーが適用される前のインターフェイスの出力トラフィックを示しています。

CLI コマンド出力

SNMP 出力

サービス ポリシーの適用後のパケット カウント

トラフィック ジェネレータを使用してトラフィックを生成したら、 police コマンドで設定された認定情報レート（CIR）を超過およびこれに適合したパケットの数を確認します。

• 19351 個のパケットがポリシング レートに適合し、送信されました

• 80 個のパケットがポリシング レートを超過し、ドロップされました

• 16066130 個のパケットがポリシング レートに違反し、ドロップされました

次の CLI および SNMP 出力は、サービス ポリシーが適用された後のインターフェイス上のカウントを示しています。オブジェクト cbQosCMDropPkt は、超過および違反したパケットの合計を示し、cbQosCMDropByte は超過および違反したバイトの合計を示します。（出力では、超過および違反したパケット カウントが太字で示されています）。

CLI コマンド出力

SNMP 出力

サンプル カウンタ

大容量カウンタは、基本的な ifTable カウンタの 64 ビット バージョンです。基本的なセマンティクスは、32 ビット対応と同じです。構文は 64 ビットに拡張されます。

表 A-2 に、容量カウンタのオブジェクト ID（OID）を示します。

関連情報および有益なリンク

次の URL から、シスコ IF-MIB カウンタに関する有用な情報にアクセスできます。

• SNMP カウンタに関する FAQ：

http://www.cisco.com/en/US/customer/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml

• Cisco IOS MIB ツールへのアクセス：

http://tools.cisco.com/ITDIT/MIBS/servlet/index

LAN-PHY モードの設定

1 ポート 10GE LAN/WAN-PHY 共有ポート アダプタ（SPA-1X10GE-WL-V2）で LAN-PHY モードを設定するには、次のコマンドを使用します。

（注） LAN-PHY モードを設定し、SPA をリロードした後、すべてのリンクがアップ状態になります。

（注） Cisco IOS Release 15.1(2)S から、1 ポート 10GE LAN/WAN-PHY 共有ポート アダプタ（SPA-1X10GE-WL-V2）は、LAN モードと WAN モードの両方をサポートします。

SIP ハードウェア タイプの表示

Cisco ASR 1000 シリーズ ルータに搭載された SIP ハードウェア タイプを確認するには、show platform コマンドを使用できます。Cisco ASR 1000 シリーズ ルータには、SIP ハードウェア情報を提供するコマンドがあります。各 SIP/SPA カードの詳細を出力するサブコマンドは他にもあります。次の例は、このようなコマンドの一部のリストです。

例 A-9 show platform コマンドの例

次の例に、Cisco ASR 1000 シリーズ ルータにおける show platform コマンドの出力を示します。

Router#sh platform

Chassis type: ASR1006

Slot Type State Insert time (ago)

--------- ------------------- --------------------- -----------------

0 ASR1000-SIP10 ok 06:19:03

0/0 SPA-1XOC12-POS ok 06:17:25

0/1 SPA-2XCT3/DS0 ok 06:17:25

0/2 SPA-2XT3/E3 ok 06:17:25

0/3 SPA-8X1GE-V2 ok 06:17:34

1 ASR1000-SIP10 ok 06:19:03

1/0 SPA-1X10GE-L-V2 ok 06:17:36

1/1 SPA-5X1GE-V2 ok 06:17:25

1/2 SPA-8X1FE-TX-V2 ok 06:17:36

2 ASR1000-SIP10 ok 06:19:03

2/0 SPA-2X1GE-V2 ok 06:17:36

2/1 SPA-10X1GE-V2 ok 06:17:36

2/2 SPA-2XOC3-POS ok 06:17:36

R0 ASR1000-RP1 ok, active 06:19:03

R1 unknown 06:19:03

F0 ASR1000-ESP10 ok, active 06:19:03

P0 ASR1006-PWR-AC ok 06:18:25

P1 ASR1006-FAN ok 06:18:25

Slot CPLD Version Firmware Version

--------- ------------------- ---------------------------------------

0 06120701 12.2(20070802:195019) [gschnorr-mcp_...

1 06120701 12.2(20070802:195019) [gschnorr-mcp_...

2 06120701 12.2(20070802:195019) [gschnorr-mcp_...

R0 0706210B 12.2(20070807:170946) [gschnorr-mcp_...

R1 N/A N/A

F0 07021400 12.2(20070802:195019) [gschnorr-mcp_...

Router#sh platform ?

hardware Show platform hardware information

software Show platform software information

| Output modifiers

<cr>

Router#sh platform har

Router#sh platform hardware ?

cpp Cisco packet processor

interface Interface information

port port information

slot Slot information

subslot Subslot information

Router#sh platform hardware slot ?

0 SPA-Inter-Processor slot 0

1 SPA-Inter-Processor slot 1

2 SPA-Inter-Processor slot 2

F0 Embedded-Service-Processor slot 0

F1 Embedded-Service-Processor slot 1

R0 Route-Processor slot 0

R1 Route-Processor slot 1

Router#sh platform hardware slot 0 ?

dram MCP85xx DRAM commands

eobc Show EOBC

fan Fan commands

io-port IO Port information

led LED-related commands

mcu MCU related commands

plim PLIM information

sensor Sensor information

serdes Serdes information

spa SPA related information

voltage Voltage commands

Router#