RMON を使用したネットワーク サービス品質の監視

しきい値の設定

監視対象変数に上昇しきい値と下降しきい値を設定することにより、変数の値が許容可能な操作範囲を超えたときにアラートを受け取ることができます。（「図 1」を参照してください。）

図 1: しきい値の設定

イベントは、各サンプル期間の後ではなく、最初にしきい値が一方向に超過したときにのみ生成されます。たとえば、上昇しきい値超過イベントが発生した場合、対応する下降イベントまでしきい値超過イベントは発生しません。これにより、システムによって生成されるアラームの量が大幅に削減され、アラームが発生したときに運用スタッフが対応しやすくなります。

リモート監視を構成するには、次の情報を指定します。

• 監視する変数(SNMPオブジェクト識別子による)

• 各検査間の時間の長さ

• 上昇するしきい値

• 下降しきい値

• 上昇中のイベント

• 落下イベント

リモート監視を正常に構成する前に、監視する必要がある変数とその許容動作範囲を特定する必要があります。これには、許容可能な動作範囲を決定するために、ある程度のベースライン化が必要です。最初に運用範囲を特定し、しきい値を定義する場合、少なくとも3か月の初期ベースライン期間は珍しいことではありませんが、ベースライン監視は、監視対象の各変数の存続期間にわたって継続する必要があります。

RMONコマンドラインインターフェイス

Junos OS には、ルーター上のリモート監視エージェントを制御するために使用する 2 つのメカニズムが用意されています。コマンドライン インターフェイス(CLI)と SNMP。CLIを使用してRMONエントリーを設定するには、 [edit snmp] 階層レベルで以下のステートメントを含めます。

