Resumen

  • Cada MAU tenía un objeto de estado jabber, un contador de entradas en ese estado y un trap para avisar al gestor.
  • Los traps consecutivos debían guardar un intervalo mínimo de cinco segundos; por diseño, su secuencia no constituía un recuento exhaustivo de transiciones.
  • Un noJabber posterior no borraba el historial y un aumento del contador no demostraba que la condición siguiera activa.

El intervalo pertenecía al aviso

Supongamos que una MAU entra en jabber, vuelve a la normalidad y repite la transición cuatro segundos después. Es un caso lógico, no una avería documentada. El contador puede sumar dos; una consulta posterior puede leer noJabber; el canal de alertas, obligado a espaciar los traps, puede mostrar solo uno.

Las tres respuestas son compatibles. «Hay que mirar», «esto es lo que el agente ve ahora» y «tantas entradas se observaron durante esta época» son preguntas distintas. La RFC 1515 protegió esa diferencia en vez de comprimirla en una luz roja.

Una coordenada antes que un diagnóstico

Publicada en septiembre de 1993, la RFC 1515 definió objetos para gestionar las Medium Attachment Units de IEEE 802.3. La MAU conectaba el medio con un puerto de repetidor o con una interfaz semejante a Ethernet, y el MIB reservaba grupos básicos para ambos casos.

Una fila de repetidor se identificaba por grupo, puerto e índice de MAU. Una fila de interfaz compartía el ifIndex de MIB-II. Separar el valor de esas coordenadas convertía una observación física concreta en una afirmación vaga sobre «la red».

Disponibilidad del medio, estado administrativo y jabber tampoco eran sinónimos. Según el tipo, la disponibilidad podía expresar pérdida de enlace, poca luz, falta de bucle, fallo remoto o señal inválida. Esos datos podían correlacionarse, pero ninguno aportaba automáticamente la causa del otro.

El estado hablaba en presente

rpMauJabberState e ifMauJabberState admitían other, unknown, noJabber y jabbering. Durante la inicialización, unknown reconocía que el estado verdadero aún no se conocía. noJabber era normal; jabbering describía la condición actual.

La semántica terminaba ahí. No identificaba placa, cable o transmisor culpable; no medía duración, tramas perdidas o impacto; no probaba que el aviso llegara ni que una reparación surtiera efecto.

Para una MAU AUI, el agente debía devolver other y el contador de entradas permanecía en cero. Por tanto, cero podía ser una regla de aplicabilidad, no un certificado general de ausencia de problemas físicos.

El contador retenía los cruces

rpMauJabberingStateEnters e ifMauJabberingStateEnters sumaban entradas en jabbering. Un episodio largo podía valer uno y tres episodios breves, tres. La cifra no contaba segundos, mensajes, bytes, tramas ni usuarios.

También necesitaba una época. La sucesora RFC 3636 explicó que la reinicialización del sistema de gestión podía discontinuar el contador y relacionó los de interfaz con ifCounterDiscontinuityTime. Una base que guardara solo el último entero podía interpretar un reinicio como mejoría.

Estado y contador se complementaban sin reemplazarse. Un incremento seguido de noJabber permite afirmar que hubo una entrada y que ahora no se observa la condición. No permite deducir su duración ni atribuir una reparación.

El trap aceptaba perder detalle

La RFC definió traps separados para MAU de repetidor y de interfaz. Cada uno incluía su objeto de estado y se enviaba al entrar en jabber. A continuación aparecía la restricción decisiva: el agente debía dejar al menos cinco segundos entre traps consecutivos.

Era una defensa contra ráfagas en el plano de gestión. Precisamente por eso, la lista de mensajes recibidos no podía convertirse en lista completa de sucesos. La ausencia de un segundo trap dentro de la ventana no anulaba una segunda transición que el contador sí hubiera observado.

La RFC 1157 definía Trap-PDU aparte de las operaciones de petición y respuesta, con dirección del agente, identificadores, tiempo desde la última inicialización y variables. La RFC 1215 establecía la convención TRAP-TYPE. Esa estructura hacía interpretable el aviso; no garantizaba una cronología exhaustiva ni su recepción final.

El diseño sobrevivió a nuevas velocidades

La RFC 2239 sustituyó a RFC 1515 con un superconjunto para 100 Mb/s, autonegociación y conectores. La RFC 2668 amplió de nuevo el módulo. En 2003, RFC 3636 incorporó 10 Gb/s y dejó obsoletas RFC 2668 y RFC 1515.

En esa evolución permanecieron el estado, los contadores y la pausa de cinco segundos. La última especificación precisó además que varios tipos rápidos debían devolver cero en esos contadores. Añadir capacidades no convirtió la métrica antigua en un veredicto universal.

El registro útil conserva identidad y tipo de MAU, estado, contador, época, marca temporal del trap, hora de recepción e intervalo de consulta. Así puede decir «el contador aumentó dos y registramos un trap». No inventa «el puerto falló dos veces» si faltan causa y alcance.

Los textos de Lu Heng sobre primacía del código en ejecución, especificación inicial mínima y capas de realidad aportan la disciplina: el contrato común debe limitarse a hechos verificables. Un aviso puede iniciar una decisión local; no manda sobre la realidad que su propio canal descartó.

Fuentes y frontera probatoria

El expediente técnico usa la ficha de RFC 1515, RFC 1515, RFC 1157, RFC 1215, RFC 2239, RFC 2668 y RFC 3636. Demuestra semántica y linaje, no conformidad de productos actuales, frecuencia de despliegue, tasas de entrega, incidentes, pérdida de tráfico, daño físico o reparación.