要約

  • RFC 2358 は Ethernet 共通の型を維持したまま、100 Mb/s の適合性とシンボルエラーを追加し、媒体固有の統計を一般のインターフェース索引へ結び付けた。
  • カウンターが証明するのは定義された事象の発生であり、速度、能力、デュプレックス、故障原因、修復結果は別々に確認しなければならない。

Fast Ethernet の難しさは、速くなったこと自体よりも、同じ技術をどう観測し続けるかにあった。新しい速度ごとに別物として登録すれば管理ソフトは分断される。逆に従来の項目だけに押し込めれば、100 Mb/s 固有の信号異常を見失う。1998年6月の RFC 2358 は、その間に観測の設計を置いた。

この Standards Track 文書は RFC 1650 を廃止し、100 Mb/s Ethernet の管理情報を加えた。ただし完成版を名乗ってはいない。Ethernet は速度、配線、機能の変化に応じて管理対象も変わると明記した。実際、RFC 2665 が翌年にギガビットと全二重を追加し、RFC 3635 はさらに 10 Gb/s へ広げた。RFC 2358 は現在仕様ではなく、Fast Ethernet を受け止めた時点の記録である。

共通性は ifType に現れる。速度にかかわらず Ethernet 系インターフェースは ethernetCsmacd(6) を使い、fastEther(62) や fastEtherFX(69) に分けるべきではない。現在の回線速度は ifSpeed、媒体とデュプレックスは 802.3 MAU MIB の ifMauType が担う。身元と状態を別の欄に置いたのである。

全二重だから速度を二倍にする、という表示も禁じられた。100 Mb/s 全二重でも ifSpeed は 100 Mb/s である。RFC 2358 自体には標準的なデュプレックス表示がないため、MAU MIB の実装が必要だった。速度を取得できても、MAU の証拠がなければデュプレックスは未確認である。

能力と現状も違う。100 Mb/s 対応インターフェースは低速で動作中でも ether100MbsCompliance を実装しなければならない。百メガ時だけ意味を持つカウンターは増えないままでよい。適合宣言は実装可能性を示すが、現在のネゴシエーションや健全性までは示さない。

dot3StatsIndex は同じ値の ifIndex と同一インターフェースを指す。一般的なパケット・オクテット情報と、Ethernet 固有の衝突・エラーを同じポートについて読める。この結合が古くなれば、正しい数値を別ポートへ付ける事故が起きる。再起動後の索引変更は、測定値そのものと同じくらい重要である。

100 Mb/s 向けの象徴的な追加が dot3StatsSymbolErrors だった。有効なキャリア中に無効なデータシンボルが現れた回数を数えるが、一つのキャリア事象内で複数の異常シンボルがあっても最大一回しか増えない。増分1は「条件に合う事象が一つ増えた」ことを示す。壊れたビット数でもフレーム数でも、利用者が感じた障害数でもない。

衝突の定義も狭い。レイトコリジョンは送信開始から512ビット時間を過ぎて検出された衝突で、10 Mb/s なら51.2マイクロ秒に相当する。過剰衝突は衝突回数が多すぎて送信に失敗したフレームを数える。遅延送信は媒体が使用中だったため最初の試行を待ったフレームで、衝突したフレームを含まない。任意のヒストグラムはフレームが経験した衝突回数ごとに集計する。

こうした値は原因候補を絞っても、犯人を指名しない。レイトコリジョンはデュプレックス不一致や範囲外の構成と整合するかもしれない。FCS、アラインメント、シンボルエラーは媒体やトランシーバー、ノイズ、チップ、ドライバーの問題と共存し得る。片側のカウンターだけでケーブルや相手装置を断定する根拠にはならない。

dot3StatsInternalMacTransmitErrors は限界を明記した。レイトコリジョン、過剰衝突、キャリア検出エラーに分類されなかった内部送信失敗を数え、正確な意味は実装依存である。便利な残余分類ではあるが、メーカーをまたいで同じ原因を意味するとは限らない。

測定器の出自は dot3StatsEtherChipSet に記録された。送受信統計とエラー表示を集めるチップを示し、既知の異常を考慮できるようにする。これは証言者を特定する情報であり、チップが故障原因だという自白ではない。

複数のエラー条件を満たす受信フレームも、MAC サービスが上位へ提示した状態に従って一つの分類へだけ計上された。したがって全カウンターの合計は物理症状の完全な台帳ではなく、分類規則を通った結果である。

さらに Counter32 の差分には時間軸が要る。再起動、リセット、索引変更を挟めば単純な引き算は無効になる。サンプル時刻と ifCounterDiscontinuityTime を合わせて保存しなければならない。値、対象、測定器、期間がそろって初めて証拠になる。

能動試験も万能ではなかった。RFC は非推奨になっていた ifTestTable を介してループバックと TDR に触れたが、対応は任意で、多くのチップは片方または両方を持たなかった。TDR の結果を返す標準オブジェクトもなく、ベンダー固有 MIB が必要だった。試験開始、完了、結果取得、故障位置、修復確認は別の記録である。

読み取り専用も公開情報を意味しない。書き込み可能なオブジェクトはなく、正しい実装なら SNMP SET で改変できない。一方、チップセット名は機器ベンダーを推測させる。SNMPv1 は安全な環境ではなく、IPsec でネットワークを守っても誰が GET できるかは決まらない。文書は SNMPv3 の利用者認証とビュー制御を勧めた。

RFC 2358 の台帳は、装置、ポート、索引、計測期間、速度、能力、媒体、デュプレックス、分類済み増分、チップ、相手側観測、仮説、変更、再検証から成る。一つ前の欄が真でも、次の欄は自動では埋まらない。