Una ruta ECMP defectuosa ECMP / link bundle member fault
ID de la causa isp-ecmp · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Los ISP y los centros de datos tienen varias rutas hacia el mismo destino y asignan una a cada conexión. Si se estropea una sola ruta, solo los jugadores asignados a ella siguen con lag.
Por qué En un tramo que agrupa varios enlaces, un enlace o un dispositivo está defectuoso o saturado → Efecto La ruta se elige según la combinación de direcciones y puertos (hash), así que solo las conexiones asignadas a esa ruta sufren pérdida y latencia → En pantalla En la misma región y con el mismo ISP, solo algunos jugadores sufren teletransporte constante. A veces se arregla al reconectar
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Tareas (Equipo de desarrollo)
Registrar estadísticas de pérdida y retransmisión por conexión para poder sacar la IP, el puerto y la hora de los afectados (en TCP, el número de retransmisiones de TCP_INFO; en UDP, calcularla con los números de secuencia que faltan).
Tareas (Equipo de infraestructura)
Reunir la IP, el puerto y la hora de los afectados y pasarlos al ISP o al centro de datos, monitorear la pérdida por ruta, medir las rutas con el mismo protocolo y puerto que el juego (mtr --tcp o --udp con --port), sacar del grupo el enlace o el dispositivo defectuoso si la ruta pasa por nuestros dispositivos.
Tareas (Externo)
Pedir al ISP que revise y reemplace la ruta defectuosa, indicar a los jugadores que de momento pueden esquivarlo reconectándose (cuando al reconectar cambia el puerto).
Cifras de referencia
Con 4 rutas, solo lo sufre más o menos una cuarta parte de los jugadores. La medición de ping puede ir por una ruta distinta a la del juego y salir perfecta.
En el gráfico
Alto solo en algunos · Pérdida/retransmisiones por conexión (por IP/puerto)
Dónde mirar
Desglosar la pérdida y las retransmisiones por conexión según IP y puerto de origen. Lanzar mtr en UDP (-u) al puerto del juego (-P) con un puerto de origen fijo (-L), y repetir varias veces cambiando el puerto de origen. Con -P y sin -L, el puerto de origen cambia en cada sonda y se mezclan varias rutas
Se confirma si
En la misma región y con el mismo ISP, solo ciertas combinaciones de puerto (o dirección) de origen pierden paquetes de forma constante, y todo va bien cuando el puerto cambia al reconectar
Se descarta si
Si va mal con cualquier puerto, apunta a congestión o a un fallo en todo un tramo
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Para que los paquetes de una conexión no lleguen desordenados, los dispositivos (ECMP, LAG) fijan una ruta por conexión según un valor calculado a partir de las direcciones y los puertos (o solo de las direcciones, según la configuración del dispositivo). Donde solo se usan las direcciones, reconectar lleva a la misma ruta y no mejora nada. Por eso, si llegan juntos reportes como “el ping está bien, pero el juego va con lag” y “se arregló al reconectar”, hay que sospechar de esta causa.
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop SelectionIETF El criterio para distinguir flujos varía según la implementación (solo la dirección de destino, el par de direcciones o también los puertos); con varias rutas, los resultados de ping y traceroute son poco confiables
mtr(8) manual page sourcemtr Opciones -u (UDP), -P (puerto de destino) y -L (puerto de origen UDP); con solo -P, el número de secuencia de la sonda va en el puerto de origen, así que cambia en cada sonda