← Todos los artículos

Lo que Osprey se niega a adivinar

Lo más importante que he construido es un conjunto de negativas

Michel Wijnberg

Una herramienta de red que adivina es peor que una que admite su ignorancia, y la razón no es filosófica. Es operativa.

Si una herramienta dice “no lo sé”, usted va y lo averigua. Si produce una respuesta plausible, usted actúa en consecuencia. Y en la pantalla nada distingue una respuesta correcta de una respuesta segura de sí misma, así que el modo de fallo no es “la herramienta se equivocó”, sino “la herramienta se equivocó y yo no tenía ningún motivo para comprobarlo”.

Por eso Osprey tiene una regla que se impone a todos mis instintos de producto: enuncie la evidencia, o enuncie que no la hay. Nunca interpole. Nunca dibuje un marcador de posición que parezca un dato.

Así es como se ve eso en un producto que se vende de verdad.


1. “No puedo calcular este camino por la vía buena”

La entrada anterior trataba de la cadena de reenvío salto a salto, que sigue la tabla de rutas propia de cada router en vez de dibujar un corredor con raíz en el origen, validada con exactitud contra los 4.032 pares de routers del AS 200.

Ese motor funciona para OSPFv2. No funciona para IS-IS, y Osprey lo dice en lugar de retroceder en silencio:

Un camino IS-IS con un paso de la explicación que declara no disponible la cadena de reenvío
Un camino IS-IS con un paso de la explicación que declara no disponible la cadena de reenvío

4. Hop-by-hop forwarding chain unavailable Showing the source’s own shortest-path view, which every intermediate router may legitimately disagree with. Osprey does not model this protocol’s inter-area reachability hop-by-hop (IS-IS carries inter-level reachability differently from OSPF and has no Type-3 equivalent to persist, so Osprey stores nothing from which L1↔L2 route leaking could be reconstructed. An L1-only source in particular forwards on the attached-bit default toward its nearest L1/L2 router, not by end-to-end cost; EIGRP has its own observed chain).

Tres cosas sobre ese mensaje.

Nombra el modelo que respondió: la vista de camino más corto del origen, para que usted sepa cuál de los dos motores está mirando. Nombra el motivo: Osprey no almacena nada a partir de lo cual pudiera reconstruir la fuga de rutas L1↔L2. Eso es un límite del modelo de Osprey, no del protocolo: IS-IS no tiene un summary LSA de tipo 3 porque nunca lo necesitó; transporta la alcanzabilidad entre niveles en los LSP de L2 y en el bit attached. Y nombra la consecuencia concreta, que es la parte que de verdad le afectaría: un origen que solo es L1 no reenvía por coste extremo a extremo en absoluto. Sigue el bit attached hacia su router L1/L2 más cercano, según la ISO 10589. Su primer salto real puede no tener nada que ver con el camino dibujado.

El camino se sigue mostrando, porque una vista de camino más corto es genuinamente útil. Simplemente no se le permite hacerse pasar por la respuesta fuerte.

La misma disciplina se aplica a OSPFv3, a un ámbito que solo contiene parte de las áreas de una instancia de protocolo, a áreas con un enlace virtual y a routers que viven en dos instancias de protocolo que pueden transportar ambas la familia de direcciones. Cada caso recibe su propio motivo con nombre. Ninguno restablece en silencio la imagen antigua.


2. “Este número no significaría nada”

EIGRP no es un protocolo de estado de enlace. No hay base de datos a la que unirse, no hay SPF que ejecutar y, sobre todo, no hay forma con sentido de sumar los costes de los saltos, porque la métrica compuesta de EIGRP describe un camino entero y no un enlace suelto.

Así que Osprey no imprime un total:

Un camino EIGRP con una columna "Metric" y sin coste total
Un camino EIGRP con una columna "Metric" y sin coste total

Observed EIGRP forwarding chain EIGRP has no link-state database; this path follows the routers’ own DUAL result (per-hop topology tables), so there is no summed cost to show: 3 RIB-installed variant(s) shown alongside (the RIB holds equal next-hops).

Lo que obtiene en su lugar es la distancia calculada propia de cada router hacia el destino, decreciendo a lo largo de la cadena: 712704 → 710144 → 658944 → 556544 → 505344 → 428544 → 223744 → 133120 → 128256.

Cada uno de esos números salió de un router. Ninguno fue derivado. El campo vacío de “coste total” no es una carencia de la implementación. Es la representación correcta de una magnitud que no existe.

La misma regla se dispara al cruzar una frontera de AS, donde un coste OSPF y un coste IS-IS son números en espacios métricos sin relación entre sí:

Per-segment costs (never summed) | 15 hops


3. “Esta es exactamente mi confianza, segmento a segmento”

Los caminos entre dominios no se pueden calcular. Solo se pueden empalmar a partir de evidencias, y las evidencias no son uniformemente buenas, así que Osprey las gradúa por segmento en lugar de emitir una confianza global para todo el camino:

Un camino entre dominios con distintivos de confianza por segmento: AS 200 resolved, AS 300 inferred
Un camino entre dominios con distintivos de confianza por segmento: AS 200 resolved, AS 300 inferred

AS 200 ospfv2/1 cost 20051 es resolved. AS 300 isis/LAB cost 1320 es inferred. El mismo camino, la misma pantalla, distinto estatus epistémico, ambos etiquetados.

Detrás de esos distintivos hay una escalera estricta que se prueba en orden:

PeldañoEvidenciaConfianza
aUna fila de RIB en una frontera de ese dominio que cubre el destinoresolved
a2Un route server cuya propia RIB BMP cubre el destino a través del siguiente ASinferred (bmp-rib-rs)
bUna sesión eBGP establecida hacia el siguiente AS de la cadenainferred
cNadaopaque: se dibuja como un segmento con una nota y sin ningún salto

