요약

  • RFC 1515는 MAU마다 jabber의 현재 상태, jabber 상태에 들어간 횟수, 관리자의 주의를 환기하는 trap을 정의했다.
  • 연속하는 trap에는 최소 5초의 간격이 필요했기 때문에 통보 열은 의도적으로 억제되었고, 완전한 사건 수가 되지 못했다.
  • 이후의noJabber는 과거의 전이를 지우지 않으며, 카운터 증가도 이상의 지속을 증명하지 않는다. 개체, 적용 범위, 관측 시점이 필요했다.

5초의 공백이 말하는 것

어떤 MAU가 jabber 상태에 들어갔다가 정상으로 돌아온 뒤 4초 후에 다시 들어간다고 하자. 이것은 규격을 설명하기 위한 가정이며, 실제 사고의 재현이 아니다. 전이 카운터는 둘 늘어날 수 있다. 다음 폴링에서는 이미noJabber일지도 모른다. 그러나 trap은 5초 미만의 간격으로 연속 송출할 수 없다.

경보 한 건, 전이 두 번, 현재는 정상이라는 세 가지 기록은 동시에 성립한다. "즉시 주의해야 하는가", "지금 무엇이 보이는가", "이 관측 기간에 몇 번 들어갔는가"는 서로 다른 질문이기 때문이다.

관측값보다 먼저 대상을 고정한다

1993년 9월의RFC 1515는 IEEE 802.3의 Medium Attachment Unit을 관리하는 MIB를 정했다. MAU는 매체와 리피터 포트, 또는 이더넷형 인터페이스를 잇는다. 규격은 양쪽에 서로 다른 기본 그룹을 두었다.

리피터 쪽은 그룹, 포트, MAU의 각 인덱스로 유일해지고, 인터페이스 쪽은 MIB-II의ifIndex에 대응했다. 좌표를 잃은 상태값은, 어떤 물리 연결이 변했는지 설명할 수 없다.

관리 상태, 매체 가용성, jabber도 별개의 것이다. 매체 가용성은 MAU의 유형에 따라 링크 단절, 낮은 광량, 루프백 부재, 원단 장애, 무효 신호 등을 나타낼 수 있었다. 상관은 가능해도, 한쪽이 다른 쪽의 원인을 자동적으로 증명하는 것은 아니다.

상태는 현재형으로만 말한다

rpMauJabberState와ifMauJabberState에는other,unknown,noJabber,jabbering이 있었다. 초기화 중처럼 진짜 상태를 알 수 없는 경우,unknown은 올바른 답이었다.noJabber는 통상,jabbering은 현재 그 상태에 있음을 나타낸다.

거기에서 고장 부품, 지속 시간, 손실 프레임, 이용자 영향을 이끌어낼 수는 없다. 통보 도달이나 복구 성공도 증명하지 않는다. AUI형에서는 상태를other로 하고, 대응 카운터를 0으로 하는 규정이 있었다. 0은 적용 대상 외라는 의미를 가지며, 물리 장애 모두의 부재 증명이 아니다.

카운터는 "들어갔다"를 세는

rpMauJabberingStateEnters와ifMauJabberingStateEnters는jabbering으로의 이행 횟수였다. 긴 한 번은 1, 짧은 세 번은 3이 될 수 있다. 초, 프레임, 바이트, 이용자, 통보 건수가 아니다.

관측 시점도 필수적이었다. 후속의RFC 3636은 관리 시스템 재초기화 등에 의한 불연속을 명시하고, 인터페이스 쪽을ifCounterDiscontinuityTime에 결부시켰다. 최신 정수만을 저장하면, 리셋을 개선으로 오인한다.

카운터가 늘고, 나중에 현재 상태가 정상이라면, "기간 내에 이행이 있었고, 지금의 폴에서는 보이지 않는다"고 말할 수 있다. 이상이 몇 초 지속되었는지, 수리로 돌아왔는지는 별도의 증거를 기다린다.

Trap은 주의 환기에 특화했다

RFC 1515는 리피터 MAU용과 인터페이스 MAU용의 jabber trap을 정하고, 대응하는 상태를 실었다. jabber에 들어가면 보내는 한편, 연속 trap은 최소 5초 떨어뜨리도록 요구했다.

이것은 관리 경로를 통보의 집중에서 지킨다. 그러나 그 대가도 명백하다. 수신한 trap의 건수를, 발생한 전이의 건수로 다룰 수 없다. 억제 시간 중의 침묵은, 카운터가 포착한 추가 전이를 부정하지 않는다.

RFC 1157은 SNMPv1의 Trap-PDU를 요구·응답과 별도로 하고, 송신원, 식별자, 최근 초기화로부터의 시각, 변수를 갖게 했다.RFC 1215는TRAP-TYPE의 기술 규약을 제공했다. 통보의 의미는 정해졌지만, 완전한 시계열이나 최종 수령이 보장된 것은 아니었다.

고속화해도 삼분법은 남았다

RFC 2239는 RFC 1515를 포괄하고, 100 Mb/s, 오토네고시에이션, 잭 관리를 추가했다.RFC 2668이 더 확장했고, 2003년의 RFC 3636은 10 Gb/s를 더해 RFC 2668과 RFC 1515를 폐지했다.

그래도 상태, 전이 카운터, 5초 간격은 남았다. 이후 문서는, 더 고속인 몇몇 유형에서 카운터를 0으로 하는 것도 명시했다. 기술의 추가는, 오래된 지표를 만능의 건강 판정으로 바꾸지 않았다.

검증 가능한 기록은 MAU의 개체와 유형, 상태, 카운터, 관측 시점, trap 내 시각, 수신 시각, 폴링 주기를 남긴다. "카운터는 2 늘었고, trap은 한 건 기록되었다"는 말할 수 있다. "포트가 두 번 고장 났다"는 원인과 영향의 자료 없이는 말할 수 없다.

Lu Heng의Running-Code Primacy,Minimum Initial Specification,현실의 층은 이 읽기를 규율 부여한다. 공통 사양은 국소적으로 검증 가능한 좁은 의미에 머문다. 통보는 행동을 촉구할 수 있어도, 스스로 저장하지 않은 현실의 지배자가 될 수는 없다.

정보원과 증거의 경계

기술적 근거는 RFC Editor의RFC 1515 기록, RFC 1515, RFC 1157, RFC 1215, RFC 2239, RFC 2668, RFC 3636이다. 현행 제품의 구현, 보급률, 전달률, 개별 장애, 통신 손실, 기기 손상, 복구는 입증하지 않는다.