요약

  • RFC 1207은 두 대의 Sun 3/60이 ttya 직렬 포트로 SLIP을 쓰는 상황을 전했다. ping과 rlogin은 작동했지만 NFS 마운트는 server not responding: RPC Timed Out을 반환했다. 답변은 SunOS 3.5가 꺼 둔 UDP 체크섬과 자체 체크섬이 없는 SLIP을 지목했다.
  • 같은 절의 다른 답변은 SCO TCP/IP for Xenix의 SLIP이 SCO 직렬 드라이버와만 맞고, 별도 드라이버를 쓰는 지능형 다중 포트 보드에는 맞지 않는다고 했다. 선로의 연결 상태와 실제 업무의 성공 여부를 따로 확인해야 했다는 기록이다.

연결 확인표에 없던 파일 시스템

처음 두 시험은 운영자를 안심시켰다. Sun 3/60 두 대를 각자의 ttya에 물리고 SLIP을 올렸다. 상대에게 ping이 닿았고 rlogin으로 원격 세션도 열렸다. 그런데 NFS 마운트는 서버가 응답하지 않는다는 RPC 시간 초과로 끝났다. 선로를 통째로 실패로 표시하기도, 통째로 성공으로 표시하기도 어려운 결과였다.

이 사례를 실은 RFC 1207은 1991년 2월 G. Malkin, A. Marine, J. Reynolds가 편집한 FYI 문서다. 편집자들은 주요 메일링리스트에서 거듭 올라오는 질문을 모아, 새로 인터넷에 들어오는 네트워크의 운영 인력에게 쓸 만한 참고자료를 주려 했다. 같은 문답을 목록 가입자 모두가 반복해서 읽는 비용도 줄이려 했다. 이 NFS 사례가 필요한 이유는 간단하다. 한 가지 연결 시험의 성공만으로 실제 사용자가 하려는 작업을 설명할 수 없었기 때문이다.

답변은 결함의 위치를 특정했다. SunOS 3.5가 UDP 체크섬을 꺼 놓았고, 이더넷에서는 링크 계층의 검사 덕분에 그 설정이 문제없이 보일 수 있었다. SLIP은 자체 체크섬을 제공하지 않는다. 문서는 그런 직렬선에서 NFS를 쓰려면 UDP 체크섬을 켜야 한다고 했다. 옛 커널을 보관하라는 주의와 함께, adb로 udpcksum 값을 바꾸는 당시의 명령까지 적었다.

운영자가 보게 되는 증상은 파일 시스템의 시간 초과지만, 제안된 조정 지점은 로컬 커널이다. 원격 서버 이름이나 직렬 케이블을 바꾼다는 이야기가 아니다. ping은 자신이 지난 경로가 닿는다는 사실을 보여 줬고, rlogin은 대화형 연결이 된다는 사실을 보여 줬다. NFS의 UDP 교환이 같은 조건을 견딘다는 사실은 둘 중 어느 시험에도 들어 있지 않았다.

포트가 많아도 드라이버가 안 맞으면 끝이다

같은 8.3절에는 다른 종류의 함정이 있다. Xenix에서 SLIP 포트를 많이 쓰려는 질문에, 답변은 SCO TCP/IP for Xenix가 SLIP을 지원한다고 인정한다. 곧바로 조건을 붙인다. 그 SLIP은 SCO 직렬 드라이버에서만 작동한다. 자체 드라이버를 가져오는 지능형 다중 포트 보드는 이 조합에서 쓸 수 없다. 답변이 제시한 길은 단순한 포트 여러 개, 혹은 단순한 다중 포트 보드였다.

고급 보드를 샀는데 더 작은 보드보다 쓸모가 적어지는 순간이다. 포트 수는 물리적 가능성을 말하고, 드라이버는 운영체제와 SLIP이 그 포트를 실제로 다룰 수 있는지를 결정한다. 제품 설명에서 ‘SLIP 지원’과 ‘다중 포트’라는 두 문구를 따로 찾아도 두 기능의 접점은 증명되지 않는다. 랙에 꽂은 뒤 운영자가 확인해야 할 것은 보드가 적재한 실제 드라이버다.

RFC 1207은 이 절의 앞부분에서 SLIP이 동기식 회선 전용이라는 기억도 바로잡았다. SLIP은 비동기식 직렬선용이고, PPP는 비동기식과 동기식 모두에 쓸 수 있다는 답이다. 물리 회선, 드라이버, 패킷의 무결성 검사, 응용 프로그램. 초기 인터넷 접속에는 이 네 질문이 차례로 따라왔다. 어느 하나의 정답이 다음 질문의 정답을 대신하지 않았다.

제시된 패치와 확인된 복구 사이

FAQ에는 adb를 이용한 구체적인 커널 명령이 실렸다. 그 한 줄은 편집자들이 어느 설정을 의심했는지 또렷하게 보여 준다. 다만 문서에는 해당 기계에서 명령을 실행했다는 기록, 변경 전후의 패킷 캡처, 이후 NFS 마운트 성공 여부가 없다. 이런 기록이 있어야 그 설치 환경의 실제 복구를 말할 수 있다. 원문이 직접 남긴 관측 결과는 ping과 rlogin의 성공, NFS의 시간 초과다.

편집자들은 서문에서 메일링리스트 답변을 줄이거나 원래 답이 없던 질문에 직접 답을 보태기도 했다고 설명한다. 원문의 사람 이름은 삭제했다. 그 결과 같은 번호의 8.3절에는 Xenix 보드 질문과 SunOS 파일 시스템 사례가 나란히 놓였다. 두 사례가 같은 시설이나 같은 운영자에게서 나왔다는 기록은 없다. 편집된 배열은 공통 문제를 읽기 좋게 만들었지만, 개별 설치 환경의 장비 목록과 수정 후 결과까지 보존하지는 않았다. 다음 운영자는 그 빈칸을 자기 현장의 시험 기록으로 채워야 했다.

출처