Resumo

  • O RFC 1224 limitou a soma dos alertas de um agente com maxAlertsPerTime, windowTime e alertsEnabled.
  • Ao cruzar o limite, o agente enviava um alertsDisabled e se calava; o próprio aviso de silêncio podia se perder.
  • Um log numerado preservava alertId e alertData, mas leitura ou exclusão não provavam atendimento nem recuperação.

O problema tinha duas direções

Publicado em maio de 1991, o RFC 1224 aparece como Experimental no RFC Editor e tem sua trajetória mantida pelo IETF Datatracker. Ele não escolhia condições de alarme. Seu assunto era o fluxo depois da geração.

Um equipamento em falha talvez não conseguisse avisar que falhou. No extremo oposto, uma interface oscilante poderia inundar o gerente e consumir a rede de gestão. O desenho precisava impedir excesso e, ao mesmo tempo, detectar ou reconstruir informação perdida.

O RFC 1157 apoiava SNMP em datagramas não confiáveis e deixava a seleção de destinos de Trap-PDU para a implementação. O RFC 1215 organizava a definição de traps, mas desaconselhava fortemente criar novas. Uma notificação bem formada continuava sem recibo.

O pino desligava a emissão

O limitador de janela móvel usava maxAlertsPerTime e windowTime. A conta abrangia todos os tipos do agente, não uma cota para cada categoria.

Na inicialização, alertsEnabled era verdadeiro. Cada alerta gerado consultava o estado. Falso significava não enviar; verdadeiro permitia transmitir e guardar o horário. Quando o conjunto cabia dentro da janela crítica, o agente enviava uma única alertsDisabled e mudava o estado para falso.

Era uma defesa de CPU, banda e capacidade do gerente. Mas a mensagem final também podia desaparecer. Por isso o gerente devia consultar periodicamente alertsEnabled, reativá-lo quando necessário e registrar a possibilidade de traps perdidos no intervalo. O silêncio passava a ter causa operacional própria.

O log criava uma segunda rota

No mecanismo consultável, cada alerta local ganhava alertId crescente e uma cópia OPAQUE em alertData. O gerente podia buscar o próximo identificador ou um específico e, quando suportado, remover a linha por SET ou DELETE. O RFC 1189 contextualiza as operações CMOT/CMIP equivalentes usadas no texto.

Essa custódia sobrevivia à falha da entrega espontânea, mas não era infinita. Uma tabela cheia substituía a entrada mais antiga. Ler primeiro a mais velha reduzia a chance de perda; não prometia história completa.

Uma linha mostrava que o agente criou e guardou uma cópia. Não mostrava que enviou, que a rede entregou, que o gerente coletou antes da substituição ou que alguém corrigiu a causa. Excluir a linha era uma transição administrativa, não um laudo de recuperação.

Com vários gerentes, comunidades diferentes podiam ver limites, estados e tabelas distintos. A reativação de um não obrigava a visão do outro. O RFC também não discutia segurança: SET e DELETE não demonstravam identidade autenticada.

Fontes