Resumen

  • Anja Feldmann y otros cinco investigadores definieron la demanda como un volumen que entra por un enlace y se dirige a un conjunto de salidas posibles, separando el tráfico ofrecido de la ruta elegida en ese momento.
  • En la red IP de AT&T unieron NetFlow, tablas de reenvío, configuraciones y comprobaciones SNMP; la pérdida, la antigüedad de las instantáneas y la ambigüedad de entrada quedaron registradas en vez de desaparecer bajo un total.

En una pantalla de operaciones, el enlace rojo suele ganar la discusión. Tiene un porcentaje, una alarma y una ubicación. Sin embargo, ni siquiera un contador correcto puede decir qué demandas coinciden en ese punto. Tampoco puede predecir adónde se trasladará la carga si el operador cambia un peso OSPF o si BGP selecciona otra salida.

El trabajo conjunto de Anja Feldmann, Albert Greenberg, Carsten Lund, Nick Reingold, Jennifer Rexford y Fred True partió de esa diferencia. Su matriz de tráfico no era una lectura directa. Era el resultado de relacionar varias fuentes imperfectas para recuperar un objeto que ningún elemento de red contenía completo.

La carga pertenece al enlace. La demanda pertenece al tráfico que debe atravesar la red. Entre ambas están la topología y las decisiones de encaminamiento. Si una herramienta trata el resultado actual como si fuera la demanda, solo puede volver a representar el presente; no puede evaluar con rigor una configuración alternativa.

Una salida posible no es una ruta fija

Una matriz de extremo a extremo para cada pareja de direcciones habría tenido un tamaño desmesurado. Además, un solo proveedor no veía el recorrido completo de la mayor parte de las comunicaciones, que cruzaban varios dominios administrativos.

El equipo eligió una representación útil para el control que sí tenía. Cada demanda reunía un enlace de entrada, un volumen y el conjunto de enlaces de salida capaces de alcanzar el prefijo de destino. Era una relación de un punto a varios posibles. Una retirada BGP podía cambiar el conjunto; la ruta interna decidía qué miembro se usaba en ese instante.

Así, modificar OSPF no alteraba retroactivamente la demanda. Alteraba su asignación sobre los enlaces. NetScope, el sistema de ingeniería de tráfico desarrollado por cinco de los investigadores, aprovechaba esa separación para localizar un enlace cargado, identificar las demandas que lo atravesaban y ensayar una configuración en un entorno simulado.

La escala temporal también fue una decisión. Para planificar capacidad o reequilibrar rutas importaban intervalos de decenas de minutos, horas o días, no el orden de cada paquete. Los flujos se repartían en ventanas y se agregaban según la entrada y el conjunto de salidas.

El dato útil nacía de cuatro fuentes

En el caso ideal, cada entrada produciría estadísticas de flujo. El registro indicaba la interfaz, la dirección destino, el inicio, el fin y los bytes. Las tablas de reenvío relacionaban prefijos con salidas. Los archivos de configuración describían nombres, clases de enlace, capacidades, filtros y parámetros OSPF. El modelo de encaminamiento comprobaba qué trayectorias eran compatibles con todo ello.

La red operativa no permitía activar medición detallada en todos los accesos. Algunas plataformas carecían de la función y otras podían sufrir una carga excesiva. La alternativa fue observar principalmente los enlaces de peering, donde había routers capaces y pasaba buena parte del tráfico entre proveedores.

El ahorro tenía un precio conocido. El tráfico entre dos accesos del mismo proveedor podía no tocar ningún peering. Los flujos salientes se veían en la salida, no necesariamente en la entrada. El tránsito que recorría varios saltos podía generar un registro al entrar y otro al salir, por lo que había que reconocer el segundo para no duplicar el volumen.

Para inferir el origen de un flujo saliente, la dirección fuente se asociaba con uno o varios accesos de cliente. Luego se preguntaba al modelo si, con la topología y las rutas de aquella instantánea, cada candidato podría haber llegado a la interfaz donde el flujo fue observado. Un candidato imposible se eliminaba. Si quedaban varios, el cálculo conservaba esa pluralidad y repartía el volumen; si no quedaba ninguno, contabilizaba un fallo.

La matriz contenía así distintos grados de conocimiento. Haber visto la salida no equivalía a haber visto la entrada. Tener un candidato no equivalía a tener uno único. Una celda precisa sin esa etiqueta habría ofrecido más confianza que evidencia.