El peldaño (c) es el que importa. Cuando Osprey no puede establecer cómo entra el tráfico en un dominio, no interpola un conjunto de saltos con aspecto plausible. Dibuja un segmento explícitamente opaco y se explica; y donde la causa es accionable, dice lo accionable en lugar de una disculpa genérica. El mensaje tiene esta forma:

AS 65000 has no areas in the selected scope. Include its areas to trace through this domain

Ese es un mensaje con el que se puede hacer algo. “Punto de entrada desconocido” no lo es. (Todos los caminos del laboratorio de estas entradas se resuelven, así que esa nota concreta no aparece en estas capturas. Se dispara cuando un ámbito omite de verdad un AS de tránsito.)

El peldaño (a2) existe por un motivo concreto que vale la pena señalar: un route server transparente nunca aparece en el AS_PATH. Sin leer la propia RIB del route server no hay manera de ver un desvío por un IX. El camino parecería directo cuando no lo es.


4. “Estos puertos son un hecho / una conjetura / genuinamente ambiguos”

Cuando Osprey anota una transición eBGP con puertos físicos, distingue cuatro situaciones en lugar de aplanarlas en una única respuesta segura:

  • Exactamente un par de enlaces, sin alternativa por fabric → los puertos se enuncian como hecho: jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2
  • Enlaces en paralelo → un agregado, con la incertidumbre nombrada: “3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)”
  • Ambas fronteras en un bridge compartido, sin enlace directopresencia de fabric con los puertos de conexión, la afirmación de que existe un bridge entre ambas, nunca la afirmación de que la sesión lo cruza
  • Un enlace directo y además un fabric compartido → ambigüedad explícita que nombra los dos y no elige ninguno

Más las reglas de apoyo: las filas deben ser más frescas que 13 horas, la antigüedad se declara a partir de 6 horas, y un bridge emparejado solo por sysname veta una afirmación de puerto sin llegar nunca a mostrarse como hecho.

El peldaño más fuerte asciende una conjetura a hecho: cuando ambas direcciones de la sesión BGP se resuelven a puertos concretos mediante las asociaciones de la IP-MIB de los dispositivos, la anotación pasa a ser ip-bound y anula las barreras de ambigüedad, porque a esas alturas ya no es una inferencia.


5. “Estos campos no están disponibles”

El más sutil, y mi favorito:

El navegador de LSDB declarando que LSAge, SeqNo y Checksum no están disponibles
El navegador de LSDB declarando que LSAge, SeqNo y Checksum no están disponibles

13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)

Esos LSA se reconstruyeron a partir de recorridos SNMP en lugar de recibirse por una adyacencia de protocolo, y un recorrido SNMP de la MIB de OSPF le da el contenido de los LSA pero no los campos de cabecera en vivo.

La implementación tentadora son tres columnas de ceros. Se dibujarían preciosas, se ordenarían bien y serían mentira. Y peor: una mentira indetectable, porque un LSA con edad 0 parece un LSA recién inundado y no una medición ausente.

Así que las columnas están ausentes y el motivo se imprime en la parte superior del panel.


6. Negarme a usar mi propio mejor motor

El que más me satisface, porque me costó una funcionalidad.

El modo de simulación de Osprey permite tirar enlaces, quitar nodos, cambiar métricas y ver cómo se desplaza el tráfico. El movimiento obvio es ejecutar el flamante motor de cadena salto a salto contra la topología mutada.

Osprey deliberadamente no lo hace.

Una cadena de reenvío posterior a la mutación no es computable. Seguir la tabla propia de cada router exige saber cuál sería la tabla de cada router después del cambio, y eso depende de los summary LSA de tipo 3 que los ABR supervivientes volverían a originar. Esos LSA todavía no existen. No se pueden sintetizar sin adivinar, y adivinarlos produciría un camino salto a salto con toda la autoridad del motor validado y nada de la validación.

Así que ambos lados de la simulación se quedan en la proyección SPF claramente etiquetada, y lo dicen en los avisos. La respuesta más bonita estaba disponible. Solo que no habría sido cierta.


Por qué esto es una funcionalidad y no una disculpa

Vendo un producto de topología de red. Cada uno de los comportamientos anteriores hace que una captura de pantalla sea un poco menos impresionante que la de un competidor, y ya he tenido la conversación en la que alguien señala que una respuesta segura demuestra mejor.

Es cierto. También destruye lo único que hace que la herramienta merezca la pena.

Un ingeniero a las 03:00 con un área particionada no necesita una imagen bonita. Necesita saber por qué partes de la imagen puede apostar. Un producto que gradúa su propia evidencia (resolved, inferred, opaque, unavailable, not computable) le permite gastar su escepticismo donde toca, en lugar de repartirlo por igual entre todo lo que hay en pantalla.

La medición de la entrada anterior es lo que gana esa confianza: 4.032 de 4.032 pares de routers reproducidos exactamente contra la verdad de referencia leída de los routers. Las negativas de esta entrada son lo que la protege. Una herramienta que acierta 4.032 veces y luego se marca un farol en la 4.033 no le ha enseñado nada sobre en qué caso está usted.

Diga lo que sabe. Diga cómo lo sabe. Diga cuándo no lo sabe.


Con esto se cierra la primera serie. El recorrido por el laboratorio está aquí, la arquitectura de descubrimiento pasivo aquí, y el motor de caminos salto a salto aquí. Una segunda serie, sobre sostener varias verdades a la vez, ordenar evidencias contradictorias y demostrar que tu propio producto se equivoca, empieza con El mismo router, tres verdades distintas.