Resumo

  • Um único agente SNMP podia representar várias entidades lógicas e uma árvore de componentes físicos; números iguais podiam ter sentidos diferentes em escopos diferentes.
  • Mapeamentos tornavam a referência rastreável, mas não comprovavam propriedade, localidade, completude nem equivalência entre agentes.

Imagine dois roteadores lógicos que apresentam ifIndex.5. A coincidência parece uma chave de junção. Na RFC 2037, ela era um aviso: antes de juntar, era preciso saber em qual espaço de nomes cada 5 havia sido emitido.

O documento aceitava que um único equipamento reunisse várias entidades lógicas. Um roteador poderia participar de dois sistemas autônomos e ter uma área OSPF 0.0.0.0 em cada um. Um chassi também poderia abrigar repetidores, bridges e roteadores lógicos diferentes sob o mesmo agente.

O escopo era parte da chave

A RFC chamou de escopo de nomes o conjunto de informações acessível em uma operação e submetido a um espaço único de identificadores. Em SNMPv1 e SNMPv2c, entLogicalCommunity indicava a comunidade usada para acessar o escopo da entidade lógica.

Isso não fazia da community uma certidão de autoridade. Entidades que compartilhavam o mesmo valor não ganhavam uma relação administrativa implícita. A linha também não dizia se a entidade existia localmente ou era alcançada por proxy. E a própria gestão dos escopos ficava fora da Entity MIB.

Uma evidência defensável precisava guardar agente, horário, community e índice lógico. “Interface 5” não bastava.

Um slot vazio continuava visível

entPhysicalContainedIn ligava cada componente ao contêiner imediato, formando uma árvore que terminava no índice zero. Chassi, slots, módulos e portas podiam aparecer em níveis separados. Os contêineres tinham de ser representados tanto vazios quanto ocupados.

A regra separava duas situações: um slot conhecido sem módulo e um slot que o agente não modelou. Só a primeira era uma ausência explícita. A segunda podia resultar de suporte incompleto, informação antiga ou escolha de cobertura. Ainda assim, a tabela continuava sendo o modelo do agente, não prova de inspeção física ou inventário completo.

O mapeamento de suporte era muitos-para-muitos

entLPMappingTable conectava entidades lógicas aos componentes físicos que as sustentavam. Uma entidade lógica podia usar várias peças, e uma peça podia ser compartilhada por várias entidades. Não havia base para ler a relação como propriedade exclusiva, controle administrativo, locação ou responsabilidade jurídica.

O nível do mapeamento também importava. Em um hub com portas comutáveis entre repetidores, substituir vários vínculos de porta por um vínculo do módulo escondia a superfície que poderia mudar. Uma simplificação visual eliminaria informação operacional.

O alias dava corpo ao índice externo

entAliasMappingTable unia uma entidade lógica, um componente físico e um identificador de outra MIB, como ifIndex. O índice lógico selecionava o escopo; o físico apontava a peça; o alias trazia o objeto externo.

O índice lógico zero funcionava como curinga quando não existia uma regra específica. Era um padrão dentro da visão do agente, não uma igualdade universal. A ausência de alias, por sua vez, significava apenas que nenhum alias era exposto.

Agentes diferentes podiam discordar sem violar o RFC

Instâncias sobrepostas da Entity MIB não precisavam ser equivalentes ou consistentes. Agentes distintos podiam escolher índices arbitrários, identificadores de fornecedor e subconjuntos diferentes. Assim, a igualdade de índices não comprovava identidade entre agentes, e uma descrição divergente não comprovava erro.

Reconciliação exigia evidência adicional, como serial, topologia ou registro operacional, com a confiança dessa união declarada. O mesmo vale para mudanças ao longo do tempo: um aviso de alteração não explica motivo, autorização ou completude.

Na RFC 2037, todos os objetos acessíveis definidos pelo módulo eram somente leitura. Uma consulta bem-sucedida provava uma resposta de um agente naquele escopo e instante; não provava disponibilidade, implantação, autoridade ou impacto. A RFC 2737 acrescentou mais tarde contexto SNMPv3 e objetos administrativos graváveis, antes das revisões RFC 4133 e RFC 6933. Essas novidades pertencem aos sucessores, não ao texto de 1996.

Fontes