Midiendo el Tiempo de Respuesta de Prefijos Anycast

08/05/2024

Midiendo el Tiempo de Respuesta de Prefijos Anycast

Escrito por Tomas Lynch – Senior Network Architect en Vultr

¿Cómo sabemos si un prefijo que estamos propagando desde distintos puntos es considerada como la mejor ruta por otras redes? Empecemos con qué es la mejor ruta hacia un prefijo. Para mi, y me imagino que para todos, es la ruta que tiene menor tiempo de respuesta y cero pérdida de paquetes.

Si la ruta es única, no hay mucho para hacer, esta va a ser la mejor a pesar de una latencia alta. Para una red propagada desde un solo punto, o prefijo unicast, tampoco habrá muchas opciones para elegir aunque hay más sabores. Sin embargo la mejor ruta para un prefijo propagado desde distintos puntos, llamadas redes anycast, puede ser todo un desafío.

Este desafío surge desde el inicio de Internet. Internet es una red topológica y no geográfica. Los paquetes para ir de una ciudad a otra no siguen por lo general los caminos físicos más cortos sino que son guiados por una serie de interconexiones entre distintas redes. Veamos la siguiente imagen de un país imaginario llamado Carlandia.

A pesar de que la gente de la Ciudad D se queja de que los tiempos de respuesta a Ciudad C son el doble que la Ciudad A, Carlos II, rey de Carlandia, decidió que el centro del poder estaba en la Ciudad A y que todos los enlaces de Internet deberían pasar por allí. Dejando de lado las bromas, esto sucede mucho dentro de los países reales, mucho más entre países y mucho más cuando el proveedor principal es a su vez cliente de otros proveedores. Si aparte de esto tomamos en cuenta que utilizando distintos atributos BGP una red puede decidir que la mejor ruta a un prefijo anycast es la de peor tiempo de respuesta, los problemas de latencia se hacen difíciles de resolver sin poder saber qué pasa del otro lado.

La presentación “Medición de Latencia de Prefijos Anycast con NLNOG Ring” que realicé en el marco de LACNIC41, apunta a resolver estos problemas de rutas no óptimas y entender por qué suceden y cómo podemos influir en la selección de rutas en redes de terceros. Para ello, presenté una herramienta muy útil, abierta a todos los interesados, que es el proyecto Ring de NLNOG.

¿Cuántas veces hemos llamado a amigos y colegas pidiendo una prueba de ping desde sus redes hacia un prefijo nuestro para medir la latencia? ¿Cuántas veces hemos desistido en llamarlos pensando que somos molestos? La idea detrás del proyecto Ring es muy simple: si tú nos dejas acceder a un servidor o máquina virtual en tu red, nosotros te dejamos acceder a las nuestras.

A esas máquinas tendremos acceso de root, y podremos realizar todo tipo de pruebas: ping, mtr, ssh, scp, etc. como si lo hiciéramos desde una máquina propia. También contamos con la habilidad de generar comandos simples desde un conjunto de máquinas como desde todas ellas. El siguiente es un ejemplo de un ping desde 10 máquinas miembros de Ring hacia un prefijo anycast simulado:

$ ring-ping -n 10 -v -i 2001:db8::1

hostuniversal07: 36.754 [ Australia - AS136557 ]
vultr13:         0.230  [ Mexico - AS20473 ]
isc01:           9.261  [ United States - AS1280 ]
cdw03:           10.451 [ Minnesota, United States - AS3599 ]
kamel01:         1.057  [ Sweden - AS213113 ]
kviknet01:       10.753 [ Denmark - AS204151 ]
grenode01:       9.699  [ France - AS51083 ]
leaseweb02:      0.630  [ Netherlands - AS60781 ]
fnutt01:         8.795  [ Norway - AS57381 ]
inberlin01.ring.nlnog.net: timeout

9 servers: 9.74ms average 9.26ms median
1 unreachable via: inberlin01.ring.nlnog.net

El comando ring-ping es utilizado para generar pings desde distintas máquinas hacia una IP en particular. En este caso el ping es generado en 10 máquinas al azar hacia 2001:db8::1. Dependiendo de la presencia que tenga en cada país puedo decir si la latencia es adecuada. Por ejemplo, si no tuviera presencia en Dinamarca pero si en algún lugar de Europa, los 10 milisegundos de latencia serían adecuados. Por otro lado, si tuviera presencia en Australia, dependiendo de la ciudad, esos 36 milisegundos podrían ser una alarma y entonces tendría que ver cómo AS136557 llega a mi DNS. Esto lo puede hacer simplemente accediendo a la máquina “hostuniversal07” y haciendo un mtr hacia direcciones de mis prefijos anycast.

Es decir que el proyecto Ring, nos permite ver de forma abierta cómo otras redes alcanzan los prefijos que propagamos hacia Internet ayudando entonces a mejorar la performance de nuestra red. Incluso las herramientas de RIPE Atlas son instaladas en todos los nodos RING combinando las funcionalidades de ambas plataformas. Hoy el proyecto cuenta con más de 500 organizaciones con distintos sistemas autónomos en más de 60 países.

Pero, siempre hay un pero, la cantidad de máquinas de la región LACNIC que participan del proyecto es muy baja a la fecha. Solamente 15 máquinas de las más de 600 que integran el proyecto Ring están en la región. Es por esto, que aprovecho a invitarlos a que se unan a este proyecto. Solamente necesitan proveer una máquina, que puede ser virtual, para acceder a una herramienta sumamente útil con una amplia distribución geográfica. Para sumarse a este proyecto y leer con más detalle los requerimientos y participantes, los invito a acceder a https://ring.nlnog.net/.

Puedes ver mi presentación completa aquí

Subscribe
Notify of

0 Comments
Inline Feedbacks
View all comments