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

目次

MIB の使用方法

物理エンティティの管理

インベントリ管理の実行

物理ポートの ifIndex 値の判別

ルータ資産のタグ付け

FRU ステータスのモニタおよび設定

SNMP トラップの生成

トラップを受信するホストの識別

設定の変更

環境条件

FRU ステータスの変更

アラームを使用した停止のモニタリング

アラームの概要

CLI によるアクティブなアラームの表示

CISCO-ENTITY-ALARM-MIB によるアラーム モニタリング

CISCO-ENTITY-ALARM-MIB のアラーム情報の解釈

CISCO-ENTITY-ALARM-MIB の例

アラーム用トラップおよび Syslog メッセージのイネーブル化

ルータ インターフェイスのモニタリング

インターフェイスのリンクアップ/リンクダウン トラップのイネーブル化

リンクダウン トラップに対する SNMP トラップ フィルタリング機能

PXF 利用率のモニタリング

PXF の利用率と効率の確認

PXF パフォーマンスしきい値および再起動のモニタリング

ラインカードの事前プロビジョニング

ラインカードの交換-- MIB のステート特性

バルク ファイルの検索

バルク ファイル検索の手順

SNMP コマンド

Java アプレット

QoS のモニタリング

QoS の設定

QoS の設定情報および統計情報のアクセス

QoS インデックス

QoS のモニタリング

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

QoS 統計情報テーブル

QoS 統計情報の例

QoS アプリケーションの例

サービス ポリシーに関するカスタマー インターフェイスのチェック

QoS 課金情報の検索

カスタマーに課金するトラフィック

出入力インターフェイスのカウント

カスタマーに課金するトラフィック合計の算出方法

QoS トラフィック ポリシングのシナリオ

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

サービス ポリシー適用前のパケット数

トラフィックの生成

サービス ポリシー適用後のパケット数

CISCO-AAA-SESSION-MIB の使用方法

CISCO-CBP-TARGET-MIB の使用方法

Cisco UDI のサポート

MIB の使用方法

この章では、Cisco 10000 シリーズ上で SNMP を使用して次の作業を実行する方法について説明します。SNMP を使用してルータのルーティング テーブル エントリをポーリングする際の、パフォーマンスの問題を回避する方法については、「MIB の取り扱いに関する考慮事項」を参照してください。

「物理エンティティの管理」

「アラームを使用した停止のモニタリング」

「CLI によるアクティブなアラームの表示」

「CISCO-ENTITY-ALARM-MIB によるアラーム モニタリング」

「アラーム用トラップおよび Syslog メッセージのイネーブル化」

「ルータ インターフェイスのモニタリング」

「インターフェイスのリンクアップ/リンクダウン トラップのイネーブル化」

「リンクダウン トラップに対する SNMP トラップ フィルタリング機能」

「PXF 利用率のモニタリング」

「ラインカードの事前プロビジョニング」

「ラインカードの交換-- MIB のステート特性」

「バルク ファイルの検索」

「QoS のモニタリング」

「カスタマーに課金するトラフィック」

「CISCO-AAA-SESSION-MIB の使用方法」

「CISCO-CBP-TARGET-MIB の使用方法」

「Cisco UDI のサポート」

物理エンティティの管理

ここでは、次の作業で SNMP を使用してルータの物理エンティティ(コンポーネント)を管理する方法について説明します。

「インベントリ管理の実行」

「物理ポートの ifIndex 値の判別」

「ルータ資産のタグ付け」

「FRU ステータスのモニタおよび設定」

「SNMP トラップの生成」

ラインカードをシャーシに搭載する前に、SNMP を使用してラインカードの動作上の特性を設定する方法については、「ラインカードの事前プロビジョニング」を参照してください。

目的および利点

Cisco 10000 SNMP に実装された物理エンティティ管理機能は、次の処理を実行します。

シャーシの物理エンティティを、各エンティティと他のすべてのエンティティとの関係を示す包含ツリーで表します。

Field Replaceable Unit(FRU; 現場交換可能ユニット)のステータスをモニタおよび設定します。

インターフェイス マッピングに物理ポート情報を提供します。

資産タギング用の資産情報を提供します。

シャーシ コンポーネント用のファームウェアおよびソフトウェア情報を提供します。

物理エンティティ管理に使用される MIB

CISCO-ENTITY-ASSET-MIB ― ENTITY-MIB の entPhysicalTable にリストアップされている物理エンティティ用の資産トラッキング情報(ID PROM の内容)が含まれています。この MIB は、発注時に使用する部品番号、シリアル番号、製造番号、およびハードウェア、ソフトウェア、ファームウェア情報など、物理エンティティに関する装置固有の情報を提供します。

CISCO-ENTITY-FRU-CONTROL-MIB ― 電源モジュールやラインカードなど、ENTITY-MIB の entPhysicalTable にリストアップされている FRU の管理ステータスや動作ステータスをモニタおよび管理するために使用されるオブジェクトが含まれています。


) 現在、CISCO-ENTITY-FRU-CONTROL-MIB はラインカードのみをサポートします。


CISCO-ENTITY-VENDORTYPE-OID-MIB ― ルータのすべての物理エンティティに関する Object Identifier(OID; オブジェクト識別子)が含まれています。

CISCO-ENVMON-MIB ― 環境センサー(電圧、温度、ファン、および電源モジュール)のステータス情報が含まれています。たとえば、この MIB はシャーシ内部や吸気口の温度をレポートします。

ENTITY-MIB ― ルータ上の物理エンティティを管理するための情報が含まれています。また、この MIB では、エンティティを階層や相互関係を示す包含ツリーで表します。この MIB には次のテーブルが含まれます。

entPhysicalTable ― ルータ内の各物理コンポーネント(エンティティ)を示します。このテーブルには、トップレベル エンティティ(シャーシ)のエントリ、およびシャーシ内の各エンティティのエントリが格納されます。各エントリは、エンティティに関する名前、タイプ、ベンダー、説明などの情報を提供し、シャーシ エンティティ階層のどの部分にエンティティが位置するかを示します。

各エンティティは、この MIB や他の MIB のエンティティに関する情報にアクセスするために使用される一意のインデックス( entPhysicalIndex )で識別されます。

entAliasMappingTable ― 各物理ポートの entPhysicalIndex 値を、IF-MIB ifTable 内の対応する ifIndex 値にマッピングします。

entPhysicalContainsTable ― シャーシ内の物理エンティティ間の関係を示します。物理エンティティごとに、このテーブルによって、各エンティティの子オブジェクトの
entPhysicalIndex がリストアップされます。

インベントリ管理の実行

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

図A-1図A-5 に、entPhysicalTable 内のエントリがエンティティ関連情報を提供する方法を示します。

entPhysicalTable エントリに関する注意

ENTITY-MIB entPhysicalTable のエントリを調べるときは、次の点を考慮してください。

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

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

entPhysicalParentRelPos ― 同じ entPhysicalContainedIn 値を持つ同タイプのエンティティ(シャーシ スロットやラインカード ポートなど)の相対位置を示します(図A-5 を参照)。

entPhysicalTable エントリの例

ここに記載されている図は、entPhysicalTable 内の情報の格納方法を示します。ルータの設定を判別するには、entPhysicalTable エントリを調べます。

図A-1 に、ルータ シャーシのスロット 1 に搭載されたギガビット イーサネット ラインカード、およびラインカード ポートの ENTITY-MIB entPhysicalTable エントリを示します。

図A-1 シャーシ エンティティの entPhysicalTable エントリ

 

図A-2 に、図A-4 および図A-5 に示されているエンティティの entPhysicalTable エントリの例を示します。

図A-2 entPhysicalTable エントリの例

 

図A-3 entPhysicalTable エントリの例(続き)

 

図A-4 に、構成内のすべてのラインカード、およびラインカード ポートの entPhysicalTable エントリを示します。

図A-4 ラインカードおよびラインカード ポートの entPhysicalTable エントリ

 

図A-5に、entPhysicalParentRelPos が親オブジェクト内にある同タイプのエンティティの位置を示す方法を示します。左側の entPhysicalTable エントリには、関連するフィールドのみが記載されています。

図A-5 シャーシ スロットの entPhysicalParentRelPos 値

 

このコンフィギュレーション例について、次の点に注意してください。

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

シャーシ スロットの場合は、entPhysicalContainedIn = 1(シャーシの entPhysicalIndex)

ラインカード ポートの場合は、entPhysicalContainedIn = 26(ラインカードの entPhysicalIndex)

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

6 ポート チャネライズド T3 ラインカードは、シャーシのスロット 2 に搭載されます。

物理ポートの ifIndex 値の判別

ENTITY-MIB entAliasMappingIdentifier は、ポートの entPhysicalIndex を IF-MIB ifTable 内の対応する ifIndex 値にマッピングして、インターフェイスに物理ポートをマッピングします。たとえば、次の例では、entPhysicalIndex が 35 である物理ポートを ifIndex 値が 4 であるインターフェイスに関連づけています(可能な MIB 値の詳細については、各 MIB を参照してください)。

entAliasMappingIdentifer.35.0 = ifIndex.4

ルータ資産のタグ付け

CISCO-ENTITY-ASSET-MIB ceAssetTag オブジェクトを使用すると、追跡する必要がある任意のラインカードまたは Performance Routing Engine(PRE)に一意の不揮発性識別子(タグ)を割り当てることができます。PRE またはラインカードを別のシャーシに搭載した場合も、このタグは維持されます。

たとえば、次の ceAssetTable エントリは、シリアル番号が CAB0430AXEU であるギガビット イーサネット ラインカードに割り当てられている pre-1-1ge の資産タグを示します。このシャーシからラインカードを取り外して別のシャーシに取り付けた場合も、ceAssetTag は pre-1-1ge のままです。

ceSerialNumber = CAB0430AXEU
ceOrderablePartNumber = ESR-1GE
ceAssetTag = pre-1-1ge
. . .

FRU ステータスのモニタおよび設定

電源モジュールやラインカードなど、FRU の管理ステータスおよび動作ステータスを判別するには、CISCO-ENTITY-FRU-CONTROL-MIB cefcModuleTable 内のオブジェクトを調べます。

cefcModuleAdminStatus ― FRU の管理ステートです。FRU をイネーブルまたはディセーブルにするには、cefcModuleAdminStatus を使用します。

cefcModuleOperStatus ― FRU の現在の動作ステートを示します。


) 現在、CISCO-ENTITY-FRU-CONTROL-MIB はラインカードのみをサポートします。MIB の制約事項については、「CISCO-ENTITY-FRU-CONTROL-MIB」を参照してください。


