요약

  • SNMP의 원래 32비트 카운터는 최댓값에서 0으로 순환하도록 설계되었습니다. 따라서 더 작은 두 번째 값은 역방향 트래픽이나 인터페이스 오류가 아니라 정상적인 산술 결과일 수 있습니다.
  • 더 빨라진 링크는 32비트 순환 주기를 안정적인 폴링에는 너무 짧게 만들었습니다. Interfaces MIB는 64비트 대용량 카운터를 추가하면서도 이전 관리자를 위해 하위 32비트를 유지했습니다.
  • 너비는 재설정 문제를 해결하지 못했습니다.sysUpTime과ifCounterDiscontinuityTime이 측정 시대를 정의합니다. 어느 하나라도 폴링 사이에 단절을 보이면 계산된 트래픽 증분은 폐기해야 합니다.

링크가 트래픽을 계속 전송하는 동안 카운터는 떨어졌다

1 Gb/s 인터페이스를 폴링한다고 상상해 보십시오. 첫 번째 값은 약 43억 옥텟에 가깝습니다. 다음 값은 훨씬 작은 숫자인데, 패킷 전달은 한 번도 멈추지 않았습니다. 보통 정수로 뺄셈을 하면 음수가 나옵니다. 감소를 재설정으로 취급하면 트래픽이 지워집니다. 모든 감소를 한 번의 순환으로 취급하면 재시작 이후 트래픽을 허위로 만들어낼 수 있습니다.

이것은 대시보드에 맡겨진 경계 사례가 아니었습니다. 가장 초기의 인터넷 관리 타입에 이미 내장되어 있었습니다. 카운터는 유한한 숫자 공간에서 누적된 사건을 표현했습니다. 두 값을 하나의 비율로 바꾸려면 관리자는 두 숫자 이상의 정보가 필요했습니다. 카운터의 너비, 관측 사이의 시간, 그리고 두 샘플이 동일한 측정 이력에 속한다는 증거가 필요했습니다.

차트는 하나의 연속 선을 보여주기 때문에 이 구분은 잊기 쉽습니다. 프로토콜 기록은 그보다 엄격합니다. 프로토콜은 하나의 항목의 식별성과, 그 값들이 비교 가능한 시대를 분리합니다.

순환은 첫 번째 카운터에 이미 내장되어 있었다

1990년에 발표된RFC 1155는Counter를2^32-1까지 단조 증가한 뒤 순환하여 0부터 다시 시작하는 비음수 정수로 정의했습니다. 순환은 최댓값 다음의 정상적인 후속 상태였습니다. 순환이라고 해서 장치가 거꾸로 갔거나, 모든 바이트를 잃었거나, 이전 관측을 철회했다는 뜻이 아니었습니다.

RFC 1213은 MIB-II를 통해 이 타입을 널리 알렸습니다. 인터페이스 행에는ifInOctets,ifOutOctets및 패킷 카운터가 담겼습니다. 같은 MIB는sysUpTime과ifLastChange를 노출하여 측정값 주변의 시간 및 상태 맥락을 제공했습니다. 그러나 원시 카운터 자체는 시작 시점이나 이미 지나간 순환 횟수를 말해 주지 않았습니다.

SMIv2는 이후 이 증거적 한계를 명시적으로 밝혔습니다.RFC 2578에서Counter32와Counter64는 정의된 초기값이 없습니다. 따라서 고립된 하나의 샘플은 일반적으로 정보량이 없습니다. 두 타입 모두 순환하며, 차이는 숫자 공간이 유지되는 기간뿐입니다.

끊김 없는 하나의 시대 안에서는 알려진 한 번의 순환을 모듈러 연산으로 처리할 수 있습니다. 여러 번의 순환이 가능한 만큼 긴 간격을 넘어서면, 두 끝점 값만으로는 몇 번의 순환이 일어났는지 알 수 없습니다. 숫자의 정확성은 그 숫자 바깥에 있는 어떤 경계에 의존합니다.

속도가 너비를 폴링 기한으로 바꾸었다

유한한 너비는 링크가 빨라지면서 운영상 비용이 되었습니다.RFC 1573은 연속된 최대 크기 패킷 스트림이 32비트 옥텟 카운터를 10 Mb/s 이더넷에서 약 57분 남짓, FDDI에서 약 5.7분, 1 Gb/s 매체에서 대략 34초 만에 순환시킬 수 있다고 계산했습니다.RFC 2863은 이후의 Interfaces MIB에 대해 같은 경고를 유지했습니다.

폴링을 더 빠르게 하는 것은 무한한 해답이 아니었습니다. 더 짧은 간격마다 관리 대역폭과 처리량이 소모되었고, 한 번의 누락된 주기만으로도 재구성이 모호해질 수 있었습니다. 워킹 그룹은 단위를 스케일링하는 방법, 즉 개별 옥텟 대신 옥텟 블록을 세는 방안을 검토했지만 기각했습니다. 낮은 트래픽 비율에서는 스케일링된 카운터가 한 블록이 다 차기를 기다리느라 안정적인 트래픽이 버스트처럼 보일 수 있었습니다.

선택된 절충안은 더 넓은 타입이었습니다. RFC 1573은 64비트 카운터를 갖는 대용량 그룹을 도입했습니다. RFC 2863은 지원을 인터페이스 속도에 연결했습니다. 20 Mb/s 이하에서는 32비트 바이트 및 패킷 카운터, 20 Mb/s 초과에서는 64비트 옥텟 카운터, 그리고 650 Mb/s 이상에서는 옥텟에 더해 64비트 패킷 카운터까지 요구했습니다.

