Resumen

  • Un agente SNMP podía describir varias entidades lógicas y numerosos componentes físicos; el mismo número podía designar cosas distintas según el ámbito.
  • Las tablas de contención, mapeo y alias permitían reconstruir la referencia, pero no demostraban propiedad, cercanía, cobertura total ni acuerdo entre agentes.

El error no empieza cuando un índice es falso. Empieza cuando un índice correcto sale de su ámbito y la base de datos lo presenta como si fuera un nombre global.

RFC 2037 describía un router presente en dos sistemas autónomos, cada uno con su área troncal OSPF 0.0.0.0. También contemplaba un chasis con varios routers, puentes o repetidores lógicos detrás de un único punto de gestión. En ambos casos podían repetirse objetos e índices sin referirse a la misma realidad.

El ámbito no era metadato opcional

El RFC denominó ámbito de nombres al conjunto de información accesible en una operación y regido por un espacio único de identificadores. En SNMPv1 y SNMPv2c, entLogicalCommunity señalaba la comunidad con la que se accedía al ámbito de una entidad lógica.

Por eso, dos apariciones de ifIndex.5 no bastaban para deducir una interfaz común. La observación completa incluía agente, momento, comunidad e índice lógico. Quitar esos datos dejaba el número, pero destruía su dirección.

La tabla lógica tampoco certificaba relaciones administrativas. Compartir una comunidad no implicaba administración compartida. La fila no distinguía entre una entidad local y otra alcanzada por proxy, ni convertía a la Entity MIB en gestora de los propios ámbitos.

El hueco vacío también formaba parte del chasis

La tabla física construía una jerarquía con entPhysicalContainedIn. Desde un puerto se podía subir al módulo, al hueco y al chasis, hasta alcanzar el índice cero. Los contenedores debían aparecer tanto ocupados como vacíos.

Así, un hueco sin módulo era diferente de un hueco no modelado. El primero expresaba una ausencia dentro de una estructura conocida. El segundo podía ser una limitación del agente, una vista anticuada o una parte no expuesta. Ninguno de esos registros, sin otra prueba, equivalía a una inspección física certificada.

Lo lógico y lo físico se cruzaban en muchos puntos

entLPMappingTable admitía una relación de muchos a muchos. Una entidad lógica podía depender de varios componentes y un componente podía dar soporte a varias entidades lógicas. La fila describía soporte operativo; no otorgaba propiedad exclusiva, control administrativo, responsabilidad presupuestaria ni autoridad legal.

La selección del componente tenía consecuencias. En un concentrador cuyos puertos podían cambiar de repetidor, resumir varios enlaces de puerto en un solo enlace de módulo borraba la capacidad que realmente se administraba. Una fotografía más corta podía ser también una fotografía menos fiel.

El alias cerraba la referencia

entAliasMappingTable enlazaba entidad lógica, componente físico e identificador de otra MIB. Solo esa combinación permitía afirmar que un ifIndex concreto correspondía a una pieza concreta dentro de un ámbito concreto.

El índice lógico cero funcionaba como comodín para casos sin una asignación más específica. No proclamaba una identidad global: era una regla predeterminada en la vista de ese agente. Y una tabla de alias vacía solo decía que no se exponían alias, no que no existiera ninguna relación operativa.

Cada agente podía recortar el sistema de otra manera

Dos agentes podían cubrir partes solapadas del mismo equipo sin producir instancias equivalentes. Los índices arbitrarios y los identificadores de fabricante podían variar; también podía variar el subconjunto visible. El RFC no exigía coherencia cruzada.

La reconciliación necesitaba, por tanto, datos ajenos al índice: número de serie, topología, registros operativos u otra unión validada. Un número coincidente no probaba identidad y una descripción divergente no probaba que una de las dos fuera errónea.

En RFC 2037, todos los objetos accesibles del módulo eran de solo lectura. Eso delimitaba un instrumento de observación, no una autoridad operativa. Una lectura no demostraba alcance completo, disponibilidad actual, intención de despliegue ni control administrativo. RFC 2737 incorporó después contextos SNMPv3 y objetos administrativos modificables; RFC 4133 y RFC 6933 continuaron la sucesión. Esas capacidades posteriores no deben atribuirse a la versión de 1996.

Fuentes