図A-6に、entPhysicalIndex が 24 であるギガビット イーサネット ラインカードの cefcModuleTable エントリを示します。

図A-6 cefcModuleTable エントリの例

 

ルータがトラップを生成して FRU ステータスの変更を示す方法については、「FRU ステータスの変更」を参照してください。

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 通知タイプです。trap(1) または inform(2) のいずれかの値をとります。

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

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

snmpTargetAddrTable ― SNMP 通知を受信するホストのアドレスをトランスポートします。各エントリは、タグ値の一覧など、ホスト アドレスに関する情報を提供します。

snmpTargetAddrTagList ― ホスト アドレスに関連づけられたタグ値のセットです。ホストのタグ値が snmpNotifyTag に一致する場合は、このホストが snmpNotifyType で定義された通知タイプを受信するホストとして選択されます。

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

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

設定の変更

エンティティ トラップがイネーブルの場合、次に示すいずれかのテーブルの情報が変更されると(つまりルータの設定が変更されると)、ルータは entConfigChange トラップ(ENTITY-MIB)を生成します。

entPhysicalTable

entAliasMappingTable

entPhysicalContainsTable


) 設定変更を追跡する管理アプリケーションは、時々 entLastChangeTime(ENTITY-MIB)の値をチェックして、スロットリングおよび伝送損失によって失われた entConfigChangeを 検出する必要があります。


設定を変更するためのトラップのイネーブル化

設定が変更された場合に entConfigChange トラップを生成するようにルータを設定するには、CLI から次のコマンドを入力します。トラップをディセーブルにするには、このコマンドの no 形式を使用します。

Router(config)# snmp-server enable traps entity
Router(config)# no snmp-server enable traps entity

環境条件

CISCO-ENVMON-MIB では次のトラップを送信して、ルータの環境センサーで検出された状態に関して警告を発します。

ciscoEnvMonShutdownNotification ― ルータがシャットダウンしようとしているときに送信されます。

ciscoEnvMonTemperatureNotification ― 温度が正常な範囲を超えたときに送信されます。

ciscoEnvMonFanNotification ― ファンが故障したときに送信されます。

ciscoEnvMonRedundantSupplyNotification ― 冗長電源入力モジュールが故障したときに送信されます。

環境トラップのイネーブル化

環境条件用のトラップを生成するようにルータを設定するには、CLI から次のコマンドを入力します。トラップをディセーブルにするには、このコマンドの no 形式を使用します。

Router(config)# snmp-server enable traps envmon
Router(config)# no snmp-server enable traps envmon
 

SNMP を使用して環境トラップをイネーブルにするには、該当する通知イネーブル オブジェクトを true(1) にします。たとえば、ciscoEnvMonEnableShutdownNotification は、シャットダウン通知をイネーブルにします。トラップをディセーブルにするには、通知オブジェクトを false(2) に設定します。

FRU ステータスの変更

FRU トラップがイネーブルの場合、ルータは FRU のステータス変更に応答して、次のトラップを生成します。これらのトラップの詳細については、CISCO-ENTITY-FRU-CONTROL-MIB を参照してください。

cefcModuleStatusChange ― FRU の変更を示す動作ステータス(cefcModuleOperStatus)です。

cefcFRUInserted ― FRU はシャーシに搭載されています。このトラップは、FRU および搭載先コンテナの entPhysicalIndex を表します。

cefcFRURemoved ― FRU はシャーシから取り外されています。このトラップは、FRU および取り外し先コンテナの entPhysicalIndex を表します。

FRU トラップのイネーブル化

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

Router(config)# snmp-server enable traps fru-ctrl
Router(config)# no snmp-server enable traps fru-ctrl
 

SNMP を使用して FRU トラップをイネーブルにするには、cefcMIBEnableStatusNotification を true(1) に設定します。トラップをディセーブルにするには、cefcMIBEnableStatusNotification を false(2) に設定します。

アラームを使用した停止のモニタリング

Cisco 10000 シリーズは、アラームを生成して、SONET パス上での信号損失や、チャネライズド T3 ラインカードでの T1 インターフェイスの起動などの状態を示します。アラームはルータ エンティティのステータス情報も提供し、ネットワーク パフォーマンスの低下や障害( 停止 )を引き起こす可能性のある状態をユーザに警告します。

アラーム メッセージはコンソールに送信され、アラームに関する情報はこのセクションの後半で説明する CISCO-ENTITY-ALARM-MIB にも保持されます。entPhysicalTable(ENTITY-MIB)内の各物理エンティティには、エンティティ上で発生する可能性のある状態を定義するアラーム セットが含まれています。

ここでは、アラームの基本的な情報について説明します。次のサブセクションが含まれています。

CLI によるアクティブなアラームの表示

CISCO-ENTITY-ALARM-MIB によるアラーム モニタリング

ルータのインターフェイスに問題がないかどうかを監視する方法については、「ルータ インターフェイスのモニタリング」を参照してください。


) アラームは、イベントでなく状態を意味します。たとえば、"Core critical temperature limit" アラームは、シャーシ内部の温度がクリティカルな状態に達したことを意味します。


目的および利点

アラーム モニタ機能には、次のような利点があります。

アラームがアサートされたまたはクリアされた時点を監視できます。

アラームの履歴情報を取得できます。

アラーム統計情報およびアラーム数を追跡できます。

アラームに応答して SNMP トラップおよび Syslog メッセージを生成できます。

アラーム モニタに使用される MIB およびアラーム サブシステム

ルータは次のものを使用して、アラームを監視します。

CISCO-ENTITY-ALARM-MIB ― ENTITY-MIB entPhysicalTable で定義された物理エンティティに関するアラーム。

CISCO-SYSLOG-MIB ― SNMP を使用して Syslog メッセージを監視するオブジェクトが含まれています。

Cisco IOSアラーム サブシステム ― 物理エンティティに関するアラーム。

オメガ アラーム サブシステム ― 論理エンティティおよび論理インターフェイスに関するアラーム(チャネライズド T3 ラインカードの T1 インターフェイスなど)。

アラームの概要

アラームには次の情報が含まれます。

アラーム タイプ ― アラームを識別する一意のコード

重大度 ― アラームの原因となる状態の重大度(詳細は、「CLI によるアクティブなアラームの表示」を参照)

説明 ― アラームの原因となった状態に関する情報

アラームのステート

アラームのステートは、アラームの原因となる状態の現在のステートを示します。

アサート ― 状態が現在も存在しています。

クリア ― 状態が解消されました。

SNMP は次のトラップを使用して、アラームの現在のステートを示します。

ceAlarmAsserted ― アラームの原因となる状態がまだ存在しています。

ceAlarmCleared ― アラームの原因となる状態が解消されました。

デフォルトでは、アラームがアサートされるかまたはクリアされるたびに、SNMP トラップおよび Syslog メッセージが生成されます。ただし、トラップまたは Syslog メッセージが生成されるアラームの重大度を設定したり、トラップおよびメッセージを完全にディセーブルにすることができます(アラーム用トラップおよび Syslog メッセージのイネーブル化を参照)。

アラームの重大度

アラームの重大度は、次のようにアラームが表す状態タイプを意味します。

critical(1) ― サービスに影響する重大な状態であり、即時に対処する必要があります。

major(2) ― サービス中断を引き起こすハードウェア/ソフトウェア状態、またはルータの動作に不可欠なハードウェアで発生したハードウェア/ソフトウェア状態。重大度は critical アラームよりも低くなりますが、major アラームもすみやかに対処する必要があります。

minor(3) ― サービスに影響しない、または重要でないハードウェア上で発生した状態または問題。

info(4) ― 動作を向上させるイベントに関する有益な情報メッセージ、または問題を引き起こす可能性のある状態を示します。

CLI によるアクティブなアラームの表示

ルータ上でアクティブなすべてのアラームに関する情報を表示するには、CLI から次のコマンドを入力します( severity は表示するアラームのレベルです)。この重大度以上のアクティブなアラームがすべて表示されます。 severity を指定しない場合は、すべてのアクティブなアラームが表示されます。

Router(config)# show facility-alarm status [ severity ]

CISCO-ENTITY-ALARM-MIB によるアラーム モニタリング

SNMP で CISCO-ENTITY-ALARM-MIB を使用すると、ルータ上のアラームを監視できるようになります。


) CISCO-ENTITY-ALARM-MIB は、entPhysicalTable(ENTITY-MIB)で定義された物理エンティティのアラームだけを監視します。論理エンティティ(チャネライズド インターフェイスなど)のアラームは、Cisco IOS ソフトウェアによって Syslog を使用して監視されます。


この MIB には、アラームに関する情報を示す次の複数のテーブルとオブジェクトが含まれています。

ceAlarmDescrMapTable ― 各物理エンティティに一意のインデックス(ceAlarmDescrIndex)を割り当て、エンティティのアラームを識別します(図A-7 を参照)。テーブルには、entPhysicalTable(ENTITY-MIB)内の entPhysicalVendorType で識別されるエントリがエンティティごとに含まれます。

ceAlarmDescrTable ― 各物理エンティティが生成できるアラームの記述が含まれます。

ceAlarmTable ― ルータ上の物理エンティティが現在アサートしているアラームがリストされています。また、そのエンティティのアラーム制御情報が含まれます。

ceAlarmHistTable ― ルータで発生したアラームの履歴が含まれます。

ceAlarmCriticalCount ― ルータ上で現在アサートしているクリティカルなアラームの数を示します。ルータは、メジャー アラームのカウント数(ceAlarmMajorCount)およびマイナー アラームのカウント数(ceAlarmMinorCount)も保持しています。

この MIB には、アラームに対するルータの応答方法を制御する次のようなオブジェクトも含まれています。

ceAlarmCutOff ― SNMP エージェントにより制御される可聴アラームをオフにできます。このオブジェクトは、中央オフィスの Alarm-Cutoff(ACO; アラーム カットオフ)スイッチのような働きをします。アラームのモニタおよびログ、または SNMP 通知および Syslog メッセージの生成には影響を及ぼしません。

ceAlarmNotifiesEnable ― SNMP の ceAlarmAsserted 通知または ceAlarmCleared notification 通知を生成させる原因となるアラームの重大度。

ceAlarmSyslogEnable ― Syslog メッセージを生成させる原因となるアラームの重大度。


) ceAlarmNotifiesEnable および ceAlarmSyslogEnable の使用方法については、「アラーム用トラップおよび Syslog メッセージのイネーブル化」を参照してください。


