要約

  • RFC 1207は、ttyaポートで結んだ二台のSun 3/60について、pingとrloginは動くのにNFSマウントはserver not responding: RPC Timed Outとなる質問を収録した。回答は、SunOS 3.5で無効になっていたUDPチェックサムと、チェックサムを持たないSLIPの組み合わせを問題にした。
  • 同じ節の別の回答では、SCO TCP/IP for XenixのSLIPはSCOのシリアルドライバーでしか動かず、独自ドライバーを持つ高機能な多ポート基板とは組み合わせられないと説明した。「接続できる」と「目的の仕事ができる」の間には、異なる検査がいくつもある。

通った試験は、通していない試験を代行しない

診断の出だしは順調だった。SunOS 3.5を走らせる二台のSun 3/60を、それぞれのttyaからSLIPで接続する。pingで相手を確認でき、rloginでも入れる。そこでNFSをマウントしようとすると、サーバーが応答しないというRPCタイムアウトが返る。作業者から見れば、ネットワークを疑う根拠が二つ減った直後に、ファイル共有だけが止まる。

この話を残したRFC 1207は、G. Malkin、A. Marine、J. Reynoldsがまとめた1991年2月のFYIだ。主なメーリングリストから経験者の質問を集め、新しくインターネットにつながるネットワークの運用担当者が使える参照先を作ろうとした。同じ質問をリストで何度も処理する負担も減らしたかった。開通した回線の上で一つのアプリケーションだけが失敗する例は、その目的にぴったりだった。

回答は、NFSサーバーを取り替えろとは言わない。SunOS 3.5はUDPチェックサムをオフにしており、イーサネットでは下位のリンク層に検査があるため動いていた、と説明する。SLIPにはその検査がない。そこでNFSをSLIP上で使うならUDPチェックサムを有効にする必要がある、とした。古いカーネルを保存したうえで、adbからudpcksumを変更する当時のコマンドまで掲載している。

ここで見落としやすいのは、プロトコル名より試験の射程だ。pingは到達性を示した。rloginは対話的な経路を示した。NFSのRPCが同じ条件で成功することまでは、どちらも確かめていない。線が動くかどうかという単一の問いに、三つの結果を押し込むと、失敗した仕事だけが説明から消える。

高機能な基板が、かえって選択肢を狭めた

第8節のもう一つの質問は、シリアルポートを増やしたいXenix利用者から来た。SCOのTCP/IP製品にはSLIPがある。それでも回答は、独自のドライバーを付属させた高機能な多ポートシリアル基板では動かないとする。SCOのSLIPが使うのはSCO製のシリアルドライバーだからだ。多くのポートが必要なら、個別の単純なポートを増やすか、単純な多ポート基板を検討するという答えだった。

この例には、購入の落とし穴がある。ポートが多い基板とSLIP対応のOSを別々に選んでも、その二つをつなぐドライバーの契約が一致しなければ回線を運用できない。高機能な基板ほどよい、という直感が役に立たない。必要なのは基板の宣伝文句ではなく、実際にロードされるドライバーとSLIP実装の組み合わせだ。

同じ章の冒頭では、SLIPは同期回線専用だという思い違いも正されている。答えは逆で、SLIPは非同期回線向け、PPPは非同期にも同期にも使える。物理回線の種類、ドライバー、パケットの検査、アプリケーションの動作。1991年の担当者は、それぞれを別の設問として扱う必要があった。

カーネルの一行は、復旧報告ではない

RFC 1207のSunOS回答は、修正箇所を具体的に示す。adbを使う一行が載るほど、問題は抽象論ではなかった。ただし問答には、変更を実行した日時も、変更後のNFSマウント結果も、パケット記録もない。これらがあれば、その二台で診断が当たったかを確かめられる。掲載されている観測結果は、疎通とログインの成功、そしてマウントのタイムアウトだ。

編集者は序文で、メーリングリストの回答を短くした場合や、自分たちで回答を補った場合があると述べる。寄稿者の名前も外した。この資料は再現可能な障害報告書ではなく、現場の問いを公的な参照先に移したものだ。それでも、仕事に必要な条件を見極める手順は明瞭だ。最初に失敗した仕事を名指しする。次に、その仕事を支える層の設定を確認する。最後に、修正後に同じ仕事が完了したかを見る。成功したpingをNFSの合格印にしてはいけない。

出典