요약

  • RFC 1452는 프록시 또는 이중 언어 매니저가 로컬 데이터베이스를 사용해 대상 프로토콜을 선택하면서 SNMPv2 애플리케이션을 SNMPv1 에이전트에 연결할 수 있게 했습니다.
  • GetBulk는 그 경계를 넘지 못했습니다. 프록시는 반복 제어 값을 지우고 하나의 GetNext 요청을 보냈으며, 일부 레거시 오류 값은 의도적으로 그대로 유지되었습니다.
  • 번역된 응답이 유용했다는 것은 매핑된 교환이 성공했다는 증거일 뿐, 원래의 동작, 정보 구조, 보안 속성 또는 운영 결과가 그대로 유지되었다는 증거가 아니었습니다.

하나의 애플리케이션, 두 번의 실행

RFC 1452는 실질적인 전환 문제를 다뤘습니다. SNMPv2 매니저와 SNMPv1 에이전트가 공존해야 했습니다. 모든 애플리케이션이 모든 엔드포인트를 이해하도록 요구하면 마이그레이션 로직이 각 도구 안으로 들어가므로, 이 메모는 그것을 프록시 또는 두 버전 모두를 다룰 수 있는 매니저에 배치했습니다.

그 추상화는 매력적이었습니다. 애플리케이션이 하나의 인터페이스를 통해 관리 동작을 수행할 수 있었기 때문입니다. 그러나 중개자는 애플리케이션이 PDU 자체에 담아 주지 않는 사실이 필요했습니다. 에이전트에 접속하기 전에, 이중 언어 매니저는 로컬 데이터베이스를 조회해 올바른 프로토콜을 선택했습니다. 따라서 대상 식별, 데이터베이스 항목, 선택된 버전, 요청 매핑은 서로 별개의 기록이었습니다.

데이터베이스가 낡았다면 인터페이스는 그대로 사용 가능한 상태로 남으면서 잘못된 프로토콜이 선택될 수 있었습니다. RFC 1452는 그 로컬 목록을 스스로 검증하도록 만들지 않았습니다. "두 버전을 모두 지원한다"는 매니저의 역량을 설명할 뿐, 모든 대상 항목의 진실을 설명하지 않았습니다.

대량 조회는 하나의 다음 단계가 되었다

GetRequest, GetNextRequest, SetRequest의 경우 SNMPv2에서 SNMPv1로 가는 프록시는 PDU를 그대로 통과시켰습니다. GetBulk에는 SNMPv1에서 그런 대응물이 없었습니다. 규칙은 명시적이었습니다.non-repeaters와max-repetitions를 0으로 설정한 다음 태그를 GetNextRequest로 바꾼다는 것이었습니다.

그 결과 레거시 에이전트는 각 바인딩마다 한 번의 다음 단계 동작만 수행했습니다. 애플리케이션의 원래 반복 제어가 기술한 대량 조회를 실행하지 않았습니다. 이 매핑은 구형 장비를 통해 진행할 수 있는 방법을 보존했지만, 한 번의 교환에서 요청된 다음 위치의 개수는 보존하지 않았습니다.

이것은 GetBulk가 고유 환경에서 작동하는 방식과는 다른 문제입니다.RFC 1448은 당대의 SNMPv2 동작을 정의했고, 이후 버전들도 반복되는 후속 위치 모델을 유지했습니다. 공존 프록시는 SNMPv1에 새 동작을 몰래 가르친 것이 아니라 더 낮은 공통 동작을 선택한 것입니다.

따라서 프록시 위쪽의 응답은 애플리케이션이 처음 표현한 것보다 더 좁은 질문에 답할 수 있었습니다. 교환을 감사하려면 요청 ID만으로는 부족했습니다. 원본 PDU, 선택된 대상 버전, 번역 규칙, 하류 PDU, 응답이 모두 필요했습니다.

구형 오류는 구형처럼 보이도록 놓아두었다

번역이 항상 과거를 더 새로운 어휘로 정규화한 것은 아니었습니다. SNMPv1 GetResponse가noSuchName,badValue또는readOnly를 담고 있으면, RFC 1452는 SNMPv2 개체 자신은 그런 값을 생성하지 않더라도 프록시가 그것을 바꾸지 않도록 지시했습니다. 더 새로운 쪽의 매니저는 오류 구조 자체가 레거시 기원을 드러내는 응답을 해석해야 했습니다.

그것은 정직한 비대칭이었습니다.noSuchName을 더 정밀한 바인딩별 예외로 바꾸는 것은 구형 응답자가 제공하지 않은 세부 정보를 만들어내는 일이었을 것입니다. 대략적인 상태를 유지하면 출처가 보존되지만, "SNMPv2 인터페이스를 통해 수신했다"가 "고유한 SNMPv2 의미론"을 뜻하지는 않게 되었습니다.