CISCO-ENTITY-ALARM-MIB のアラーム情報の解釈

CISCO-ENTITY-ALARM-MIB からルータのアラームに関する情報を取得するには、次の手順を実行します。


ステップ 1 ceAlarmTable のオブジェクトの値を読み取り、ルータ上で現在アサートしているアラームの有無を確認します。テーブルの各エントリには、各物理エンティティが現在アサートしているアラーム関する情報が含まれています。それぞれ、エンティティの entPhysicalIndex(ENTITY-MIB)でインデックスされます。

ステップ 2 ceAlarmDescrSeverity および ceAlarmDescrText オブジェクトの値を読み取り、個々のアラームに関する情報を取得します。各アラームが関連付けられているエンティティを判別する方法については、図A-7 を参照してください。

ステップ 3 ceAlarmCriticalCount、ceAlarmMajorCount、および ceAlarmMinorCount の値を読み取り、すべてのエンティティが現在アサートしているアラームの合計数を確認します。


 

CISCO-ENTITY-ALARM-MIB の例

次に、CISCO-ENTITY-ALARM-MIB の内容の一例を示します。

ceAlarmDescrVendorType.1 = cevPortDs3E3Atm
ceAlarmDescrVendorType.2 = cevPortT3
ceAlarmDescrVendorType.3 = cevPortGe
ceAlarmDescrVendorType.4 = cevPortPOS
ceAlarmDescrVendorType.5 = cevChassis10008
ceAlarmDescrVendorType.6 = cevContainerC10KSlot
ceAlarmDescrVendorType.7 = cevContainerC10KFanTraySlot
ceAlarmDescrVendorType.8 = cevPowerSupplyC10KAC
ceAlarmDescrVendorType.9 = cevFanTrayC10008
ceAlarmDescrVendorType.10 = cevCpuCreRp
ceAlarmDescrVendorType.11 = cevPortFEIP
ceAlarmDescrVendorType.12 = cevPortOC3SUNI
ceAlarmDescrVendorType.13 = cevPortOC12SUNI
ceAlarmDescrVendorType.14 = cevPortChOc3Stm1
ceAlarmDescrVendorType.15 = cevPortChOc12
ceAlarmDescrVendorType.16 = cevPortChE1T1
ceAlarmDescrSeverity.1.0 = 2
ceAlarmDescrSeverity.1.1 = 2
ceAlarmDescrSeverity.1.2 = 2
ceAlarmDescrSeverity.1.3 = 2
ceAlarmDescrSeverity.1.4 = 2
ceAlarmDescrSeverity.1.5 = 2
ceAlarmDescrSeverity.1.6 = 4
ceAlarmDescrSeverity.2.0 = 2
ceAlarmDescrSeverity.2.1 = 2
ceAlarmDescrSeverity.2.2 = 2
ceAlarmDescrSeverity.2.3 = 2
ceAlarmDescrSeverity.2.4 = 2
ceAlarmDescrSeverity.2.5 = 2
ceAlarmDescrSeverity.2.6 = 2
ceAlarmDescrSeverity.2.7 = 2
ceAlarmDescrSeverity.2.8 = 2
ceAlarmDescrSeverity.2.9 = 2
ceAlarmDescrSeverity.2.10 = 4
ceAlarmDescrSeverity.3.0 = 1
ceAlarmDescrSeverity.3.1 = 1
. . .
ceAlarmDescrText.1.0 = Loss of Signal Failure
ceAlarmDescrText.1.1 = Out of Frame Failure
ceAlarmDescrText.1.2 = Alarm Indication Signal
ceAlarmDescrText.1.3 = Far End Receiver Data Failure
ceAlarmDescrText.1.4 = Loss of Cell Delineation
ceAlarmDescrText.1.5 = Physical Port Link Down
ceAlarmDescrText.1.6 = Physical Port Administrative State Down
ceAlarmDescrText.2.0 = Far End Remote Alarm Indication Alarm
ceAlarmDescrText.2.1 = Near End Remote Alarm Indication Alarm
ceAlarmDescrText.2.2 = Far End Alarm Indication Signal
ceAlarmDescrText.2.3 = Near End Alarm Indication Signal
ceAlarmDescrText.2.4 = Far End Loss of Frame Failure
ceAlarmDescrText.2.5 = Far End Loss of Signal Failure
ceAlarmDescrText.2.6 = Far End Test Code
ceAlarmDescrText.2.7 = Far End Idle
ceAlarmDescrText.2.8 = Other Failure
ceAlarmDescrText.2.9 = Physical Port Link Down
ceAlarmDescrText.2.10 = Physical Port Administrative State Down
ceAlarmDescrText.3.0 = Physical Port Link Down
ceAlarmDescrText.3.1 = C10K Gigabit Ethernet GBIC missing
. . .
 

図A-7 に、インデックスを使用してルータのアラームを識別する方法を示します。

図A-7 CISCO-ENTITY-ALARM-MIB のインデックス

上記の CISCO-ENTITY-ALARM-MIB の例には、次のアラーム情報が含まれています(MIB の一部のみ)。

 

インデックス
アラーム テキスト
重大度
コンポーネント

1.0

Loss of Signal Failure

2

E3/DS3 ATM ポート

1.5

Physical Port Link Down

2

E3/DS3 ATM ポート

5.0

Core critical temperature limit

1

C10008 シャーシ

5.5

Inlet minor temperature limit

3

C10008 シャーシ

6.0

Active Card Removed OIR Alarm

1

シャーシ スロット

6.2

Card Operational Status Down

1

シャーシ スロット

アラーム用トラップおよび Syslog メッセージのイネーブル化

デフォルトでは、アラームがアサートされるかまたはクリアされると、SNMP はトラップおよび Syslog メッセージを生成します。ただし、次のセクションの手順に従って、トラップおよび Syslog メッセージが生成されるアラーム タイプを制御したり、トラップおよびメッセージを完全にディセーブルにすることができます。

アラーム用トラップのイネーブル化

アラーム用の SNMP トラップをイネーブルまたはディセーブルにするには、次のいずれかを実行します。デフォルトでは、アラームがアサートされるかまたはクリアされると、SNMP はトラップを生成します。

CLI に、次のコマンドを入力します。トラップをディセーブルにするには、このコマンドの no 形式を使用します。

Router(config)# snmp-server enable traps alarms
Router(config)# no snmp-server enable traps alarms
 

SNMP を使用して、次の CISCO-ENTITY-ALARM-MIB オブジェクトを設定します。

ceAlarmNotifiesEnable ― SNMP トラップを生成する原因となるアラームの重大度。critical(1)、major(2)、minor(3)、または info(4) のいずれかの値をとります。トラップをディセーブルにするには、ceAlarmNotifiesEnable を 0 に設定します。

たとえば、メジャーおよびクリティカル アラーム用のトラップを生成するには、
ceAlarmNotifiesEnable を major に設定します。マイナー、メジャー、およびクリティカル アラーム用のトラップを生成するには、ceAlarmNotifiesEnableをminor に設定します。アラームの重大度ついては、「CLI によるアクティブなアラームの表示」を参照してください。


) CISCO-ENTITY-ALARM-MIB は、ENTITY-MIB entPhysicalTable で定義された物理エンティティのアラームだけをモニタします。論理エンティティ(チャネライズド インターフェイスなど)のアラームは、Cisco IOS ソフトウェアによって Syslog を使用してモニタされます。


アラーム用 Syslog メッセージのイネーブル化

デフォルトでは、ルータはアラームがアサートされるかまたはクリアされるたびに、Syslog メッセージを記録します。ただし、次の CISCO-SYSLOG-MIB オブジェクトを使用して、Syslog メッセージを生成するアラーム タイプを設定することができます。

ceAlarmSyslogEnable ― Syslog メッセージを生成するアラームの重大度。critical(1)、major(2)、minor(3)、または info(4) のいずれかの値をとります。アラームの重大度ついては、「CLI によるアクティブなアラームの表示」を参照してください。Syslog メッセージをディセーブルにするには、ceAlarmSyslogEnable を 0 に設定します。

さらに、アラームに応答して Syslog メッセージが記録される場合、次の CISCO-SYSLOG-MIB オブジェクトによって SNMP 通知が送信されます。

clogNotificationsEnabled ― Syslog メッセージが記録される場合に通知を生成するかどうかを指定します。通知をイネーブルにするにはこのオブジェクトを true(1) に、ディセーブルにするには false(2) に設定します。

clogMessageGenerated ― Syslog メッセージが生成される場合に送信される SNMP 通知です。

ルータ インターフェイスのモニタリング

ここでは、ルータ インターフェイスの状態を監視して、インターフェイス上のサービスに影響を及ぼす可能性のある問題や状況が生じているかどうかを確認する方法について説明します。インターフェイスが Down しているのか、または問題が生じているのかを確認するには、次のことを行います。

インターフェイスの動作状態および管理状態の確認

インターフェイスの状態を調べるには、次の IF-MIB オブジェクトを確認します。

ifAdminStatus ― インターフェイスの管理上設定されている(望ましい)ステートインターフェイスをイネーブルにしたり、ディセーブルにするには、ifAdminStatus を使用します。

ifOperStatus ― インターフェイスの現在の動作ステートを示します。

リンクダウンおよびリンクアップ トラップのモニタ

インターフェイスに障害が発生したかどうかを確認するには、リンクダウンおよびリンクアップ トラップを監視します。これらのトラップをイネーブルにする方法については、「インターフェイスのリンクアップ/リンクダウン トラップのイネーブル化」を参照してください。

linkDown ― インターフェイスに障害が発生したか、障害になりつつあることを示します。

linkUp ― インターフェイスが Down ステートでなくなったことを示します。

インターフェイス上のアラームの有無の確認

インターフェイスで次のいずれかのアラームが現在アサートしているかどうかも確認します。これらのアラームはインターフェイスがダウンしており、トラフックの送受信ができないことを意味します。

Physical Port Link Down ― インターフェイスの動作ステートが Down であることを示します。

イーサネット、OC- x 、OC- x ATM、OC- x POS、および STM- x ラインカードの場合、このアラームの重大度は critical(1) です。

シリアル回線(E1/T1、T3、および E3/DS3 ATM)をサポートするラインカードの場合、このアラームの重大度は major(2) または minor(3) です。

Physical Port Administrative State Down ― インターフェイスの管理上設定されている(望ましい)ステートを示します。管理上のステートが Down の場合、動作ステートも Down になります。

ラインカードの場合はすべて、このアラームの重大度は info(4) です。

