Summary

  • RFC 1574は1994年2月、OSIサービスを提供するCLNPのホストとルーターに、エコー、経路追跡、経路表の出力という基本的な診断機能を求めた。
  • エラー報告フラグ付きの要求なら、新しいエコーの識別値を知らないCLNP装置もエラーを返せる。その返事は応答した装置の手掛かりであり、最終目的地までの通信を示すものではない。

回線に障害が起き、当番が遠くの装置に探りを入れる。返事は「そのエコー方式は知らない」というエラーだった。管理画面が一律に失敗と塗れば終わりだが、当番には一歩進んだ知らせである。探査パケットは少なくとも、文句を言える装置に届いた。Susan HaresとCathy Wittbrodtは1994年のRFCで、そうした差を読める道具をOSI網に要求した。当時はネットワーク層の診断手段が乏しく、実装同士が通じないこともあったという。

一つ目はCLNPのエコーだ。対になるRFC 1575は、要求に16進数の1E、応答に1Fという識別値を定めた。RFC 1574は要求側にエラー報告フラグの設定も求める。CLNP自体は扱えても新しいエコーを知らない装置なら、エラーパケットを返すよう試みる。正常なエコー応答、非対応を告げるエラー、完全な沈黙。この三つを同じ赤い印にしては、障害の位置が見えなくなる。

RFCはPing道具に、各パケットの往復時間、複数回の最短・最長・平均時間、受け取ったエラーコードの表示を求めた。コードを見せる理由は現場にある。最初の装置が拒んだのか、遠くの装置が拒んだのかで、次に調べる場所は違う。抽象的な「失敗」より、一通の具体的な苦情が役立つ。

二つ目は経路追跡である。CLNPパケットのLifetimeはIPのTTLに似た役目を持つ。値1の要求は最初の中継点で寿命が切れ、エラーを返す。値2なら次の点へ進める。値を上げていくと、返事をした装置が順に現れる。A0とA1は寿命切れ、B0は非対応のオプション、80と81は到達不能または未知の宛先を示す。どれも同じ「途中で止まった」では済まない。

指定した経由地を通るよう求める部分ソースルートには、さらに厄介な点があった。ISO 8473では、このオプションを知らない装置は要求を無視してパケットを転送できる。目的地に届いたとしても、指定した経由地を通過したとは限らない。RFC 1574は、ソースルートの住所不明や経路不適合といったエラーを利用者へ示すよう求めた。到着したという事実だけを誇れば、試したかった道の検査に失敗する。

三つ目の道具は、装置の頭の中を見るものだ。OSIのホストとルーターは、帯域外の方法で経路表を出力できなければならない。経路の出所にはES-IS、IS-IS、IDRP、静的設定などがある。RFCはshow osi routesのような絞り込み可能な表示を提案し、SNMPやCMIPにも触れた。ただし当時のCLNS MIBでは、求める情報をすべて取り出せなかった。経路表は装置の判断材料を見せる。パケットが実際にどこから返ったかは、別の記録が語る。

この情報提供RFCには、特定の障害や普及率の測定は載っていない。実装の成否を見るには、日付付きのエコー結果、追跡結果、経路表が必要だ。RFCが先に定めたのは、障害時の問いを混ぜないための作法だった。失敗の返事に役立つ情報があるなら、その情報を画面から消してはいけない。