Resumen

  • En el código fijado de Sagan, is_success busca un RTT evaluado como verdadero y sin error de paquete en el último salto suministrado. No exige que responda la dirección de destino.
  • destination_ip_responded y last_hop_responded ya ofrecen comprobaciones separadas. La biblioteca permite distinguirlas; esta investigación no ha demostrado que un producto concreto las confunda.
  • last_median_rtt puede conservar un valor de un salto anterior aunque el salto final permanezca en silencio. Veintiuna pruebas existentes y cinco casos sintéticos se completaron localmente sin fallos ni llamadas de red, no como una medición de disponibilidad real.

El dato decisivo no son los diez milisegundos, sino la dirección que los acompaña.

En uno de los casos inventados para comprobar Sagan, un router responde en ese tiempo y ocupa el último salto de la lista. Su dirección no coincide con el destino. El objeto resultante tiene is_success en true y destination_ip_responded en false. No son dos versiones incompatibles del mismo hecho. Son respuestas a preguntas distintas.

El ejemplo usa direcciones de documentación, sin enviar paquetes a una red. No describe un incidente de un cliente. Sirve para comprobar qué exige una clasificación antes de emplearla en un informe operativo.

Sagan es la biblioteca de RIPE NCC que interpreta resultados de RIPE Atlas y los presenta como objetos de Python. Su razón de ser es evitar que cada usuario vuelva a resolver los cambios de formato y sus excepciones. Este trabajo examina el commit 45d01f754896ad648e5b306c4209153bab774af9, fechado el 2026-06-03. Esa referencia identifica el código estudiado, no todas las copias instaladas ni la equivalencia de cualquier distribución actual. Propósito del proyecto.

Qué significa aquí terminar con éxito

La función set_is_success examina los paquetes del último salto de la lista recibida. Basta con encontrar un RTT que Python evalúe como verdadero en un paquete no marcado como error. La condición no añade una comparación entre el origen de ese paquete y la dirección de destino.

Esa comparación tiene su propia función: set_destination_ip_responded. Otro método, set_last_hop_responded, comprueba si hay un RTT evaluado como verdadero, independientemente de que el paquete venga del destino. El código conserva las tres preguntas en tres indicadores. Condiciones del traceroute.

Una respuesta normal de la dirección objetivo puede satisfacer todas las condiciones. Por eso un ejemplo sencillo puede hacerlas parecer equivalentes. Una respuesta sin error de otra dirección, en cambio, satisface los criterios de respuesta del último salto y éxito sin satisfacer el del destino. El router no se convierte en el objetivo: cambia la pregunta a la que corresponde cada true.

La separación también opera en sentido inverso. Un caso sintético termina con una respuesta de la dirección objetivo, diez milisegundos de RTT y el código de error p. destination_ip_responded y last_hop_responded son true; is_success es false. La lista de errores finales contiene «Port unreachable». La dirección y el tiempo siguen presentes aunque el paquete tenga una clasificación de error. Gestión del estado de error.

Esto no demuestra que una aplicación esté funcionando ni que haya dejado de hacerlo. El analizador compara direcciones registradas y clasifica datos de paquetes. No autentica al emisor ni completa una transacción del servicio que un cliente quiere utilizar.

El contraargumento está en la propia biblioteca

No sería correcto concluir que Sagan oculta la respuesta del destino o carece de un modo de comprobarla. El indicador específico ya existe. La documentación enumera destination_ip_responded, last_hop_responded, is_success y los errores del último salto. El usuario dispone de herramientas para formular una interpretación más precisa. Propiedades publicadas.

El nombre de una propiedad resulta cómodo, pero su condición decide qué prueba. Conservar la comodidad no exige borrar el significado de las demás propiedades. Tampoco hace falta pedir al programa que resuelva una pregunta sobre disponibilidad para la que no se ha encargado una medición.

El riesgo hipotético aparece cuando un consumidor conserva solo is_success y lo presenta como «destino accesible» o «servicio disponible». Esta investigación no ha identificado una aplicación concreta que haga esa sustitución. La posibilidad de una mala interpretación debe permanecer como posibilidad, no convertirse en una acusación basada en el nombre de un campo.

Un número puede sobrevivir al silencio final

last_median_rtt sigue una regla distinta de los indicadores terminales. Un salto obtiene su mediana a partir de los RTT retenidos. El resultado recorre la lista de saltos en sentido inverso y toma la primera mediana evaluada como verdadera. La selección no requiere que los paquetes procedan del destino.

En otro caso sintético, el primer router responde en cinco milisegundos, el segundo en diez y el tercer salto solo contiene un marcador de agotamiento del tiempo de espera. Los tres indicadores terminales son false. El valor de last_median_rtt continúa siendo diez milisegundos.