アラームの監視方法については、「アラームを使用した停止のモニタリング」を参照してください。また、「CISCO-ENTITY-ALARM-MIB によるアラーム モニタリング」および「CISCO-ENTITY-ALARM-MIB のアラーム情報の解釈」も参照してください。


) SNMP は、アラームが生成またはクリアされたときに ceAlarmAsserted または
ceAlarmCleared トラップを生成します。CISCO-ENTITY-ALARM-MIB を読み取ると、アラームをアサートしているインターフェイスがあるかどうかが確認できます。


インターフェイスのリンクアップ/リンクダウン トラップのイネーブル化

ルータのインターフェイスがアップ ステート(準備完了)またはダウン ステート(未準備)に変化したときに通知を送信するように SNMP を設定するには、次の手順を実行してリンクアップおよびリンクダウン トラップをイネーブルにします。


ステップ 1 次の CLI コマンドを発行して、インターフェイスのリンクアップおよびリンクダウン トラップをイネーブルにします。一部を除きほとんどのインターフェイスでイネーブルになります。

Router(config)# snmp-server enable traps snmp linkdown linkup
 

ステップ 2 各インターフェイスで ifLinkUpDownTrapEnable オブジェクト(IF-MIB ifXTable)を確認して、リンクアップおよびリンクダウン トラップがイネーブルまたはディセーブルになっているかを確認します。

ステップ 3 インターフェイス上のリンクアップおよびリンクダウン トラップをイネーブルにするには、
ifLinkUpDownTrapEnable を enable(1) に設定します。インターフェイスの最下位レイヤのみリンクダウン トラップを送信するようにルータを設定する方法については、「リンクダウン トラップに対する SNMP トラップ フィルタリング機能」を参照してください。


) インターフェイスのレイヤによっては、リンクダウン トラップをサポートしていないものがあります(ATM の複数レイヤなど)。


ステップ 4 Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)規格に対応するリンクアップおよびリンクダウン トラップをイネーブルにするには、次のコマンドを発行します。(該当する IETF 規格は RFC 2233です)。

Router(config)# snmp-server trap link ietf
 

ステップ 5 ATM サブインターフェイス上のリンクアップおよびリンクダウン トラップをイネーブルにするには、次のコマンドを発行します。

Router(config)# snmp-server enable traps atm subif
 

ステップ 6 ATM Permanent Virtual Circuit(PVC; 相手先固定接続)上のリンクアップおよびリンクダウン トラップをイネーブルにするには、次のコマンドを発行します。最初のコマンドでは、 interval に、連続するトラップ間の最小間隔を指定し、 fail-interval に、失敗時のタイムスタンプを格納する最小間隔を指定します。

Router(config)# snmp-server enable traps atm pvc interval seconds fail-interval seconds
Router(config)# interface atm slot / subslot / port
Router(config-if)# pvc vpi / vci
Router(config-if-atm-vc)# oam-pvc manage

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


 

リンクダウン トラップに対する SNMP トラップ フィルタリング機能

主要インターフェイスがダウンした場合だけリンクダウン トラップが送信されるようにリンクダウン トラップをフィルタするには、SNMP トラップ フィルタリング機能を使用します。インターフェイスがダウンした場合には、そのすべてのサブインターフェイスがダウンすることから、各サブインターフェイスのリンクダウン トラップが多数発生することになります。このフィルタリング機能を使用することで、サブインターフェイスのトラップをフィルタできます。

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

[no] snmp ifmib trap throttle

PXF 利用率のモニタリング

ここでは、SNMP を使用してルータ上の Parallel Express Forwarding Network Processor(PXF)の利用率をモニタする方法を説明します。

PXF の利用率と効率の確認

PXF パフォーマンスしきい値および再起動のモニタリング

目的および利点

CISCO-ENTITY-PFE-MIB を使用すると、SNMP を通じて Packet Forwarding Engine(PFE)のパフォーマンス情報にアクセスできます。PFE は特定の IP 機能を加速してネットワークのパフォーマンスを向上させるテクノロジーです。この MIB には、PFE の利用率と効率を監視するためのオブジェクトが含まれています。Cisco 10000 シリーズでは、Parallel Express Forwarding Network Processor(PXF)が PFE 機能を担っており、PRE の一部を構成しています。

この MIB には次の利点があります。

次の CLI コマンドで PXF の利用率と効率情報の要約が得られます。

show hardware pxf cpu context
 

1 分、5 分、および 15 分間隔でパフォーマンスの傾向に関する情報が得られます。

PXF の利用率および効率に関する 24 時間分の履歴が保持されます。

ユーザの設定した利用率と効率のしきい値に照らして PXF のパフォーマンスが測定され、しきい値を超えたり PXF が再起動された場合にイベントが生成されます。

PXF 利用率のモニタに使用する MIB

CISCO-ENTITY-PFE-MIB

PXF の利用率と効率の確認

次の PXF のパフォーマンスの測定には、CISCO-ENTITY-PRE-MIB 使用します。

PXF の 利用率 は、処理に現在使用されている PXF の割合を示します。PXF の処理の増加につれて、利用率は 0 ~ 100% に増加します。

PXF の 効率 は、PXF がどれだけ最適に実行しているかを示します。この値が高ければ、それだけ PXF の効率がよいことを意味します。通常の動作状態では、PXF の効率は一般的に 100% を示します。効率が低下すると、この値は減少します。

ルータ上の PXF の利用率および効率を確認するには、次の MIB テーブルの情報を確認します。

cePfePerfCurrentTable ― 利用率と効率の割合(現在値、1 分、および 5 分)。

cePfePerfIntervalTable ― 15 分間隔における過去 24 時間のパフォーマンス統計情報。テーブルには 96 回分の測定間隔データが保持されますが、PXF が 24 時間動作していなかった場合はこれより少なくなります。

各 15 分間隔の開始は、PXF が最後に起動された時刻または再起動された時刻が基準になります。したがって、実時間での 15 分刻みの開始時刻(10 時 45 分、11 時 15 分など)とは一致しません。たとえば、PXF が 10 時 20 分に起動された場合、そのあとの 15 分間隔の開始は、10 時 35 分、10 時 50 分などのようになります。

cePfePerfTotalTable ― 過去 24 時間の利用率および効率。

PXF パフォーマンスしきい値および再起動のモニタリング

PXF の利用率および効率のしきい値を設定し、そのしきい値に対する PXF のパフォーマンスを監視するには、CISCO-ENTITY-PFE-MIB を使用します。SNMP は PXF のパフォーマンス(ceCpfePerfCurrentTable)としきい値(cePfePerfConfigTable)を比較し、PXF の利用率または効率がしきい値に達した場合または超過した場合にイベントを生成します。このイベントをイベント履歴テーブル(cePfeHistTable)に記録したり、SNMP 通知を生成したりできます。また、この両方を実行することも、何の処置もとらないこともできます。PXF イベントは、PXF が再起動された場合にもその都度生成されます。

たとえば、1 分間隔の PXF 利用率測定(cePfePerfCurrent1MinUtilization)がそのしきい値(cePfePerfThld1MinUtilization)に達したか超過した場合、SNMP は thld1MinUtilizationEvent を生成します。イベントの説明については、MIB の HistEventType オブジェクトを参照してください。

PXF のしきい値を設定して監視し PXF の利用率と効率を追跡するには、次の手順を実行します。


ステップ 1 cePfePerfConfigTable を使用して、PXF の利用率と効率の許容可能なしきい値を定義します。

ステップ 2 cePfeHistNotifiesEnable を次のいずれかの値に設定して、しきい値を超えた場合または PXF が再起動した場合に SNMP が実行する動作を指定します。

none(1) ― SNMP は何の処置もとりません。これがデフォルトです。

log(2) ― cePfeHistTable にエントリを作成します。

notify(3) ― SNMP 通知を送信します。

logAndNotify(4) ― cePfeHistTable エントリを作成し、SNMP 通知を送信します。

ステップ 3 イベントを cePfeHistTable に記録する場合は、cePfeHistTableSize を使用してテーブル内に許容するエントリの最大数を指定します。テーブルが一杯になると、新しいイベントでテーブル内の最も古いエントリが上書きされます。

ステップ 4 cePfeHistNotifiesEnable を log(2) または logAndNotify(4) に設定すると、超過しきい値および PXF 再起動に関する情報を cePfeHistTable で確認できます。


 

ラインカードの事前プロビジョニング

ここでは、ラインカードの事前プロビジョニング プロセスの情報、およびそのプロセスが SNMP データに与える影響について説明します。事前プロビジョニング機能を使用すると、特定タイプのラインカードの場合、ラインカードを実際にシャーシに搭載する前にラインカード スロットが事前に設定されます。システムの実行コンフィギュレーション ファイルにラインカードの基本設定が追加されます。これ以降、ラインカードが実際にシャーシに搭載された場合は、ラインカードにこの設定が適用されます。


) SNMP を使用してラインカード スロットを事前プロビジョニングすることはできません。この処理には、CLI card コマンドを使用する必要があります。手順については、CCO の Cisco 10000 Series Router New Features ドキュメンテーション リンクの下にある、Cisco 10000 Series Router Line Card Slot Preprovisioning機能の説明を参照してください。


事前プロビジョニングされたラインカードの取り付け

Cisco 10000 シャーシにラインカードを取り付けると、次の動作が発生します。

挿入されたラインカードが、スロットに事前プロビジョニングされたラインカードのタイプと一致する場合は、事前プロビジョニングされた設定がラインカードに適用されます。

ラインカード スロットが事前プロビジョニングされていない場合は、ラインカードに基本設定が適用され、実行コンフィギュレーション ファイルにこの設定が追加されます。

ラインカード スロットが特定タイプのラインカード用に事前プロビジョニングされている場合に、そのタイプと異なるタイプのラインカードが挿入されると、(実行コンフィギュレーション ファイル内の)事前プロビジョニングされた設定が、実際に搭載されたラインカードの基本設定で置き換えられます。

スロットで使用されるように設定されたカード タイプを判別するには、 show running-config コマンドを使用します。

影響を受ける MIB

事前プロビジョニングされたラインカードを Cisco 10000 シャーシに搭載するか、またはラインカードの動作に影響する CLI コマンドを入力すると、次に示す MIB テーブル内の情報が影響を受けます。

ENTITY-MIB(entPhysicalTable および entAliasMappingTable)

CISCO-ENTITY-ASSET-MIB(ceAssetTable)

CISCO-ENTITY-FRU-CONTROL-MIB(cefcModuleTable)

