要約

  • RFC 1461は、X.25上で複数のネットワーク層プロトコルを扱う装置向けのSNMP管理情報を定めた。封入アドレスからX.121番号を探せない場合と、着信したX.121番号から封入アドレスを認識できない場合を別々に数える。
  • それぞれ最後に失敗したアドレスと装置の稼働時間を残す。どのインターフェースの失敗か断定しにくくても、記録を捨てずに最も可能性の高い項目へ計上する。

障害調査で光っているポートを見れば、少なくとも物理的な入口はある。だがIPパケットが求める宛先と、X.25網が呼び出す相手の番号は別物だ。RFC 1356はIPなどをX.25で運ぶ手順を規定した。Mark ThroopによるRFC 1461は、その手順を実装する装置の管理側に、何を見せるべきかを定めた。1993年5月の仕様書であり、実際の障害件数を報告した文書ではない。

三つの表を読むと、故障箇所の切り分け方が見える。最初の表に入るのは、多プロトコル通信に使うX.25インターフェースだけ。次の表には相手のX.121アドレス、利用するインターフェース、呼び出しパラメータへの参照がある。最後の表は相手が使える封入方式を示す。X.25インターフェースが存在することと、その相手にIPを送れることの間には、まだ二つの確認が残る。

送信側の失敗カウンタは、封入アドレスを相手のX.121番号へ変換できないと増える。相手表を引いても、DDN型の算法を使っても番号が見つからない場合だ。直近の失敗アドレスも保存する。IPなら先頭の0xCCが封入種別、続く4オクテットがIPアドレスになる。時刻欄には失敗時のsysUpTimeが入る。これは装置起動後の経過時間で、暦上の日時ではない。

着信にも別の診断口が用意された。X.121番号を持つ呼び出しが届いても、その番号を封入アドレスに対応付けられなければ、別のカウンタが進む。最後の呼び出し番号と稼働時間も残る。Qビットの異常による切断は、さらに独立した項目だ。発信先が見つからない、発信者を認識できない、接続が別の理由で切れた。この三つを同じ「回線障害」に押し込めない設計である。

RFCは帰属のあいまいさまで書いている。送信側の照合失敗をどのインターフェースに数えるべきか分からないとき、エージェントは最初の有力候補に計上する。失敗の存在を消さない代わりに、行番号を絶対視するなという仕様だ。基礎にあるRFC 1382はX.25回線や呼び出しパラメータを扱う。RFC 1461は、その回線に乗せる前の宛先選びを可視化した。