Resumo

  • A RFC 1215 usou TRAP-TYPE para mapear autoridade de registro, variáveis ordenadas, significado textual e um inteiro nos campos de um Trap-PDU SNMPv1. A expansão acontecia na implementação, não quando o evento ocorria.
  • A trap dizia o que a aplicação ou entidade emissora reconhecia. Sozinha, não comprovava falha física, causa, impacto sobre usuários nem identidade autenticada.
  • O SNMPv1 utilizava datagramas não confiáveis e deixava a seleção de destinos à implementação. Definição, reconhecimento, geração, envio, recepção, confirmação e ação eram registros diferentes.

O vocabulário ficava pronto antes do alarme

A passagem mais importante da RFC 1215 descreve tempo de construção, não tempo de falha: a macro TRAP-TYPE é expandida conceitualmente durante a implementação, e não em tempo de execução.

Assim, um módulo pode definir myLinkDown, ordenar objetos e redigir seu sentido quando nenhum enlace caiu. Um compilador pode aceitar o módulo; o gerente pode preparar uma tela. Tudo isso cria a gramática de uma mensagem futura, não uma observação.

A aparência induz ao atalho. A descrição fala em reconhecer uma falha. O inteiro parece código de incidente. A lista de objetos parece um conjunto de provas. Mas a definição é um formulário vazio. Ela orienta a leitura de uma instância que talvez nunca seja gerada.

O registro do RFC Editor data o texto de março de 1991 e o classifica como Informational. O IETF Datatracker preserva a mesma identidade. A própria RFC chama o uso de traps de controverso, o desaconselha fortemente e limita a macro à definição concisa de traps existentes.

Essa reserva não prova que traps não eram usadas. Ela impede transformar uma convenção informativa em padrão obrigatório ou aprovação irrestrita.

OID de empresa era registro, não assinatura

ENTERPRISE tinha presença obrigatória. A cláusula identificava a empresa de gestão sob cuja autoridade de registro a trap era definida e colocava o valor no campo enterprise do Trap-PDU.

O campo respondia onde a definição estava registrada. Não respondia qual pessoa ou processo enviou aquele datagrama, quem era o dono atual do equipamento nem quem podia autorizar uma mudança. No caso especial dos traps padrão, sysObjectID ocupava o campo. Isso ajudava a interpretar o objeto configurado; não autenticava o remetente.

A empresa que registrou o tipo, a empresa que depois comprou o produto, o integrador, o administrador local e o processo emissor podem ser atores distintos. Um OID não funde essas identidades.

A RFC 1215 informa apenas que questões de segurança não são discutidas. Não há base ali para supor autenticação de origem, integridade, sigilo ou proteção contra repetição.

Ordem obrigatória não significava dossiê completo

VARIABLES especificava a sequência ordenada de objetos MIB presentes em cada instância daquele tipo. O agente ainda podia anexar variáveis adicionais.

A definição fornecia, portanto, um núcleo esperado. Não continha os valores da ocorrência futura e não assegurava que toda informação operacional relevante estivesse no PDU. Objetos acrescentados também podiam exigir semântica própria.

Um ifIndex localiza uma interface na configuração. Ele não demonstra por si só cabo rompido, circuito indisponível, causa raiz ou perda de serviço.

DESCRIPTION enunciava o sentido do tipo. REFERENCE apontava para trap, evento ou alarme de outro módulo. Texto normativo e ligação documental não eram observadores independentes.

O inteiro da macro ia para specific-trap nas traps empresariais, com generic-trap ajustado para enterpriseSpecific(6). Na convenção snmp, ele ia para generic-trap e specific-trap ficava em zero. Era um número de namespace, não escala de gravidade, confiança, tempo, quantidade ou sequência.

O exemplo preservava o ponto de vista do emissor

A descrição de myLinkDown diz que a aplicação SNMP emissora reconhece uma falha em um enlace representado na configuração do agente. A frase não atribui onisciência à trap.

O reconhecimento pode vir de estado de driver, contador, limiar ou transição local. Ele não mede independentemente o meio físico, não identifica o responsável pelo circuito e não calcula impacto sobre clientes.

A RFC 1157 usa a mesma formulação para linkDown: a entidade emissora reconhece a falha. O primeiro vínculo de variável identifica o ifIndex afetado. O índice aponta para o registro, não para toda a cadeia causal.

O timestamp também tem escopo: mede o tempo desde a última reinicialização da entidade de rede até a geração da trap. A primeira manifestação, o reconhecimento, a geração, a partida e a chegada precisam de relógios separados.

A aplicação ainda precisava pedir a geração

Segundo a RFC 1157, a entidade de protocolo só gera o Trap-PDU quando a aplicação SNMP solicita. A escolha dos destinos depende da implementação.

Entre definição e envio existem políticas locais. A condição pode não ser reconhecida; a aplicação pode não solicitar geração; a emissão pode ser suprimida; o destino pode não estar configurado ou estar obsoleto; o receptor pode desconhecer a semântica empresarial.

O exemplo authenticationFailure torna o silêncio ambíguo. A implementação deve poder gerar a trap e também suprimir sua emissão por mecanismo próprio. Ausência não comprova ausência de falha. Pode representar não reconhecimento, supressão, endereço errado, perda ou falta de processamento.

UDP 162 indicava onde tentar entregar

O SNMPv1 precisava apenas de um serviço de datagramas não confiável. Cada mensagem seguia em um datagrama, e traps deveriam chegar à porta UDP 162 para processamento posterior.

A porta não provava ouvinte, passagem por firewall, espaço de buffer, interpretação correta, persistência ou atenção humana. Uma emissão registrava tentativa; não registrava recepção.

Ao receber um Trap-PDU, a entidade de protocolo apresentava o conteúdo à aplicação SNMP. Esse é um estado receptor concreto, mas ainda anterior a correlação, ticket, decisão, mudança e recuperação.

A evolução posterior reforçou a diferença. RFC 2578 situa a RFC 1215 no SMIv1 e usa NOTIFICATION-TYPE para definir sintaxe e semântica de notificações SMIv2. Uma definição mais nova continuava sendo definição.

A RFC 3416 diz que SNMPv2-Trap não tem confirmação associada à entrega. InformRequest é confirmado, mas nem ele garante entrega. Depois da recepção, o destinatário apresenta o conteúdo e envia um Response-PDU.

A resposta comprova melhor uma troca protocolar. Não valida de forma independente a condição, não comprova concordância do operador e não demonstra reparo.

Uma trap útil mantinha seus custodiantes visíveis

Autor do módulo, autoridade de registro, aplicação do agente, entidade de protocolo, configuração, rede, receptor e operador controlavam partes distintas. RFC 1215 lhes deu uma linguagem comum, não um único poder.

Preservar essa cadeia permite correlacionar a trap com sondagem, contadores, roteamento e testes do serviço. Apagá-la transforma uma afirmação local bem formatada em veredicto universal.

Fontes