El contador subió; la causa no: RFC 2358 y Fast Ethernet

Resumen

• RFC 2358 amplió la MIB de interfaces Ethernet para 100 Mb/s, conservando un tipo común y uniendo la tabla específica del medio con el índice general de interfaz.
• Los objetos medían eventos acotados, no culpables: capacidad, velocidad, dúplex, errores, época del contador y reparación seguían siendo pruebas separadas.

Fast Ethernet no era únicamente el mismo cable con una cifra mayor en la pantalla. A 100 Mb/s aparecían nuevas exigencias de conformidad y de señalización, mientras que las aplicaciones de gestión necesitaban conservar la continuidad con los puertos de 10 Mb/s. RFC 2358, publicado en junio de 1998, resolvió esa tensión mediante una arquitectura de observación: una identidad estable, propiedades separadas y contadores cuyo significado dependía de reglas explícitas.

El documento, de la vía de estándares, sustituyó a RFC 1650 e incorporó información útil para administrar interfaces de 100 Mb/s. También reconoció que era una fotografía temporal. RFC 2665 lo dejó obsoleto en 1999 al añadir gigabit y dúplex completo; RFC 3635 llevó después la familia a 10 Gb/s. Por eso RFC 2358 no debe presentarse como la MIB vigente, sino como la capa histórica en la que Fast Ethernet obligó a revisar qué podía decir un instrumento.

La continuidad empezaba por ifType. El texto recomendó ethernetCsmacd(6) para todas las interfaces semejantes a Ethernet, sin importar la velocidad. Los tipos fastEther(62) y fastEtherFX(69) no debían sustituir esa identidad. ifSpeed indicaba la velocidad operativa; ifMauType, en la MIB MAU 802.3, aportaba el tipo de medio y el modo dúplex. La clase no tenía que fragmentarse cada vez que aumentaba la velocidad.

La separación evitaba una lectura seductora y falsa: una línea de 100 Mb/s en dúplex completo no debía publicar 200 Mb/s. La velocidad de línea y la posibilidad de transmitir en ambos sentidos eran propiedades distintas. RFC 2358 exigía la MIB MAU porque, sin ella, la aplicación no disponía de una forma estándar de conocer el dúplex. El tráfico observado no podía rellenar esa ausencia con certeza.

También distinguió capacidad y estado actual. Una interfaz capaz de 100 Mb/s tenía que implementar ether100MbsCompliance aunque en ese instante trabajara a menos velocidad. Los contadores exclusivos de 100 Mb/s podían no avanzar. La conformidad probaba una obligación del agente; no probaba la negociación actual, la carga, la ausencia de pérdida ni el funcionamiento del servicio.

dot3StatsIndex se vinculaba al mismo puerto que el ifIndex con igual valor. Gracias a esa unión, los contadores generales de paquetes y octetos podían leerse junto a las estadísticas de colisiones y errores del medio. Pero la unión también era una condición de validez. Si un reinicio reasignaba índices y el inventario no se actualizaba, un sistema podía atribuir una medida precisa al puerto equivocado.

La novedad más característica fue dot3StatsSymbolErrors. Contaba las ocasiones en que apareció un símbolo de datos inválido mientras había portadora válida. No contaba cada símbolo erróneo: avanzaba como máximo una vez por evento de portadora, incluso si en él aparecían varios símbolos malos. La unidad protegía la comparabilidad, pero castigaba las inferencias descuidadas. Un incremento no equivalía a un bit, una trama ni una interrupción visible para el usuario.

Los contadores de colisión mantenían límites similares. Una colisión tardía era la detectada después de 512 tiempos de bit; el RFC dio 51,2 microsegundos para 10 Mb/s. Las colisiones excesivas contaban tramas cuya transmisión fracasaba por demasiadas colisiones. Las transmisiones diferidas habían esperado porque el medio estaba ocupado y no incluían tramas que colisionaron. El histograma opcional agrupaba tramas por el número exacto de colisiones experimentadas.

Ningún nombre nombraba por sí solo la causa. Las colisiones tardías pueden acompañar un desacuerdo de dúplex o una topología fuera de límites; los errores FCS, de alineación y de símbolo pueden acompañar problemas de medio. La MIB no identificaba automáticamente el cable, el transceptor, el extremo remoto, el silicio o el controlador. Convertir compatibilidad en culpabilidad requería evidencia de ambos extremos y una prueba después del cambio.

El objeto dot3StatsInternalMacTransmitErrors lo decía de forma explícita. Reunía fallos internos de transmisión que no habían sido contados como colisiones tardías o excesivas ni como errores de detección de portadora, y su significado preciso era específico de la implementación. Era un cajón delimitado, no una explicación universal.

dot3StatsEtherChipSet ofrecía procedencia. Identificaba el chip que recogía estadísticas e indicaciones de error para que el gestor pudiera considerar anomalías conocidas. La procedencia del sensor ayuda a interpretar un testimonio; no convierte al sensor en causante del incidente. Un identificador de chip y una serie anómala podían justificar revisar erratas, no dictar un reemplazo automático.

Las convenciones de clasificación también limitaban las sumas. Si una trama recibida cumplía varias condiciones de error, se contabilizaba exclusivamente según el estado que el servicio MAC presentaba a su usuario. Los gráficos describían el resultado del clasificador, no todas las propiedades físicas simultáneas de cada trama.

Faltaba aún el tiempo. Los objetos eran Counter32; una diferencia útil necesitaba intervalo de sondeo y contexto de discontinuidad. Un reinicio, una puesta a cero o una reasignación de interfaz podía invalidar la resta. La MIB de interfaces aportaba esa época. Separar valor y época era tan importante como separar contador y causa.

Las pruebas activas tampoco ofrecían un oráculo. El RFC habló de bucle y reflectometría temporal mediante una ifTestTable ya desaprobada. Eran opcionales y muchos chips no las soportaban. El resultado de TDR no tenía un objeto estándar; debía aparecer en una MIB del fabricante. Invocar, completar, recuperar, interpretar y verificar una reparación eran actos distintos.

La seguridad cerró la misma lógica. Los objetos no eran de escritura ni de creación, de modo que SNMP SET no debía modificarlos. Sin embargo, la lectura podía revelar información sensible como el fabricante del chipset. SNMPv1 no era seguro por sí solo, y proteger la red con IPsec no definía quién podía hacer GET. El RFC recomendó los modelos de usuario y control de vistas de SNMPv3.

La cadena probatoria quedó así: equipo e interfaz; época; velocidad actual; capacidad; medio y dúplex; incrementos clasificados; instrumento; observación del par; hipótesis; intervención; verificación posterior. Que una línea esté probada no llena automáticamente la siguiente.