CLI アクセスがない場合、SNMP アクセスが許可されていれば、SNMP マネージャーまたは管理アプリケーションを使用してリモート監視を構成できます。( 表 1を参照してください。SNMP を使用して RMON を設定するには、RMON イベントおよびアラーム テーブルに対して SNMP Set 要求を実行します。

RMONイベントテーブル

生成するタイプごとにイベントを設定します。例えば、 上昇 と 下降という 2 つの汎用イベントや、監視対象の変数ごとに異なるイベント( 温度上昇 イベント、 温度低下 イベント、 ファイアウォール ヒット イベント、 インターフェイス使用率 イベントなど)を設定することができます。イベントが設定されたら、更新する必要はありません。

RMONアラームテーブル

RMONアラームテーブルには、監視対象の変数のSNMPオブジェクト識別子(そのインスタンスを含む)が、上昇しきい値と下降しきい値、および対応するイベントインデックスとともに格納されます。RMONリクエストを作成するには、 表 2に示すフィールドを指定します。

alarmStatus フィールドと eventStatus フィールドはどちらも、RFC 2579, SMIv2 のテキスト表記法で定義されているentryStatusプリミティブです。

RMONのトラブルシューティング

RFC 2819 alarmTableの表 3に記載されている拡張を提供するジュニパーネットワークスのエンタープライズ RMON MIB, jnxRmon の内容を調べることで、ルーターで実行される RMON エージェント rmopd のトラブルシューティングを行います。

この表の拡張機能を監視すると、リモート アラームが期待どおりに動作しない理由に関する手がかりが得られます。

測定ポイント

メトリックが測定される測定ポイントを定義することは、メトリック自体を定義することと同じくらい重要です。このセクションでは、この章のコンテキスト内の測定ポイントについて説明し、サービスプロバイダーネットワークから測定できる場所を特定するのに役立ちます。測定ポイントがどこにあるかを正確に理解することが重要です。測定ポイントは、実際の測定が何を意味するかの意味を理解するために不可欠です。

IP ネットワークは、インターネット プロトコルを実行している物理リンクによって接続されたルーターの集合で構成されます。ネットワークは、イングレス(入口)ポイントとエグレス(出口)ポイントを持つルーターの集合として表示できます。「図 2」を参照してください。

• ネットワーク中心の測定は、ネットワーク自体のイングレス ポイントとエグレス ポイントに最も近いマップ測定ポイントで行われます。たとえば、サイト A からサイト B へのプロバイダ ネットワーク全体の遅延を測定するには、測定ポイントをサイト A のプロバイダ ネットワークへのイングレス ポイントとサイト B のエグレス ポイントにする必要があります。

• ルーター中心の測定はルーター自体から直接行われますが、正しいルーターサブコンポーネントが事前に識別されていることを確認するように注意してください。

図 2: ネットワーク エントリ ポイント

基本的な主要業績評価指標

たとえば、サービス プロバイダ ネットワークで 3 つの基本的な主要業績評価指標(KPI)を監視できます。

• ネットワーク層の別の測定ポイントからある測定ポイントの「到達可能性」を測定します(たとえば、ICMP pingを使用)。プロバイダー ネットワークの基盤となるルーティングとトランスポート インフラストラクチャは可用性の測定をサポートし、障害は利用不可として強調表示されます。

• プロバイダーネットワークで発生しているエラーの数と種類を測定し、ハードウェア障害やパケット損失など、ルーター中心とネットワーク中心の両方の測定で構成できます。

• のプロバイダーネットワークが、IPサービスをどの程度サポートできるか(遅延や使用率など)を測定しています。

ベースラインの設定

プロバイダネットワークのパフォーマンスはどれくらいか? ネットワークの通常の運用パラメータを特定するために、最初の3か月間の監視期間をお勧めします。この情報を使用して、例外を認識し、異常な動作を特定できます。測定された各メトリックの存続期間中、ベースライン監視を継続する必要があります。時間の経過と共に、パフォーマンスの傾向と成長パターンを認識できる必要があります。

この章では、特定されたメトリックの多くには、許容可能な運用範囲が関連付けられていません。ほとんどの場合、特定のネットワーク上の実際の変数のベースラインを決定するまで、許容される運用範囲を特定することはできません。

ネットワークの可用性を定義

サービスプロバイダのIPネットワークの可用性は、 図 3に示すように、地域のPOP(ポイントオブプレゼンス)間の到達可能性と考えることができます。

図 3: 地域のポイントオブプレゼンス

上記の例では、すべてのPOPが他のすべてのPOPに対する可用性を測定する測定ポイントのフルメッシュを使用する場合、サービスプロバイダのネットワークの総可用性を計算できます。このKPIは、ネットワークのサービスレベルを監視するためにも使用でき、サービスプロバイダーとその顧客は、サービスレベル契約(SLA)の条件内で運用しているかどうかを判断するために使用できます。

POP が複数のルーターで構成されている場合、 図 4 に示すように各ルーターの測定を行います。

図 4: 各ルーターの計測

測定には次のものが含まれます。

• パスの可用性—イングレスインターフェイスA1から見たエグレスインターフェイスB1の可用性。

• ルーターの可用性—ルーターで終端する、測定されたすべてのパスのパスの可用性の割合。

• POP の可用性 - 任意の 2 つの地域の POP(A と B)間のルーターの可用性の割合。

• ネットワーク可用性:サービスプロバイダのネットワーク内のすべての地域POPにおけるPOPの可用性の割合。

図 4 で POP A から POP B への POP 可用性を測定するには、次の 4 つのパスを測定する必要があります。

POP B から POP A への可用性を測定するには、さらに 4 つの測定が必要になります。

可用性測定の完全なメッシュは、大量の管理トラフィックを生成する可能性があります。上のサンプル図から:

• 各 POP には、2 つの共同配置 PE(プロバイダ エッジ)ルーターがあり、それぞれに 2 つの STM1 インターフェイスがあり、合計 18 台の PE ルーターと 36 個の STM1 インターフェイスがあります。

• コアプロバイダ(P)ルーターは6台あり、4台がそれぞれ2xSTM4および3xSTM1インターフェイスを備え、2台がそれぞれ3xSTM4および3xSTM1インターフェイスを備えています。

これにより、合計 68 個のインターフェイスになります。各インターフェイス間のパスのフルメッシュは次のとおりです。

[n x (n–l)] / 2 は [68 x (68–1)] / 2=2278 パスを与える

サービスプロバイダのネットワークの管理トラフィックを削減するには、インターフェイスの可用性テストのフルメッシュを生成するのではなく(たとえば、各インターフェイスから他のすべてのインターフェイスへ)、各ルーターのループバックアドレスから測定します。これにより、必要な可用性測定の数が、ルーターごとに合計 1 つに減ります。

[n x (n–1)] / 2 [24 x (24–1)] / 2=276 測定値

これにより、各ルーターから他のすべてのルーターへの可用性が測定されます。

可用性の測定

可用性の測定に使用できる方法は 2 つあります。

• 事前対応型:運用サポートシステムによって、可能な限り頻繁に可用性が自動的に測定されます。

• 事後対応型:ユーザーまたは障害監視システムから障害が最初に報告されたときに、ヘルプデスクが可用性を記録します。

このセクションでは、プロアクティブな監視ソリューションとしてのリアルタイム パフォーマンス監視について説明します。

サービスクラスの測定

サービスクラス(CoS)メカニズムを使用して、輻輳ピーク時にネットワーク内で特定のクラスのパケットを処理する方法を規制できます。通常、CoS メカニズムを実装する場合は、次の手順を実行する必要があります。

• このクラスに適用されるパケットのタイプを識別します。たとえば、特定のイングレスエッジインターフェイスからのすべての顧客トラフィックを1つのクラスに含めるか、ボイスオーバーIP(VoIP)などの特定のプロトコルのすべてのパケットを含めます。

• 各クラスに必要な決定論的動作を特定します。たとえば、VoIP が重要な場合は、ネットワークが輻輳しているときに VoIP トラフィックに最高の優先度を与えます。逆に、輻輳中は、顧客にあまり影響を与えない可能性があるため、Webトラフィックの重要性をダウングレードすることもできます。

この情報を使用して、トラフィック クラスを監視、マーキング、およびポリシングするメカニズムをネットワーク イングレスで設定できます。マークされたトラフィックは、通常、ネットワーク輻輳時にクラスごとに異なるキューイングメカニズムを適用することで、エグレスインターフェイスでより決定論的な方法で処理できます。ネットワークから情報を収集して、輻輳発生時のネットワークの動作を示すレポートを顧客に提供できます。（「図 5」を参照してください。）

図 5: 輻輳時のネットワークの動作

これらのレポートを生成するには、ルーターは次の情報を提供する必要があります。

• 送信されたトラフィック—クラスごとに受信したトラフィックの量。

• 配信されたトラフィック:クラスごとに送信されたトラフィックの量。

• ドロップされたトラフィック:CoS制限のためにドロップされたトラフィックの量。

次のセクションでは、この情報がジュニパーネットワークスのルーターによってどのように提供されるかについて概説します。

クラス当たりのインバウンド ファイアウォール フィルター カウンター数

ファイアウォールフィルター カウンターは、クラスごと、インターフェイスごとのインバウンドトラフィックの照合とカウントに使用できる非常に柔軟なメカニズムです。たとえば、以下のように表示されます。

たとえば、 表 8 には、他のクラスとの照合に使用される追加のフィルターが表示されます。

RFC 2474に準拠したCoS DiffServコードポイント(DSCP)を持つパケットはすべて、この方法でカウントできます。ジュニパーネットワークスのエンタープライズ固有のファイアウォールフィルターMIBは、 表 9に示す変数にカウンター情報を示します。

この情報は、SNMPv2 をサポートする任意の SNMP 管理アプリケーションで収集できます。Concord Communications, Inc.やInfoVista, Inc.などのベンダーの製品は、ネイティブのジュニパーネットワークス デバイス ドライバーでジュニパーネットワークス ファイアウォール MIB をサポートしています。

キューあたりの出力バイト数の監視

ジュニパーネットワークスのエンタープライズATM CoS MIBを使用して、アウトバウンドトラフィックを、仮想回線転送クラスごと、インターフェイスごとに監視することができます。（「表 10」を参照してください。）

ATM 以外のインターフェイス カウンターは、ジュニパーネットワークスのエンタープライズ固有の CoS MIB によって提供され、 表 11 に示す情報を提供します。

ドロップされたトラフィックを計算する

ドロップされたトラフィックの量は、着信トラフィックからアウトバウンドトラフィックを差し引くことで計算できます。

表 12に示すように、CoS MIBからカウンターを選択することもできます。