이러한 임계값은 특정 비트 전송률이 진실을 만든다는 주장이 아니라 엔지니어링 절충이었습니다. 64비트 관리의 비용과 당시 고르지 않던 보급률을, 32비트 값이 모호하지 않게 남는 시간의 감소와 균형 맞춘 것이었습니다.

더 넓은 카운터는 옛 창을 그대로 남겨 두었다

이 전환은 기존 항목을 삭제하지 않았습니다. 대용량 카운터가 존재할 때 RFC 1573과 RFC 2863은 연관된 32비트 카운터를 자신의 하위 32비트로 계속 사용할 수 있도록 요구합니다. 오래된 관리자도 여전히 인터페이스를 읽을 수 있고, 더 새로운 관리자는 훨씬 긴 관측 창을 유지할 수 있습니다.

따라서 호환성은 같은 누적 사건에 대한 두 가지 관점을 보존했습니다. 두 값은2^32모듈로에서는 일치하지만, 긴 폴링 간격에 대해 동등한 증거를 제공하지는 않습니다.ifInOctets에서ifHCInOctets로 조용히 전환하는 수집기는 물리 링크와 항목 레이블이 그대로인데도 자신의 역사적 시계열의 의미를 바꿀 수 있습니다.

Counter64역시 무한 장부가 아닙니다. RFC 2578은2^64-1에서 순환하도록 정의합니다. 더 넓은 공간은 그 문서들이 고려한 비율에서는 일반적인 순환을 드물게 만들 뿐, 재시작, 누락된 관측, 의미 변화를 사라지게 하지는 않습니다.

인터페이스 이름은 측정값보다 오래 살아남을 수 있었다

너비는 순환적 고갈만을 다룹니다. 하드웨어는 제거되었다가 다시 돌아올 수 있습니다. 에이전트가 그대로 살아 있는 동안 라인 카드가 재설정될 수 있습니다. 운영자가 동일한 논리 포트로 인식하는 인터페이스는, 예전 하드웨어 카운터 값을 보존할 수 없더라도 같은ifIndex를 유지할 자격이 있을 수 있습니다.

이전 인터페이스 테이블 관행은 곤란한 선택을 강요했습니다. 인터페이스가 없는 동안 모든 카운터를 보존하거나, 관리자가 옛값과 새값을 이어 받지 않도록 새 인덱스를 할당하거나.RFC 2233은 세 번째 선택지를 도입했습니다. 인터페이스의 식별성은 유지하되, 그 측정 시대가 바뀌었다는 사실을 노출하는 것입니다.

그 항목이ifCounterDiscontinuityTime이었습니다.RFC 2863은 이를, 하나 이상의 연관된 인터페이스 카운터가 단절을 겪은 가장 최근 시점의sysUpTime값으로 정의합니다. 관리 서브시스템이 재초기화된 이후 단절이 없었다면 값은 0입니다.

이 분리가 이 메커니즘의 지속적인 공헌입니다. 안정적인ifIndex는 해당 행이 관련 관리 범위 안에서 여전히 인터페이스의 이름을 나타낸다는 뜻입니다. 오늘의 카운트가 어제의 누적을 이어받는다는 보장은 아닙니다.

타임스탬프는 원인이 아니라 단절을 표시했다

관리자의 규칙은 이례적으로 직접적입니다. 두 폴링 사이의 차이를 계산할 때,ifCounterDiscontinuityTime이 다르다면 그 차이는 폐기해야 합니다. 또한sysUpTime을 확인해야 합니다. 에이전트 재초기화가 더 큰 이름 및 시간 맥락을 재설정할 수 있기 때문입니다.

증분을 폐기하는 것은 트래픽이 0이라고 선언하는 것이 아닙니다. 표준 증거가 그 구간에 걸쳐 하나의 정확한 합계를 더 이상 뒷받침하지 않는다고 말하는 것입니다. 운영자는 계획을 위해 누락된 기간을 추정할 수 있지만, 그 추정을 마치 카운터의 관측값인 것처럼 저장해서는 안 됩니다.

타임스탬프는 또한 의도적으로 범위가 제한되어 있습니다. 에이전트가 마지막으로 단절을 선언한 시점은 기록하지만, 그 이유는 기록하지 않습니다. 라인 카드가 교체되었는지, 소프트웨어가 업그레이드되었는지, 항목이 재생성되었는지, 구현이 잘못 동작했는지는 말하지 않습니다.RFC 3635는 이 단절 경계를 이더넷 계열 카운터로 그대로 옮기면서 이를 진단용 원인 코드로 바꾸지 않았습니다.

그렇기 때문에 변하지 않은 마커는 유용하지만 마법적이지는 않습니다. 정의된 모델 아래에서 비교를 지원할 뿐, 에이전트를 인증하거나 샘플을 검증하거나, 카운터가 하류 분석가가 가정한 계층을 설명한다는 것을 증명하지는 않습니다.

출처와 증거의 한계

이 설명의 폐쇄된 역사 기록은RFC 1155,RFC 1213,RFC 1573,RFC 2233,RFC 2578,RFC 2863,RFC 3635입니다. 이들은 문법, 계보, 관리자의 의무를 확립합니다. 현재 제품의 준수 여부를 측정하거나, 실시간 단절을 설명하거나, 청구서를 검증하거나, 카운트된 트래픽이 목적지에 도달했음을 증명하지는 않습니다.