Estimar lo que no se puede medir

Una matriz de tráfico deducida de los contadores de enlace, el colector de flujos que decidí no construir, y los límites honestos de mi propio laboratorio

22 de agosto de 2026 Michel Wijnberg

La entrada anterior se detuvo una pregunta antes, a propósito. Osprey puede decirle que tirar nrt1-cr1 ↔ sea1-cr1 cambia 56 caminos y no aísla a nadie. La pregunta que un operador hace a continuación es la que decide si el cambio es seguro:

¿Adónde va el tráfico, y se desborda algo?

Nadie aprueba un cambio solo con recuentos de caminos. El número que lo decide es la capacidad: si los enlaces que heredan el tráfico tienen sitio para él. Esta entrada trata de hasta dónde se puede llegar honestamente hacia ese número cuando nada en la red lo mide directamente, y de dónde esa respuesta deja de ser una en la que apoyarse.

Responderla exige saber cuánto tráfico fluye desde cada origen a cada destino: una matriz de tráfico. Casi nadie tiene una.

Lo que decidí no construir

La forma de manual de conseguir una matriz de tráfico es la exportación de flujos: NetFlow, sFlow, IPFIX. Los routers muestrean flujos, envían registros a un colector, y uno los agrega en demandas origen-destino.

Lo planifiqué. Hay un documento de diseño de 1.139 líneas en este repositorio para un colector de flujos con deduplicación consciente de la LSDB. Está marcado, en su propia primera línea:

Status: SHELVED (2026-03-12). Deferred indefinitely after cross-plan feasibility review.

con cinco razones declaradas. Las dos que realmente lo decidieron:

Volumen. De 70 a 220 GB por semana con 500 routers, aproximadamente cien veces todo el resto de la base de datos. PostgreSQL es el único almacén de datos de este producto, a propósito; tragarse una tubería de flujos significa o bien un segundo almacén o bien una base de datos que se cae.
Valor marginal. Alrededor del 80 % de la visibilidad práctica del tráfico ya estaba disponible a partir de los contadores de interfaz SNMP, que ya se estaban recogiendo.

Eso no es una imposibilidad técnica. Es un juicio de que el último 20 % cuesta un subsistema nuevo, una carga operativa nueva y una categoría de riesgo de almacenamiento, y no me pareció que valiera la pena. Hay gente razonable que discrepa; algunas redes necesitan flujos de verdad. Lo que importa aquí es que la decisión está escrita con su razonamiento, para que cualquiera que evalúe Osprey pueda comprobar si su situación se parece a la mía.

Así que: nada de registros de flujo. Lo que deja el problema interesante.

Deducir la matriz de lo que los enlaces admiten

Lo que Osprey sí tiene es la carga de todos los enlaces, medida como es debido: contadores ifHCInOctets / ifHCOutOctets de 64 bits, sondeados en un ciclo, diferenciados a bits por segundo, corregidos por desbordamiento y divididos por la velocidad de la interfaz para dar un porcentaje de utilización.

Eso es un conjunto de totales por enlace. Lo que uno quiere es un conjunto de demandas por pares. Recuperar lo segundo de lo primero es un problema inverso indeterminado: muchas matrices de tráfico distintas producen exactamente las mismas cargas de enlace. Tiene un enfoque bien conocido: Tomogravity (Zhang, Roughan et al., 2003).

Funciona en dos movimientos, y Osprey implementa ambos:

// computeTrafficEstimate estimates traffic redistribution after topology
// mutations using the gravity model (Zhang/Roughan et al., "Tomogravity" 2003).
//
// Without a full traffic demand matrix, per-pair demands are estimated using
// the gravity model: demand(i,j) ∝ V(i)·V(j)/V_total, where V(i) is the
// total traffic volume at device i (derived from SNMP interface utilization).
// These gravity demands are then calibrated against observed per-link loads
// so that the model's predictions match reality.

El paso de gravedad supone que el tráfico entre dos routers es proporcional al producto de cuánto transporta cada uno en total, la misma forma que la gravedad newtoniana, o que un modelo de comercio entre dos economías. Es un supuesto previo, no una medición, y se equivoca de formas concretas: no tiene ningún concepto de un par de vecinos con mucho trasiego ni de uno tranquilo.

