요약

  • RFC 1461은 1993년 5월 X.25 위의 다중 프로토콜 통신을 관리하는 SNMP 객체를 정의했다. 캡슐화 주소에서 X.121 상대 번호를 못 찾는 경우와 수신한 X.121 번호를 캡슐화 주소로 알아보지 못하는 경우를 따로 센다.
  • 각 방향에는 실패 횟수, 마지막 실패 주소, 장비 가동 시간 기준 시점이 남는다. 어느 인터페이스에 귀속할지 모호해도 실패 자체는 기록하라는 규칙도 있다.

패킷에는 IP 목적지가 적혀 있다. 하지만 X.25 망에서 통화를 걸 때 필요한 것은 상대의 X.121 주소다. 두 주소 사이의 번역이 비면 정상 인터페이스도 패킷을 배달하지 못한다. RFC 1356은 IP를 비롯한 여러 네트워크 계층 프로토콜을 X.25로 나르는 규칙을 마련했다. Mark Throop의 RFC 1461은 그 운반을 관리하는 장비가 무엇을 보여야 하는지 정했다. 실제 사고를 집계한 보고서는 아니다.

표 세 개가 문제를 쪼갠다. 첫 표에는 다중 프로토콜 트래픽에 쓰이는 X.25 인터페이스만 오른다. 상대 표에는 X.121 주소, 사용할 인터페이스, 통화 매개변수 참조가 있다. 캡슐화 표는 상대가 어떤 형식의 패킷을 받을 수 있는지 나타낸다. 포트가 존재한다는 사실만으로 상대 번호나 프로토콜 수용 능력까지 증명할 수는 없다.

송신 조회가 실패하면 첫 번째 카운터가 증가한다. 캡슐화 주소에 대응하는 X.121 주소를 상대 표에서도, 알고리즘으로도 찾지 못한 경우다. 장비는 마지막 실패 주소도 보관한다. IP 주소라면 다섯 옥텟으로, 첫 0xCC는 캡슐화 유형이고 나머지 네 옥텟이 IP 주소다. 마지막 실패의 sysUpTime도 남는다. 이것은 장비가 켜진 뒤의 시간이며 달력상의 사고 시각이 아니다.

수신 방향에는 다른 카운터가 있다. 들어온 X.25 통화의 X.121 번호를 캡슐화 주소와 연결하지 못하면 그 번호와 시점이 따로 남는다. Q비트 문제로 회선이 종료된 경우에는 또 다른 기록을 쓴다. 수신자를 모르는 문제, 발신자를 모르는 문제, 통화 중 종료를 모두 ‘회선 장애’라고 적으면 원인 세 개가 사라진다.

가장 실무적인 문장은 귀속 오류를 다룬다. 송신 조회 실패가 어느 인터페이스에서 났는지 확실하지 않아도 에이전트는 가장 그럴듯한 첫 항목에 기록해야 한다. 실패 횟수는 보존되지만 인터페이스 이름은 추정일 수 있다. RFC 1382가 X.25 회선과 통화 설정을 살폈다면, RFC 1461은 통화 전에 상대를 찾는 단계의 실패를 드러낸 셈이다.