Resumen

  • RFC 2366 permitía eliminar una fila principal de cliente, MARS o MCS aunque las filas de circuitos virtuales asociadas todavía existieran o estuvieran en uso; la limpieza posterior era otra operación.
  • read-create era el acceso máximo del modelo, no la garantía de que todo agente conforme aceptara escrituras: la conformidad mínima podía ser de solo lectura y ningún contador, trampa o SET certificaba por sí solo el cierre o la entrega.

El operador envía una orden de borrado. La consola responde sin error. La fila del cliente desaparece. La tentación es leer ese vacío como una conclusión: ya no hay cliente, por lo tanto tampoco hay circuito.

RFC 2366 describió una realidad más difícil. marsClientRowStatus servía para crear, modificar y eliminar la fila de un cliente MARS. Para activarla debían estar configuradas sus columnas y existir la fila estadística correspondiente. Sin embargo, el texto permitía borrarla aun cuando una tabla asociada —citaba marsClientVcTable— conservara filas existentes o en uso.

Después del borrado, el agente o la estación de gestión debía, si era posible, usar SET para retirar las filas obsoletas. No era una transacción única. Primero desaparecía el padre; luego comenzaba una reconciliación cuyo resultado dependía de capacidades adicionales. Entre ambos actos, una fila hija podía representar un VC todavía activo, un VC ya cerrado o un residuo sin vigencia.

La regla se repetía para el servidor MARS y para el MCS. También sus filas principales podían eliminarse mientras las tablas de VC seguían pobladas o en uso. Esa repetición define el mecanismo propio de RFC 2366: el ciclo de vida del modelo de gestión no tenía por qué coincidir de forma atómica con el ciclo de vida de la red ATM.

RFC 2022 había definido el sistema subyacente. El MARS distribuía información de pertenencia a grupos dentro de un clúster. Un emisor podía levantar un circuito punto a multipunto hacia los receptores o entregar el tráfico a un MCS. RFC 2366 no trasladó esa maquinaria al gestor. Solo construyó una proyección consultable —y a veces modificable— de partes de ella.

La proyección separaba tres roles. El cliente tenía dirección ATM, MARS predeterminado, estado de registro, identificadores, temporizadores, bloques multicast, servidores de respaldo, circuitos y contadores. El MARS mostraba estado y prioridad, mapas de hosts y servidores, miembros registrados, VC y estadísticas. El MCS mantenía tablas paralelas de registro, respaldo, circuitos y actividad.

Cada tabla respondía una pregunta limitada. La lista de clientes registrados no era toda la configuración de cada cliente. Un mapa entre grupo y dirección ATM no era el circuito que transportaba datos. Una fila VC podía contener VPI/VCI, rango de grupos, parte remota, tipo PVC o SVC, función de control, temporizador, revalidación, encapsulado y MTU negociada. No demostraba que el conmutador mantuviera la conexión ni que un paquete alcanzara todas las hojas.

La procedencia de la fila también cambiaba la autoridad. Los mapas configurados podían administrarse. Los aprendidos dinámicamente no podían modificarse ni borrarse mediante el mismo RowStatus. Una fila VC podía pasar a fuera de servicio y editarse bajo ciertas reglas, pero una fila SVC no podía alterarse o eliminarse por esa vía. Ver un objeto no implicaba gobernarlo.

Los permisos del módulo contenían una segunda separación. Muchos objetos declaraban MAX-ACCESS read-create, lo que autorizaba al diseño a exponer creación y escritura. Pero las declaraciones de conformidad reducían el acceso mínimo a read-only y repetían que la escritura no era obligatoria.

RFC 1904 daba contenido a esa diferencia: cuando un objeto es realmente escribible, un SET debe poder influir razonablemente en la entidad administrada. Un agente de observación podía ser conforme sin aceptar esa responsabilidad. El permiso máximo de la gramática no era una ficha de capacidad del equipo concreto.

Y la capacidad tampoco era autoridad. Para interpretar un SET hacían falta la identidad autenticada, la vista VACM, la operación permitida, la respuesta del agente y la persistencia del cambio. Luego venían la señalización, el estado del conmutador, el tráfico y la recepción. Una respuesta SNMP satisfactoria pertenecía al inicio de esa cadena, no al final.

Los contadores acumulaban mensajes de control: solicitudes, altas, bajas, respuestas multipartes, rechazos, migraciones y expiraciones esperando el último MARS_MULTI. El MARS contaba además grupos con miembros o MCS registrados. Un número sin instante, línea base, reinicio e identidad de instancia era ambiguo. Incluso con ese contexto probaba actividad observada por un agente, no entrega.

Los estados aparentemente sencillos tampoco podían ampliarse sin evidencia. Un cliente podía figurar como registrado desde la perspectiva del agente. El MTU predeterminado podía diferir del negociado en un VC. HSN, CSN y SSN ayudaban a detectar mensajes perdidos o cambios de membresía, pero no describían el plano de datos. Una marsFaultTrap mostraba que el agente detectó una condición; faltaban todavía envío, recepción, diagnóstico, reparación y recuperación.

La sección de seguridad trataba la MIB como superficie de control. Permitir SET sin protección podía perjudicar la red. SNMPv1 no decidía quién tenía derecho a crear, cambiar o borrar objetos, aunque el transporte circulara por una red protegida. El RFC recomendaba el modelo de usuario y el control por vistas de SNMPv3 y advertía que hasta la lectura podía necesitar restricciones.

La lectura revelaba mucho: direcciones ATM, membresía, mapas, prioridades de respaldo, extremos de circuitos, MTU, temporizadores y fallos. Cifrado, autenticación, autorización de la vista y justificación del uso eran controles distintos.

Dos meses después apareció una lección en el propio nombre del módulo. RFC 2366 lo había situado bajo snmpModules. RFC 2417 lo declaró obsoleto por un error administrativo y lo volvió a enraizar en mib-2 57, conservando su semántica. El significado de las filas podía permanecer; la coordenada pública con la que otros sistemas las encontraban tenía que corregirse.

RFC 2366 no prometió una consola omnisciente. Dio un lenguaje común para observar y, donde estuviera implementado y autorizado, actuar. Su límite más valioso estaba en lo que no fusionó: fila principal, filas asociadas, señalización, circuito, tráfico y resultado. Borrar una de esas pruebas no borraba las demás.

Fuentes