tooBig사례는 경계를 더 선명하게 만들었습니다. 프록시는 오류를 전파하기 전에 변수 바인딩을 제거했습니다. RFC 1452는 심지어 고유한 SNMPv2 개체는 GetBulk에 대해tooBig을 생성하지 않으나, 프록시는 요청을 다운그레이드한 뒤 그 결과를 운반해야 한다고 적었습니다. 상류 교환은 하류 프로토콜의 역사에 속한 상태를 담을 수 있었습니다.

트랩은 재구성물로 나타났다

SNMPv1 Trap-PDU는 바이트 단위로 통과하지 않았습니다. 프록시는sysUpTime.0을 앞에 붙이고, 일반 또는 기업별 트랩 필드로부터snmpTrapOID.0을 계산하고, 기업 바인딩을 덧붙였습니다. 그 결과 만들어진 SNMPv2 트랩은 여러 구형 필드에서 유도된 것이었습니다.

이 구성은 유용했습니다. 더 새로운 애플리케이션이 알아볼 수 있는 알림 형식을 받았기 때문입니다. 그러나 이것은 계보 이벤트이기도 했습니다. 계산된 OID, 복사된 시간, 기업 값은 독립적으로 관찰된 사실과 혼동되어서는 안 됩니다. 그것들은 하나의 레거시 메시지에 대해 명세된 표현이었습니다.

대상 처리도 중개자의 몫이었습니다. RFC 1452는 하나의 뷰 존재 확인에 명시된 예외를 두고 SNMPv2 알림 절차를 적용했습니다. 프록시는 단순히 바이트를 재배열하는 것이 아니라 재구성된 알림이 어디로 갈지 결정하는 일에 참여했습니다.

문법이 바뀌어도 스키마는 남을 수 있었다

공존은 MIB 모듈까지 다뤘습니다. RFC 1452는 SNMPv1 모듈을 SNMPv2와 함께 계속 사용할 수 있고, 변환이 통상적으로 그 객체들을 폐기로 표시할 필요가 없다고 밝혔습니다. 진정한 의미 변화만이 그렇게 해야 한다고 했습니다.

그래도 연속성에는 변환 대장이 필요했습니다. 임포트가 바뀌었습니다.Counter와Gauge는 명시적인 32비트 타입이 되었습니다.ACCESS는MAX-ACCESS가 되었습니다.mandatory는current가 되었고,optional은obsolete가 되었습니다. 빠져 있던 설명과 인덱스는 채워 넣어야 했습니다. 레거시 쓰기 전용 선언은 읽기-쓰기가 되었고, 구현에 따른 읽기 동작은 설명에 밝혀야 했습니다.

객체 식별자는 주변 계약이 새로운 문법을 갖추는 동안에도 안정적으로 남을 수 있었습니다. 그렇다고 매니저에게 권한을 부여하거나, 구현의 읽기 결과를 증명하거나, 모든 개정판이 같은 것을 뜻한다는 것을 보여주지는 않았습니다. 1996년의 후속 문서인RFC 1908은 하나의 모호성을 명시했습니다. 서로 다른 개정판이 서로 다른 필수 리프를 가지면 레거시 서브트리에서 그룹을 유도하는 것은 실패하며, 그때 SMIv2 재작성만이 유일하게 모호하지 않은 답이라는 것이었습니다.

이후의 공존 문서들은 숨어 있던 작업을 드러냈다

RFC 2576과 그 뒤를 이은 BCP인RFC 3584는 공존을 SNMPv3까지 확장했습니다. 그 세부 내용은 번역 비용을 더 쉽게 볼 수 있게 합니다. 바인딩별 SNMPv2 예외는 여러 바인딩이 실패했을 때 구현 선택에 따라 하나의 SNMPv1noSuchName으로 붕괴될 수 있었습니다. Counter64는 알림을 번역 불가능하게 만들 수 있었습니다. 프록시는 SNMPv1이 표현할 수 없는 값을 건너뛰기 위해 GetNext 요청을 반복할 수 있었고, RFC 3584는 그것이 비용이 클 수 있다고 경고했습니다.

그 이후의 규칙들은 경계이지, 1993년 구현에 대한 증거가 아닙니다. 그것들은 RFC 1452에서 이미 보이는 일반적 속성을 확인해 줍니다. 호환성 계층은 상태, 정책, 때로는 반복 작업을 소유합니다. 반환되는 증거의 형태와 비용을 바꾸면서 서비스를 유지할 수 있습니다.

RFC 1452 자체는 보안을 다루지 않았습니다. 프록시를 통과한 요청이 인증되고, 승인되고, 기밀유지되고, 올바른 것은 아니었습니다. 응답 역시 성공적인 운영 변경을 증명하지 않았습니다. 프로토콜 교환, 애플리케이션 해석, 네트워크 효과는 서로 분리되어 있었습니다.

출처