Resumen

  • Un mismo usuario informó en el foro de RIPE NCC de consultas IP sin datos junto a consultas de sus prefijos con resultados.
  • Las cuatro comprobaciones del 3 de septiembre devolvieron datos. No reprodujeron el síntoma ni permiten afirmar que se haya resuelto definitivamente.
  • La búsqueda del prefijo que contiene una dirección es una etapa adicional. Un resultado vacío no basta para concluir que desapareció una ruta o falló un servicio.

Antes de preguntar si una ruta está visible hay que determinar qué ruta se está buscando. Esa distinción, casi invisible para quien introduce una dirección en una casilla, es el centro de un intercambio reciente sobre Looking Glass, la consulta de rutas de RIPEstat.

El ejemplo comunicado el 2 de septiembre parecía contradictorio: 14.137.164.1 no devolvía datos; 14.137.164.0/24, sí. En nuestras comprobaciones del día siguiente ambas consultas funcionaron. También lo hicieron las dos variantes de un ejemplo anterior. No hay, por tanto, una avería actual reproducida en estas pruebas. Tampoco una explicación de lo que sucedió antes.

La noticia no autoriza a elegir entre «sigue roto» y «ya está arreglado». Permite examinar algo más concreto: cómo una herramienta pasa de una dirección individual a un bloque anunciado y qué puede significar una respuesta vacía durante ese recorrido.

Dos entradas, una operación adicional

La documentación de Looking Glass indica que un prefijo explícito debe coincidir exactamente con un prefijo presente en los datos de rutas. Cuando recibe una IP, el servicio intenta localizar el prefijo enrutado que la engloba. Además, excluye registros demasiado antiguos según el límite de consulta retrospectiva, cuyo valor predeterminado es de 86.400 segundos.

El usuario puede así investigar sin conocer previamente el bloque anunciado. La contrapartida es que la consulta incluye una resolución inicial del objeto. Si esa operación falla, la respuesta podría variar sin que ningún router haya cambiado sus anuncios. Es una dependencia que conviene investigar, no una causa confirmada para este caso.

Tampoco sería correcto recomendar añadir /24 a cualquier dirección. La red puede anunciar otro tamaño de prefijo. Un bloque inventado para la prueba no constituye un control válido: cambia la pregunta. La comparación debe utilizar un prefijo cuya presencia en el enrutamiento esté establecida.

Lo comunicado y lo comprobado

El hilo público se abrió el 24 de agosto con 159.138.184.0 frente a 159.138.184.0/24. Al día siguiente, ties, una cuenta identificada públicamente como personal de RIPE NCC, explicó la búsqueda por prefijo más específico, consideró que parecía un fenómeno transitorio y propuso consultar el tratamiento de los fallos de búsqueda.

El 2 de septiembre el mismo usuario, moonteach, señaló que el primer ejemplo ya funcionaba y aportó el nuevo. Las dos horas de consulta reproducidas en ese mensaje distan 27 segundos. Son muestras aportadas por una persona, no observaciones simultáneas ni testimonios independientes. El intercambio no contiene una causa definitiva o un anuncio de corrección completada.

Por nuestra parte, las cuatro solicitudes se ejecutaron de forma sucesiva el 3 de septiembre, entre las 04:13:08.929 y las 04:13:10.945 UTC. Todas devolvieron HTTP 200, estado ok y datos. Las respuestas a las direcciones señalaron expresamente la conversión al /24 correspondiente, que también apareció como recurso efectivo.

Recurso solicitado Entradas de colectores Filas de pares
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

Estos son recuentos de las respuestas conservadas, no números de operadores distintos o un inventario completo de RIS. En la segunda pareja, los valores latest_time difieren en 20 segundos: tener el mismo número de filas no demuestra que los datos sean idénticos. Los enlaces de la tabla consultan el estado actual, no una copia fija de las capturas históricas.

Los cuatro resultados limitan la interpretación: el síntoma no apareció en esos intentos. No permiten calcular una tasa de fallos, reconstruir el estado anterior del servidor ni atribuir el cambio a una corrección concreta.

Un vacío no identifica dónde está el problema

El formato de la Data API separa el estado, los mensajes, la versión y la información de caché. La entrega correcta de una respuesta pertenece a un nivel distinto de la existencia de una ruta. Ninguno de esos hechos demuestra por sí solo que un paquete alcance su destino.

RIS recoge observaciones BGP mediante sesiones aportadas voluntariamente por redes. Esas vistas no equivalen a una prueba de reenvío de extremo a extremo. Entre el tráfico real y la pantalla del analista intervienen la perspectiva del par, el colector, la selección del objeto y la antigüedad de los datos.

Aquí no se ha probado una caída de clientes, pérdida de tráfico o secuestro de rutas. El vacío puede abrir una investigación; todavía no establece su desenlace. La pregunta útil es qué prefijo llegó realmente a consultar el servicio antes de devolverlo.