La verdad salto a salto

Su herramienta de caminos dibuja un corredor. Los routers reenvían salto a salto. Esta es la medición de esa diferencia sobre 4.032 pares.

10 de agosto de 2026 Michel Wijnberg

Casi todas las herramientas de caminos de red que he usado (incluida la mía hasta hace poco) funcionan así:

Toma el router de origen.
Ejecuta Dijkstra sobre la topología.
Dibuja el camino más corto resultante.

Eso es un corredor con raíz en el origen, y es un modelo sutilmente equivocado del reenvío IP. El reenvío real no tiene corredor. Cada router compara de forma independiente la dirección de destino con su propia tabla de rutas y elige un siguiente salto. Las dos respuestas coinciden solo mientras la regla de decisión y el conjunto de entrada de cada router intermedio coincidan con los del origen.

En OSPF, con frecuencia no lo hacen.

Un paquete que nunca llega

Este es un caso de mi laboratorio, medido en todos los routers implicados con show ip route, leído de los equipos y no modelado:

Router	Dice sobre el destino	Reenvía a
`dfw1-gw2`	`metric 20031, type inter area`	`dfw1-cr1`
`dfw1-cr1`	`metric 30001, type intra area`	`ord1-cr1` ← no a `dfw2-cr1`
`ord1-cr1`	`metric 20001, type intra area`	`jfk1-cr1`
`jfk1-cr1`	`metric 10001, type intra area`	`lhr1-cr1`
`lhr1-cr1`	`metric 1, connected`	entregado

El corredor con raíz en el origen dibujó esto:

dfw1-gw2 → dfw1-cr1 → dfw2-cr1 → iad2-cr1 → ams1-cr1 → lhr1-cr1

El paquete nunca llega a dfw2-cr1. El corredor es un camino más barato. Simplemente no es un camino que ningún router vaya a construir. Dos reglas independientes del RFC 2328 hacen que dfw1-cr1 lo rechace:

§16 paso (3) / §16.2 ¶1: la puerta del backbone. Un router conectado a varias áreas examina solo los summary-LSA del backbone. El summary más barato de dfw2-cr1, con coste 20011, está realmente en la base de datos del área 4.6.23.0 de dfw1-cr1 (lo confirmé con show ip ospf database summary), pero no es un candidato, porque dfw1-cr1 es un ABR y ese summary no llegó por el área 0. El RFC 3509 §2.1/§2.2 (el comportamiento ABR de Cisco que corre de verdad en estos equipos) condiciona esto a tener una conexión activa al backbone, que dfw1-cr1 tiene.

§16.2 paso (6): intra gana a inter, y punto. “If the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred).” dfw1-cr1 ya tiene un camino intraárea con métrica 30001. El summary de 20011 pierde frente a él. La métrica es irrelevante: esta es una regla sobre el tipo de camino, y la comparación de costes nunca llega a ocurrir.

Cualquiera de las dos reglas por separado mata el corredor. Una herramienta que ejecuta un solo SPF desde el origen no puede ver ninguna de las dos, porque nunca le pregunta a dfw1-cr1 qué piensa dfw1-cr1.

¿Con qué frecuencia importa esto de verdad?

Esta es la parte que me importa, porque “su modelo es teóricamente impreciso” es una afirmación mucho más débil que un número.

Así que leí la tabla de rutas OSPF completa de los 64 routers del AS 200 y comparé cada uno de los 4.032 pares ordenados origen/destino:

Medición	Resultado
Pares interárea donde el corredor dibujó ≥1 salto que ningún router tomaría	360 de 2.839 (12,68 %)
Pares intraárea con el mismo defecto	0 de 1.193
Total	360 de 4.032 (8,93 %)

El cero en intraárea es la comprobación de cordura. Dentro de una sola área, todos los routers ejecutan SPF sobre una LSDB idéntica, y un camino más corto sigue siendo el más corto desde cualquier punto a lo largo de él, así que los dos modelos tienen todas las razones para coincidir. Lo importante es que se midió que coincidían, en lugar de darlo por supuesto: 1.193 pares, ninguna discrepancia. En cuanto entran en escena un ABR y un summary-LSA, uno de cada ocho caminos es ficción.

No “ligeramente subóptimo”. Ficción, con un router que el paquete demostrablemente no visita nunca. Si usa ese camino para planificar una ventana de mantenimiento o para explicar un incidente, está razonando sobre una ruta que no existe.

La solución: preguntar a todos los routers

Osprey ahora recorre la cadena. En cada salto evalúa la ruta propia que ese router tiene instalada hacia la dirección de destino, usando la LSDB de ese router, sus propias pertenencias a áreas, su propio estado de ABR y su propia mezcla de distancias administrativas; después sigue el siguiente salto que realmente selecciona, y repite.

Validado contra los mismos 4.032 pares:

Comprobación	Resultado
Métrica propia del router reproducida exactamente	4.032 / 4.032
Tipo de camino (intra / inter / externo) exacto	4.032 / 4.032
Conjunto completo de siguientes saltos ECMP instalados idéntico	4.032 / 4.032
La cadena termina en `delivered` en el destino solicitado	4.032 / 4.032

