Resumo

  • RFC 5190 permite que um pedido lógico seja preenchido por vários SETs antes do disparo. Outro cliente com as mesmas permissões pode alterar a linha nesse intervalo; autenticação por mensagem não prova uma intenção única.
  • O resultado também é distribuído: resposta SET, estado operacional, notificação e GETs posteriores têm autoridades diferentes. Preservar apenas o último evento elimina autoria e causalidade.

O conflito não parecia conflito. Os dois controladores usavam o mesmo owner, tinham VACM válido e acreditavam estar continuando a mesma operação. O equipamento viu uma sequência legítima de escritas.

RFC 5190 reconhece a janela. Se os parâmetros de PRR ou PER não couberem num único SET, vários clientes que compartilham permissões podem alcançar a mesma regra antes do pedido ficar completo. Um altera o que o outro já escreveu.

O texto supõe que, em geral, esses agentes estarão coordenados. Depois recomenda medidas concretas: horários separados, group indexes distintos ou faixas de rule index que não se sobreponham. A recomendação revela o limite — a coordenação não nasce da autenticação.

Principal válido não significa intenção íntegra

USM pode comprovar identidade, integridade, confidencialidade e proteção contra replay. VACM pode permitir a leitura ou escrita de objetos específicos. Essas garantias se aplicam a cada mensagem.

Uma operação lógica, porém, emerge da combinação de mensagens. Se A escreve cinco campos e B muda dois antes do trigger, cada ação tem autor; a composição final não tem necessariamente um pedido original equivalente.

O recibo precisa de um assembly ID acima do SNMP packet. Para cada varbind, guardar writer, valor anterior, valor novo, versão da linha e plano esperado. O SET que dispara processamento deve apontar para a versão que o cliente acreditava completar.

Owner comum identifica o espaço da regra. Não substitui a proveniência de cada mutação. Em failover, esse detalhe separa continuidade controlada de split brain.

A resposta do SET ainda não é a resposta MIDCOM

Depois de preencher a linha, o cliente escreve midcomRuleAdminStatus. A resposta positiva desse SET confirma a escrita. O middlebox pode então entrar em checkingRequest e processingRequest.

Só mais tarde surgem reserved, enabled, rejeição ou término. Marcar sucesso no último SET apaga o trabalho ainda em curso e atribui ao agente SNMP um fato que pertence ao estado posterior do middlebox.

Uma notificação solicitada pode anunciar o resultado, mas traz apenas estado operacional e lifetime. Valores positivos ou detalhes de erro ficam na linha para GET. O trap é um índice temporal, não uma resposta completa em todos os casos.

O sistema deve mostrar os limites: parâmetros aceitos, processamento iniciado, estado terminal observado, resposta reconstruída. Um único badge não consegue preservar os quatro.

Timeout de SET cria duas histórias

Request e reply SET podem desaparecer no UDP. Se o request se perde, nada mudou. Se só o reply some, a escrita pode estar ativa. Repetir imediatamente escolhe uma história sem evidência.

RFC 5190 propõe verificar primeiro por GET, usar snmpSetSerialNo, manter retransmission timer abaixo do menor lifetime/storage time ou evitar retransmissão. A escolha deve ser parte do registro.

Isso é especialmente importante para durações. O valor pode estar decrescendo enquanto o cliente espera. Uma segunda escrita não é apenas cópia: ela chega a outro estado temporal.

Serial number ajuda no escopo do protocolo; não atesta tráfego nem efeito de aplicação. O recibo precisa manter timeout, leitura de recuperação e decisão de retry.

Trap perdido não é operação perdida

Notificações também usam transporte não confiável. O cliente que espera um evento deve ter timeout e consultar status. A alternativa de polling usa mais operações, mas o RFC a chama de mais confiável.

Confiabilidade aqui significa poder observar novamente. Não significa snapshot atômico. Entre GETs, linhas mudam, entram e saem. O cliente deve combinar notificações ocorridas durante a coleta ou repetir a leitura.

Uma ausência de trap abre uma consulta; não fecha um veredito. Uma ausência de linha pode significar índice errado, falta de acesso, operação inexistente ou linha terminal já removida.

Cada uma dessas hipóteses merece um estado explícito. Transformá-las todas em failed torna a automação simples e a realidade irreconstruível.

A linha terminal pode sumir antes do prazo mostrado

midcomRuleStorageTime indica quanto uma linha pode permanecer após erro ou término. O contador volta a zero. Mesmo assim, a implementação pode remover uma linha terminada antes do valor anunciado acabar.

O row é cache de diagnóstico, não arquivo obrigatório. Se o pipeline deixar o GET para depois, a notificação pode sobreviver enquanto endereço retornado, erro e contexto desaparecem.

Por isso, ao observar estado terminal, copiar de imediato owner, grupo, índice, request parameters, oper status, erro, valores concedidos e timestamps. Guardar também storage type/time e a tentativa de coleta.

“Row not found” nunca deve ser promovido a “ação nunca ocorreu” sem outras evidências. Ausência tardia não corrige a história; apenas limita o que ainda pode ser provado.

Monitoramento composto precisa de janela

Uma lista de políticas pode demandar vários GETs. Enquanto o cliente lê, outra transação adiciona ou exclui regras. RFC 5190 admite essa perda de atomicidade e manda reconciliar eventos ou repetir.

O inventário precisa indicar início, fim, eventos intermediários e método de merge. Contagem sem janela mistura versões diferentes do middlebox.

Para liderança, isso muda a pergunta. Não é “quantas regras havia às 10:00?”, mas “qual conjunto foi observado entre 10:00:00 e 10:00:04, e quais eventos cruzaram a coleta?”.

Só então o número pode sustentar capacidade, auditoria ou resposta a incidente.

Objeto de evidência operacional

Fixar operation ID, middlebox, rule/group/interface, principal responsável e parâmetros pretendidos. Anexar cada SET com identidade, decisão VACM, varbinds, serial, response ou timeout.

Registrar a versão disparada e os estados checking/processing. Indicar se o terminal veio de trap ou poll. Preservar campos literais da notificação e GETs complementares como observações separadas.

Copiar o row antes do fim da retenção. Guardar concorrência e reconciliação. Finalmente ligar o estado local a recursos NAT/firewall, packet captures, recibo remoto e resultado da aplicação.

Uma regra pode ser tecnicamente bem formada e ainda não ter um autor único. A governança começa quando o sistema consegue mostrar essa diferença, em vez de escondê-la atrás de identidades válidas.

Fontes

  1. RFC 5190 HTML
  2. RFC 5190 texto
  3. Registro RFC 5190
  4. Datatracker RFC 5190
  5. Histórico RFC 5190
  6. Referências RFC 5190
  7. Errata RFC 5190
  8. RFC 5189
  9. Registro RFC 5189
  10. RFC 3416
  11. RFC 3418
  12. RFC 3414
  13. RFC 3415
  14. RFC 2578
  15. RFC 2579
  16. RFC 2580
  17. RFC 3304
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy