Red · Looking glass

Mídelo tú mismo

Cada cifra de latencia en este sitio proviene de nuestras propias sondas, que es exactamente el tipo de afirmación que no deberías tomar como cierta. El looking glass se ejecuta desde todos los 34 sitios, no requiere cuenta, y responde a la única pregunta que importa: ¿cómo es realmente el camino entre tú y esa ciudad ahora mismo?

Flota
sitios34
Países29
capacidad4.6 Tbit/s
00

Construye el comando

Elige un sitio y una herramienta. Estos se ejecutan desde tu máquina contra nuestros hosts de prueba publicados, que es la única medición que te dice algo sobre tu propia ruta.

Herramienta
Comando
mtr -rwzbc 100 lg-ams-01.paragonvps.com
Host de pruebalg-ams-01.paragonvps.com
SitioAmsterdam, Netherlands
Archivo de pruebahttps://lg-ams-01.paragonvps.com/1g.bin

Un archivo de 1 GB de datos aleatorios incompresibles, para medir el rendimiento y no tu compresor.

Ejecuta cada uno de estos tres veces en diferentes horas antes de sacar una conclusión. Un solo traceroute durante la ventana de mantenimiento de otro no es evidencia.

01

Qué es y qué no es

Un host de sonda en cada sitio, en la misma VLAN que producción, detrás del mismo filtrado.

El looking glass es un host pequeño en cada sitio que ejecuta pruebas en tu nombre e imprime el resultado crudo. Se encuentra en la misma red que las instancias de clientes y detrás del mismo filtrado de borde, por lo que lo que mide es lo que obtendrías. Sin ruta de prueba optimizada, sin uplink separado, sin rincón tranquilo del rack.

No es un benchmark ni una herramienta de marketing. Algunos resultados son poco favorecedores: Sídney a cualquier lugar es caro en milisegundos, y Johannesburgo aún está consolidando su tránsito. Esos números están ahí porque ocultarlos sería inútil cuando cualquiera puede ejecutar la prueba.

01

Todos los 34 sitios, todo el tiempo

Incluidos los sitios de preventa. Johannesburgo ha respondido a las sondas desde antes de tener una sola instancia de pago.

02

Sin cuenta, sin registro

Consistente con el resto del servicio. La única prueba que requiere algo de ti es iperf3, y necesita un token únicamente para evitar que el equipo se use como fuente de inundación.

03

Limitado en velocidad, deliberadamente

Una prueba a la vez por dirección de origen y cuatro pruebas por minuto. Un looking glass es un vector de amplificación encantador si el operador no lo ha pensado.

04

Los resultados son tuyos

La salida es texto plano con un enlace permanente que dura treinta días. Pégalo en un ticket, o en una discusión con el equipo de red de otra persona.

02

Lo que puedes ejecutar

Cinco pruebas, elegidas porque responden a preguntas diferentes. Ejecutarlas todas prueba poco; elegir la correcta generalmente resuelve el asunto en un minuto.

01

Empieza con MTR, no con ping

Un ping te informa sobre un momento. Trescientos ciclos de MTR te dicen si la ruta es mala, ocasionalmente mala, o está bien y tuviste mala suerte.

02

Usa primero el archivo de prueba para medir el rendimiento

Una descarga de 1 GB por HTTPS reproduce lo que hace la mayoría de las cargas de trabajo reales. Si es lenta pero iperf3 es rápido, el problema es el control de congestión o los middleboxes, no la capacidad.

03

El MTU de la ruta merece noventa segundos

Una parte sorprendente de las incidencias de "el sitio carga pero las subidas grandes se quedan colgadas" terminan aquí, normalmente en un túnel que alguien olvidó entre tú y nosotros.

PruebaLa pregunta que respondeLímites
Ping ICMP¿Es alcanzable y cuál es el tiempo de ida y vuelta ahora mismo?Hasta 100 paquetes por ejecución
Traceroute (ICMP y UDP)Qué saltos toma la ruta de ida al salir de ese sitioMáximo 30 saltos, 3 sondas por salto
MTRPérdida y latencia por salto a lo largo del tiempo en lugar de en una instantáneaHasta 500 ciclos, aproximadamente 8 minutos
Objetivo iperf3Qué rendimiento puedes obtener realmente hacia ese sitioToken del panel, 60 segundos, hasta 4 flujos
Archivo de pruebaUna respuesta de rendimiento sin instalar nada100 MB y 1 GB sobre HTTPS
Sonda de MTU de rutaSi algo en el medio está consumiendo paquetes grandesInforma del tamaño más grande que sobrevive
03

Leer el resultado sin malinterpretarlo

La salida de traceroute no es una imagen de tu tráfico. Es un conjunto de respuestas de enrutadores que tenían cosas mejores que hacer, y leerla como un gráfico de latencia produce conclusiones seguras pero erróneas.

La mayoría de las quejas sobre enrutamiento que recibimos son correctas acerca del síntoma y erróneas acerca del salto.

01

Los saltos intermedios exageran

Un enrutador que responde a una sonda de traceroute lo hace en su plano de control, que está ocupado y trata ICMP como la prioridad más baja. Cuando un salto muestra 180 ms y el siguiente 14 ms, el primer enrutador estaba ocupado, no la ruta frente a él.

02

Solo la última línea es real

La pérdida que aparece en el salto seis y desaparece en el siete son respuestas limitadas en velocidad, no tráfico perdido. Cuando comienza en el salto seis y continúa hasta el destino, envíanos el resultado.

03

El DNS inverso es una pista

Los códigos de aeropuerto en los nombres de los saltos suelen estar desactualizados por años. Trátalos como una indicación de intención de quien nombró la interfaz, nunca como evidencia de geografía.

