트래픽 그래프가 갑자기 낮아졌거나 불가능한 값으로 뛰면 회선 사용량보다 원래 카운터 두 개와 수집 조건을 먼저 확인합니다. 현재값이 이전값보다 크다는 이유만으로 카운터가 순환하지 않았다고 볼 수 없습니다. 이 글의 목표는 평균 속도를 계산해도 되는 구간과 추가 수집이 필요한 구간을 구분하는 것입니다.
대상은 SNMP 인터페이스 octet 카운터로 속도를 계산하는 운영자입니다. 장비가 이미 산출한 순간 속도, 패킷 수, 합산된 여러 인터페이스 값은 그대로 넣지 않습니다. 계산값은 두 관측 사이의 평균이며 그 사이의 짧은 혼잡을 보여주는 순간 최대값이 아닙니다.
1. 그래프 대신 이 원자료부터 확보합니다.
| 항목 | 확인할 값 | 빠졌을 때의 처리 |
|---|---|---|
| 대상 | 장비·인터페이스·ifIndex·방향 | 서로 다른 포트 또는 수신/송신 값 혼용 금지. |
| 카운터 | 정확한 OID·이전값·현재값 | 도구 기본값을 실제값처럼 사용하지 않음. |
| 폭·단위 | Counter32/Counter64·octet | bit·packet이면 이 산식 적용 보류. |
| 시각 | 두 번의 실제 수집 시각·경과 초 | 예약된 폴링 주기와 실제 간격 구분. |
| 링크 속도 | 같은 방향에 적용할 물리적 상한 | LAG·속도 변경·가상 인터페이스는 별도 확인. |
| 불연속 | ifCounterDiscontinuityTime·재초기화 이력 | 리셋 여부를 모르면 정상으로 가정하지 않음. |
RFC 2863 §6은 ifInOctets·ifOutOctets를 Counter32, ifHCInOctets·ifHCOutOctets를 Counter64로 정의합니다. 같은 객체를 두 번 읽고 원래 숫자의 자릿수를 보존합니다. 64비트 원자료를 반올림된 지수 표기나 정밀도가 부족한 스프레드시트 숫자로 옮겼다면 원본부터 다시 확보합니다.
2. 현재값이 커도 숨은 순환이 가능합니다.
다음은 수학적 모호성을 보여주는 설명용 가상값이며 장비에서 수집한 기록이 아닙니다. 32비트 octet 카운터, 300초 간격, 한 방향 최대 1Gbps, 불연속이 없다는 조건을 둡니다.
| 항목 | 설명용 값 |
|---|---|
| 이전 카운터 | 1,200,000,000 octet |
| 현재 카운터 | 1,275,000,000 octet |
| 단순 차이 | 75,000,000 octet |
| 32비트 전체 범위 | 2³² = 4,294,967,296 octet |
순환 없이 75,000,000 octet이 증가했다면 평균은 75,000,000 × 8 ÷ 300 = 2,000,000bps, 즉 2Mbps입니다. 그러나 그보다 2³² octet이 더 증가했어도 현재 카운터는 똑같이 표시됩니다.
(75,000,000 + 4,294,967,296) × 8 ÷ 300 ≈ 116,532,461bps이므로 약 116.532Mbps도 가능합니다. 두 값 모두 1Gbps 이하입니다. 따라서 두 관측값만으로 실제 평균을 2Mbps라고 확정할 수 없습니다. “두 번 이상 순환하지 않았다”라는 가정도 0회와 1회 후보를 구분하지 못합니다.
RFC 2863 §3.1.6은 1Gbps에서 32비트 octet 카운터가 약 34초 만에 순환할 수 있는 문제와 고용량 카운터를 설명합니다. 낮게 보이는 그래프는 실제 저부하일 수도, 놓친 순환일 수도 있습니다.
3. 가능한 증가량을 하나로 좁힙니다.
폭이 n비트라면 순환 범위는 M = 2ⁿ입니다. 불연속이 없을 때 관측값과 맞는 최소 증가량은 (현재 - 이전 + M) mod M이고, 실제 증가량 후보는 그 값에 M을 0번 이상 더한 값입니다. 여기에 해당 방향 속도 × 실제 경과시간 ÷ 8로 얻은 상한을 대조합니다.
| 같은 카운터 값에 적용한 설명용 조건 | 계산 해석 |
|---|---|
| 32비트, 300초, 1Gbps | 여러 증가량이 가능. 최소 평균 2Mbps만으로 실제 속도를 확정하지 않음. |
| 실제 원자료가 64비트, 300초, 1Gbps | 이 조건의 후보는 75,000,000 octet 하나. 평균 2Mbps. |
| 실제 수집 간격이 10초인 32비트, 1Gbps | 이 조건의 후보는 하나. 평균 60Mbps. |
| 재초기화·카운터 불연속 확인 | 전후 차분을 버리고 이후의 연속된 두 관측을 다시 수집. |
| 최소 증가량도 물리 상한보다 큼 | 단위·폭·시각·속도·인터페이스 또는 리셋 가정을 재확인. |
기존 32비트 자료를 선택 상자만 64비트로 바꾸면 해결되지 않습니다. 실제로 고용량 OID를 다시 수집해야 합니다. 300초에 얻은 값을 10초로 바꾸는 것도 같은 오류입니다. 짧은 간격 예제는 실제로 그 간격에 수집했다는 별도 가정입니다.
한 방향 1Gbps의 상한만을 사용할 때 M × 8 ÷ 1,000,000,000 ≈ 34.36초보다 짧은 실제 간격은 증가량이 전체 범위에 도달하는 것을 막는 조건입니다. 수집 지연을 고려해 경계에 딱 맞추지 않습니다. 링크 속도가 바뀌었거나 합산 카운터라면 이 보장을 그대로 적용할 수 없습니다.
4. 계산 도구의 경고를 다음 수집 행동으로 바꿉니다.
이 페이지 도구는 같은 인터페이스·한 방향·octet·불연속 없음·속도 상한이라는 가정 아래 가능한 증가량을 확인합니다. 기본 예제의 경고는 입력 형식 오류가 아니라 단일 평균을 정할 증거 부족입니다.
| 도구 결과 또는 관찰 | 다음 행동 |
|---|---|
| 여러 순환 후보 | 실제 64비트 카운터를 확보하거나 더 짧은 간격으로 새로 수집. |
| 불연속 있음·여부 모름 | 재시작 로그와 discontinuity 값을 확인하고 연속 구간을 새로 확보. |
| 한 후보로 계산 가능 | 평균의 시간창·방향·가정을 그래프에 함께 기록. |
| 범위·상한과 불일치 | 원본 OID·카운터 폭·단위·속도 변화부터 확인. |
RFC 2863 §3.1.5은 두 폴링 사이 ifCounterDiscontinuityTime이 달라졌다면 차분을 폐기하고 재초기화도 확인하도록 설명합니다. 현재 카운터가 작아졌다는 사실만으로 리셋과 순환을 구분할 수는 없습니다.
5. 평균 속도와 장애 원인을 별도로 기록합니다.
속도 계산이 맞아도 그 평균만으로 통화 끊김이나 패킷 손실의 원인을 확정하지 않습니다. 같은 시간창의 큐 드롭·인터페이스 오류·사용자 증상과 변경 이력을 연결합니다. 전체 누적 오류 수보다 시험 구간의 증가분이 필요합니다.
인터페이스·방향
____, OID·폭·단위____. 이전/현재 원자료____, 실제 간격____초, 속도 상한 근거____. 불연속 확인____. 계산 결과는단일 평균/다중 후보/재수집 필요 ____. 같은 시간의 증상·오류 증가____. 다음 수집 방법____.
평균을 계산할 수 없는 구간은 0Mbps로 채워 정상처럼 보이게 만들지 않습니다. 미확인 구간을 표시하고 원자료를 보존합니다. 음성 증상과 연결할 때는 같은 통화의 신호·미디어 기록에 정확한 시간창을 전달합니다.