El paso tomográfico es lo que lo hace utilizable. La conjetura gravitatoria se escala de modo que, cuando todas las demandas estimadas se encaminan por los caminos que el IGP realmente selecciona, las cargas por enlace resultantes coinciden con las cargas que fueron medidas. El supuesto previo queda corregido por la evidencia, y la evidencia es lo único aquí que no es una conjetura.

Entonces, y solo entonces, las demandas calibradas se vuelven a encaminar por los caminos posteriores al fallo (ponderadas por ECMP, de modo que un par cuyo tráfico se reparte en cuatro contribuye un cuarto a cada enlace), y la diferencia es la redistribución proyectada.

Tres decisiones deliberadamente poco impresionantes

Toda la ingeniería interesante de un estimador está en los sitios donde uno le impide ser confiado.

Calibrar globalmente, no por enlace. La versión tentadora calcula un factor de escala para cada enlace de forma independiente. Ajusta mejor los datos y es mucho peor:

// Compute a GLOBAL calibration factor: total observed bps / total gravity sum.
// Per-link calibration can amplify noise when gravitySumPerLink is small
// relative to observed traffic, producing extreme scaling factors that
// inflate per-pair demands unrealistically. Global calibration distributes
// the error uniformly, producing more stable and realistic results.

Un enlace tranquilo con una suma gravitatoria casi nula y un poco de tráfico medido produce un factor de escala enorme, que a su vez infla todos los pares que lo cruzan. El ajuste más fino le compra disparates ocasionales. Un único factor global reparte el error de forma pareja y nunca explota.

Limitar cualquier par al 5 % del volumen total. Un techo duro sobre qué porción de la red puede llegar a ser una demanda estimada, porque el modo de fallo de un problema inverso es que un par lo absorba todo.

Negarse a reportar cambios pequeños. Un desplazamiento proyectado menor del 0,5 % de la utilización del enlace se descarta, y un 0,1 % en la vía de los cambios de coste, que también lleva los enlaces y nodos hipotéticos y reparte finamente el efecto de un nuevo nodo de tránsito entre muchos enlaces. Por debajo de eso, el número es indistinguible del temblor de los contadores, e imprimirlo invita a alguien a actuar sobre ruido.

Cada una de esas decisiones hace que la salida parezca menos precisa. La precisión no es el objetivo; el objetivo es que un número mostrado en pantalla sea uno en el que se pueda apoyar.

Y ahora la parte en la que mi laboratorio no puede ayudarme

Todo lo de las ocho entradas anteriores se validó contra un laboratorio capaz de contradecirme. 4.032 pares de routers comprobados contra tablas de rutas reales. 360 corredores ficticios encontrados. Tres protocolos, tres caminos de descubrimiento, de acuerdo sobre el mismo punto único de fallo.

Para el tráfico, el laboratorio es casi inútil, y quiero ser exacto sobre por qué.

Los routers de este laboratorio no reenvían prácticamente nada. Ejecutan protocolos, intercambian LSA y actualizaciones BGP, y eso es esencialmente todo. Las mediciones:

Medición	Valor
Interfaces con datos de utilización	1.279
…por debajo del 0,05 % de utilización	1.241
Utilización más alta en cualquier sitio	0,431 %, en un puerto de 10 Mbps
Tasa de interfaz más alta en cualquier sitio	~43 kbps
Pico entre las 368 interfaces catalogadas a 10 Gbps	~24 kbps, es decir 0,00024 %

La consecuencia se ve en la captura de la simulación de la entrada anterior, si sabe dónde mirar. La cabecera de enlaces caídos dice “2 links, 6Kbps displaced”, seis kilobits, y el panel no muestra ninguna sección de Traffic Redistribution ni riesgo de congestión alguno. No porque el código no se ejecutara. Porque todos los desplazamientos proyectados quedaron por debajo de ese suelo de ruido del 0,5 % y fueron descartados correctamente.

