Resumen

  • La RFC 1516 permitía demorar brevemente el reinicio del repetidor para que saliera la respuesta SNMP; esa respuesta correspondía a la solicitud, no a la terminación física.
  • El autotest disruptivo no garantizaba el reenvío de paquetes, pero conservaba los contadores de gestión y el estado administrativo de los puertos.
  • La salud y el evento de finalización llegaban por registros posteriores, y aun así hacía falta una prueba independiente para declarar recuperado el servicio.

El acuse que no debía cerrar el caso

Al escribir reset(2) en rptrReset, una estación de gestión pedía al repetidor volver al estado START. La RFC 1516 autorizaba al agente a aplazar la acción durante un periodo corto, por ejemplo el tiempo necesario para transmitir la respuesta SNMP. La respuesta debía transmitirse en todo caso.

Por eso, recibir noError no significaba que el equipo ya hubiera terminado. Significaba que una respuesta del agente podía correlacionarse con la solicitud. El paso disruptivo venía después. Una automatización que cerrase el ticket en ese momento convertiría una propiedad del intercambio de control en un resultado del mundo físico.

La separación era importante porque el reinicio incluía un autotest disruptivo de naturaleza no especificada. No debía inyectar paquetes ni interferir con las funciones de gestión, pero los paquetes recibidos durante la prueba podían ser transferidos o no. El canal que contestaba la orden podía seguir funcionando mientras la entrega de tráfico quedaba fuera de garantía.

El objeto no guardaba el estado del trabajo

rptrReset no era una barra de progreso. Escribir reset(2) producía la acción; escribir noReset(1) no hacía nada; leer el objeto devolvía siempre noReset(1). Una lectura posterior idéntica podía corresponder a ningún reinicio, a uno solicitado o a uno ya concluido.

El historial tenía que vivir en otro lugar: solicitud, identificador, respuesta, tiempos y observaciones posteriores. Guardar solo el valor leído borraba la diferencia entre intención y ejecución.

La elección del nombre de la MIB también delimitaba el objeto. En 1993, “hub” y “concentrador” podían designar chasis con Ethernet, Token Ring, FDDI, puentes, routers y servidores de terminales. La norma decidió hablar de repetidores IEEE 802.3. No pretendía que su estado resumiera todo el producto comercial.

Reiniciar no autorizaba a olvidar

La acción no ponía a cero los contadores de gestión de la RFC ni modificaba portAdminStatus. Un puerto administrativamente deshabilitado debía seguir así. La información acumulada antes de la intervención seguía disponible después de que el hardware atravesara START y el autotest.

Esta persistencia fijaba dos límites. Un reinicio no debía utilizarse como excusa para borrar el rastro que permitiría evaluar su efecto. Pero un contador conservado tampoco demostraba qué ocurrió con cada paquete durante la prueba. Política, memoria y estado físico podían cruzar la misma frontera de formas distintas.

La consecuencia para un operador es concreta: comparar antes y después sin inventar una nueva época de contador; verificar que la configuración administrativa no cambió; y añadir una medición del servicio que la MIB no promete.

La finalización tenía otro mensaje

Después del autotest, el agente actualizaba rptrOperStatus y rptrHealthText y enviaba una trampa de salud. rptrResetEvent era una notificación distinta, enviada al completarse un reinicio iniciado por gestión. La respuesta del Set y el evento de finalización tenían dueños temporales diferentes.

Tampoco bastaba con esperar una sola trampa. Las notificaciones consecutivas de reset debían espaciarse al menos cinco segundos; las suprimidas se descartaban, no quedaban en cola. Si se reiniciaba el propio agente, la señal correspondiente era coldStart o warmStart, no rptrResetEvent. La ausencia del evento no era una prueba universal de ausencia de actividad.

El texto de salud era específico del agente, y una prueba no disruptiva podía devolver “okay” tras una prueba trivial. Estado saludable, finalización del reset y servicio útil seguían siendo afirmaciones separadas.

Una corrección deliberada del contrato

La RFC 1368 ya preservaba contadores y estado administrativo. La propia lista de cambios de RFC 1516 dice que se aclaró el breve retraso del reset y lo que debía ocurrir después del reset y el autotest. El orden respuesta-acción fue una precisión incorporada conscientemente.

La RFC 2108 sustituyó después aquella MIB por una versión SMIv2 que incorporó múltiples repetidores y 100 Mb/s. Aunque dejó obsoletos los escalares antiguos, conservó el mecanismo en rptrInfoReset: contestar, ejecutar, preservar gestión y notificar la finalización mediante rptrInfoResetEvent.

La RFC 1157 define cómo el identificador de solicitud enlaza una respuesta SNMP con una petición pendiente y cómo se forma la respuesta de un Set correcto. La RFC 1215 define la convención de las trampas. Ninguna convierte la correlación del mensaje en una prueba del resultado posterior.

Un expediente que no dependa de un botón verde

El registro mínimo conserva agente y objeto objetivo, valor solicitado, request ID, código de respuesta y horas de envío y recepción. Después añade inicio y final de la acción, continuidad de contadores, portAdminStatus, salud observada, notificación recibida y un canario de tráfico o aplicación.

Así pueden convivir frases exactas: “el agente aceptó el Set”, “el agente anunció que terminó el reset” y “el servicio volvió a responder”. Si solo la primera está disponible, las otras dos continúan abiertas.

Los ensayos de Heng Lu sobre la primacía del código en ejecución, la especificación inicial mínima y las capas de realidad explican la disciplina. La capa común debe ser pequeña y verificable; la implementación realiza el test, el operador autoriza la intervención y el tráfico observado decide qué consecuencia ocurrió.

Fuentes y límite de evidencia

El registro del RFC Editor, RFC 1516, RFC 1368, RFC 1157, RFC 1215 y RFC 2108 establecen la historia y la semántica. Los tres ensayos de Heng Lu aportan el marco editorial.

Las fuentes no demuestran un producto, despliegue, orden ejecutada, respuesta entregada, duración, trampa recibida, paquete reenviado, avería ni recuperación. La apertura es una reconstrucción lógica, no un incidente documentado.