El radio de impacto
Todos los enlaces y todos los routers probados a la vez, y por qué la teoría de grafos lo reduce a 13 milisegundos
Michel Wijnberg
“¿Y si rompo esto?” es una pregunta sobre una cosa. La pregunta que un arquitecto necesita responder de verdad es la inversa, y es mucho más difícil:
De todo lo que hay en esta red, ¿qué partes importan?
No se llega ahí pinchando enlaces de uno en uno. El AS 200 de mi laboratorio tiene 275 enlaces y 64 routers. Probar cada fallo a mano son 339 experimentos, y hay que rehacerlos cada vez que cambia la topología.
Así que Osprey los hace todos a la vez. Lo que eso compra es una lista corta: de 339 cosas que pueden fallar, el puñado que de verdad le costaría algo. Esa es la diferencia entre una revisión de resiliencia que se planifica para el trimestre que viene y una que se ejecuta antes de aprobar un cambio.
Todos los enlaces, todos los routers, trece milisegundos
Lea la cabecera: “1 with impact in 13ms”, y debajo la explicación de qué se probó: “Links whose failure causes device isolation. Redundant links omitted.”
Se evaluaron todos los enlaces del inquilino. Exactamente uno de ellos,
mia1-cr1 ↔ mia1-gw1, aísla algo, y lo que aísla es un router: mia1-gw1. Cambie el
selector a Node Failures y la respuesta es la imagen especular: de 64 routers,
exactamente uno (mia1-cr1) deja incomunicado exactamente a otro.
Ese es el resultado que quiere un arquitecto: no una lista de 275 filas que leer, sino la afirmación de que 274 de ellas son demostrablemente irrelevantes.
La misma debilidad, encontrada tres veces, a través de tres protocolos
La vista estructural del mismo hecho vive en su propio informe:
64 dispositivos, 275 enlaces analizados, 1 punto de articulación (mia1-cr1,
172.16.4.31) y 1 enlace puente. Un punto de articulación es un vértice cuya
eliminación aumenta el número de componentes conexos: el nombre en teoría de grafos de
“si este router se muere, la red se parte”.
Aquí viene la parte que no planeé y que más me gusta. Ejecuté el mismo informe contra los otros dos inquilinos:
| Inquilino | IGP | Punto de articulación | Enlace puente |
|---|---|---|---|
| Harrier-Broadband | OSPFv2 | mia1-cr1 | mia1-cr1 ↔ mia1-gw1 |
| Kestrel-Dynamics | EIGRP | e-mia1-cr1 | e-mia1-cr1 ↔ e-mia1-gw1 |
| Merlin-Carrier | IS-IS | i-mia1-cr1 | i-mia1-cr1 ↔ i-mia1-gw1 |
Tres operadores. Tres IGP distintos. Tres caminos de descubrimiento completamente
separados: recorridos de la LSDB de OSPF, tablas de vecinos de CISCO-EIGRP-MIB, LSP de
IS-IS. La misma debilidad estructural en cada uno, en el mismo sitio.
La explicación honesta es que construí el laboratorio a partir de una plantilla y le di a
Miami una pasarela con una sola conexión tres veces. Pero eso es exactamente lo que lo
convierte en una comprobación útil: el mismo error físico, descrito a Osprey a través de
tres modelos de protocolo sin relación entre sí, produjo las mismas tres respuestas. Si la
extracción de topología de IS-IS tuviera un fallo, i-mia1-cr1 es donde habría aparecido
la discrepancia.
No sabía que eso estaba en el laboratorio hasta que la herramienta me lo dijo. Llevaba ahí semanas, en un laboratorio que construí precisamente para pillar cosas.
Esa es la parte que conviene separar de la teoría de grafos, porque la teoría es la mitad poco llamativa. Los puntos de articulación y los puentes están en los libros de texto, y cualquier herramienta puede calcularlos sobre cualquier dibujo. Lo que decide si la respuesta significa algo es qué son los vértices y las aristas. El grafo de Osprey no es un diagrama que alguien mantuvo: se reconstruye a partir de lo que los propios routers inundan, así que un puente en él es una afirmación sobre el reenvío y no sobre una imagen. Ejecute el mismo algoritmo sobre un fichero de Visio caducado y obtendrá las mismas formas y nada de la verdad.
Por qué la respuesta llega antes de que suelte el ratón
Trece milisegundos para 275 escenarios de fallo no es fruto de un paralelismo ingenioso. Es fruto de no hacer el trabajo.
Un enlace cuya eliminación desconecta un grafo es un puente: una arista que no está en ningún ciclo. El algoritmo de búsqueda de puentes de Tarjan los identifica todos en un solo recorrido en profundidad, O(V+E), para el grafo entero de una vez. Y un enlace que no es un puente no puede posiblemente aislar nada: por definición está en un ciclo, así que hay otro camino alrededor.
Así que la evaluación encuentra primero los puentes y solo simula esos:
// Precompute bridges in O(V+E). These are the only links that can
// cause unreachable devices when removed.
bridgeLinks := spf.FindBridges(baselineMerged)Después elimina una clase más. Si dos routers están unidos por varios enlaces en paralelo, ninguno de ellos puede ser un puente en el sentido que importa, porque si falla uno quedan los demás:
// Parallel links: if a device pair has multiple links, failing any one
// cannot disconnect them. Remove such links from the bridge set.274 enlaces quedan eliminados por un teorema y no por una comprobación de alcanzabilidad. Un enlace se simula. Ese es todo el truco, y es la razón por la que la respuesta llega antes de que haya soltado el ratón. En una red cien veces mayor sigue siendo un recorrido más un puñado de comprobaciones.
Aquí la teoría de grafos no es decoración. Es la diferencia entre un informe que se ejecuta y un informe que se ojea.
Qué significa “crítico” cuando nada es crítico
La pestaña Critical Pairs responde a una pregunta un paso más allá: qué dos enlaces, ninguno de los cuales es un punto único de fallo, son fatales juntos?
Esa es una clase de riesgo genuinamente desagradable. Ninguno de los dos enlaces aparece en ningún informe de SPOF. Ninguno por separado hace nada. Quite los dos (la misma canaleta, la misma tarjeta, la misma ventana de mantenimiento) y la red se parte.
Encontrarlos significa, para cada arista que no es puente, quitarla y volver a ejecutar la detección de puentes sobre lo que queda. Es O(L·(V+E)), y es lo más caro del informe.
En los tres inquilinos la respuesta es cero, y el panel lo dice con palabras:
No critical link pairs detected — your topology has good redundancy.
Un cero que ha costado trabajo real de calcular vale más que una lista larga. Este dice: no hay ningún par de enlaces en esta red cuya pérdida simultánea la particione, y eso se ha comprobado exhaustivamente en lugar de darse por supuesto.
El radio de impacto no es solo topología
La estructura es un tipo de dependencia. El otro tipo es la alcanzabilidad, y se mide en espacio de direcciones:
| AS par | Pares | Prefijos | Espacio IP | Equivalente CIDR |
|---|---|---|---|---|
| 100 | 2 | 3 | 131.328 | /15 |
| 300 | 2 | 3 | 131.074 | /15 |
Tres prefijos no suena a mucho hasta que se representa como 131.328 direcciones, equivalentes a un /15, alcanzables únicamente a través del AS 100. El recuento de prefijos es un indicador pésimo de la exposición (un /15 y un /32 cuentan los dos como “1”), así que el informe convierte a espacio de direcciones y de vuelta a un equivalente CIDR, que es la unidad en la que un arquitecto razona de verdad.
Junto a eso, el informe cruza cada par crítico de enlaces con los grupos SRLG a los que pertenecen sus miembros, de modo que dos enlaces que parecen independientes en el mapa pero comparten canaleta se reportan como correlacionados y no como diversos.
Lo que me lleva a la carencia que prefiero enunciar yo a que la descubra usted.
La parte honesta e inacabada
El soporte de SRLG de Osprey está completo en todas las direcciones menos una. Puede definir grupos, adjuntar enlaces, tirar un grupo entero como una única mutación de simulación y ver la correlación de riesgo compartido en el informe de dependencias. Lo que no puede hacer es descubrirlos.
Nada alimenta la tabla de SRLG. Todos los grupos se introducen a mano. Osprey almacena los sub-TLV de ingeniería de tráfico del RFC 5305 que ve en IS-IS como bytes en bruto, pero todavía no decodifica el sub-TLV de SRLG, así que una red que ya anuncia sus grupos de riesgo compartido en su IGP no obtiene ningún beneficio.
El consumidor se construyó antes que la fuente. Ese es el orden equivocado, está en la hoja de ruta, y hasta que se haga, la descripción honesta de la funcionalidad es “simulación de SRLG, a partir de los grupos que usted le indique”, no “descubrimiento de SRLG”.
Prefiero escribir esa frase a que alguien lo descubra durante una evaluación.
Por qué este es el informe que ejecutaría primero
Si mañana heredara una red, lo primero que querría no sería un mapa. Sería la respuesta a tres preguntas:
- ¿Qué fallos individuales aíslan algo de verdad? (Un enlace. Un router.)
- ¿Qué parejas de fallos lo hacen, sin que ningún informe de fallo individual lo muestre? (Ninguna: verificado, no supuesto.)
- ¿Cuánto espacio de direcciones hay detrás de cada dependencia externa? (Un /15 por AS par.)
Las tres son computables a partir de un modelo que ya es correcto, en bastante menos de un segundo, sin tocar un router. Ese es todo el argumento para haber dedicado cuatro entradas a acertar primero con el modelo: un modelo exacto no es el producto, es el sustrato sobre el que corren las preguntas útiles.
A continuación: el número que esta entrada ha esquivado en silencio. Cuánto tráfico se mueve realmente cuando ese enlace falla, y por qué mi laboratorio no puede decírmelo. Estimar lo que no se puede medir.