No “aproximado”. Idéntico, en cada par, incluido el conjunto completo de siguientes saltos de igual coste en lugar de un miembro elegido al azar.

Así se ve en el lienzo: camino de ida en naranja, de vuelta en azul, y todo lo que no está en el camino atenuado hasta formar un corredor:

Un camino OSPF dibujado sobre la topología con superposiciones de ida y vuelta y cuatro caminos de igual coste

Fíjese en el selector 4 equal-cost paths y en la etiqueta per-flow hash. Osprey enumera el conjunto ECMP completo en lugar de elegir un miembro y presentarlo como el camino, porque su tráfico se reparte por hash entre los cuatro, y una sesión de diagnóstico que examine solo uno de ellos no encontrará nada raro tres de cada cuatro veces.

Y aquí está el mismo camino desplegado:

Un camino OSPF de 10 saltos con tabla por salto, distintivos de ABR, puertos de entrada y salida y la explicación numerada

Cada salto lleva el router que tomó la decisión, el área en la que la tomó, las interfaces físicas de entrada y salida con sus direcciones, y el coste. Los distintivos ABR se derivan de las LSDB, no de los nombres de host. La cinta de áreas de debajo muestra el camino cruzando 12.1.24.0 → 0.0.0.0 → 6.18.1.0, que es el tránsito por el backbone que el RFC 2328 exige para el tráfico interárea.

Y el coste total que se muestra, 30061, es la métrica que el propio origen tiene instalada. Es literalmente el número que show ip route imprime en lax1-gw1, con el coste del stub incluido, no una suma que Osprey haya calculado agregando los enlaces que le gustaban.

La explicación es generada, no decorativa:

Route type: O IA (inter-area): Source 172.16.2.33 and destination 172.16.5.23 have no shared area, routing via backbone (area 0.0.0.0)

Path traverses: area 12.1.24.0 (cost 10) → area 0.0.0.0 (cost 30040) → area 6.18.1.0 (cost 10)

Total cost: 30061 via 10 hops

ECMP: 4 equal-cost paths available

Al cruzar la frontera del AS

Dentro de un solo IGP la cadena es computable porque la LSDB está completa. Al cruzar una frontera de AS, nada lo está. No hay base de datos compartida, ni espacio métrico compartido, ni política compartida de distancias administrativas.

La respuesta honesta no es rendirse, y desde luego no es fingir que las métricas se componen. Es empalmar evidencias.

Un camino de 15 saltos que cruza del AS 200 al AS 300, con costes por segmento y una transición eBGP

Quince saltos desde lax1-gw1 en el AS 200 (inquilino Harrier-Broadband, OSPF) hasta i-sin1-gw1 en el AS 300 (inquilino Merlin-Carrier, IS-IS). Lea lo que hace:

El salto 8, jfk1-gw1, lleva un distintivo BGP: aquí es donde se detiene el IGP y la decisión de BGP toma el relevo.
El salto 9, i-jfk1-gw1, lleva un distintivo IS-IS: un protocolo completamente distinto, otro plan de direccionamiento, otro inquilino.
El pie dice “Per-segment costs (never summed) | 15 hops”. Un coste OSPF de 20051 y un coste IS-IS de 1320 son números en espacios métricos sin relación entre sí. Sumarlos daría 21371, que no es una cantidad que exista. Osprey se niega a imprimirla.

La explicación generada nombra sus evidencias en cada paso:

BGP border selection: jfk1-gw1 holds 10.66.0.0/15 for 10.66.15.3 (AS path: 300)

AS 200: IGP segment: lax1-gw1 → jfk1-gw1, cost 20051

eBGP transition 200 → 300: jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 (bmp-peer+l2; ip-bound)

AS 300: IGP segment: i-jfk1-gw1 → i-sin1-gw1, cost 1320

El paso 3 es mi línea favorita del producto. No dice “estos dos routers probablemente están conectados de alguna forma”. Nombra puertos físicos en ambos extremos, y luego enseña su trabajo en ese paréntesis:

bmp-peer: una sesión eBGP establecida entre ambos, vista por BMP
+l2: el extremo lejano se emparejó a través de la adyacencia LLDP/CDP de las fronteras
ip-bound: ambas direcciones de sesión se resolvieron a esos puertos concretos mediante las asociaciones de la IP-MIB de los dispositivos

Tres piezas de evidencia independientes que coinciden. Cuando no coinciden, el producto lo dice, que es justamente el tema de la siguiente entrada.

Por qué esto me importa más que las funcionalidades

Un dibujo de camino es una afirmación sobre lo que su red hará con un paquete. Si la afirmación es errónea una vez de cada ocho y nada en pantalla distingue las erróneas de las correctas, el dibujo es peor que inútil. Es confiadamente inútil, y se le creerá exactamente en el momento en que equivocarse sale caro.

Pasar de “plausible” a “reproduce exactamente las 64 tablas de rutas, 4.032 de 4.032” costó un banco de validación, un laboratorio del que puedo leer la verdad de referencia, y estar dispuesto a descubrir que mi propia herramienta llevaba 360 veces dibujando ficción.

Para eso está el laboratorio.

A continuación, la otra cara de la misma moneda: los sitios donde Osprey no puede calcular la respuesta, y lo dice: Lo que Osprey se niega a adivinar.