O contador caiu enquanto o tráfego continuou subindo: como o SNMP marcou uma nova época de medição

Resumo

• O contador original do SNMP chegava ao fim de 32 bits e voltava a zero. Uma leitura posterior menor podia ser aritmética normal, não falha, reinício ou tráfego em sentido contrário.
• Links mais rápidos encurtaram demais o intervalo de volta. Contadores de alta capacidade com 64 bits ampliaram a observação, preservando os 32 bits inferiores para gerenciadores antigos.
• Largura não resolve reset. sysUpTime e ifCounterDiscontinuityTime delimitam a época de medição; se a época muda entre duas coletas, o delta deve ser descartado.

O enlace não parou, mas o número voltou

Uma coleta lê quase 4,3 bilhões de octetos. A seguinte traz poucos milhões. Nenhum alarme de link ocorreu e os pacotes continuaram passando. Uma subtração comum, porém, produz resultado negativo.

Interpretar toda queda como reset apaga o tráfego que cruzou o limite. Somar uma volta em toda queda fabrica bilhões de octetos quando o hardware reiniciou. Para calcular taxa, o gerenciador precisa dos dois valores, da largura, do intervalo e de prova de que ambos pertencem à mesma história de acumulação.

Um painel consegue desenhar uma linha contínua sem essas provas. O modelo do protocolo não autoriza essa facilidade: identidade da interface e continuidade do contador são fatos diferentes.

A volta fazia parte do primeiro Counter

O RFC 1155, de 1990, definiu Counter como inteiro não negativo que cresce até 2^32-1 e recomeça em zero. A volta é sucessão normal num espaço finito. Ela não desfaz eventos anteriores nem informa a condição física do equipamento.

O RFC 1213 levou a regra para a MIB-II. Linhas de interface expunham ifInOctets, ifOutOctets e contadores de pacotes, ao lado de sysUpTime e ifLastChange. Havia contexto de tempo e estado, mas o valor não carregava uma origem absoluta nem o número de voltas já feitas.

No SMIv2, o RFC 2578 tornou o limite explícito. Counter32 e Counter64 não têm valor inicial definido; uma amostra isolada, em geral, não contém informação. Os dois voltam. O espaço maior apenas demora mais para reutilizar um número.

Se as coletas estão na mesma época e no máximo uma volta é possível, a diferença modular recupera o incremento. Se cabem várias voltas no intervalo, os pontos finais não revelam quantas ocorreram.

A velocidade transformou bits em prazo de coleta

Com a aceleração dos meios, a janela encolheu. O RFC 1573 calculou que pacotes de tamanho máximo em sequência poderiam fazer um contador de octetos de 32 bits voltar em pouco mais de 57 minutos numa Ethernet de 10 Mb/s, 5,7 minutos em FDDI e cerca de 34 segundos em 1 Gb/s. O RFC 2863 manteve o diagnóstico.

Coletar sempre mais rápido aumenta processamento e tráfego de gestão; uma falha de polling ainda perde a volta. Escalar o contador, por exemplo contando blocos de 1.024 octetos, também foi rejeitado. Em baixa taxa, o número esperaria acumular um bloco e faria um fluxo constante parecer uma rajada.

A escolha foi ampliar o tipo. O RFC 1573 introduziu grupos de alta capacidade. O RFC 2863 exige contadores de bytes e pacotes de 32 bits até 20 Mb/s, octetos de 64 bits acima de 20 Mb/s e também pacotes de 64 bits a partir de 650 Mb/s.

Os cortes conciliavam custo do agent, suporte então desigual e risco de perder uma volta. Não eram uma certificação de exatidão pela velocidade.

A janela nova manteve a antiga visível

Os objetos anteriores permaneceram. Havendo o contador de alta capacidade, o de 32 bits continua acessível como os 32 bits menos significativos do total de 64 bits. Um manager legado segue lendo; outro obtém um período maior sem ambiguidade de volta.

As visões concordam módulo 2^32, mas não sustentam a mesma inferência depois de um buraco longo. Trocar silenciosamente ifInOctets por ifHCInOctets altera o alcance histórico da série, mesmo com o mesmo nome de porta.

Counter64 também não é infinito. O RFC 2578 manda voltar depois de 2^64-1. A largura reduz a frequência da volta normal; não elimina reinício, recriação, perda de coleta ou mudança no significado do objeto.

A interface podia conservar o nome e perder o histórico

Outro problema não cabia em mais bits. Uma placa pode sair e voltar; o módulo que mantém contadores pode reiniciar enquanto o agent permanece ativo. Para a operação, continua sendo a mesma interface e faz sentido manter ifIndex. Para medição, unir os valores antigos e novos seria falso.

Antes, era preciso preservar os contadores durante a ausência ou atribuir outro índice. O RFC 2233 acrescentou ifCounterDiscontinuityTime, permitindo reter a identidade da linha e declarar uma nova época para seus contadores.

O RFC 2863 define o objeto como o valor de sysUpTime na ocasião mais recente em que um Counter32 ou Counter64 associado sofreu descontinuidade. Se nada ocorreu desde a reinicialização do subsistema de gestão, o valor é zero.

Assim, ifIndex continua nomeando a interface dentro daquele contexto sem prometer que a acumulação de hoje começa onde a de ontem terminou.

A marca dizia quando, não o motivo

A obrigação do manager é direta. Se ifCounterDiscontinuityTime for diferente nas duas coletas, a diferença calculada deve ser descartada. sysUpTime também precisa ser verificado, porque a reinicialização do agent pode alterar todo o contexto.

Descartar não equivale a registrar tráfego zero. Significa que o total exato do período não é demonstrável com aquelas amostras. Uma estimativa para planejamento pode existir, desde que não seja armazenada como observação do contador.

A marca também não explica a causa. Não distingue troca de placa, atualização, recriação lógica ou erro de implementação. O RFC 3635 aplica a mesma fronteira aos objetos Ethernet sem transformar o timestamp em diagnóstico autenticado.

Por isso, uma marca inalterada permite comparação dentro do modelo. Não certifica o equipamento, não prova chegada de pacotes, correção de cobrança ou efeito de serviço.

Fontes e limites da evidência

O conjunto histórico fechado reúne os RFC 1155, RFC 1213, RFC 1573, RFC 2233, RFC 2578, RFC 2863 e RFC 3635. Eles estabelecem tipos, evolução e obrigações de coleta. Não medem adoção atual, conformidade de produto, causa de um evento real, entrega de tráfego ou validade de uma fatura.