Tres IGP, un solo mapa
Qué aspecto tienen 192 routers, tres operadores y tres protocolos de enrutamiento en una sola pantalla
Michel Wijnberg
Tengo un laboratorio. No es un diagrama y no es un simulador. Son 192 routers reales con pilas de protocolo reales, y lo uso a diario para construir Osprey frente a algo que puede contradecirme de verdad.
El laboratorio es incómodo a propósito. Alberga tres operadores que no comparten nada:
| Inquilino | ASN | IGP | Forma |
|---|---|---|---|
| Harrier-Broadband | 200 | OSPFv2 y OSPFv3 | 15 áreas por protocolo, doble pila sobre los mismos enlaces |
| Kestrel-Dynamics | 100 | EIGRP, IPv4 + IPv6 | plano, porque EIGRP no tiene áreas |
| Merlin-Carrier | 300 | IS-IS, multi-AF | 17 áreas de nivel 1 bajo un backbone de nivel 2 |
Tres protocolos, tres planes de direccionamiento, tres ASN, tres juegos de credenciales. Ningún IGP compartido en ninguna parte. Es más o menos el peor caso que se le puede poner delante a una herramienta de topología, que es exactamente por lo que lo construí.
Todo lo que viene a continuación es una captura de ese laboratorio, tomada en directo mientras escribía esta entrada. Nada está recreado.
Por qué la jerarquía va antes que la imagen
La mayoría de las herramientas de topología empiezan por un lienzo y le atornillan la estructura después. Eso funciona hasta que el mismo router físico pertenece legítimamente a dos respuestas distintas a la vez. En una red de operador, eso es un martes cualquiera.
Osprey lo invierte. Cada objeto cuelga de una jerarquía explícita:
Network → Autonomous System → Routing Domain → Protocol Instance → Area → DeviceEsa cadena no es decoración. Es lo que permite al producto responder “qué proceso OSPF, en qué VRF, en qué AS, bajo qué inquilino” sin adivinar, y es la razón por la que un dispositivo puede ser ABR en una instancia y un router interno corriente en otra sin que el modelo se enrede consigo mismo.
Fíjese en lo que muestra la barra lateral: OSPF 1 y OSPFv3 1 (v6) son instancias de protocolo separadas, cada una con su propio conjunto de 15 áreas, su propia LSDB y su propio SPF. Circulan por los mismos enlaces físicos. No se fusionan en una sola abstracción “IGP” bienintencionada, porque de verdad no son una única cosa. El RFC 5340 le da a OSPFv3 su propia LSDB y su propia topología, y fingir lo contrario produce respuestas erróneas en cuanto ambos discrepan.
Harrier-Broadband: OSPF, 15 áreas, doble pila
Este es el AS 200, coloreado por área:
64 routers, 151 enlaces, 30 áreas (15 en OSPFv2, 15 en OSPFv3). La masa azul del centro es el área 0.0.0.0, el backbone. Cada grupo de color que cuelga de ella es un área no troncal que alcanza el backbone a través de sus ABR.
A este tamaño la imagen todavía se lee. Con cinco veces este tamaño ya no, y por eso la misma topología puede colapsarse en sus áreas:
Cada nube es un área; cada línea es un haz de adyacencias interárea con el recuento
encima (4×, 8×, 2×). Esta es la vista que uso realmente para responder “¿qué
mal conectada está el área 19.5.1.0 con el backbone?”. Aquí la respuesta es “por
cuatro enlaces”, un perfil de riesgo muy distinto al de las áreas de dos enlaces
que tiene al lado.
Merlin-Carrier: IS-IS, y la familia de direcciones sí importa
El AS 300 ejecuta IS-IS. La misma forma física, un modelo de protocolo completamente distinto:
IS-IS es donde muchas herramientas se caen en silencio, porque IS-IS no es “OSPF con otras palabras”. Una sola LSDB de IS-IS puede transportar alcanzabilidad de CLNS, IPv4 e IPv6 a la vez, y el camino más corto correcto es por familia de direcciones.
Así que Osprey lo calcula por familia de direcciones, y le dice cuál está mirando:
Mire la tabla de saltos. Como la familia de direcciones es CLNS, los saltos se
identifican por System ID (0100.6600.8003) y circuito, no por una dirección
IPv4, que en un camino CLNS no significaría nada. Cambie el selector a IPv4 o IPv6
y el mismo camino se vuelve a dibujar con el direccionamiento que esa familia usa
realmente.
(Esa captura también está admitiendo algo sobre el modelado salto a salto en IS-IS. Es el tema de una entrada posterior y no lo voy a enterrar aquí.)
Kestrel-Dynamics: EIGRP, que no tiene base de datos de estado de enlace
Y luego está el AS 100:
Un solo color. Dos “áreas”. No es un fallo de dibujado. Es EIGRP siendo honesto consigo mismo.
EIGRP es un protocolo de vector distancia sin base de datos de estado de enlace
que unir y sin concepto de área con el que colorear. Las dos entradas son
sencillamente las instancias IPv4 e IPv6. EIGRP sí forma adyacencias de vecino,
mediante su propio protocolo Hello, pero detrás no hay una base de datos de estado
de enlace que recorrer ni un SPF que ejecutar: los vecinos intercambian vectores
de distancia, no un mapa sincronizado. Así que Osprey lo lee en modo solo lectura
desde CISCO-EIGRP-MIB y reconstruye el grafo de adyacencias a partir de lo que
cada router informa sobre sus propios vecinos. En este laboratorio son 580
relaciones de vecindad activas.
Esa diferencia se propaga hasta el cálculo de caminos, y se ve:
En ese camino no hay ningún “coste total”, y nunca lo iba a haber. La métrica compuesta de EIGRP describe un camino entero, no un salto suelto, así que sumar costes de salto produciría un número que no significa nada. Lo que se obtiene en su lugar es la distancia calculada actual de cada router hacia el destino, decreciendo a lo largo de la cadena: 712704 → 710144 → 658944 → … → 128256. Es exactamente lo que leería en los routers uno por uno. (La Feasible Distance de DUAL es una magnitud sutilmente distinta: el mínimo desde que la ruta pasó a pasiva por última vez, el umbral de factibilidad. La tabla de saltos mantiene ambas separadas en lugar de etiquetar una como la otra.)
Tres protocolos, tres modelos genuinamente distintos, tres respuestas correctas. No una abstracción fingiendo que son lo mismo.
Debajo de la imagen: la propia LSDB
El lienzo es una representación. El modelo que hay debajo es la base de datos de estado de enlace, y Osprey la mantiene navegable:
13.382 LSA, separados por tipo: Router (1), Network (2), Summary (3), ASBR (4), External (5) y NSSA (7). Los indicadores ABR y ASBR se derivan de los propios LSA, no de una convención de nombres.
Lea con atención la línea que hay bajo el título:
13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)
Esos LSA se reconstruyeron a partir de recorridos SNMP, no se recibieron por una adyacencia de protocolo. Un recorrido SNMP de la MIB de OSPF le da el contenido de los LSA, pero no los campos de cabecera en vivo. Así que Osprey muestra el contenido y declara sin rodeos que faltan tres campos, en lugar de dibujar tres columnas de ceros que parecerían datos.
Es una cosa pequeña. También es toda la filosofía de diseño en una sola línea, y es la razón por la que me fío de los otros 13.382 números de esa pantalla.
La cuestión
El mapa no es el producto. El modelo sí.
Tres operadores que no comparten protocolo, ni plan de direccionamiento, ni ASN caben en una sola herramienta sin que ninguno quede aplanado a un mínimo común denominador. OSPF conserva sus áreas y sus dos LSDB, IS-IS conserva sus niveles y sus familias de direcciones, EIGRP conserva sus distancias de DUAL y su ausencia total de base de datos de estado de enlace.
Donde de verdad difieren, el producto difiere. Donde no puede saber algo, lo dice.
Osprey es pasivo: sin agentes en los routers, sin inyección de rutas, sin reenvío de paquetes. Cómo funciona eso en realidad, y lo que cuesta, es la siguiente entrada.