Cuando la red se contradice a sí misma
Seis fuentes de verdad, una respuesta, y qué hacer cuando se contradicen entre sí
Michel Wijnberg
Osprey aprende sobre una red a partir de seis sitios:
| Fuente | Le dice |
|---|---|
| LSDB de OSPF / IS-IS | qué cree cada protocolo que es la topología |
| Tabla de rutas por SNMP | qué instaló realmente un router |
| Adj-RIB-In por BMP | qué anunció cada par BGP a este router, y de quién |
| LLDP / CDP | qué está físicamente cableado con qué |
| IP-MIB | qué dirección vive en qué puerto |
| Tabla de sesiones BGP | quién está emparejado con quién |
Cada una de ellas es autoridad sobre algo. Ninguna es autoridad sobre todo. Y no siempre coinciden.
La respuesta ingenua es elegir un ganador global (“confía en LLDP para la topología, confía en BMP para BGP”) y seguir adelante. Eso falla en la primera red donde LLDP está desactualizado en un extremo de un enlace, o donde hay un bridge entre dos routers que creen estar conectados directamente.
La respuesta con la que acabé es más aburrida y funciona: ordene la evidencia por afirmación, y registre de dónde salió cada afirmación.
Puertos: cuatro situaciones, cuatro respuestas distintas
La versión más afilada de este problema es anotar una transición eBGP con puertos físicos. Dos routers de sistemas autónomos distintos tienen una sesión. ¿Por qué cable pasa?
Osprey distingue cuatro casos y da un tipo de respuesta distinto a cada uno:
Un par de enlaces, sin alternativa por fabric. Los puertos se enuncian como hecho:
jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2Enlaces en paralelo. El par no está determinado, así que no afirma ninguno:
3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)Ambas fronteras en un bridge compartido, sin enlace directo. Informa de la presencia del bridge con los puertos de conexión: la afirmación de que existe un camino a través de él, nunca la de que esta sesión lo tome:
shared L2 fabric: ix-sw (wn-edge Et0/3 ↔ ix-sw Et0/1; ix-sw Et0/2 ↔ nn-edge Et0/3) (session path unconfirmed)Un enlace directo y además un fabric compartido. Ambigüedad, nombrada explícitamente, sin elegir ninguno.
Ese cuarto caso es el que hace que el diseño merezca la pena. Es genuinamente frecuente en un punto de intercambio, es genuinamente indecidible solo desde L2, y es exactamente donde una herramienta que quiere parecer segura elegirá el enlace directo y se equivocará en silencio.
El peldaño que convierte una conjetura en un hecho
Hay una salida, y no es una heurística. Si ambas direcciones de la sesión BGP se resuelven a puertos concretos mediante las asociaciones de la IP-MIB de los dispositivos, entonces los puertos ya no son inferidos. El propio router le ha dicho qué interfaz posee esa dirección. Esa evidencia anula las barreras de ambigüedad:
eBGP transition 200 → 300 jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 (bmp-peer+l2; ip-bound)
Lea ese paréntesis como una cadena de custodia:
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 fronterasip-bound: ambas direcciones de sesión se resolvieron a esos puertos exactos vía IP-MIB
Tres fuentes independientes coincidiendo. La afirmación es tan fuerte como lo más débil sobre lo que se apoya, y la notación dice qué es eso.
La frescura forma parte de la evidencia
Los datos de L2 caducan, y un dato L2 caducado es peor que ninguno, porque tiene un aspecto idéntico al de un dato L2 fresco. Así que las filas de apoyo llevan reglas:
- Las filas deben ser más frescas que 13 horas para poder sostener siquiera una afirmación de puerto
- La antigüedad se declara por encima de 6 horas
- Un bridge emparejado solo por sysname, en lugar de por una identidad de dispositivo resuelta, veta una afirmación de puerto sin llegar nunca a mostrarse él mismo como hecho
Esa última es sutil y me gusta: a una evidencia débil se le permite destruir confianza sin que se le permita crearla. Un bridge identificado a medias es motivo suficiente para dejar de afirmar un par de puertos directo, y ni de lejos suficiente para afirmar el bridge.
Procedencia: la misma tabla, dos pedigrís distintos
En la segunda entrada mostré la tabla de pares BGP: 378 sesiones repartidas en 57 pares. Lo que esa captura no muestra es que no llegaron todas por la misma vía:
| Fuente | Sesiones |
|---|---|
| BMP: el router empuja su Adj-RIB-In (RFC 7854) | 24 |
| SNMP: un recorrido de la BGP4-MIB en el momento del sondeo | 354 |
Ambas son ciertas. No son igual de buenas. BMP transporta todos los caminos que anunció el par, más Peer Up y Peer Down tal como los ve el router, en tiempo real. Un recorrido SNMP le da la tabla de sesiones tal como estaba en el último sondeo y nada sobre lo que pasó entremedias.
Conviene ser preciso sobre qué RIB, porque eso decide lo que se puede afirmar. El RFC 7854 monitoriza la Adj-RIB-In: lo que llegó de cada par, antes de que este router eligiera nada. La tabla propia seleccionada por el router, la Loc-RIB, es una extensión posterior y aparte (RFC 9069) que los exportadores de aquí no envían. Así que este laboratorio puede decir “el par X me ofreció este camino” con la autoridad de un router, mientras que “este es el camino que el router instaló” es un cálculo propio de Osprey sobre esos candidatos. Son afirmaciones distintas y se etiquetan de forma distinta.
Por eso cada fila registra cuál de las dos es, en una columna source, y ese valor
soporta peso en lugar de ser decorativo. Cuando Osprey empalma un camino entre AS y
necesita un salto interdominio, una sesión eBGP cuenta como evidencia con su procedencia
adjunta: bmp-peer y snmp-peer son peldaños distintos de la escalera, y la anotación
del camino dice sobre cuál se apoyó.
Hay una regla relacionada que me gusta, enterrada en el motor de caminos. Para clasificar
una ruta BGP como interna o externa, la heurística obvia es mirar el AS_PATH: un camino de
un solo elemento implica iBGP. Osprey no hace eso primero. Une la ruta al tipo de par
real de la tabla de sesiones, en vivo desde bgp_peer o a fecha T desde
bgp_peer_history, y solo recurre a la heurística del AS_PATH cuando no se resuelve
ningún par de origen. La heurística acierta casi siempre. “Casi siempre” es precisamente
el modo de fallo del que trata toda esta serie.
Donde nada coincide: dígalo
A veces las fuentes no solo discrepan: se agotan. El empalme de caminos entre dominios gradúa cada segmento con una escalera estricta:
| Peldaño | Evidencia | Confianza |
|---|---|---|
| a | Una fila de RIB en una frontera que cubre el destino | resolved |
| a2 | Un route server cuya propia RIB BMP lo cubre a través del siguiente AS | inferred (bmp-rib-rs) |
| b | Una sesión eBGP establecida hacia el siguiente AS | inferred |
| c | Nada | opaque: un segmento con una nota y sin ningún salto dibujado |
Y la calificación es por segmento, no por camino, porque un camino puede ser seguro en un AS y pura conjetura en el siguiente. Por eso la captura entre dominios de más arriba lleva dos distintivos distintos en dos mitades de la misma respuesta.
El peldaño (a2) existe por un motivo concreto que merece nombrarse: 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. Toda una clase de topología real de internet es invisible salvo que uno vaya a buscar precisamente lo que la esconde.
La regla
Cuando dos fuentes discrepan, hay tres cosas que puede hacer:
- Elegir una. Rápido, parece decidido, silenciosamente equivocado en momentos desconocidos.
- Promediarlas. Produce un número que no describe nada que exista.
- Ordenarlas, y decir cuál usó.
Osprey hace lo tercero, en todas partes, y es la razón por la que me fío más de su salida que de mi propio recuerdo de qué aspecto tenía una red el martes pasado.
El coste es que la interfaz tiene que cargar con más palabras que la de un competidor:
resolved, inferred, opaque, ip-bound, session link undetermined, bmp-peer
frente a snmp-peer. Cada una de ellas es un sitio donde un producto más bonito habría
dibujado una línea limpia.
Una línea limpia es una afirmación. Si no puede respaldarla, no la dibuje.
A continuación, la entrada donde esta filosofía se vuelve contra su autor: el día en que descubrí que mi propia herramienta llevaba tiempo dibujando ficción: El día en que mi topología me mintió.