요약

  • RFC 1451은 주기적 샘플링, 임계값 알람, 이벤트 정의, 수신지별 InformRequest 알림을 분리함으로써 SNMPv2 관리 스테이션들 사이의 분산 모니터링을 구현했다.
  • 알림 행은 자체적인 카운트다운 수명을 가졌으며 갱신되어야 했다. 만료는 그 전달 관계를 파괴했지만, 알람이나 이벤트 정의 자체를 파괴하지는 않았다.
  • 재전송은 구현 한도로 제한되었고, 이후의 확인형 InformRequest 의미조차 전달을 보장하거나 누군가 그 이벤트에 조치했음을 증명하지 못했다.

계속 살려 두어야 했던 경로

RFC 1451은 단일 관리자를 기다리는 평범한 에이전트를 다루지 않았다. 이 메모는 다른 관리 스테이션들에 대해 에이전트 역할까지 수행하는 관리 스테이션을 다루었다. 한 스테이션이 다른 스테이션에 모니터링 서비스 수행을 요청할 수 있었고, 그로 인해 제어와 관측이 하나의 큰 네트워크나 상호 연결된 여러 행정 조직에 걸쳐 분산될 수 있었다.

이 메모는 그 서비스를 Alarm, Event, Notification 세 개의 테이블로 구성했다. 이 분리는 장식이 아니라 아키텍처였다. Alarm 테이블은 무엇을 언제 샘플링할지 결정했다. Event 테이블은 감지된 조건이 메커니즘 내부에서 무엇을 의미하는지 명명했다. Notification 테이블은 어느 원격 컨텍스트가 InformRequest를 수신할지, 어떤 재시도 정책 하에서 받을지를 결정했다. 한 계층을 생성한다고 해서 나머지가 조용히 함께 생성되지는 않았다.

이 도구는 샘플링 경계만을 바라보았다

알람 항목은 정수형 관리 변수 하나, 샘플링 컨텍스트, 주기, 그리고 상승·하강 임계값을 지정했다. 이중 역할 스테이션은 그 컨텍스트에 대해 개념적으로 SNMPv2 검색을 수행했다. 변수를 Alarm 테이블에 넣었다고 해서 접근 권한이 넓어질 수는 없었다. RFC 1451은 샘플링 관계가RFC 1445의 행정 모델이 허용하는 당사자들과 MIB 뷰를 존중하도록 명시적으로 요구했다.

관측은 주기적이었다. 절대 모드에서는 구간 끝의 값이 두 임계값과 비교되었다. 델타 모드에서는 연속된 두 구간 끝 사이의 차이가 비교되었다.snmpAlarmValue는 마지막으로 완료된 구간을 노출했으며, 현재 구간은 끝나기 전까지는 사용할 수 없었다. 그 경계들 사이에서 이 MIB는 연속적 시야를 주장하지 않았다.

또 다른 표현상의 한계가 있었다. 샘플링된 통계값이 부호 있는 32비트 알람 값에 맞지 않으면, 구현은 자신만의 방식으로 절단할 수 있었다. 따라서 기록된 숫자는 물리적 상태 그 전체가 아니라 프로토콜이 형태를 부여한 관측이었다.

임계값 초과는 반복 알람의 흐름이 아니었다

RFC 1451은 히스테리시스를 사용했다. 상승 이벤트가 발생한 뒤에는 값이 하강 임계값을 넘을 때까지 다른 상승 이벤트가 생성되지 않았다. 하강 이벤트 이후에도 그 반대가 적용되었다. 이는 하나의 경계 근처에서 요동치는 값이 무한한 동일 이벤트 연쇄를 만들어내는 것을 막았다.

또한 이벤트를 “임계값을 넘은 값”의 동의어가 아니라 상태 전이로 만들었다. 관련 전이가 이미 기록되어 있다면 대시보드는 높은 값을 표시하면서 이벤트 카운터는 변하지 않은 채로 있을 수 있었다. 반대로 활성화 직후의 첫 샘플은 구성된 시작 정책이 허용하는 경우 시작 알람을 생성할 수 있었다.

임계값은 이벤트 수신지 없이도 초과될 수 있었다

상승, 하강, 또는 사용 불가 조건 각각은 Event 테이블 인덱스를 가리켰다. 0은 유효한 이벤트 인덱스가 아니었다. 참조된 이벤트 행이 존재하지 않으면 연관이 존재하지 않는 것이고, 그 초과에 대해 어떤 이벤트도 생성되지 않았다. 따라서 Alarm 행은 그 다음 단계가 의도적으로든 실수로든 부재한 채로도 활성 상태를 유지할 수 있었다.

