Resumen

  • El conjunto de reglas activo decidía si un paquete se ignoraba, qué atributos se incorporaban, si se repetía la comparación con la dirección invertida y qué columnas terminarían en el archivo.
  • NeTraMet aceleraba esa selección compilando grupos de pruebas como búsquedas hash y guardando máscaras mediante índices de un byte; los límites de compilación también formaban parte del significado del registro.
  • La escasez cambiaba el alcance sin detener necesariamente el contador: por encima de HighWaterMark entraban reglas de reserva más gruesas, en FloodMark las reglas por defecto y, tras un reinicio, el sistema arrancaba igualmente por defecto.

Antes del contador había una pregunta

RFC 2123 apareció en marzo de 1997 como documento Informational. Recogía tres años de experiencia con la arquitectura de medición de flujos. La separación funcional era clara: el medidor observaba, el lector trasladaba datos, el gestor configuraba y las aplicaciones de análisis producían informes. NeTraMet encarnaba el medidor; NeMaC reunía gestión y lectura.

El archivo final no nacía directamente del cable. NeMaC descargaba un conjunto de reglas que el Packet Matching Engine aplicaba a cada paquete. Una regla podía comparar direcciones o tipos, copiar una característica al flujo, ignorar el paquete, saltar a otra rama o repetir el intento con origen y destino intercambiados. El propio archivo de reglas declaraba además el formato de columnas que el lector recogería.

Por eso «origen» no era siempre una constatación universal. Podía ser el extremo local, la pasarela elegida o el puerto conocido después de normalizar el sentido. Esa decisión facilitaba el análisis, pero debía acompañar a la cifra si la cifra iba a conservar su significado.

El registro del RFC Editor y el Datatracker de IETF mantienen el encuadre histórico: experiencia de implementación, no estándar de Internet ni certificación de todas las instalaciones. La consulta oficial de erratas de RFC 2123 no devuelve coincidencias hoy; eso no convierte cualquier inferencia posterior en correcta.

Lo descartado no dejó rastro de ausencia

El documento describe una optimización sencilla. Si las reglas sólo buscaban IP, no tenía sentido almacenar y procesar paquetes Novell o EtherTalk. NeTraMet examinaba el conjunto activo, deducía los Peer types de interés y abandonaba los demás después de identificarlos. Tampoco copiaba direcciones adyacentes que ninguna regla fuese a usar.

Así se liberaban ciclos y memoria. Al mismo tiempo, el archivo perdía la capacidad de responder preguntas no encargadas. Un total IP podía ser exacto dentro del filtro y, aun así, no demostrar que en el segmento no circularon otros protocolos. La arquitectura RFC 2063 buscaba precisamente acercar la reducción al punto de medida. El ahorro de datos no era un accidente posterior: era el diseño.

La optimización conservaba velocidad y recortaba contexto

Una clasificación podía contener centenares de comparaciones de redes. NeTraMet detectaba grupos que probaban el mismo atributo con la misma máscara y los convertía en tablas hash. El coste de construirlas se pagaba al activar el conjunto; el paquete recorría después una cadena corta. Un umbral fijado al compilar decidía cuándo convenía agrupar.

Las máscaras también ocupaban espacio. Para distinguir ceros reales de bits anulados, cada flujo necesitaba recordar la máscara aplicada. La versión documentada guardaba un índice de un byte en una tabla de máscaras, con un máximo de hasta 256 definido en compilación.

El resultado seguía siendo válido. Pero ya no podía interpretarse sin el programa ejecutable que lo había producido. Una dirección era la dirección después de la máscara; una clase era el recorrido por las reglas; una omisión podía haberse producido antes de la tabla de flujos. Eficiencia y procedencia eran inseparables.

La memoria llena rebajaba la resolución

La cantidad máxima de flujos se fijaba al iniciar NeTraMet. Un recolector incremental recuperaba registros inactivos cuando los lectores conocidos habían avanzado lo suficiente. Si la lectura no acompañaba el ritmo de creación, quedaba menos espacio para nuevos flujos.

Por encima de HighWaterMark, el medidor podía activar un conjunto de reserva. En Auckland se diseñaban reglas parecidas a las de producción pero con muchos menos atributos. Esa reducción permitió en ocasiones mantener el medidor durante uno o dos días tras caer un lector, de modo que después pudieran recuperarse totales acumulados.

Al alcanzar FloodMark, NeTraMet pasaba al conjunto por defecto. Era una defensa contra un recolector tan ocupado que dejase de responder al gestor. El texto cuenta que 65 % y 95 % funcionaban bien para sus marcas alta y de inundación; no los presenta como números seguros para cualquier equipo.

La continuidad operativa escondía así una discontinuidad semántica. Producción, reserva y defecto podían producir filas correctas, pero con diferente detalle y clasificación. Que el proceso no se detuviera no probaba que siguiese observando la misma realidad.

Reiniciar significaba volver primero al mínimo

Tras un fallo eléctrico, el medidor arrancaba con el conjunto 1 incorporado. NeMaC comparaba sysUptime a intervalos; si el nuevo valor era menor, detectaba el reinicio, descargaba las reglas de reserva y producción y solicitaba que esta última volviese a ejecutarse.

La configuración narrada usaba keepalive de cinco minutos y lectura cada quince. Podían perderse hasta cinco minutos antes de la descarga. Ese dato era una consecuencia del intervalo local, no un compromiso universal. Durante esa ventana, además, las reglas por defecto podían formular otra pregunta sobre los mismos paquetes.

Un contador que volvía a crecer no enlazaba por sí solo las dos épocas. Hacían falta el uptime, el momento de restauración y la identidad del conjunto ejecutado.

Un índice podía volver con otro flujo

Cuando el recolector liberaba una fila, FlowIndex se reutilizaba. RFC 2123 pedía unir FlowRuleSet, FlowIndex y StartTime para identificar un flujo. El índice aislado era una posición temporal, no una identidad.

La lectura por columnas tampoco congelaba toda la tabla. Una fila podía activarse cuando ya se habían leído columnas anteriores; NeMaC la dejaba para la siguiente pasada. El Meter MIB de RFC 2064 aportaba los objetos de control. La posterior arquitectura RFC 2722, de 1999, aclara otro momento histórico y no autoriza a atribuir sus mejoras a todos los despliegues de 1997.

Las cifras de rendimiento conservaban la misma frontera: unos 750 paquetes por segundo en un 286 a 10 MHz, 1.250 en un 386SX a 25 MHz y picos comunicados de 3.000 en un 486 a 40 MHz sin pérdida. Eran observaciones de hardware y carga concretos. No probaban cobertura, facturación, integridad ni confidencialidad universales; el propio RFC dejaba estas dos últimas a los protocolos de gestión y recogida.

El ensayo posterior de Lu Heng sobre primacía del código en ejecución ayuda a formular la pregunta correcta: ¿qué configuración se ejecutó realmente? La especificación inicial mínima evita convertir una elección local en mandato general. Las capas de realidad separan documento, código, registro y resultado. Son lentes posteriores, no pruebas de la intención del autor del RFC.

La aportación histórica de RFC 2123 fue mostrar la cadena completa. El gestor elegía la pregunta, el medidor proyectaba, la presión podía reducir detalle, el lector recogía una vista no atómica y el analista elaboraba la afirmación. La fila merecía confianza cuando esos eslabones seguían unidos; nunca porque fingiese ser una copia neutral del cable.

Fuentes