Resumo

  • No RFC 1304, a tabela de erros sintáticos preservava apenas a ocorrência mais recente por interface e tipo; uma linha não constituía arquivo histórico nem contagem de frequência.
  • Os objetos de recepção abrangiam apenas PDUs sem erro, enquanto sipL3Errors contava descartes por processamento de protocolo ou erro de bits e excluía problemas de endereçamento.
  • Descartes por violação de assinatura, inclusive filtragem de destino, podiam existir em outro MIB; por isso, a palavra “total” só valia dentro do conjunto declarado.

O registro que apaga sua própria véspera

Em fevereiro de 1992, o RFC 1304 definiu objetos de gestão para o SIP, o protocolo de interface do SMDS. Entre eles havia uma tabela dedicada a doze formas de erro sintático no nível 3: campos de endereço malformados, tamanhos impossíveis, extensões de cabeçalho em posição ou comprimento inválidos, etiquetas incompatíveis, divergência de comprimento e expiração do intervalo de recepção da mensagem.

Para cada interface e tipo, a linha guardava o endereço de origem rejeitado, o endereço de destino rejeitado e um instante medido em sysUpTime. A expressão decisiva era “ocorrência mais recente”. Se o mesmo tipo voltasse a acontecer, o novo caso ocuparia o lugar do anterior. Nada nessa estrutura permitia reconstruir quantas vezes ocorreu, quanto tempo durou, se atingiu sempre o mesmo remetente ou se a operação corrigiu a causa.

Um timestamp igual a zero declarava que não havia informação válida na linha. Era um estado de ausência bem definido, não um certificado de que a rede estava saudável. Poderiam ter ocorrido descartes de outra classe, falhas fora daquela interface ou problemas que a tabela jamais pretendeu representar.

Receber não significava contar tudo o que chegou

Os objetos sipL3ReceivedIndividualDAs e sipL3ReceivedGAs contavam PDUs recebidos para destinos individuais e de grupo, mas somente os que não tinham erro. Logo, seu denominador já era uma população filtrada. Uma diferença entre tráfego observado no enlace e esses objetos não demonstrava perda por si só; indicava antes que as medições não começavam necessariamente no mesmo ponto do processamento.

O objeto sipL3Errors tinha outra fronteira. Contava PDUs recebidos do sistema remoto, detectados com erros de processamento de protocolo ou de bits e, por isso, descartados. Erros relacionados ao endereçamento estavam explicitamente fora. O RFC reuniu o cálculo dos erros de PDU do nível 3 a partir de componentes sintáticos e semânticos, estes incluindo destinos individuais ou de grupo não reconhecidos e tipos inválidos de endereço SMDS.

Essa soma podia ser total para a definição e ainda assim não ser total para a pergunta do operador. O nome resumia uma taxonomia; não aboliu as exclusões que a tornavam calculável.

A política de assinatura morava em outro módulo

O próprio RFC 1304 avisou que redes SMDS públicas poderiam descartar PDUs por violações de assinatura. Esses casos seriam observados no MIB de assinatura do SMDS, não nos objetos que o documento acabava de descrever. Violações de Destination Address Screening também não entravam nos contadores de destino não reconhecido.

Assim, o mesmo sintoma visto por um usuário — dados que não chegam — podia deixar evidências em superfícies diferentes. Um erro de bits, um endereço semanticamente inválido e uma decisão de filtragem por assinatura não eram variantes intercambiáveis do mesmo fato. Tinham autoridades, regras e registros distintos.

Uma tela que consulta só o MIB de interface pode exibir zero sem falsificar aquele objeto. O erro é acrescentar silenciosamente a frase “portanto nenhum pacote foi recusado”. Para sustentá-la, seria necessário reconciliar também a superfície de assinatura, a configuração aplicável e a observação do serviço.

Um ramo vazio continuava vazio

O grupo de seleção de operadora aparecia na árvore do MIB, mas o RFC o qualificava como placeholder. Reservar um ponto na hierarquia não implantava objetos, escolhas nem lógica operacional. O endereço simbólico dava espaço para trabalho futuro; não era prova de capacidade presente.

A tabela de aplicações IP sobre SMDS trazia outra cautela. Ela relacionava um endereço IP, um endereço SMDS individual, o endereço de grupo de uma Logical IP Subnetwork e o destino dos pedidos ARP. A relação não era um para um: um endereço SMDS podia atender vários endereços IP, e uma única Subscriber-Network Interface podia participar de várias redes lógicas.

Os objetos eram definidos como somente leitura. Ainda assim, o RFC permitia que um agente, a seu critério, os tornasse graváveis para que uma estação de gestão devidamente autorizada alterasse o endereçamento. Definição do objeto, opção do agente, autorização da estação, pedido de mudança e estado resultante são cinco provas diferentes. A existência da coluna não demonstra que nenhuma delas ocorreu.

O contador mudou de endereço

Em 1994, o RFC 1694 tornou o RFC 1304 obsoleto e apresentou uma versão compatível com SMIv2, descrita como semanticamente idêntica. Ao mesmo tempo, descontinuou vários contadores SIP e indicou objetos correspondentes na ifTable do MIB-II. A intenção da métrica podia permanecer, embora seu lugar canônico de consulta mudasse.

Para uma série histórica, isso é uma mudança material. O coletor precisaria registrar qual identificador consultou, quando passou ao novo objeto, se houve amostragem simultânea, como tratou reinicializações e se os conjuntos realmente coincidiram. O padrão sucessor não fornece prova de que qualquer produto realizou essa reconciliação.

Uma curva contínua pode esconder uma troca de fonte. Um degrau pode ser migração de instrumentação em vez de evento de rede. Sem versão do módulo, identidade da interface, época do contador e intervalo de coleta, o número perde a procedência necessária para ser comparado.

O que a definição não observou

O RFC 1304 especificou objetos; não relatou valores de uma rede real. Não demonstrou implementação por fabricante, coleta por estação de gestão, correção de agente nem impacto em aplicativo. Sua seção de segurança disse apenas que questões de segurança não eram discutidas. Dessa omissão não se pode inferir autenticação, integridade ou legitimidade de uma alteração.

A contribuição histórica do documento está justamente nas fronteiras. A arquitetura não tentou fazer um contador responder por protocolo, endereçamento, assinatura, configuração e experiência final ao mesmo tempo. Ao preservar essas separações, ela permite perguntas melhores: qual população foi contada, quem tomou a decisão de descartar, qual registro reteve o evento e que observação independente liga isso ao resultado alegado?

Fontes