No hay contradicción entre el silencio del último salto y una duración obtenida antes. Los indicadores describen el final de la lista; el número describe el salto que respondió y fue elegido por el recorrido inverso. Llamarlo «latencia del destino» añadiría una conclusión que el cálculo no exige.

La misma magnitud aparece en una respuesta normal del objetivo, una respuesta de otro router y una respuesta del objetivo marcada como error. Promediar esos números no haría equivalentes sus condiciones. Antes de construir una estadística, hay que decidir qué observaciones pertenecen al mismo objeto y cuáles no.

La lista del ensayo estaba ordenada de la manera habitual. El recorrido inverso del analizador no constituye una reconstrucción independiente de la ruta física. Estos casos no permiten generalizar sobre entradas desordenadas, formatos malformados o todos los comportamientos posibles. «Último» necesita conservar su referencia a la selección realizada, no adquirir por sí solo el significado de «destino».

Menos objetos no significa menos datos originales

La opción parse_all_hops=False permite evitar la construcción de todos los objetos Hop. Es una economía razonable cuando el consumidor solo necesita algunas propiedades del resultado. La documentación explica que hops puede contener únicamente el último objeto Hop.

En el caso de tres saltos con silencio terminal, esa opción conserva solo el salto de índice tres. El RTT derivado sigue siendo diez milisegundos, procedente del salto anterior. La entrada completa permanece en raw_data. El programa no ha borrado la fuente; el conjunto de objetos prácticos y el valor calculado muestran partes diferentes de ella.

Si un exportador conserva únicamente hops y la mediana final, puede omitir el objeto que aportó el tiempo. Guardar la entrada original o identificar explícitamente el salto elegido permite explicar el resultado después. No se trata de construir todos los objetos indefinidamente, sino de decidir qué evidencia necesitará quien reciba el informe.

Esta diferencia también limita las comparaciones. Dos consumidores pueden conservar conjuntos distintos de objetos aunque partan de la misma entrada. Si se comparan sus exportaciones, la opción de interpretación debe formar parte del contexto. Una ausencia en la lista exportada no prueba una ausencia en los datos originales.

Pruebas concretas, alcance limitado

Se ejecutaron localmente las veintiuna pruebas de traceroute existentes en el proyecto. Las clases originales de base, compatibilidad y traceroute se cargaron en memoria sin modificar sus fuentes. Todas las pruebas terminaron sin fallos. Después se comprobaron cinco entradas inventadas: respuesta final de otro router, respuesta normal del destino, silencio final con RTT anterior, respuesta del destino con error y el mismo silencio con interpretación mínima. Las cinco produjeron los resultados previstos. Se prohibieron operaciones de red y no hubo ninguna. Pruebas del proyecto.

El control verifica las clases elegidas y unos casos delimitados. No certifica la instalación completa de un paquete, su aceptación por controladores, la conformidad de toda versión distribuida ni la interpretación de todos los formatos. Tampoco mide la frecuencia de estas condiciones entre sondas reales, el uso que hacen los consumidores o las pérdidas de un cliente.

Las pruebas existentes aportan además evidencia favorable al proyecto: las diferencias entre respuestas ya reciben atención explícita. No hay motivo para convertir una biblioteca útil en sospechosa por ofrecer varios indicadores. La tarea consiste en conservar sus distinciones cuando el resultado sale de ella.

La dirección correcta todavía no prueba el servicio

La documentación general de Atlas distingue el from superior, añadido por el sistema de medición, del src obtenido por la sonda. Pueden diferir legítimamente. En el analizador de traceroute, el from de un paquete anidado sirve como origen de ese paquete. La dirección superior, la dirección respondiente y la dirección de destino cumplen funciones distintas. Una coincidencia de etiquetas no las convierte en la misma identidad. Roles de dirección en Atlas.

La RFC 792 describe ICMP Time Exceeded cuando expira el TTL y las circunstancias en que un router puede notificarlo al emisor. Una respuesta así informa sobre el tratamiento de un paquete; no completa una operación en la aplicación objetivo. A la inversa, el silencio por sí solo no identifica necesariamente una ruta de envío rota: el retorno de la respuesta y su tratamiento son otras partes del problema. Especificación ICMP.

La RFC 2330 diferencia observaciones individuales, muestras y estadísticas derivadas. Su convención Type-P subraya que importa el tipo de tráfico. Un RTT de un salto, la clasificación de un traceroute y una estimación de disponibilidad en el tiempo no son el mismo dato. Compartir espacio en un informe no elimina esa diferencia metodológica. Marco de métricas de rendimiento.

La lectura más útil conserva la duración con el salto que la produjo y las condiciones del último salto junto a ella. Si se quiere una afirmación sobre la aplicación, deben añadirse pruebas de esa aplicación, del intervalo y de los puntos de observación adecuados. El nombre de una propiedad puede abreviar una condición; no puede ampliar la evidencia.

Fuentes