ラインカードの交換-- MIB のステート特性

Cisco 10000 シャーシ内のラインカードを交換すると、MIB の内容は次のように影響を受けます。ラインカードを次のラインカードに交換:

別のタイプのラインカード(たとえば、ギガビット イーサネットのラインカードをチャネライズド T3 のラインカードに交換) ― 元のラインカードの情報は MIB から削除されます。

同じタイプの別のラインカード ― MIB は元のラインカードの設定を保持します。これにより、設定情報が失われずにラインカードを交換できます。たとえば、50 のサブインターフェイスを持つギガビット イーサネットのラインカードを交換する場合、MIB はラインカードおよびそのサブインターフェイスに関する情報を保持します。MIB 内の元のラインカードの情報を換えるには、次の手順を参考にしてください。

ラインカードを同じタイプの別のラインカードに交換し、元のラインカードの情報を MIB から削除するには、次の手順を実行します。


ステップ 1 次の CLI コマンド( slot_number は 1 ~ 8)を発行して、ラインカードをシャットダウンします。

hw-module slot slot_number shutdown
 

ステップ 2 ラインカードの障害 LED が点灯するまで 30 秒待ちます。

ステップ 3 シャーシからラインカードを取り外します。


) このスロットに別のラインカードを取り付ける予定がしばらくない場合は、no card コマンド(ステップ 4 を参照)を発行することを推奨します。


ステップ 4 ルータのコンフィギュレーションおよび MIB からラインカード情報を削除するには、次の CLI コマンドを発行します。たとえば、 no card 5/0 コマンドは、スロット 5 のラインカードからコンフィギュレーション情報を削除します。

no card slot/subslot
 

ステップ 5 (任意)ラインカードのコンフィギュレーション情報が MIB から削除されたことを確認する場合は、MIB の内容を確認します。

ステップ 6 シャーシのスロットに新しいラインカードを挿入します。

ステップ 7 新しく取り付けたラインカードをアクティブにするには、次の CLI コマンドを発行します。

no hw-module slot slot_number shutdown
 


 

バルク ファイルの検索

ここでは、SNMP を使用してルータから大量のデータを検索する方法について説明します。この機能を使用して、SNMP エージェントとマネージャの間でさまざまな情報(QoS 統計、インターフェイス統計、entPhysicalTable エントリなど)を転送することができます。

目的および利点

従来は、ルータから大量のデータを検索するには、管理アプリケーションから SNMP get-next または get-bulk 要求を何度も入力する必要がありました。

SNMP のバルク ファイル検索機能を使用すると、このプロセスが簡素化され、パフォーマンスの向上につながります。バルク ファイル検索は、次の手順で行います。

1. バルク ファイルの特性を定義する。

2. バルク ファイルに含めるデータを指定する。

3. バルク ファイルを作成し、転送するデータを書き込む。

4. FTP(ファイル転送プロトコル)ユーティリティを使用して、バルク ファイルをルータから他のシステムにコピーする。

バルク ファイル検索は、次のいずれかの方法で行います。

ホストから SNMP set および get 要求を入力する(コマンドの例は SNMP コマンドを参照)。

SNMP set および get 要求を発行する管理アプリケーションを作成する。

MIB 拡張機能には、バルク検索プロセスを使用してルータの ifTable を検索する Java アプレットも含まれています(Java アプレットを参照)。

バルク ファイル検索に使用する MIB

CISCO-BULK-FILE-MIB

CISCO-FTP-CLIENT-MIB

バルク ファイル検索の手順

ここでは、バルク ファイル検索の実行手順を説明します。このプロセスの例は、「SNMP コマンド」および「Java アプレット」を参照してください。MIB オブジェクト、その特性、および有効な値についての詳細は、MIB を参照してください。


ステップ 1 CISCO-BULK-FILE-MIB の cbfDefineFileTable に行を作成し、バルク ファイルの特性を定義します。

a. この行に割り当てる一意のインデックスを決定します。

b. cbfDefineFileTable オブジェクトを設定します。

cbfDefineFileEntryStatus = createAndGo(4) または createAndWait(5)
cbfDefineFileName = bulk_file_name
cbfDefineFileStorage = ephemeral(1)
cbfDefineFileFormat = bulkASCII(3)

ステップ 2 cbfDefineObjectTable に行を作成し、バルク ファイルに含めるデータを定義します。

a. この行に割り当てる一意のインデックスを決定します。

b. cbfDefineObjectTable オブジェクトを設定します。

cbfDefineFileObjectStatus = createAndGo(4) または createAndWait(5)
cbfDefineObjectID = オブジェクト インスタンスまたはテーブル カラムの OID
cbfDefineObjectClass = object(1) または lexicaltable(2)

c. (任意)バルク ファイルに特定のテーブル行を含めるには、次の MIB オブジェクトを設定します。このオプションを使用するには、cbfDefineObjectClass = lexicaltable(2) を設定する必要があります。

cbfDefineObjectTableInstance = 先頭のテーブル行
cbfDefineObjectNumEntries = 含めるべきテーブル行の数

たとえば、ifTable の行 2 ~ 12 を含めるには、cbfDefineObjectTableInstance = ifTable.2 および cbfDefineObjectNumEntries = 10 と設定します。

ステップ 3 バルク ファイルを作成し、そのファイルにデータを書き込み、ファイルのステータスを確認します。

a. cbfDefineFileNow = create(3) を設定します。

b. バルク ファイルの cbfDefineFileIndex を使用して、cbfStatusFileState について get-next を実行します。

c. cbfStatusFileState = ready(2) になるまで、待ちます。

ステップ 4 CISCO-FTP-CLIENT-MIB の cfcRequestTable に行を作成して、バルク ファイルを FTP サーバにコピーするように FTP を設定します。

a. この行に使用する一意のインデックスを決定します。

b. cfcRequestTable オブジェクトを設定します。

cbfRequestEntryStatus = createAndWait(5) or createAndGo(4)
cfcRequestOperation = putASCII(2)
cfcRequestLocalFile = ルータ上のバルク ファイル名
cfcRequestRemoteFile = コピー先の FTP サーバ上でバルク ファイルをコピーするファイルの名前(およびパス)
cfcRequestServer = FTP サーバの IP アドレスまたは完全修飾名
cfcRequestUser = FTP サーバに対する有効なユーザ名
cfcRequestPassword = FTP ユーザ名に対応するパスワード

c. cfcRequestEntryStatusをactive(1) に設定して行をアクティブにします。バルク ファイルの転送が開始されます。

d. cfcRequestResult をチェックして、FTP 動作の結果を確認します。


 

SNMP コマンド

図A-8に、バルク ファイル検索に使用する SNMP コマンドの例を示します。これらのコマンドは一例に過ぎません。実際に使用するコマンドは、例とは異なる場合があります。有効な値については、MIB を参照してください。この例で使用する数値は、「バルク ファイル検索の手順」に示す手順に対応しています。各ステップについても図A-8で説明します。


) この例では、SNMP EMANATE ツール(SNMP Research International 製)を利用しています。以下に示すコマンドで、rtr_IP_addr は、ルータの IP アドレスです。


図A-8 バルク ファイル検索に使用する SNMP コマンドの例

 

 

ステップ 1

バルク ファイル QoSstats に対応する行を作成し、この行を Active ステートにします。

この行にインデックス 1 を割り当てます。このインデックスを使用して、行に対応するテーブル オブジェクトにアクセスします(たとえば、cbfDefineFileEntryStatus .1 、cbfDefineFileName .1 、cbfDefineFileStorage .1 など)。

バルク ファイルが読み込まれるまで、ファイルに保管されているのはデータだけです。バルク ファイルのフォーマットは、人間が読める ASCII 形式です。

ステップ 2

インデックス .1.3 で行を作成します(cbfDefine File Index および cbfDefine Object Index)。

この MIB 設定によって、ipAddrTable のデータをバルク ファイルに含めることを指定します。

ステップ 3

バルク ファイルを作成し、cbfDefineFileIndex を使用してバルク ファイルが作成されたことを確認します。

ステップ 4

このコマンドによって、バルク ファイル(QoSstats)を stats.cisco.com サーバのファイル C10kQoS にコピーする FTP put 要求を設定します。デフォルトでは、指定したユーザのホーム ディレクトリにファイルがコピーされますが、別のディレクトリを指定することもできます。たとえば、cfcRequestRemoteFile = /C10Kstats/QoSstats と指定すると、ディレクトリ /C10Kstats にバルク ファイルがコピーされます。

SNMP コマンドを使用する際、次の点に注意してください。

テーブルの行ごとに、その行のテーブル オブジェクトにアクセスするために使用する一意のインデックスを決定する必要があります。このインデックスは、テーブル内のすべての行で一意でなければなりません。行を作成する時点で、インデックスを定義する必要があります。

テーブルの行を作成するには、

テーブルの xxxEntryStatus オブジェクトに行のインデックスを追加します。

xxxEntryStatus = createAndGo(4) または createAndWait(5) に設定します。

システムは指定された行を作成し、指定されたインデックスをその行に割り当てます。たとえば、次のコマンドを使用すると、cbfDefineFileTable に行が作成され、その行は Inactive ステートに設定されます。この行には 1 というインデックスが割り当てられます。

setany -v2c rtr_IP_addr private cbfDefineFileEntryStatus.1 -i 5
 

このインデックス値を使用して、その行にある別の MIB オブジェクト(cbfDefineFileName.1、cbfDefineFileStorage.1 など)をアクセスします。

Java アプレット

Javaアプレットを使用して ifTable のバルク ファイル検索を実行するには、次の作業を行います。

1. ルータが、(アプレットの実行に必要な)Java 2 プラットフォームをサポートするワークステーションに接続されていることを確認します。

2. Cisco FTP サイトの次の URL にアクセスします。

ftp://ftp-eng.cisco.com/auto/ftp/omega/cheops

3. FTP サイトから次のファイルをワークステーションにコピーします。

10kApplets.jar

4. ワークステーションで、次のコマンドを入力してアプレットを起動します(applet.BulkFileRetrieval は、JAR ファイル内のバルク ファイル検索クラスまたはプログラムを実行するようシステムに指示します)。

java -cp <JAR_file_location> applet.BulkFileRetrieval
 

5. 表示されるウィンドウに、次の情報を入力します。

ルータ上のイーサネット ポートの IP アドレス

SNMP バージョンおよびコミュニティ

バルク ファイルの転送先 FTP サーバの IP アドレス

サーバに対して有効なユーザ名およびパスワード