Una tubería de medición también se congestiona

NetFlow enviaba los registros por UDP a un colector. Durante los periodos más intensos, el enlace hacia ese servidor perdió hasta el 90 % de los paquetes de exportación. La serie recibida no se detenía; seguía pareciendo tráfico real, solo que incompleto. Ese tipo de fallo es especialmente peligroso porque produce datos verosímiles.

Los números de secuencia permitieron estudiar los huecos. Su distribución respaldaba una aproximación de pérdida independiente, y los investigadores calcularon una probabilidad por cada diez minutos. Con ella ajustaron los bytes observados. La corrección no reconstruyó cada flujo perdido: amplió una muestra bajo un supuesto estadístico explícito.

Los contadores SNMP ofrecieron una prueba separada. Medían el total de cada interfaz cada cinco minutos. Las utilizaciones derivadas de NetFlow, una vez corregidas, siguieron con bastante proximidad las curvas SNMP. El contador no aportaba la matriz de entrada y salida, pero sí podía rechazar una reconstrucción cuyo total fuera incompatible con el enlace.

Había además que unir identidades y tiempos. NetFlow usaba índices numéricos; configuración y reenvío hablaban de nombres y direcciones. Los relojes de algunas tarjetas no coincidían con el procesador de ruta. Cada fuente llegaba a horas distintas, de modo que una unión impecable podía mezclar estados que nunca coexistieron.

Eso ocurrió en una de las cuatro jornadas. Un enlace de acceso se había actualizado después de capturar su configuración, mientras una tabla posterior ya apuntaba al nuevo enlace. Los prefijos parecían huérfanos y aumentaron los fallos. Al reconciliar la sustitución real, la tasa regresó al rango normal. La anomalía no era ruido que convenía borrar: era la señal de que dos documentos describían versiones distintas del sistema.

La cifra de cobertura no resolvía la ambigüedad

En los cuatro experimentos de noviembre de 1999, más del 98 % de los bytes observados en los peerings solía encajar en una forma de demanda. Para el tráfico saliente se encontraba al menos una entrada candidata en más del 99,3 % de los bytes. Aun así, entre el 35 y el 45 % del volumen saliente comenzó con varias entradas posibles.

El modelo de rutas redujo ese conjunto. Aproximadamente entre una cuarta y una tercera parte del volumen ambiguo terminó asociado a una sola entrada. Cuando un cliente tenía dos accesos en la misma ciudad, ambos podían seguir recorridos casi idénticos y la distinción aportaba poco a la carga interna. Tras el proceso, cerca del 2,5–4 % de los bytes salientes continuó sin una demanda compatible.

Nada de ello es una referencia para una red actual. Son resultados de cuatro días de 1999. Lo relevante es la contabilidad de incertidumbre: una matriz puede cubrir casi todo el volumen y, al mismo tiempo, no conocer unívocamente la procedencia de una parte considerable.

El análisis encontró también una distribución concentrada: pocas demandas grandes reunían buena parte del tráfico. Sus patrones variaban con la hora, aunque algunas posiciones altas persistían de un día al siguiente. Esa estabilidad favorecía la medición selectiva. La concentración, sin embargo, hacía que un cambio de comportamiento o una ruta equivocada pudiera afectar de golpe a varios enlaces.

La matriz discutía con sus propias pruebas

La trayectoria de Feldmann une análisis, modelado y routing porque ninguno bastaba por separado. Un contador sin contexto describía un efecto. Un modelo sin tráfico medido calculaba para una red imaginaria. Una configuración sin sello temporal daba una explicación exacta de un pasado quizá irrepetible.

La matriz era provisional por diseño: tenía fecha, supuestos, correcciones, ambigüedades y residuos. Justamente por eso podía sostener una decisión mejor que una cifra más limpia. Permitía preguntar qué demanda había creado la carga, adónde podía moverse y qué parte de la respuesta procedía de una observación o de una inferencia.

La lección operativa no consiste en acumular más gráficos. Consiste en conservar la cadena: muestra bruta, pérdidas, instantánea de ruta, correspondencia de interfaces, candidatos descartados y comparación independiente. Un enlace rojo localiza el dolor. Solo una evidencia unida y discutible permite anticipar las consecuencias del remedio.

Fuentes