La red tiene memoria
Reconstruir lo que la red creía a las 14:02, y la diferencia entre lo que cambió y lo que usted averiguó
Michel Wijnberg
Todas las herramientas de esta serie responden, hasta ahora, a preguntas sobre el ahora. Ese es el tiempo verbal equivocado para los dos momentos en que un ingeniero más necesita ayuda.
El primero es durante un incidente: la red se está portando mal, y lo que necesita no es su estado actual sino su estado de hace veinte minutos, antes de que alguien empezara a arreglar cosas. El segundo es después: la red vuelve a estar bien, todo el mundo tiene una teoría, y nadie puede producir la topología tal y como estaba cuando se rompió.
La respuesta de Osprey es un reloj.
Eso no es la reproducción de una grabación. Cada elemento de ese lienzo se reconstruyó
para una marca de tiempo: los dispositivos, los enlaces, sus costes y estados, las
pertenencias a áreas. El deslizador de debajo dice Jul 29, 14:02 y (30/36): el
trigésimo de treinta y seis estados de topología distintos en la ventana de 24 horas
seleccionada.
Cada punto de esa pista es un momento en el que la red era genuinamente distinta.
Toda herramienta de monitorización guarda historia, así que esa frase necesita un filo más afilado. Lo que guardan son mediciones: la CPU estaba al 83 %, la interfaz hacía 4 Gbit, el sondeo funcionó. Son lecturas tomadas del rojo, y a las 14:02 le dicen que un equipo estaba ocupado. No pueden decirle qué creía. Lo que Osprey guarda es estado: qué adyacencias existían, qué rutas estaban instaladas y con qué métrica, a qué áreas pertenecía un router, qué caminos BGP estaban seleccionados y por qué. La diferencia aparece en cuanto usted hace una pregunta de verdad. Una historia de mediciones puede decirle que un enlace estaba saturado a las 14:02. Una historia de estado puede decirle que estaba saturado porque un ABR había retirado un summary cuatro minutos antes y media región tomaba de pronto el camino largo. Lo uno es un síntoma con marca de tiempo. Lo otro es el propio razonamiento de la red, conservado.
Instantáneas que solo existen cuando pasó algo
La implementación ingenua escribe una instantánea con un temporizador. Cada cinco minutos, se vuelca la topología. Es sencillo, y produce una base de datos llena mayormente de copias idénticas más un límite de resolución más allá del cual no se ve.
Osprey escribe una instantánea cuando la topología cambia, y nunca en otro caso.
Todo evento de topología procedente de un colector se somete antes a un hash:
// computeTopologyHash computes an FNV-64a hash over the topology snapshot data.
// Uses addition accumulation of per-element hashes for order-independence.Los dispositivos aportan su router ID y sus bits ABR/ASBR, los enlaces aportan un par de routers normalizado en dirección más ambos costes y su estado, y las redes stub y las interfaces aportan los suyos. La acumulación es aditiva para que el hash no dependa del orden en que llegaron los elementos: dos colectores que informan de la misma área en secuencias distintas tienen que producir el mismo hash, o cada sondeo parecería un cambio.
El hash se compara con el último de esa área, en memoria. Igual: no se escribe nada. Distinto: se inserta una fila de instantánea.
El resultado es una línea temporal densa en información por construcción. Mi laboratorio ha producido en los últimos 30 días 478 instantáneas repartidas en 51 áreas: unas 16 al día en todo el conjunto, cada una de ellas una diferencia real. Los puntos del deslizador no son muestras. Son eventos.
También significa que un área estable puede pasar muchas horas sin una fila, y eso es correcto y no una laguna: no pasó nada, así que no hay nada que registrar. La instantánea más cercana anterior o igual a la marca de tiempo elegida es el estado en esa marca de tiempo.
El time travel no es una sola funcionalidad
El reloj es la parte visible. Lo que lo hace útil es que aproximadamente veinte endpoints
de la API aceptan el mismo parámetro at= y responden a fecha de ese momento: el grafo
de topología, el navegador de LSDB, el cálculo de caminos, los árboles SPF, las RIB por
router, las rutas interárea y externas, las entradas ASBR, las interfaces, las redes
stub, los pares BGP, los best-path de BGP, los caminos recibidos por par.
BGP recibe un tratamiento más fuerte que las instantáneas, porque BGP cambia mucho más a
menudo que la topología. Se almacena como un registro de cambios bitemporal: cada
best-path, cada sesión de par y (opcionalmente) cada entrada de RIB recibida es un
intervalo con un valid_from y un valid_to, donde un valid_to abierto significa
“todavía es cierto”. Hacer una pregunta a fecha T pasa entonces a ser un predicado en
lugar de una reconstrucción: valid_from <= T AND (valid_to IS NULL OR valid_to > T).
Dos detalles de ahí dentro son los que más costó acertar, y los dos van sobre no registrar cosas:
- El trasiego de intervalos se suprime mediante un hash de atributos que excluye deliberadamente la métrica del IGP y el dispositivo de siguiente salto resuelto. Esos cambian cada vez que el IGP reconverge, y si abrieran un intervalo nuevo, todos los prefijos BGP de la red parecerían dar un flap cada vez que se moviera el coste de un enlace sin relación alguna.
- Un par que se cae se registra como un hueco de monitorización, no como una retirada masiva. Cuando una sesión BMP se cae, el router no retiró cien mil prefijos. Simplemente dejaron de contármelos. Escribir eso como una retirada fabricaría el mayor evento de enrutamiento de la historia de la red cada vez que una sesión de monitorización tuviera un hipido.
Los dos son casos en los que la implementación fácil se inventa un evento. Una historia que se inventa eventos es peor que no tener historia, porque usted los va a investigar.
Simular en el pasado
Los dos modos se componen, y esto es lo que más me gusta del producto.
Puede entrar en time travel, colocar el reloj y entonces entrar en simulación. El
lienzo lleva una marca de agua SIMULATION @ <timestamp>, y el what-if se ejecuta contra
la topología tal y como existía en ese momento.
Lo que significa que la pregunta que puede hacer es:
¿Se habría sobrevivido a este fallo, dada la red tal y como estaba realmente a las 14:02?
No contra la topología de hoy, que desde entonces se ha reparado, re-metrizado y ampliado. Contra la que realmente había. Para el trabajo posterior a un incidente, esa es la diferencia entre una respuesta defendible y una plausible.
También respeta sus propios límites. El análisis de fallo de par BGP en un momento pasado exige que se hubiera registrado la historia completa de la RIB para ese ámbito; donde no la hubo, el resultado no es una aproximación silenciosa sino una omisión declarada:
BGP effects (peer failure, hot-potato exit shifts, BGP traffic) are not evaluated at this time: no full-RIB history (history_mode=‘full’) is recorded for the scope. Enable full history mode on a BMP target to time-travel BGP.
Ese mensaje nombra la entrada que falta y el ajuste que la proporcionaría. Es un mensaje sobre el que se puede actuar.
Lo que no está en el pasado, dicho en voz alta
Varias cosas genuinamente no tienen historia, y los endpoints que las tocan lo dicen en lugar de servir en silencio datos en vivo disfrazados de datos históricos.
Pida al navegador de LSDB un momento pasado y la respuesta lleva:
Topology and route LSAs reflect the selected time; LSA header metadata (age/seq/ checksum) is not historized and shows live values.
Pida un camino entre dominios en un momento pasado y, solo cuando la respuesta se apoyó realmente en evidencia en vivo, la explicación crece con pasos adicionales:
Time travel: L2 detail is live: L2/port annotations on this path reflect current LLDP/CDP wiring, not the selected time. L2 adjacency is not historized.
Time travel: entry resolved via current router-id: identity attributes (router-id, local address) are not historized and were borrowed from the live session record.
La condicionalidad importa. Un empalme demostrado enteramente a partir de la historia no lleva ninguna de las dos notas, así que las notas significan algo cuando sí aparecen. Un descargo genérico de “algunos datos pueden estar en vivo” en cada vista histórica sería técnicamente cierto, permanentemente ignorado e inútil.
Hay un límite más que voy a enunciar sin rodeos porque, si no, lo descubriría usted estando confuso: el coloreado de utilización de enlaces se apaga durante el time travel. El mapa de calor de tráfico se queda en blanco en lugar de mostrarle carga en vivo sobre una topología histórica. Ese es el comportamiento seguro, y es el equivocado. El blanco se lee como “no hay tráfico” cuando debería leerse como “no disponible en este momento”. El lector que lo arreglaría está planificado, no construido.
La diferencia entre lo que cambió y lo que usted averiguó
El time travel tiene un informe compañero: comparar dos momentos y listar las diferencias.
En las últimas 24 horas del AS 200: ningún dispositivo añadido, eliminado ni cambiado.
Ningún enlace añadido ni eliminado. Y 56 redes stub añadidas, todas ellas loopbacks
IPv6 /128.
Eso parece un cambio de red. No lo es.
Comprobé cuándo entraron esos 56 prefijos en la base de datos por primera vez, y todos
ellos llegaron entre las 10:00:49 y las 10:01:14 de esta mañana: una ventana de 25
segundos. Ninguna red reconfigura 56 loopbacks en 64 routers en 25 segundos. Lo que
pasó fue una pasada de descubrimiento: esos prefijos llevaban todo el tiempo en la base
de datos de OSPFv3, y este es el momento en que Osprey empezó a registrarlos.
Esta distinción merece un nombre, porque confundir ambas cosas manda a la gente a cazar un cambio que nunca ocurrió:
Un diff de topología le dice lo que el modelo averiguó. No es lo mismo que lo que hizo la red.
A veces coinciden: un enlace se cae, el modelo registra un enlace que se cae. A veces no, y la pista suele ser la forma de las marcas de tiempo: los cambios reales de red llegan con la temporización de la convergencia de protocolos, y los cambios de modelo llegan con la temporización de un ciclo de sondeo. Cincuenta y seis prefijos idénticos en 25 segundos es un ciclo de sondeo vestido de cambio.
Un producto de observabilidad que no pueda decirle cuál de las dos cosas está mirando acabará costándole una tarde a alguien. Osprey no lo etiqueta automáticamente. El diff muestra lo que registró el modelo, y el razonamiento de arriba es mío, no de la herramienta. Pero cada fila lleva las marcas de tiempo que usted necesita para decidirlo por su cuenta, que es el mínimo que creo que una herramienta honesta le debe.
Dónde termina esta serie
Tres series, y en realidad un solo argumento, alcanzado desde tres direcciones.
La Serie 1 iba sobre si el modelo es verdadero: modelar la red tal y como realmente es, observarla sin formar parte de ella, reproducir el reenvío salto a salto y negarse a adivinar.
La Serie 2 iba sobre si la evidencia es ordenable: sostener varias verdades a la vez, graduar fuentes contradictorias, encontrar tus propios errores antes que tus clientes.
La Serie 3 iba sobre lo que eso le compra: un modelo lo bastante correcto como para razonar con él. Rompa algo y vea qué pasa. Pregunte qué depende de qué. Estime lo que no puede medir, y diga que está estimando. Pregunte qué creía la red una hora antes de romperse.
Nada de eso funciona sobre un modelo en el que no confía. Cada negativa honesta de la Serie 1 y cada pieza graduada de evidencia de la Serie 2 existen para que las respuestas de la Serie 3 signifiquen algo: un what-if construido sobre una topología que es ficción en un 9 % no es una herramienta de planificación, es un generador de números aleatorios con un lienzo bonito.
La octava entrada le dio a ese argumento su forma más corta: un motor de topología es un compilador para el estado de una red: entrada desordenada y contradictoria, un modelo determinista a la salida, y los propios routers como oráculo. A los compiladores se les juzga por conformidad y no por plausibilidad, y cada negativa de estas doce entradas es lo que cuesta la conformidad en los casos en los que la respuesta no está disponible.
Acierte con el modelo. Diga cómo lo sabe. Y entonces, y solo entonces, empiece a hacerle preguntas.
La serie completa: La confianza: Tres IGP, un solo mapa · Huella cero · La verdad salto a salto · Lo que Osprey se niega a adivinar. Construir la verdad: El mismo router, tres verdades distintas · Cuando la red se contradice a sí misma · El día en que mi topología me mintió · Las pruebas unitarias de un ingeniero de redes. De ver a razonar: ¿Y si rompo esto? · El radio de impacto · Estimar lo que no se puede medir · esta misma.