メインコンテンツまでスキップ

3.2.3. IP Statistics Tables (IP 統計テーブル)

3.2.3. IP Statistics Tables (IP 統計テーブル)

IP 統計テーブル (ipSystemStatsTable および ipIfStatsTable) には, 特定のエンティティが処理したデータグラムとオクテットの数をカウントするオブジェクトが含まれています。以前の試みとは異なり, この文書では複数のアドレスタイプに対して単一のテーブルを使用します。通常, 関心のあるタイプは IPv4 と IPv6 の 2 つだけですが, 必要に応じてテーブルは他のタイプをサポートできます。

最初のテーブル ipSystemStatsTable は, システム全体の情報を伝えます。(つまり, さまざまなカウンタはすべてのインターフェース用であり, 特定のインターフェースのセット用ではありません。) そのインデックスは, 統計がカウントされたアドレスタイプを表す単一のサブ ID から形成されます。

2 番目のテーブル ipIfStatsTable は, インターフェース固有の情報を伝えます。そのインデックスは 2 つのサブ ID から形成されます。最初のサブ ID はアドレスタイプ (IPv4 と IPv6) を表し, そのアドレスタイプ内のインターフェースは 2 番目のサブ ID によって表されます。

2 つのテーブルには, 粒度の違いを除いて同じものをカウントすることを目的とした類似のオブジェクトセットがあります。オブジェクト ID "ipSystemStatsEntry.2" は, 最初のテーブルのカウンタのオブジェクト ID を 2 番目のテーブルの対応するカウンタと整列させるために予約されています。

注目すべきいくつかのオブジェクトは, ipSystemStatsDiscontinuityTime, ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate, ipIfStatsRefreshRate です。これらのオブジェクトは, システム自体よりもテーブル内の行に関する情報を提供します。

不連続オブジェクトにより, 管理エンティティは, 管理エンティティのカウンタの理解を無効にする不連続イベントが発生したかどうかを判断できます。システムの再初期化やインターフェースのサイクリングは, 不連続イベントの可能性のある例です。

リフレッシュオブジェクトにより, 管理エンティティは残りのオブジェクトに対する適切なポーリング間隔を決定できます。

次の Case 図は, パケットカウンタの一般的な順序を表しています。余分な乱雑さを避けるために, プレフィックス "ipSystemStats" と "ipIfStats" は各カウンタ名から削除されています。

from                                            from
interface upper
layers

V V
| |
+ InReceives (1) + OutRequests
| |
| |
+--> InHdrErrors (5) +--> OutNoRoutes
| |
| |
+->-+ InMcastPkts (1) |
| V |
+-<-+ |
| |
+->-+ InBcastPkts (1) |
| V |
+-<-+ |
| |
| |
+--> InTruncatedPkts (5) |
| |
| |
+--> InAddrErrors |
| |
| |
+--> InDiscards (2) |
| |
| |

+--------+------->------+----->-----+----->-----+
| InForwDatagrams (6) | OutForwDatagrams (6)|
| V +->-+ OutFragReqds
| InNoRoutes | | (packets)
/ (local packet (3) | |
| IF is that of the address | +--> OutFragFails
| and may not be the receiving IF) | | (packets)
| | |
| | V OutFragOks
| | | (packets) (7)
| | |
+->-+ ReasmReqds (fragments) +-<-+ OutFragCreates
| | | (fragments)
| | |
| +--> ReasmFails (fragments (4)) +->-+ OutMcastPkts (1)
| | | V
| | +-<-+
+-<-+ ReasmOKs (reassembled packets) |
| +->-+ OutBcastPkts (1)
| | V
+--> InUnknownProtos +-<-+
| |
| |
+--> InDiscards (2) +--> OutDiscards (2)
| |
| |
+ InDelivers + OutTransmits (1)
| |
V V
to to
upper interface
layers

(1) HC カウンタとオクテットカウンタもこれらのポイントで見つかりますが, 明確さのために省略されています。

(2) 破棄カウンタは処理パスのどの時点でもインクリメントされる可能性があります。InNoRoutes の左側で破棄されたパケットは InDiscards カウンタをインクリメントし, 右側で破棄されたパケットは OutDiscards カウンタでカウントされます。

(3) 入力側のローカルパケットは, 宛先アドレスに関連付けられたインターフェースでカウントされます。これは, パケットが受信されたインターフェースではない可能性があります。この要件は, 特に再組み立て中に元のインターフェースを失う可能性があるために発生します。

(4) 一部の再組み立てアルゴリズムは処理中にフラグメントの数を追跡できなくなる可能性があるため, 一部のフラグメントはこのオブジェクトでカウントされない場合があります。

(5) InTruncatedPkts は, フレームに有効なヘッダーが含まれているが, それ以外では必要よりも短い場合にのみインクリメントされるべきです。有効なヘッダーを含めるには短すぎるフレームは, InHdrErrors としてカウントされるべきです。

(6) フォワーディングオブジェクトは, ローカルで発信されたパケットやローカルホスト宛てのパケットであっても, アドレスがローカルホストが正しいインターフェースに渡すためにパケットを転送する必要があるような場合, インクリメントされる可能性があります。

(7) パケットをフラグメント化する際, エンティティは, FragOks + FragFails == FragRqds の等式を維持するために, OutDiscards カウンタではなく OutFragFails カウンタをインクリメントする必要があります。

両方のテーブル内のオブジェクトは, 1 時間以内にカウンタをラップするために必要な帯域幅に基づいて, いくつかの適合性グループに分散されています。ベースシステムグループはすべてのエンティティに必須です。他のシステムグループは帯域幅に応じてオプションです。インターフェース固有のグループはオプションです。