사용 불가 상황에는 자체적인 분기점들이 있었다. 권한 오류, 누락된 객체 또는 잘못된 구문은 사용 불가 이벤트 하나를 생성하고 알람 행을 파괴할 수 있었다. 응답 부재의 경우 이중 역할 관리자에게 선택이 주어졌다. 통신이 불가능하다고 판단하고 행을 파괴하거나, 최신 알람 값 인스턴스를 삭제하면서 샘플링을 계속하고 통신이 복구되면 그 값을 다시 생성하는 것이다. “값 없음”은 하나의 보편적 원인을 인코딩하지 않았다.

이벤트 기록은 생성자의 것이었다

Event 행은 권위 있는 이벤트 유형 OID를 명명하고, 로컬 카운트와 마지막으로 생성된 이벤트의 로컬sysUpTime을 담았다. 이 필드들은 이 생성자가 자신이 무엇을 만들어냈다고 믿는지를 확립할 수 있었다. 그러나 다른 스테이션이 그 이벤트를 수신했음을 보여주지는 않았다.

이 구분이 중요한 이유는, RFC 1451이 각 알람 조건이 이벤트를 트리거한다고 서술하고, 각 이벤트가 하나 이상의 알림을 유발할 수 있다고 서술하기 때문이다. “가능하다”는 표현이 관건이었다. 알림에는 이벤트와 수신지 컨텍스트로 인덱싱되는 또 다른 행이 필요했다. 하나의 이벤트는 여러 수신층을 가질 수도, 아무 수신층도 갖지 않을 수도 있었다.

요청된 재시도가 로컬 한도에 부딪혔다

알림 행에는 요청된 재전송 주기와 횟수가 포함되었다. 요청된 주기는 이중 역할 스테이션이 지원하는 최소값까지 늘어날 수 있었다. 요청된 재시도 횟수는 지원되는 최대값까지 줄어들 수 있었다. 행은 의도를 기록했지만, 실행되는 정책은 구현의 자원 한도가 함께 결정했다.

당대의RFC 1448이 InformRequest 동작을 제공했다. 이후의 규격인RFC 3416은 InformRequest를 확인형으로 서술하지만 여전히 전달을 보장하지는 않는다. 유효한 요청이 수신 엔터티에 도달하면 그 내용은 적절한 애플리케이션에 전달되고 Response-PDU가 생성된다. 이는 비확인형 트랩보다 강한 증거다. 그러나 그것이 근본 조건이 참이었는지, 중요했는지, 복구되었는지의 증명은 아니다.

전달 관계는 설계상 만료되었다

가장 많은 것을 말해주는 필드는snmpEventNotifyLifetime이었다. 이 필드는 초 단위로 카운트다운되었고, 0이 되면 알림 행의 상태가destroy가 되었다. 그 항목을 사용하는 관리 스테이션은 지속적인 전달을 유지하기 위해 주기적으로 갱신해야 했다. 기본 수명은 하루였다.

이것은 알림 관계에 대한 임대였다. 알람 정의는 살아남을 수 있었다. Event 행도 살아남을 수 있었다. 샘플링은 계속될 수 있었고 미래의 초과 여전히 생성자 측 이력을 증가시킬 수 있었다. 그러나 갱신되지 않은 수신지별 행은 사라졌다. 이 아키텍처는 어제의 구성을 오늘의 수신층에 대한 영구 증거로 취급하는 것을 거부했다.

이후의 SNMP는 역할들을 분리해 두었다

RFC 편집기는 현재RFC 1451을 Historic으로 분류한다. 이를 현재 배포 환경에 대한 설명으로 제시해서는 안 된다.RFC 3413을 포함한 이후의 SNMP 아키텍처는 알림 발신자, 알림 수신자, 관리 대상, 필터, 프록시 포워더를 각각 별도로 명명한다. 그 이후의 프레임워크는 1993년 메모의 개념을 2002년의 개념으로 다시 쓰는 이유가 아니다. 수신지 선택과 알림 처리가 서로 구별되는 아키텍처적 작업으로 남아 있었다는 증거다.

RFC 1451 자체는 이 메모에서 보안 문제를 논의하지 않는다고 밝힌다. 당사자, 컨텍스트, 접근 제어의 사용은 안전한 배포를 인증하지 않는다. 이 메커니즘은 관계가 어떻게 유지되도록 의도되었는지를 보여줄 수 있다. 그러나 누가 실제 행을 구성했는지, 어느 제품이 그것을 준수했는지, 인간이 알람을 수신했는지는 확립할 수 없다.

출처