Abelshadrim Publicado ayer a las 03:02 Publicado ayer a las 03:02 (editado) Buenas noches. ¿Cómo están? Desde hace tiempo vengo teniendo problemas de conexión con el servidor. Esto es algo que fui viendo que le esta pasando a muchos otros argentinos, sin tener nada que ver con la conexión propia de cada uno de ellos. Yo actualmente estoy utilizando un VPN para conectarme evitando un nodo particular de Beauharnois, Quebec, Canadá que esta dando problemas. Identifique dicho nodo realizando algunas pruebas, revisando la interacción entre los paquetes de datos desde mi red y los distintos nodos a través de los que se realiza la conexión con el servidor. Actualmente el único nodo que esta causando problemas es el " be102.bhs-g1-nc5.qc.ca " ubicado en Beauharnois, Quebec, Canadá. Cita || Host - % | Sent | Recv | Best | Avrg | Wrst | Last | | 192.168.0.1 - 0 | 295 | 295 | 0 | 0 | 1 | 1 | | 10.51.224.1 - 0 | 295 | 295 | 5 | 11 | 19 | 13 | | 100.72.6.197 - 0 | 295 | 295 | 5 | 12 | 23 | 12 | | 192.168.65.209 - 4 | 257 | 247 | 6 | 12 | 22 | 12 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | 100.72.9.81 - 0 | 295 | 295 | 5 | 12 | 23 | 21 | | 10.242.12.68 - 99 | 60 | 1 | 0 | 12 | 12 | 12 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | be9400.ccr81.mia03.atlas.cogentco.com - 1 | 291 | 290 | 137 | 146 | 206 | 143 | | be2085.ccr41.mia03.atlas.cogentco.com - 0 | 294 | 294 | 137 | 144 | 198 | 142 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | be100-1290.mia-mi1-bb1-a9.fl.us - 0 | 294 | 294 | 162 | 168 | 176 | 172 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | was1-vin1-vac1-a75-1-firewall.wa.us - 0 | 294 | 294 | 159 | 166 | 180 | 166 | | was1-vin1-vac1-a75-3.wa.us - 0 | 294 | 294 | 162 | 166 | 176 | 167 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | was-nva1-sbb1-nc5.va.us - 1 | 290 | 289 | 161 | 167 | 176 | 166 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | be102.bhs-g1-nc5.qc.ca - 0 | 294 | 294 | 171 | 204 | 573 | 379 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | | Request timed out. - 100 | 59 | 0 | 0 | 0 | 0 | 0 | Realice otras pruebas y los datos fueron muy similares: Cita 1 1 ms 1 ms 1 ms 192.168.0.1 2 7 ms 10 ms 16 ms 10.51.224.1 3 10 ms 12 ms 12 ms 100.72.6.197 4 12 ms 11 ms 13 ms 192.168.65.209 5 * * 13 ms 192.168.65.49 6 * * * Tiempo de espera agotado para esta solicitud. 7 * * * Tiempo de espera agotado para esta solicitud. 8 13 ms 20 ms 13 ms 100.72.9.81 9 * * * Tiempo de espera agotado para esta solicitud. 10 * * * Tiempo de espera agotado para esta solicitud. 11 * * * Tiempo de espera agotado para esta solicitud. 12 143 ms 143 ms 145 ms be9400.ccr81.mia03.atlas.cogentco.com [154.54.89.53] 13 142 ms 143 ms 142 ms be2085.ccr41.mia03.atlas.cogentco.com [154.54.167.185] 14 * * * Tiempo de espera agotado para esta solicitud. 15 170 ms 168 ms 168 ms be100-1290.mia-mi1-bb1-a9.fl.us [192.99.146.112] 16 * * * Tiempo de espera agotado para esta solicitud. 17 170 ms 166 ms 167 ms was1-vin1-vac1-a75-1-firewall.wa.us [178.32.135.117] 18 168 ms 170 ms 169 ms was1-vin1-vac1-a75-3.wa.us [178.32.135.114] 19 * * * Tiempo de espera agotado para esta solicitud. 20 * * * Tiempo de espera agotado para esta solicitud. 21 176 ms 167 ms 166 ms was-nva1-sbb1-nc5.va.us [198.27.73.219] 22 * * * Tiempo de espera agotado para esta solicitud. 23 * * * Tiempo de espera agotado para esta solicitud. 24 182 ms 401 ms 175 ms be102.bhs-g1-nc5.qc.ca [198.27.73.204] 25 * * * Tiempo de espera agotado para esta solicitud. 26 * * * Tiempo de espera agotado para esta solicitud. 27 * * * Tiempo de espera agotado para esta solicitud. 28 * * * Tiempo de espera agotado para esta solicitud. 29 * * * Tiempo de espera agotado para esta solicitud. 30 * * * Tiempo de espera agotado para esta solicitud. No se si ya lo tienen identificado o si ya se encuentran trabajando en ello, pero les comparto esto por si les sirve de algo. Como dije antes, yo estoy utilizando una VPN con la que pude rutear mi conexión con el server a través de otros nodos para evitar la perdida de paquetes de datos. ¡Saludos! Editado ayer a las 03:13 por Abelshadrim Silverproud y giantgx 1 1
Administrador Ryuzaki Publicado ayer a las 03:36 Administrador Publicado ayer a las 03:36 Hola @Abelshadrim Gracias por la investigación y aporte que has realizado. El problema es en ciertos nodos de conexión de USA que puede propagarse a la zona norte de América, del cual nosotros no poseemos ningún control. Tanto jugador como servidor somos externos a dicho inconveniente y el mismo afecta por igual otras comunidades/servicios. Nuestro control sólo abarca el punto final, el servidor. Las entidades que son responsables de los nodos problemáticos ya están al tanto de lo que sucede y se encuentran activamente trabajando en solucionarlo. Abelshadrim y Silverproud 1 1
Administrador Torete Publicado ayer a las 05:04 Administrador Publicado ayer a las 05:04 Hola @Abelshadrim, Tras analizar los datos que proporcionaste, te detallo a continuación lo que realmente ocurre en cada tramo, para que tengas un panorama claro. 1. Sobre los saltos con “Request timed out” o pérdidas puntuales La mayoría de los routers intermedios que ves en la traza no están fallando, sino que despriorizan el ICMP (el tipo de paquete que usan las herramientas como WinMTR y tracert). Esto significa que pueden responder tarde o directamente no responder, sin que eso afecte al tráfico real. Lo importante es que, cuando un salto “pierde” ICMP, pero los siguientes saltos responden bien, eso confirma que no es un problema real de la ruta, solo un filtro o prioridad baja para ICMP. Esto ocurre en varios de los saltos que mencionaste. 2. Saltos donde sí hay anomalías reales Hop 4 y 5 (segmento local / primer tramo del ISP) Presentan un porcentaje de pérdida ICMP de entre 3 % y 18 %. Es una pérdida leve a moderada, pero no se propaga a los saltos posteriores, lo cual indica que: Son pequeñas inestabilidades locales del ISP, Pero no son la causa del problema internacional que describes. Hop 9 Muestra pérdida muy alta de ICMP, pero nuevamente los saltos siguientes responden correctamente, por lo que este equipo también está filtrando/despriorizando ICMP. No es un origen de pérdida en tráfico real. Hop 24 – be102.bhs-g1-nc5.qc.ca (Beauharnois, QC, Canadá) Este es el único salto que presenta un comportamiento anómalo sostenido: Latencia media elevada, Picos de 400–500 ms, Variabilidad brusca entre respuestas. Y lo más importante: Esa inestabilidad sí se refleja en los siguientes saltos. Eso significa que aquí no hablamos de despriorización de ICMP, sino de: Congestión, Saturación del PoP, O degradación real del equipamiento o del enlace. Este tramo corresponde al backbone de OVH en Beauharnois, y efectivamente es uno de los puntos donde se han detectado incidentes intermitentes, indicados aquí: Tu solución temporal con VPN es totalmente válida, ya que evita el tramo afectado y fuerza rutas alternativas más estables. Si necesitas una opción gratuita y segura, puedes probar WARP de Cloudflare: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/download-warp/ Nos encontramos monitoreando varios PoPs desde antes de publicar la noticia enlazada, y trasladando la información al equipo responsable para que trabajen en resolver esta situación. Es importante destacar que no se trata de un problema de UltimoWoW, y no es un problema aislado que afecte únicamente a UltimoWoW, sino que impacta también a muchas otras comunidades e incluso, en ocasiones, a plataformas de gran tamaño. Saludos. Abelshadrim 1 Normas | Denuncias | Reclamaciones | FAQ
Abelshadrim Publicado ayer a las 12:02 Autor Publicado ayer a las 12:02 hace 6 horas, Torete dijo: Hola @Abelshadrim, Tras analizar los datos que proporcionaste, te detallo a continuación lo que realmente ocurre en cada tramo, para que tengas un panorama claro. 1. Sobre los saltos con “Request timed out” o pérdidas puntuales La mayoría de los routers intermedios que ves en la traza no están fallando, sino que despriorizan el ICMP (el tipo de paquete que usan las herramientas como WinMTR y tracert). Esto significa que pueden responder tarde o directamente no responder, sin que eso afecte al tráfico real. Lo importante es que, cuando un salto “pierde” ICMP, pero los siguientes saltos responden bien, eso confirma que no es un problema real de la ruta, solo un filtro o prioridad baja para ICMP. Esto ocurre en varios de los saltos que mencionaste. 2. Saltos donde sí hay anomalías reales Hop 4 y 5 (segmento local / primer tramo del ISP) Presentan un porcentaje de pérdida ICMP de entre 3 % y 18 %. Es una pérdida leve a moderada, pero no se propaga a los saltos posteriores, lo cual indica que: Son pequeñas inestabilidades locales del ISP, Pero no son la causa del problema internacional que describes. Hop 9 Muestra pérdida muy alta de ICMP, pero nuevamente los saltos siguientes responden correctamente, por lo que este equipo también está filtrando/despriorizando ICMP. No es un origen de pérdida en tráfico real. Hop 24 – be102.bhs-g1-nc5.qc.ca (Beauharnois, QC, Canadá) Este es el único salto que presenta un comportamiento anómalo sostenido: Latencia media elevada, Picos de 400–500 ms, Variabilidad brusca entre respuestas. Y lo más importante: Esa inestabilidad sí se refleja en los siguientes saltos. Eso significa que aquí no hablamos de despriorización de ICMP, sino de: Congestión, Saturación del PoP, O degradación real del equipamiento o del enlace. Este tramo corresponde al backbone de OVH en Beauharnois, y efectivamente es uno de los puntos donde se han detectado incidentes intermitentes, indicados aquí: Tu solución temporal con VPN es totalmente válida, ya que evita el tramo afectado y fuerza rutas alternativas más estables. Si necesitas una opción gratuita y segura, puedes probar WARP de Cloudflare: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/download-warp/ Nos encontramos monitoreando varios PoPs desde antes de publicar la noticia enlazada, y trasladando la información al equipo responsable para que trabajen en resolver esta situación. Es importante destacar que no se trata de un problema de UltimoWoW, y no es un problema aislado que afecte únicamente a UltimoWoW, sino que impacta también a muchas otras comunidades e incluso, en ocasiones, a plataformas de gran tamaño. Saludos. Buen día Torete, gracias por tomarte el tiempo de contestar y explicar esto. Estaba al tanto de que los timeout no representan un problema y que el resto de saltos entre nodos estaban ok ya que los mismos no se traspasaban a los siguientes nodo, salvo con el de Canadá, pero gracias por explicarlo de forma sencilla para que el resto pueda entenderlo también. No había visto el post que me compartiste, disculpen! Ryuzaki también gracias por contestar! Saludos!
Administrador Ryuzaki Publicado ayer a las 19:00 Administrador Publicado ayer a las 19:00 @Abelshadrim ¿Podrías compartirnos cuál VPN estás utilizando?
Publicaciones recomendadas
Crea una cuenta o conéctate para comentar
Tienes que ser miembro para dejar un comentario
Crear una cuenta
Regístrate para obtener una cuenta nueva en nuestra comunidad. ¡Es fácil!.
Registrar una nueva cuentaConectar
¿Ya tienes una cuenta? Conéctate aquí.
Conectar ahora