指定したユーザのホーム ディレクトリ(バルク ファイルはこの場所にコピーされます)。

6. Retrieve BULK-FILE をクリックして、バルク ファイル検索を開始します。

システムは ifTable をバルク ファイル ifTable-bulkFile< MonthDay-HourMinSec >(たとえば、ifTable-bulkFileJan3-17hr9min16sec)にコピーし、このバルク ファイルを、転送先 FTP サーバ上で指定されたユーザのホーム ディレクトリにコピーします。

7. BULK-FILE Data タブをクリックして、バルク ファイルを表示します。

図A-9に、Java アプレットを使用するバルク ファイル検索の例を示します。一連の番号は、「バルク ファイル検索の手順」の各ステップに対応しています。アプレットの各ステップについての説明は、図A-11を参照してください。

図A-9 Java アプレットによるバルク ファイル検索

 

図A-10 Java アプレットによるバルク ファイル検索(続き)

 

図A-11 Java アプレットによるバルク ファイル検索(続き)

 

 

ステップ 1a

インデックスとして使用する乱数を生成します。

ステップ 1b

次のように MIB オブジェクトを設定します。

cbfDefineFileStorage = ephemeral(1)
cbfDefineFileFormat = bulkASCII(3)

ステップ 2a

インデックスとして使用する乱数を生成します。

ステップ 3b

cbfDefineFileIndex を使用して cbfStatusFileState にアクセスします。

ステップ 4c

ステートが running(1) から ready(2) に変わるまで、cbfStatusFileState をポーリングします。

ステップ 5d

バルク ファイル転送ペンディングが終わるまで、cfcRequestResult をポーリングします。

QoS のモニタリング

ここでは、ルータ上で SNMP を使用して QoS(Quality of Service)の設定情報と統計情報にアクセスする例を示します。具体的な内容は次のとおりです。

「QoS の設定」

「QoS の設定情報および統計情報のアクセス」

「QoS のモニタリング」

「QoS アプリケーションの例」

目的および利点

従来は、QoS の設定情報および統計情報にアクセスするには、CLI から show コマンドを入力する方法しかありませんでした。

管理機能の拡張によって、SNMP を使用してルータ上の QoS 設定情報および統計情報にアクセスできるようになりました。つまり、QoS 情報を収集および保管して、管理アプリケーションで使用することができます。また、バルク ファイル転送を使用して別のシステムに情報をコピーすることもできます。

QoS に使用する MIB

CISCO-CLASS-BASED-QOS-MIB

QoS の設定

QoS を設定するには、CLI(コマンドライン インターフェイス)を使用します。詳しい設定手順については、『 Cisco 10000 Series Router Software Configuration Guide 』の「Configuring Quality of Service」を参照してください。

QoS の設定情報および統計情報のアクセス

CISCO-CLASS-BASED-QOS-MIB は、QoS の設定情報および統計情報へのアクセスを提供します。SNMP を使用してルータに QoS を設定することはできませんが、CLI を使用して設定した QoS 設定情報に SNMP でアクセスすることができます。

QoS インデックス

QoS の設定情報および統計情報のアクセスに使用するインデックスは、次のとおりです。

cbQosPolicyIndex ― インターフェイスに付加されたポリシー マップを識別する、システムによって割り当てられたインデックス(ポリシー マップは、インターフェイスに付加する時点では、 サービス ポリシー といいます)。

cbQosObjectsIndex ― QoS 機能の固有の実行時インスタンス(たとえば、ポリシー マップ、クラス マップ、match ステートメント、フィーチャ アクションなど)を識別する、システムによって割り当てられたインデックス。

cbQosConfigIndex ― QoS 機能の固有の設定(たとえば、クラス マップ、ポリシング アクションなど)を識別する、システムによって割り当てられたインデックス。同じ設定を持つ QoS オブジェクトは、同じ cbQosConfigIndex を共有します。

cbQosREDValue ― Weighted Random Early Detection(WRED; 重み付けランダム早期検出)アクションの IP precedence または IP Differentiated Services Code Point(DSCP; DiffServ コード ポイント)。各 RED クラスの設定情報および統計情報に対応するインデックスとして使用します。

図A-12に、これらのインデックスによって QoS 設定情報および統計情報にアクセスする仕組みを示します。

図A-12 Cisco 10000 シリーズ ルータ QoS インデックス

 

特定の QoS 機能について QoS 設定情報および統計情報にアクセスする手順は、次のとおりです。

1. cbQosServicePolicyTable を検索し、その機能が使用されているポリシーに割り当てられた cbQosPolicyIndex を調べます。

2. cbQosPolicyIndex を使用して cbQosObjectsTable にアクセスし、QoS 機能に割り当てられた cbQosObjectsIndex および cbQosConfigIndex を調べます。

cbQosConfigIndex を使用して、コンフィギュレーション テーブル(cbQos xxx CfgTable)で機能に関する情報にアクセスします。

cbQosPolicyIndex および cbQosObjectsIndex を使用して、QoS 統計テーブル(cbQos xxx StatsTable)で QoS 機能の情報にアクセスします。

QoS コンフィギュレーションの例

ここでは、CISCO-CLASS-BASED-QOS-MIB テーブルに保管された QoS コンフィギュレーションの例を一連の図で示します。

図A-13は、他の図の基盤となっている QoS コンフィギュレーション例を示しています。

図A-14は、サービス ポリシーおよびオブジェクト テーブルを示しています。

図A-15は、ポリシー マップ、クラス マップ、およびポリシング アクションの設定情報を示しています。

図A-16は、ATM インターフェイスに関する RED クラスのコンフィギュレーションを示しています。

この項で示す一連の図では、QoS オブジェクト別に情報が示されています。ただし、SNMP クエリーによって出力される実際の QoS 情報は、次のような形式になります。この出力は、図A-13に示すコンフィギュレーションに対応する QoS 情報の一部に過ぎません。

c10k# getmany -v3 10.86.0.94 test-user ciscoCBQosMIB
 
cbQosIfType.1047 = subInterface(2)
cbQosIfType.1052 = subInterface(2)
cbQosPolicyDirection.1047 = input(1)
cbQosPolicyDirection.1052 = output(2)
cbQosIfIndex.1047 = 36
cbQosIfIndex.1052 = 36
cbQosFrDLCI.1047 = 0
cbQosFrDLCI.1052 = 0
cbQosAtmVPI.1047 = 0
cbQosAtmVPI.1052 = 0
cbQosAtmVCI.1047 = 0
cbQosAtmVCI.1052 = 0
cbQosConfigIndex.1047.1047 = 1045
cbQosConfigIndex.1047.1048 = 1025
cbQosConfigIndex.1047.1050 = 1027
cbQosConfigIndex.1047.1051 = 1046
cbQosConfigIndex.1052.1052 = 1045
cbQosConfigIndex.1052.1053 = 1025
cbQosConfigIndex.1052.1055 = 1027
cbQosConfigIndex.1052.1056 = 1046
cbQosObjectsType.1047.1047 = policymap(1)
cbQosObjectsType.1047.1048 = classmap(2)
cbQosObjectsType.1047.1050 = matchStatement(3)
cbQosObjectsType.1047.1051 = police(7)
cbQosObjectsType.1052.1052 = policymap(1)
cbQosObjectsType.1052.1053 = classmap(2)
cbQosObjectsType.1052.1055 = matchStatement(3)
cbQosObjectsType.1052.1056 = police(7)
cbQosParentObjectsIndex.1047.1047 = 0
cbQosParentObjectsIndex.1047.1048 = 1047
cbQosParentObjectsIndex.1047.1050 = 1048
cbQosParentObjectsIndex.1047.1051 = 1048
cbQosParentObjectsIndex.1052.1052 = 0
cbQosParentObjectsIndex.1052.1053 = 1052
cbQosParentObjectsIndex.1052.1055 = 1053
cbQosParentObjectsIndex.1052.1056 = 1053
cbQosPolicyMapName.1045 = pm-1Meg
cbQosPolicyMapDesc.1045 =
cbQosCMName.1025 = class-default
cbQosCMDesc.1025 =
cbQosCMInfo.1025 = matchAny(3)
. . .

図A-13 GigabitEthernet QoS のコンフィギュレーション-- CLI show コマンド

 

図A-14 GigabitEthernet QoS --サービス ポリシーおよびオブジェクト テーブル

 

図A-15 GigabitEthernet QoS --ポリシー マップ、クラス マップ、およびポリシング アクションのコンフィギュレーション オブジェクト

 

この QoS コンフィギュレーション例について、次の点に注意してください。

ポリシー マップ pm-1Meg は、入力インターフェイスと出力インターフェイスに付加されているので、

2 つの cbQosObjectsIndex 値が使用されます(入力インターフェイスおよび出力インターフェイスにそれぞれ 1 つずつ)。

入力オブジェクトおよび出力オブジェクトの両方に、1 つの cbQosConfigIndex を使用します。

インターフェイスに付加されていないポリシー マップは、SNMP データに含まれず、
show policy-map interface コマンドで表示されません。したがって、pm-1Meg は表示されますが、pm1 は表示されません。

SNMP データには、常にデフォルトのクラス マップが含まれています。

アクションが定義されていないクラス マップは、SNMP データには含まれません。したがって、cm1 は cbQosCMCfgTable に含まれていません。

図A-16に、MIB テーブルに保管された RED 設定情報の例を示します。このコンフィギュレーションは、ギガビット イーサネットではなく、ATM インターフェイスに適用されます。

図A-16 ATM QoS -- RED コンフィギュレーション オブジェクト

 

QoS のモニタリング

ここでは、 表A-1 に示す MIB テーブルの QoS 統計情報をチェックすることによって、ルータ上で QoS を監視する方法を説明します。カスタマーに課金するトラフィック量を特定する方法については、「カスタマーに課金するトラフィック」を参照してください。


) CISCO-CLASS-BASED-QOS-MIB には、CLI の show コマンド出力よりも詳しい情報が含まれる場合があります。


 

表A-1 QoS 統計情報テーブル

QoS テーブル
統計情報

cbQosCMStatsTable

クラス マップ ― QoS ポリシーの実行前および実行後のパケット数、バイト数、およびビット レート。廃棄されたパケット数およびバイト数。

cbQosMatchStmtStatsTable

match ステートメント ― QoS ポリシーを実行する前のパケット数、バイト数、およびビット レート。

cbQosPoliceStatsTable

ポリシング アクション ― ポリシング アクションに適合、超過、および違反したパケット数、バイト数、およびビット レート。

