Huella cero
Cómo ve Osprey una red sin llegar a formar parte de ella
Michel Wijnberg
Todos los productos de monitorización del planeta dicen ser “sin agentes”. La
mayoría quiere decir que entran por SSH y raspan la salida de show, que es “sin
agentes” en el mismo sentido en que un ladrón es un invitado.
Osprey toma otro camino, y quiero ser preciso al respecto, incluida la parte en la que el eslogan de marketing no es del todo cierto.
Osprey obtiene datos de tres maneras. Las tres son visibles para un operador que mire (esto no es un producto sigiloso), pero solo una de ellas mete a Osprey dentro de la base de datos de un protocolo de enrutamiento, y esa es la que merece escrutinio.
1. El grabador GRE: una adyacencia real que nunca puede transportar tráfico
La más interesante. Osprey puede formar una adyacencia IGP genuina sobre un túnel GRE: una relación de vecindad real de OSPFv2, OSPFv3 o IS-IS, con Hellos reales, intercambio DBD real, inundación real. Aprende la LSDB igual que la aprende un router: porque se la cuentan.
Esto es estrictamente mejor que recorrer una MIB, porque obtiene la base de datos tal y como el protocolo la distribuye realmente, con números de secuencia, edades y sumas de comprobación intactas, y ve los cambios en el instante en que se inundan, no en el siguiente intervalo de sondeo.
También significa que los routers sí ven un vecino. Voy a ser directo: Osprey aparece en la LSDB. No le queda otra. El RFC 2328 §12.4.1 exige que todo router de un área origine un Router-LSA de tipo 1, y un router que forma una adyacencia sin originar uno es un router roto.
Así que la pregunta no es “¿podemos ser invisibles?”, porque no podemos, sino “¿podemos ser incapaces de afectar al reenvío?”. Esa sí tiene una respuesta real:
// originateRouterLSA creates and installs our Router-LSA in the LSDB.
// RFC 2328 Section 12.4.1 requires every router to originate a Type 1 LSA.
// We use cost 65535 (maximum) so no router will ever route traffic through
// Osprey. Only the P2P link is advertised. NO stub network for the tunnel
// inner subnet. Advertising the tunnel subnet (even at max cost) causes SPF
// on other routers to install a route for the tunnel prefix, which can
// disrupt the GRE outer path and kill the adjacency.Ahí dentro hay dos decisiones deliberadas, y la segunda costó una caída del laboratorio aprenderla bien.
Métrica máxima. El grabador anuncia su único enlace punto a punto con coste 65535, y esa es la más débil de las dos garantías. Una métrica solo hace que un camino resulte poco atractivo, y un camino poco atractivo sigue ganando cuando es el único. La garantía de verdad es la forma: el grabador tiene exactamente una adyacencia, así que es una hoja en el grafo, y no hay ningún camino a través de una hoja que ningún SPF pueda encontrar. Añada que no anuncia ningún prefijo propio y tampoco hay nada hacia lo que enrutar. La métrica máxima es una precaución redundante encima de una topología que ya no puede transportar tránsito.
Sin red stub. El grabador anuncia el enlace P2P y nada más. En particular, no anuncia la subred interna del túnel como red stub. Esta es la sutil. Si lo hiciera, todos los routers del área instalarían una ruta hacia el prefijo del túnel. Esa ruta puede entonces sobrescribir el camino subyacente sobre el que viaja el propio túnel GRE, lo que rompe el transporte exterior, lo que mata la adyacencia, lo que tira el grabador: un flap autoinfligido de manual. No anunciar nada alcanzable evita toda esa clase de problema, y sigue cumpliendo el RFC 2328.
La versión IS-IS es más estricta
IS-IS ofrece un mecanismo hecho a medida para exactamente esto, así que el grabador IS-IS lo usa. Su LSP autooriginado lleva un conjunto de invariantes duras:
| Invariante | Por qué |
|---|---|
| Bit OL = 1 | El bit de sobrecarga. La ISO 10589 obliga a que todos los demás routers traten a un router sobrecargado como no apto para tránsito. Esta es la garantía principal, no un truco de métrica. |
| Bits ATT = 0000 | Nunca atraer rutas por defecto L1. Un router solo L1 no debe apuntar su ruta por defecto a Osprey. |
| Bit P = 0 | Sin reparación de particiones. |
| Métrica TLV 22 = 0xFFFFFF | Métrica ancha máxima, precaución redundante junto al bit OL. |
| Sin TLV 128 / 130 / 135 / 236 | Son los TLV de alcanzabilidad IP. Emitir cualquiera de ellos inyectaría rutas. |
| Sin TLV 134 | Sin TE Router ID. Insertaría a Osprey en la base de datos de ingeniería de tráfico. |
| Sin TLV 222 / 242 | Sin multitopología, sin capacidades de router ni segment routing. |
Lea esa tabla como una lista de cosas que el código no puede hacer, no como una lista de ajustes. No hay ninguna opción de configuración que apague el bit de sobrecarga y no hay ninguna ruta de código que serialice un TLV de alcanzabilidad IP, porque la forma más segura de garantizar que nunca anuncia un prefijo es no implementar el anuncio de prefijos.
Es decir: visible, participante y estructuralmente incapaz de atraer un solo paquete. Es una afirmación mucho más fuerte que “invisible” y, a diferencia de “invisible”, es cierta.
2. SNMP: la LSDB por la vía aburrida, más todo lo que la LSDB no lleva
No todos los dispositivos le darán una adyacencia, y hay cosas que sencillamente no están en una base de datos de estado de enlace. Así que Osprey también sondea.
192 objetivos en este laboratorio, todos en verde, sondeando en un ciclo de 300 segundos, último sondeo medido en segundos.
La columna de credenciales muestra ***, y conviene precisar dónde ocurre ese
enmascarado: en el manejador de la API, no en el navegador. Las credenciales se
almacenan cifradas en reposo con AES-256-GCM, y toda ruta de lectura pasa la
respuesta por una máscara antes de serializarla. El frontend nunca llega a recibir
la cadena de comunidad ni las contraseñas auth/priv de v3, así que no hay ningún
botón de “mostrar”, ni podría haberlo sin cambiar el servidor.
Enmascarar en el cliente es teatro. Enmascarar en el manejador es un control.
Aquí SNMP hace cuatro trabajos:
- Reconstrucción de la LSDB donde no hay ningún grabador conectado (esto es lo que produjo los 13.382 LSA de la entrada anterior, con los campos de cabecera que faltan declarados con honestidad)
- Contadores de interfaz para tráfico, errores y utilización
- EIGRP, que no tiene ninguna base de datos a la que unirse y se lee entero
desde
CISCO-EIGRP-MIB - Vecinos L2 mediante LLDP y CDP
Este último importa más de lo que parece:
303 adyacencias L2, 66 dispositivos remotos únicos. Esta es la capa que permite a
Osprey decir por qué puerto físico cruza realmente una sesión BGP interAS, en vez
de agitar las manos y hablar de “algún enlace entre estos dos routers”, y uno de
esos enlaces interAS se ve ahí mismo en la tabla: la entrada CDP de ams1-gw1 Et1/1
a e-ams1-gw1, que es la frontera AS 200 ↔ AS 100.
3. BMP: que hablen los routers
Para BGP, el camino preferido no es preguntar. Es escuchar.
BMP (RFC 7854) es un protocolo en el que el router empuja su Adj-RIB-In, los
caminos que sus pares le anunciaron, hacia una estación de monitorización por una
sesión TCP normal. No hay bucle de sondeo, no hay que parsear show ip bgp y no hay
más carga de consulta sobre el plano de control que la propia sesión. El router
decide qué enviar y cuándo.
Aquí hay 378 sesiones repartidas en 57 pares, pero no todas llegaron por la misma vía, y esa distinción se registra en lugar de disimularse.
Seis routers de este laboratorio son exportadores BMP (ams1-gw1, jfk1-gw1,
e-ams1-gw1, e-sin1-gw1, i-jfk1-gw1, i-sin1-gw1), y dan cuenta de 24
sesiones: entre ellas, todas las sesiones eBGP del laboratorio. Las 354
restantes vienen de recorridos SNMP de la BGP4-MIB en routers que no exportan BMP en
absoluto.
Las dos vías hacia el dato son legítimas y las dos merecen la pena; simplemente no son igual de buenas. Una alimentación BMP lleva todos los caminos que anunció el par, más Peer Up y Peer Down tal como los ve el router. Un recorrido SNMP le da la tabla de sesiones en el momento del sondeo y nada entre sondeos. Cuál RIB importa aquí: el RFC 7854 monitoriza la Adj-RIB-In, lo que llegó antes de que este router eligiera nada. La tabla propia seleccionada por el router, la Loc-RIB, es una extensión posterior aparte (RFC 9069) que estos exportadores no envían, así que la selección de best-path sobre esos candidatos es un cálculo de Osprey y se etiqueta como tal.
Por eso cada fila lleva una columna source que registra de dónde vino, y ese valor
soporta peso más arriba en la pila. Cuando Osprey empalma después un camino entre AS
y necesita justificar un salto interdominio, una sesión eBGP cuenta como evidencia
con su procedencia adjunta (bmp-peer frente a snmp-peer), nunca como un hecho
anónimo. La misma tabla, pero graduada.
Ambas familias de direcciones viajan en una única sesión BMP por exportador, y por eso ve filas IPv4 e IPv6 compartiendo router informante.
Las filas eBGP de esa tabla son las interesantes, porque son las costuras entre los tres inquilinos:
| Desde | AS | Hasta | AS |
|---|---|---|---|
e-ams1-gw1 | 100 | ams1-gw1 | 200 |
i-sin1-gw1 | 300 | e-sin1-gw1 | 100 |
i-jfk1-gw1 | 300 | jfk1-gw1 | 200 |
Un triángulo: AS 200 ↔ AS 100 en Ámsterdam, AS 100 ↔ AS 300 en Singapur, AS 200 ↔ AS 300 en Nueva York. Seis sesiones, doce filas entre ambas familias. Ese triángulo es lo que hace posible el empalme de caminos entre dominios, y es el tema de la tercera entrada.
Lo que Osprey estructuralmente no puede hacer
Algunas restricciones merecen enunciarse como restricciones y no como características, porque son la razón por la que lo demás es fiable:
- Sin inyección de rutas. El grabador origina exactamente un Router-LSA que describe exactamente un enlace P2P de coste máximo, y nada más. No tiene ninguna ruta de código que anuncie un prefijo.
- Sin reenvío de paquetes. Osprey no está en el plano de datos. No hay tabla de reenvío, no hay FIB, no hay nada que programar mal.
- Sin escrituras de configuración. El terminal SSH de la interfaz es un terminal. Las pulsaciones son suyas, la sesión se graba para auditoría y Osprey jamás emite por su cuenta un comando de configuración.
- Flujo de datos en un solo sentido. Los colectores y BMP ingieren y publican en NATS; el motor persiste en PostgreSQL; la API sirve al frontend. Ningún servicio llama hacia arriba. No hay ningún camino de la interfaz web a un router que no sea una persona escribiendo en un terminal.
El resumen honesto
Osprey es pasivo en lo que importa: no puede atraer tráfico, no puede inyectar una
ruta y no puede reenviar un paquete. Pero no es invisible, y prefiero decírselo yo a
que lo descubra en un show ip ospf neighbor con una línea más de las que esperaba.
Si un fabricante le dice que su herramienta se une a su IGP y que nadie puede notarlo, pregúntele qué aspecto tiene su Router-LSA.
A continuación: por qué su herramienta de caminos probablemente le está mintiendo, y la medición sobre 4.032 pares que lo demuestra: La verdad salto a salto.