04

MPLS oculta el medio

Las rutas que cruzan un núcleo conmutado por etiquetas pueden parecer tres saltos más cortos de lo que son. La latencia sigue ahí; solo falta la honestidad sobre su origen.

05

La física establece el mínimo

Ámsterdam a Singapur es aproximadamente 168 ms y ningún acuerdo de interconexión mejorará eso de manera significativa. Si tu medición está cerca de nuestra cifra publicada, la ruta funciona correctamente y la respuesta es un segundo sitio, no una incidencia.

04

Rutas asimétricas, dónde vive la confusión

Un traceroute mide la ruta de ida y nada más. Cada número, sin embargo, incluye el viaje de regreso de la respuesta de ese salto, y el viaje de regreso puede tomar una ruta completamente diferente alrededor del planeta.

El tráfico de nosotros a ti y el tráfico de ti a nosotros son decisiones separadas tomadas por redes separadas. Nosotros elegimos lo que sale; las redes intermedias eligen lo que vuelve. La mayoría de los operadores transfieren el tráfico en la primera oportunidad, por lo que tu ruta de retorno a menudo sale de tu proveedor en una ciudad diferente de la que nuestra ruta entró.

La consecuencia visible es un salto que parece lento mientras tu tráfico real está bien. Peor es la invisible: la congestión en la ruta de retorno se manifiesta como latencia que pasarás una tarde buscando en la dirección de ida.

01

Mide siempre ambas direcciones

MTR desde tu máquina a la instancia, y MTR desde el looking glass en ese sitio de regreso a tu dirección, idealmente al mismo tiempo. La mitad de la evidencia produce media respuesta.

02

La asimetría por sí sola no es un fallo

Casi todas las rutas en internet son asimétricas y casi todas funcionan. Se convierte en un problema solo cuando una dirección está congestionada, pierde paquetes o atraviesa un filtro con estado.

03

Solo podemos influir en lo que regresa

Nuestra política de enrutamiento controla directamente la dirección de salida. La ruta de retorno cambia solo si anunciamos de manera diferente, transferimos en otro lugar o le pedimos amablemente a un par. Las tres son posibles; ninguna es instantánea.

04

Los middleboxes con estado odian la asimetría

Si ejecuta un firewall que espera ver ambas direcciones de un flujo y la ruta de retorno deja de cruzarlo, obtiene reinicios intermitentes que se ven exactamente como una falla de red. Compruébelo antes de culpar a nadie.

05

Presentar una queja de enrutamiento que se atienda

La mediana de la primera respuesta a un ticket es de 11 minutos. Una corrección de enrutamiento tarda más, porque alguien más tiene que estar de acuerdo.

  1. 01

    Descartar su propia instancia

    Compruebe la carga, el seguimiento de conexiones, los contadores de interfaz de la propia instancia y si alguna regla de filtrado suya está descartando tráfico. Algo así como uno de cada cinco informes termina aquí, y termina más rápido si usted mira primero.

  2. 02

    Recopile ambas direcciones

    Al menos 300 ciclos de MTR desde su lado y 300 desde el 'looking glass' en ese sitio, ejecutados en la misma ventana. Adjunte el enlace permanente en lugar de una captura de pantalla; necesitamos los números, no una imagen de ellos.

  3. 03

    Ponga la marca de tiempo correctamente

    UTC o un desplazamiento explícito. "Esta mañana" describe un momento para usted y un rango de once horas para nosotros, y correlacionar los datos de flujo con eso es adivinar.

  4. 04

    Diga qué cambió y cuándo

    Siempre ha sido así, o comenzó el martes. Continuo, o entre las 20:00 y las 23:00 hora local. Esa única frase generalmente decide si estamos ante un cambio de peering o ante la congestión nocturna de alguien.

  5. 05

    Envíelo al soporte

    Escriba a [email protected] o abra un ticket en el panel. Cualquier cosa que resulte ser un problema real de ruta se escala al equipo de red en la misma hora, y se le informa qué le pedimos a la otra red.

Lo que podemos hacer: reenrutar, dejar de preferir un tránsito, pedir a un peer que investigue, o moverlo a un sitio con una mejor ruta. La congestión dentro de una red que no tocamos está más allá de las cuatro opciones, y allí lo enrutamos alrededor del problema en lugar de pasar una semana teniendo razón.

06

Preguntas sobre el looking glass

Por sesenta segundos a la vez, sí. El token existe para evitar que el host se convierta en la fuente de inundación de alguien, no para racionar la medición honesta. Las pruebas sostenidas requieren su propia instancia en ambos extremos.

No debería, y si lo hace, nos gustaría saberlo. El host de prueba está en la misma VLAN y hereda la misma política. Una diferencia genuina generalmente significa una política por prefijo aplicada a su dirección, lo cual merece un ticket.

No en el looking glass público. Pídalo en un ticket con un prefijo específico y una razón, y obtendrá la respuesta, incluido qué upstream estamos prefiriendo para él y por qué.

Dentro de los límites de velocidad, sí; las pruebas son salientes e inofensivas en ese volumen. Usarlo como fuente de medición para un objetivo que usted no controla está bien. Como componente de algo más grande, no lo está.

Treinta días, luego expiran junto con la salida almacenada. Adjúntelo a un ticket mientras aún se resuelva, o pegue el texto, que preferimos de todas formas.

Listo cuando tú lo estés

Ejecute la prueba y luego elija la ciudad

La latencia que midió supera a la que alguien publicó. Una vez que los números tengan sentido, el índice de ubicaciones tiene el stock, el uplink y la capacidad de filtrado de cada sitio.