cbQosQueueingStatsTable

キューイング ― 廃棄されたパケット数、バイト数、およびキュー デプス。

cbQosTSStatsTable

トラフィック シェーピング ― 遅延および廃棄されたパケット数およびバイト数、機能のステート、およびキュー サイズ。

cbQosREDClassStatsTable

ランダム早期検出 ― キューが満杯のとき廃棄されたパケット数およびバイト数、および送信されたバイト数およびオクテット数。

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

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

カウンタの QoS 統計情報にアクセスする際、次の点に注意してください。

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

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

cbQosxxx MIB オブジェクトを使用して、カウンタの下位 32 ビットにアクセスします。

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

QoS 統計情報テーブル

ここでは、CISCO-CLASS-BASED-QOS-MIB 統計情報テーブルのカウンタを一連の図で示します。

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

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

テーブルに保管された QoS 統計情報の例は、「QoS 統計情報の例」を参照してください。

以下の図では見やすさを配慮して、一部のカウンタについては、実際には 3 つのオブジェクトとして実装されていても 1 つのオブジェクトで表しています。たとえば、 cbQosCMPrePolicyByte は次のように実装されています。

cbQosCMPrePolicyByteOverflow
cbQosCMPrePolicyByte
cbQosCMPrePolicyByte64

) 実装上の機能として、一部の QoS 統計情報カウンタは、対応できる最大値に達する前にラップアラウンドする場合があります。


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

 

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

 

QoS 統計情報の例

ここでは、show コマンドで表示される QoS 統計情報と、CISCO-CLASS-BASED-QOS-MIB テーブルに保管された QoS 統計情報の例を、一連の図で示します。

図A-19 は、 show policy-map interface コマンドによる QoS 統計情報の出力例を示しています。

図A-20は、入力サービス ポリシーに対応するクラス マップ統計情報を示しています。

図A-21は、出力サービス ポリシーに対応するクラス マップ統計情報を示しています。

図A-22は、入力および出力サービス ポリシーに対応する match ステートメント統計情報を示しています。

図A-19 QoS 統計情報の出力例-- CLI の show コマンド

 

図A-20 QoS クラス マップ統計情報--入力サービス ポリシー

 

図A-21 QoS クラス マップ統計情報--出力サービス ポリシー

 

図A-22 QoS match ステートメント統計情報

 

QoS アプリケーションの例

ここでは、CISCO-CLASS-BASED-QOS-MIB から情報を取り出して QoS 課金処理に使用するためのサンプル コードを示します。課金アプリケーションを開発する際、これらの例を参考にしてください。このサンプル コードでは、次の処理を行います。

サービス ポリシーに関するカスタマー インターフェイスのチェック

QoS 課金情報の検索

サービス ポリシーに関するカスタマー インターフェイスのチェック

ここでは、サービス ポリシーのあるカスタマー インターフェイスについて
CISCO-CLASS-BASED-QOS-MIB をチェックし、(QoS サービスの課金業務などの)アプリケーション処理を行えるよう、これらのインターフェイスをマークするアルゴリズムの例を示します。

このアルゴリズムでは、カスタマー インターフェイスごとに 2 つの SNMP get-next 要求を使用します。たとえば、ルータ上に 2000 個のカスタマー インターフェイスがある場合、各インターフェイスに対応づけられた送信および受信サービス ポリシーがあるかどうかを判別するには、4000 個の SNMP get-next 要求が必要になります。


) このアルゴリズムは一例に過ぎません。実際に使用するアプリケーションでは、この例とは異なる処理が必要になる場合があります。


特定のカスタマーに対応するインターフェイスを調べるため、MIB をチェックします。カスタマー インターフェイスの送信方向および受信方向にサービス ポリシーが対応づけられているかどうかを示す、1 対のフラグを作成します。非カスタマー インターフェイスは TRUE でマークします(これらのインターフェイスについては、以降の処理は不要です)。

FOR each ifEntry DO
IF (ifEntry represents a customer interface) THEN
servicePolicyAssociated[ifIndex].transmit = FALSE;
servicePolicyAssociated[ifIndex].receive = FALSE;
ELSE
servicePolicyAssociated[ifIndex].transmit = TRUE;
servicePolicyAssociated[ifIndex].receive = TRUE;
END-IF
END-FOR
 

cbQosServicePolicyTable を調べ、サービス ポリシーが付加されているカスタマー インターフェイスをマークします。インターフェイスの方向もチェックします。

x = 0;
done = FALSE;
WHILE (!done)
status = snmp-getnext (
ifIndex = cbQosIfIndex.x,
direction = cbQosPolicyDirection.x
);
IF (status != ‘noError’) THEN
done = TRUE
ELSE
x = extract cbQosPolicyIndex from response;
IF (direction == ‘output’) THEN
servicePolicyAssociated[ifIndex].transmit = TRUE;
ELSE
servicePolicyAssociated[ifIndex].receive = TRUE;
END-IF
END-IF
END-WHILE
 

サービス ポリシーが付加されていないカスタマー インターフェイスの取り扱いを指定します。

FOR each ifEntry DO
IF (!servicePolicyAssociated[ifIndex].transmit) THEN
Perform processing for customer interface without a transmit service policy.
END-IF
IF (!servicePolicyAssociated[ifIndex].receive) THEN
Perform processing for customer interface without a receive service policy.
END-IF
END-FOR

QoS 課金情報の検索

ここでは、CISCO-CLASS-BASED-QOS-MIB を使用して QoS 課金処理を行うアルゴリズムの例を示します。このアルゴリズムは、ポリシング後の入力および出力統計情報を定期的に取り出し、それらを組み合わせた結果を課金データベースに送信します。

このアルゴリズムでは、次の要求を使用しています。

カスタマー インターフェイスごとに 1 つの SNMP get 要求 ― ifAlias を検索

カスタマー インターフェイスごとに 2 つの SNMP get-next 要求 ― サービス ポリシー インデックスを検索

ポリシーに含まれる各オブジェクトについて、カスタマー インターフェイスごとに 2 つの
SNMP get-next 要求 ― ポリシング後のバイト数を検索。たとえば、ポリシーに 100 個のインターフェイスと 10 個のオブジェクトがある場合、このアルゴリズムでは 2000 個(2 × 100 × 10)の get-next 要求が必要になります。


) このアルゴリズムは一例に過ぎません。実際に使用するアプリケーションでは、この例とは異なる処理が必要になる場合があります。


カスタマー課金情報を設定します。

FOR each ifEntry DO
IF (ifEntry represents a customer interface) THEN
status = snmp-getnext (id = ifAlias.ifIndex);
IF (status != ‘noError’) THEN
Perform error processing.
ELSE
billing[ifIndex].isCustomerInterface = TRUE;
billing[ifIndex].customerID = id;
billing[ifIndex].transmit = 0;
billing[ifIndex].receive = 0;
END-IF
ELSE
billing[ifIndex].isCustomerInterface = FALSE;
END-IF
END-FOR
 

課金情報を検索します。

x = 0;
done = FALSE;
WHILE (!done)
response = snmp-getnext (
ifIndex = cbQosIfIndex.x,
direction = cbQosPolicyDirection.x
);
IF (response.status != ‘noError’) THEN
done = TRUE
ELSE
x = extract cbQosPolicyIndex from response;
IF (direction == ‘output’) THEN
billing[ifIndex].transmit = GetPostPolicyBytes (x);
ELSE
billing[ifIndex].receive = GetPostPolicyBytes (x);
END-IF
END-IF
END-WHILE
 

課金のためポリシング後のバイト数を調べます。

GetPostPolicyBytes (policy)
x = policy;
y = 0;
total = 0;
WHILE (x == policy)
response = snmp-getnext (type = cbQosObjectsType.x.y);
IF (response.status == ‘noError’)
x = extract cbQosPolicyIndex from response;
y = extract cbQosObjectsIndex from response;
IF (x == policy AND type == ‘classmap’)
status = snmp-get (bytes = cbQosCMPostPolicyByte64.x.y);
IF (status == ‘noError’)
total += bytes;
END-IF
END-IF
END-IF
END-WHILE
RETURN total;
 

カスタマーに課金するトラフィック

ここでは、SNMP QoS 情報を使用してカスタマーに課金するトラフィック合計を算出する方法について説明します。また、インターフェイスに付加された QoS サービス ポリシーがそのインターフェイスの ポリシング トラフィックであることを示すシナリオについても説明します。

ここでは、次の内容について説明します。

「カスタマーに課金するトラフィック合計の算出方法」

「QoS トラフィック ポリシングのシナリオ」

出入力インターフェイスのカウント

ルータは、出入力 インターフェイスで送受信された、それぞれのパケット数とバイト数に関する情報を保持しています。QoS サービス ポリシーがインターフェイスに付加されると、ルータはそのインターフェイス上のトラフィックにポリシーの規則を適用し、インターフェイス上のパケットとバイトのカウントを増やします。

CISCO-CLASS-BASED-QOS-MIB の次のオブジェクトに、インターフェイスでのカウント数がわかります。

cbQosCMDropPkt および cbQosCMDropByte (cbQosCMStatsTable) ― サービス ポリシーで設定された制限を超えたことにより廃棄されたパケットとバイトの合計数。この数には、サービス ポリシーの制限を超えたことにより廃棄されたパケットとバイトだけが含まれます。他の理由で廃棄されたパケットとバイトは含まれません。

cbQosPoliceConformedPkt および cbQosPoliceConformedByte (cbQosPoliceStatsTable) ― サービス ポリシーの制限内であったために伝送されたパケットとバイトの合計数。

カスタマーに課金するトラフィック合計の算出方法

カスタマーに課金可能なインターフェイス上のトラフィック合計を算出するには、次の手順を実行します。


ステップ 1 カスタマーに適用されているインターフェイス上のサービス ポリシーを確認します。

ステップ 2 カスタマーのトラフィックを定義するサービス ポリシーのインデックス値とクラス マップを確認します。この情報は次の手順で必要になります。

ステップ 3 カスタマーに対応する cbQosPoliceConformedPkt オブジェクト(cbQosPoliceStatsTable)をアクセスして、このカスタマーに課金可能なトラフィック合計を確認します。

ステップ 4 (任意)カスタマーに対応する cbQosCMDropPkt オブジェクト(cbQosCMStatsTable)をアクセスして、サービス ポリシー制限を超えたため廃棄されたカスタマーのトラフィック量を確認します。


 

QoS トラフィック ポリシングのシナリオ

