¿Y si rompo esto?
Un modelo en el que confía solo merece la pena si puede hacerle preguntas que nunca le han hecho
Michel Wijnberg
Las ocho primeras entradas de esta serie trataban de acertar con el modelo: descubrir la red sin formar parte de ella, reproducir el reenvío salto a salto, negarse a adivinar y descubrir por las malas que mi propia herramienta estaba dibujando ficción.
Todo eso es preparación. Un modelo de red que es meramente exacto es una fotografía carísima. La razón para invertir ese esfuerzo es poder hacerle la pregunta que no se le puede hacer a la red real:
¿Y si rompo esto?
Esa pregunta decide las ventanas de mantenimiento. Alguien tiene que decir si sacar una tarjeta a las 03:00 es sobrevivible, y normalmente lo responde desde un modelo mental y el recuerdo de la última caída. Lo que viene a continuación no es interesante porque Osprey tenga un simulador. Es interesante porque el fallo ya no tiene que ocurrir antes de que se pueda razonar sobre él.
Siete cosas que puede cambiar
El modo de simulación de Osprey toma el modelo en vivo, lo clona, aplica mutaciones y recalcula. La lista completa de cosas que le dejará cambiar es corta, y esa brevedad es deliberada:
| Mutación | Qué hace |
|---|---|
link_failure | Tira un enlace |
node_failure | Tira un router |
cost_change | Recalibra la métrica de un enlace, ida y vuelta de forma independiente |
hypothetical_link | Añade un enlace que no existe, con un coste y una velocidad |
hypothetical_node | Añade un router que no existe |
srlg | Tira un grupo de riesgo compartido: una acción, N fallos de enlace correlacionados |
peer_failure | Tira una sesión BGP |
Cualquier otra cosa se rechaza con unknown mutation type. No hay mutación de
reestructuración de áreas, ni de redistribución, ni de fallo en cascada, porque no podía
implementar ninguna de ellas sin inventarme datos. Volveré a eso.
Un cable, y lo que la red hace al respecto
Aquí va uno real del laboratorio. nrt1-cr1 ↔ sea1-cr1 es un enlace transpacífico de
backbone en el AS 200, coste 10 bajo OSPFv2, uno de los 275 enlaces que Osprey mantiene
en las dos instancias OSPF de ese inquilino. Hice clic
derecho y elegí Simulate Failure:
Lea los tres números de arriba. Nada quedó inalcanzable. 56 caminos cambiaron. No apareció ningún punto único de fallo nuevo. Toda la evaluación tardó 57 ms del lado del servidor.
Ahora lea la cabecera Failed Links, porque está haciendo algo que la gente pasa por alto: 2 links. Hice clic en un cable y Osprey tiró dos enlaces, porque ese cable transporta OSPFv2 y OSPFv3 como dos instancias de protocolo independientes con dos costes independientes. Tirar el cable lo tira en ambas. Una herramienta que modela una arista por cable tiene que decidir cuál de sus dos vidas termina.
Lo interesante es el desglose de esos 56:
- 15 aumentaron: el camino se encareció.
sea1-cr1 → nrt1-cr1pasa de coste 1 a coste 11, el enlace directo sustituido por un camino de tres saltos. - 41 redirigidos: el camino cambió de saltos y el coste no se movió en absoluto.
Ese segundo número es el que merece que uno se quede mirándolo. Cuarenta y dos pares origen/destino tomaron una ruta distinta por la red y no pagaron nada por ello, porque ya había una alternativa de igual coste. Así es como se ve la redundancia cuando se expresa como medición en vez de como adjetivo. “Tenemos caminos diversos” es una afirmación. “41 de 56 pares afectados se redirigen con coste idéntico” es un número, y es el número que le dice si la ventana de mantenimiento tiene que ser a las 03:00.
Aquí no se tecleó nada en ningún router. El laboratorio no perdió un enlace. Se lo pregunté al modelo.
La negativa en lo alto de la pantalla
Ahora mire la banda ámbar de esa primera captura, porque es una admisión, y es la razón por la que me fío del resto del panel:
simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view
La tercera entrada sostenía que un corredor con raíz en el origen es el modelo equivocado del reenvío IP, respaldado por una medición: 360 de 2.839 pares de routers interárea tenían un corredor que contenía un salto que ningún paquete tomaría jamás. Sustituí ese motor por uno que recorre la tabla de rutas propia de cada router, y lo validé contra los 4.032 pares.
Y luego, en simulación, deliberadamente no lo uso.
La razón está en el código, y es la frase de la que estoy más orgulloso en este producto:
// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.Recorrer la tabla propia de cada router exige saber cuál sería la tabla de cada router después del cambio. En OSPF eso depende de los summary-LSA de tipo 3 que los ABR supervivientes volverían a originar: LSA que no existen, porque el fallo no ha ocurrido. Puedo adivinarlos. No puedo adivinarlos correctamente, y una cadena salto a salto construida sobre summaries adivinados llevaría toda la autoridad del motor validado y nada de la validación.
Así que ambos lados de la comparación se quedan en la proyección claramente etiquetada. La imagen del antes se empeora a propósito para que siga coincidiendo con la del después. Un “56 caminos cambiados” que en realidad es “36 cambios genuinos más 20 artefactos de que los dos lados usan motores distintos” no es un diff. Es ruido con un número encima.
EIGRP: el techo son mis datos, no el protocolo
Tire algo en el inquilino EIGRP y Osprey se detiene en lugar de proyectar:
the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.
EIGRP no tiene base de datos de estado de enlace contra la que recalcular. Lo que Osprey
tiene es la tabla de topología propia de cada router leída de CISCO-EIGRP-MIB, y esas doce
columnas llevan las distancias de DUAL (feasible distance, computed distance, reported
distance), no los componentes con los que se construyeron esas distancias.
Para recalcular DUAL tras un cambio hacen falta ancho de banda mínimo, retardo total,
fiabilidad, carga, MTU y recuento de saltos. Existen en el equipo; lo comprobé en
e-ams1-cr1 con show ip eigrp topology 10.64.0.0/15. Sencillamente no están en la tabla
MIB que Osprey lee.
Esa distinción está escrita en el comentario del código a propósito:
// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.Hay una diferencia real entre “este protocolo no se puede simular” y “actualmente no recojo las entradas”, y un producto que las confunde le está diciendo en voz baja que no se moleste en volver a preguntar. Este es un techo de recolección de datos, y es levantable. Cuando lo levante, el mensaje desaparecerá.
Debajo hay una regla más pequeña y más afilada. Si la mutación es una eliminación pura (un fallo de enlace o de nodo), y lo eliminado demostrablemente no está en la cadena observada, Osprey sigue mostrando la cadena real y dice por qué: “observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)”. Quitar capacidad en otro sitio nunca puede mejorar un camino de vector distancia que no la usaba. Pero un cambio de coste o un enlace nuevo sí pueden atraer un camino desde cualquier parte, así que esos siempre cuentan como que lo tocan. El motor se niega precisamente cuando tiene que hacerlo, no de forma categórica.
Lo que no está en la lista de mutaciones, y por qué
Las siete mutaciones son las que pude implementar sin fabricar entradas. Las que faltan, faltan por razones enunciadas:
- Reestructuración de áreas. Mover un ABR o redibujar una frontera de área cambia qué summary-LSA existen siquiera. Eso no es una mutación de la topología, es otra topología.
- Cambios de redistribución. Dependen de route-maps y prefix-lists sobre los que Osprey no tiene visibilidad. Estaría modelando una política que no puedo leer.
- Fallos en cascada. Predecir el segundo fallo exige dinámicas de colas y de TCP que una herramienta de topología no tiene por qué pretender modelar. Señale el riesgo; no prediga la cascada.
Cada una de ellas se demostraría de maravilla. Cada una sería un número sin nada detrás.
La cuestión
La simulación es donde un producto de topología o bien rentabiliza el trabajo de modelado o bien lo deja al descubierto. Todo atajo tomado en el modelo de datos aparece aquí como una respuesta segura y equivocada, porque un what-if no tiene verdad de referencia contra la que contrastarse. El fallo no ha ocurrido, así que nada puede contradecirle. Precisamente por eso es la funcionalidad en la que más vale la pena ser cuidadoso.
La versión honesta impresiona menos por captura de pantalla y resulta bastante más útil a las 03:00: siete cosas que puede cambiar, cuatro números que salen, y una banda que explica qué motor los produjo.
A continuación: falla un enlace, pero ¿qué partes de la red dependían realmente de él? El radio de impacto.