La fontanería es verificablemente correcta: los contadores se leen, las tasas se diferencian, las demandas gravitatorias se forman, la calibración se ejecuta, la redistribución se calcula sobre los caminos ECMP posteriores al fallo, y el suelo de ruido rechaza lo que debe rechazar. Lo que el laboratorio no puede decirme es si la estimación es buena, porque validar un estimador exige una verdad de referencia contra la que comparar, y aquí verdad de referencia significa tráfico real con una matriz origen-destino conocida.

Un laboratorio sin tráfico no puede producir una. Añadir carga sintética tampoco lo arreglaría: estaría generando tráfico a partir de una matriz que yo mismo elegí, para luego felicitar al estimador por recuperar la matriz que acababa de darle. Eso no es validación, es una forma muy lenta de comprobar mi propia aritmética.

Entonces, ¿cuánto debería fiarse de ello?

Esta es la escalera honesta, en el orden en que los números se vuelven menos sólidos:

Utilización de enlace, en vivo e histórica: medida. Contadores de 64 bits, diferenciados, corregidos por desbordamiento, comprobados contra la velocidad de la interfaz. Esto son datos.
Qué caminos cambian tras una mutación: calculado a partir de la topología. Determinista, y la topología que hay debajo es la que se validó contra 4.032 pares de routers.
Cuánto tráfico se traslada a cada enlace: estimado, a partir de un supuesto previo gravitatorio corregido por cargas de enlace medidas. Útil en cuanto a dirección, calibrado contra evidencia real, y no una medición.

El peldaño 3 es genuinamente valioso. Es la diferencia entre “estos doce enlaces absorben el fallo” y “este único enlace absorbe la mayor parte y ya está al 70 %”. También es el único peldaño de toda esta serie junto al que no puedo poner un número de validación, y sería deshonesto presentarlo con la misma voz que “4.032 de 4.032”.

El producto sí traza esa línea donde puede. Cuando el tráfico de un par BGP tiene que derivarse de proporciones de recuento de prefijos en lugar de una interfaz SNMP emparejada, la fila lleva un tooltip que dice exactamente eso, “Traffic estimated from prefix count ratios (no SNMP interface match)”, junto a filas marcadas SNMP que vinieron de contadores. La misma tabla, graduada, que es el patrón en el que esta serie entera acaba aterrizando, y esta es la tercera vez que toma la misma forma. Un camino entre dominios gradúa sus segmentos resolved / inferred / opaque (la cuarta entrada); una anotación de puerto gradúa sus cuatro veredictos desde el hecho enunciado hasta la ambigüedad explícita (la sexta entrada); los tres peldaños de arriba gradúan un número de tráfico. Tres escaleras, un mismo hábito: donde la evidencia que sostiene una respuesta es desigual, gradúela en el sitio en lugar de emitir una única confianza para todo el conjunto.

Para qué sirve el laboratorio, dicho otra vez

La séptima entrada sostenía que el laboratorio no está para que Osprey quede bien, sino para demostrar que Osprey se equivoca. Esta entrada es el corolario que a nadie le gusta: un laboratorio solo puede refutar aquello que es capaz de ejercitar.

El mío es excepcionalmente bueno contradiciéndome sobre topología, semántica de protocolos y reenvío, porque tiene 192 routers reales con tablas de rutas reales que puedo leer y comparar. Es incapaz de contradecirme sobre tráfico, porque no transporta ninguno.

Saber en cuál de esas dos situaciones está uno, para cada número que imprime su producto, es la mayor parte de lo que separa una herramienta fiable de una meramente confiada. Sé exactamente qué afirmaciones de Osprey están respaldadas por medición, cuáles por cálculo sobre un modelo validado, y cuáles por un estimador en el que creo pero que no puedo demostrar aquí.

Esta entrada es la tercera categoría. Hay exactamente una, y ahora ya sabe dónde está.

A continuación, la última entrada de esta serie: el modelo es correcto, y además es un modelo del ahora. ¿Qué aspecto tenía la red una hora antes de romperse? La red tiene memoria.