ここでは、カスタマーに課金可能なインターフェイス上のトラフィック合計を算出するために、SNMP QoS 統計情報を使用するシナリオを示します。また、サービス ポリシーをインターフェイス上のトラフィックに適用した場合に、パケット数がどのように変わるかについても示します。

次の手順を実行して、シナリオを作成します。各手順の説明は後続のセクションにあります。

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

2. サービス ポリシーがインターフェイス上のトラフィックに適用される前のパケット数を確認します。

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

4. サービス ポリシーが適用されたあとの、次に示すパケット数を確認して、カスタマーに課金するトラフィック合計を算出します。

Conformed packets ― サービス ポリシーで設定された範囲内のパケット数。カスタマーにはこの数値に対して課金できます。

Exceeded packets または dropped packets ― サービス ポリシーの範囲外であることから伝送されなかったパケット数。これらのパケット数はカスタマーに課金できません。


) 上記のシナリオでは、Cisco 10000 シリーズが中間デバイスとして使用されています(つまり、トラフィックは他のデバイスで発信され、他のデバイスに向けられています)。


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

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

policy-map police-out
class BGPclass
police 8000 1000 2000 conform-action transmit exceed-action drop
 
interface GigabitEthernet1/0/0.10
description VLAN voor klant
encapsulation dot1Q 10
ip address 10.0.0.17 255.255.255.248
service-policy output police-out

サービス ポリシー適用前のパケット数

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

CLI コマンドの出力

c10k# show policy-map interface g6/0/0.10
 
GigabitEthernet6/0/0.10
 
Service-policy output: police-out
 
Class-map: BGPclass (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 101
Police:
8000 bps, 1000 limit, 2000 extended limit
conformed 0 packets, 0 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
 
Class-map: class-default (match-any)
4 packets, 292 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Output queue: 0/8192; 2/128 packets/bytes output, 0 drops

SNMP の出力

c10k# getone -v2c 10.86.0.63 public ifDescr.65
ifDescr.65 = GigabitEthernet6/0/0.10-802.1Q vLAN subif

トラフィックの生成

次の ping コマンドでトラフィックを生成します。

c10k# ping
Protocol [ip]:
Target IP address: 10.0.0.18
Repeat count [5]: 99
Datagram size [100]: 1400
Timeout in seconds [2]: 1
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
 
Sending 100, 1400-byte ICMP Echos to 10.0.0.18, timeout is 1 seconds:
.!!.!..!.!..!.!.!..!.!..!.!..!.!.!..!.!..!.!..!.!.!..!.!..!.!..!.!.!..
!.!..!.!..!.!.!..!.!..!.!..!.!
Success rate is 42 percent (42/100), round-trip min/avg/max = 1/1/1 ms

サービス ポリシー適用後のパケット数

ping コマンドを使用してトラフィックを生成したら、 police コマンドで設定されている Committed Access Rate(CAR; 専用アクセス レート)を超えたパケット数と CAR に準拠するパケット数を確認します。

42 パケットがポリシング レートに準拠し、送信されました。

57 パケットがポリシング レートを超え、廃棄されました。

次の CLI および SNMP の出力は、サービス ポリシーが適用されたあとのインターフェイスのカウント数を示しています。(この出力では、準拠したパケット数と超過したパケット数が太字で示されています)。

CLI コマンドの出力

c10k# show policy-map interface g6/0/0.10
 
GigabitEthernet6/0/0.10
 
Service-policy output: police-out
 
Class-map: BGPclass (match-all)
198 packets, 281556 bytes
30 second offered rate 31000 bps, drop rate 11000 bps
Match: access-group 101
Police:
8000 bps, 1000 limit, 2000 extended limit
conformed 42 packets, 59892 bytes; action: transmit
exceeded 57 packets, 81282 bytes; action: drop
 
Class-map: class-default (match-any)
15 packets, 1086 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Output queue: 0/8192; 48/59940 packets/bytes output, 0 drops

SNMP の出力

c10k# getmany -v2c 10.86.0.63 public ciscoCBQosMIB
. . .
cbQosCMDropPkt.1143.1145 = 57
. . .
cbQosPoliceConformedPkt.1143.1151 = 42
. . .

CISCO-AAA-SESSION-MIB の使用方法

インターフェイスのマッピング セッションを改善するために、CISCO-AAA-SESSION-MIB に次のオブジェクトが追加されました。

casnNasPort ― casnSessionId で識別されるセッションに関連付けられた特定の概念上の行を特定します。このオブジェクトのポイント先である概念上の行は、セッションの転送に使用されるポートを表します。セッションを転送しているポートが特定できない場合、このオブジェクトの値は zeroDotZero になります。

たとえば、セッションが ATM の PVC を使用して確立されているとします。ATM インターフェイスの ifIndex が 7 で、PVC の VPI と VCI 値がそれぞれ 1 と 100 の場合、このオブジェクトの値は、(この例では)次のようになります。

 

casnVaiIfIndex ― PPP セッションに関連付けられている Virtual Access Interface(VAI)の ifIndex を特定します。このインターフェイスが IF-MIB に含まれていない場合は、このオブジェクトはゼロになります。

CISCO-CBP-TARGET-MIB の使用方法

CISCO-CBP-TARGET-MIB には、クラスベースのポリシー マッピングを持つターゲットを表現するためのテキストの表記法を定義するオブジェクトが含まれています。ターゲットになれるのは、クラスベース ポリシーを適用できる論理インターフェイスまたはエンティティです。

ccbptTarget は連続するオクテットで構成され、ccbptTargetTypes の値に従って解釈されます。

次に、genIf(1) タイプを使用したインデックスの一例と、コンフィギュレーション マッピング データの出力に対応してインデックス値をデコードする方法を示します。

上図は、ccbptPolicyMap オブジェクトのインスタンスに対する Object Identifier(OID; オブジェクト ID)のインデックス部分のマッピングを示したものです。インデックスの各部は次のように定義されます。

Config Policy Mapping Data
-------------------------------
ccbptPolicyMap.1.4.0.0.6.97.3.1.3001 = cbQosPolicyMapName.1293
 

左から右に向かって説明します。

ccbptTargetType ― 値 1 は、ccbptTargetType が genIf(1) であることを意味します。このターゲット タイプは、ccbptTargetId に含まれる値が ifIndex 値であることを意味します。

ccbptTargetId Length ― 値 4 は、次に続く ccbptTargetId の長さが 4 バイトであることを意味します。この MIB では、ccbptTargetId は可変長の OCTET-STRING として定義されており、テーブルのインデックス内では、オクテット ストリング長のあとに続く必要があります。

ccbptTargetId ― 値 0.0.6.97 は、ターゲット ID を意味します。この 3 番めのインデックスの長さは、インデックス全体の 2 番めのバイトの値で決定されます(この例では、ターゲット ID の長さは 4 バイト)。サポートされる ccbptTargetID の値については、 ccbptTargetID の値 を参照してください。

ifIndex の数値の例

この if Index ccbptTargetID の数値 0.0.6.97 は、次のように定義されています。

 

ccbptTargetDirection ― 値 3 は、ccbptTarget の出力方向を意味します。

ccbptPolicyType ― 値 1 は、ccbptPolicyType が ciscoCbQos(1) であることを意味します。

ccbptPolicyId ― 値 3001 は、ccbptPolicyId が、ターゲットに適用されたポリシー インスタンスに対するポリシー インデックスの整数であることを意味します。

値は Unsigned32(1..4294967295)です。この例では、ccbptPolicyId は cbQosPolicyIndex に等しく、cbQosPolicyIndex は、CISCO-CLASS-BASED-QOS-MIB から CbQosService PolicyTable へのインデックスになります。

cbQosPolicyMapName.1293 値は cbQosPolicyMapTable 内の行を意味し、この行には ccbptTargetId の出力方向に適用されたポリシー マップのコンフィギュレーションが記述されています。

ccbptTargetID の値

サポートされる ccbptTargetID の値は次のとおりです。

genIf(1) の場合:OCTECSTRING (SIZE(4)) - ifIndex (4d)。ここで (4d) 値は、この例では、ccbptTargetId の長さに対応する 4 バイトの 10 進数です。

atmPvc(2) の場合:OCTET STRING (SIZE(8)) - ATM PVC (4d:2d:2d)。ここで、ATM PVC の ccbptTargetId の長さは 8 バイト (4d:2d:2d) です。例:

frDlci(3) の場合:OCTET STRING(SIZE(6)) - フレームリレーの ifIndex は最初の 4 バイト、DLCI は最後の 2 バイト (4d:2d) です。

controlPlane(4) の場合:OCTET STRING(SIZE(4)) - Control Plane Entity (4d)

Cisco UDI のサポート

IDPROM に格納される Cisco Unique Device Identifier(UDI)標準への Cisco 準拠の取り組みが ENITITY-MIB でサポートされるようになりました。

Cisco UDI を使用すると、各 Cisco 製品を個別に識別できます。UDI は、次の 3 つの個別データ要素で構成され、entPhysicalTable に格納される必要があります。

発注可能製品識別子(PID) ― 製品 ID(PID)。PID は、お客様がシスコ製品を発注する際に使用する英数字の識別子です。NM-1FE-TX や CISCO3745 などがその例です。PID は 18 文字までに制限されており、entPhysicalModelName オブジェクト内に格納します。

バージョン識別子(VID) ― バージョン ID(VID)。VID は、PID のバージョンです。VID は、お客様に報告される形で製品のバージョンが変わった回数を意味します。たとえば、NM-1FE-TX の製品 ID で表される製品は、V04 の VID を持つ可能性があります。VID は 3 文字までに制限されており、entPhysicalHardwareRev オブジェクト内に格納します。

シリアル番号(SN) ― シリアル番号は製品内の特定の部品の識別に使用される 11 文字の識別子で、entPhysicalSerialNum オブジェクト内に格納します。シリアル番号の内容は、製造部品番号 7018060-0000 で定義されています。SN は、次の Web サイトで部品番号 701806-0000 を検索してアクセスします。

https://mco.cisco.com/servlet/mco.ecm.inbiz.inbiz

シリアル番号の形式は、次の 4 つのフィールドで構成されています。

場所(L)

年(Y)

ワークウイーク(W)

連続シリアル ID(S)

SN ラベルは次のように表現されます。LLLYYWWSSS.


) IDPROM にバージョン ID フィールドを持たない旧式または既存のカードに対しては、バージョン ID にヌルが返されます。したがって、IDPROM にバージョン ID フィールドを持たないカードの場合、対応する entPhysicalHardwareRev はヌルが返されます。