핑은 실패했다. 오류 메시지가 먼저 살아 있는 장비를 찾았다

Summary

• RFC 1574는 1994년 2월 OSI 서비스를 제공하는 CLNP 호스트와 라우터가 갖출 기본 진단 도구로 에코, 경로 추적, 라우팅 표 출력을 제시했다.
• 오류 보고 플래그를 켠 요청에는 새 에코 선택값을 모르는 CLNP 장비도 오류로 답할 수 있다. 그 답은 응답한 지점을 가리키지만 목적지까지의 경로를 입증하지는 않는다.

당직자가 고장 난 서비스 쪽으로 탐지 패킷을 보낸다. 돌아온 것은 정상 에코가 아니라 “이 기능을 모른다”는 오류다. 화면에 실패라고만 적으면 이야기는 끝난다. 출처와 코드를 보면 다른 이야기가 시작된다. 패킷이 적어도 항의할 수 있는 장비까지 갔다는 뜻이다. Susan Hares와 Cathy Wittbrodt는 1994년 RFC에서 이런 차이를 운영 도구에 남기려 했다. 당시 OSI 네트워크 계층을 고칠 도구는 드물었고, 있더라도 서로 맞지 않는 구현이 많다고 적었다.

첫 번째 도구는 CLNP 에코다. 짝이 되는 RFC 1575는 요청에 16진수 1E, 응답에 1F 선택값을 정했다. RFC 1574는 요청에 오류 보고 플래그도 켜도록 했다. CLNP는 알아듣지만 새 에코는 모르는 장비라면 오류 패킷을 돌려주려 해야 한다. 정상 응답, 지원하지 않는다는 오류, 아무 소식도 없음은 서로 다른 진단이다. 그래서 도구는 각 패킷의 왕복 시간과 여러 번 측정한 최솟값·최댓값·평균값, 받은 오류 코드를 보여 줘야 했다.

두 번째 도구는 패킷을 한 홉씩 따라간다. 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다. 특정 사고에서 얼마나 잘 작동했는지 알려면 날짜가 붙은 에코, 추적, 라우팅 표 기록이 필요하다. 설계가 남긴 운영 원칙은 선명하다. 오류를 실패라는 한 단어로 뭉개지 않으면, 그 안에 다음에 열어 봐야 할 장비의 위치가 들어 있다.