Por que la fibra óptica de movistar va como va (twitch, latencia, juegos..)

Por que la fibra óptica de movistar va como va (twitch, latencia, juegos..)

https://share.pingplotter.com/eD3LUJQoHPv

 

A veces es mas de un enrutador, a veces pasan de 30% de packet loss, especialmente los fines de semana. El resultado es un jitter brutal y microdesconexiones (que son lo que jode twitch) y latencia absurda en juegos.

 

Me voy a pasar a ONO. Cuando se haga el cambio vuelvo por aquí y os cuento la diferencia para bien o para mal (pero vamos, tengo amigos en Madrid como yo que les va como un tiro, mitad de latencia, estable y sin estas mierdas todos los días con twitch y demás).

Mensaje 1 de 12
1.943 Visitas
11 RESPUESTAS 11

Buenas @sqraalq

 

Al margen de que quieras irte a otro ISP, lo cual siempre recomiendo a quien sea que esté descontento con el servicio que tiene (que para eso tenemos elección de mercado), creo que no entiendes bien los resultados que da un tracert o un ping, pues es lo que se puede sacar en claro de tus palabras.

 

Sobre un 30% de paquetes perdidos, como dices, la respuesta simple, rápida: Es falso. Ni un tracert ni un ping miden paquetes perdidos... bueno, no lo que tú puedes creer o interpretar con ese "paquetes perdidos". Y esto no eres tú, es un error muy muy habitual de los usuarios al usar ping/tracerts.

 

Un tracert/ping se basa en la presunción de que los nodos de red (intermedios o finales), va a reponder con mensajes ICMP Echo Reply (en caso de Ping) o ICMP TTL Exceeded (en caso de Tracert). Esta presunción es válida posiblemente para la mayoría de nodos, pero está a años luz de poder generalizarse. Cualquier servidor o nodo puede configurarse para:

 

a) Responder siempre el 100% de mensajes ICMP

b) No responder jamás con mensajes ICMP

c) Aplicar cualquier tipo de heurística, es decir, responder de forma selectiva en función de los parámetros que se quieran, como x peticiones por unidad de tiempo, según el origen de la petición, o cualquier factor que el administrador quiera

 

Esto se traduce en algo muy simple.

 

Si estamos ante el caso A, y en un entorno ideal, el Ping siempre nos devolvería una latencia y jamás perdería un solo paquete, si envia 10, le responderían con 10. Por su parte el Tracert lograría el mensaje del servidor por TTL agotado y podría conocer igualmente latencia e IP del nodo.

 

Si estamos en el caso B, el 100% de los ping enviados a dicho nodo o destino no serían respondidos, con lo que el equipo jamás podría tener idea si llegaron o no. No porque no llegasen, sino porque el equipo remoto no tiene por qué contestar a ello. Con el tracert funciona de forma similar, no habría posibilidad de calcular latencia, pero tampoco la IP del equipo, ya que este pasaría como un nodo "invisible"... sí, sabemos que está ahí porque el TTL es reducido en 1 y el siguiente nodo tiene un TTL superior, pero no podemos conocer IP, ubicación, latencia...

 

Y si estamos en el caso C, podemos mezclar A y B. Es decir, que los nodos por los que circulan tus paquetes pueden responder o no. Cuando no responden con mensajes ICMP, es lo que vemos como "Paquetes Perdidos", que no tiene absolutamente nada que ver con que exista en la red una pérdida de paquetes de datos. No existe tal pérdida, simplemente el nodo remoto no ha contestado... y ojo, no tiene por qué hacerlo, cada vez es más habitual limitar de algun modo esto, precisamente por la manía de muchos de estresar servidores y redes, inundando con tráfico ICMP estas.

 

-----------------

 

Bueno, eso en lo relativo a lo de "paquetes perdidos", que como ves es una auténtica falacia. Es más, siempre me hace gracia... algo que parece no preguntarse quienes hacen esas afirmaciones. Si realmente tu nodo 3, mirando tu captura, existiese una pérdida del 30% de paquetes... no se vería reflejada esta en los restantes nodos?? A fin de cuenta para llegar al nodo 4, deben de pasar antes por el nodo 3 ;). Simplemente el nodo 3 responde los ICMP cuando quiere y como quiere... realmente como lo hacen el resto, en función de como estén configurados.

 

Para saber y conocer REALMENTE si existe una pérdida de paquetes, es necesario realizar test específicos para ellos, en los que tanto cliente como servidor saben de antemano que paquetes se van a enviar, se establece una transferencia y se cotejan luego los datos. Y créeme, esto no es lo que haces.  Y sí, de ya te digo que la pérdida de paquetes en las redes es muy normal, hasta cierto % claro está. Si quieres ver realmente esto, puedes hacer este test, como ejemplo:

 

https://www.measurementlab.net/tools/ndt/

 

En detalles verás el % real de paquetes perdidos en el test, y me arriesgaría decir que está lejos de llegar al 1%

 

----------------

 

Respecto a la latencia o al Jittler

 

Bien, la latencia es acumulativa, significa que por cada nodo por el cual nuestros datos pasan, la latencia aumenta cada vez más, incluso por cada centímetro de cable recorrido. El Jitter no es más que la varianza de la latencia, y la usamos para ver más o menos la estabilidad de la conexión.

 

El problema, es que el ISP puede controlar su red, nada más. Más del 95% de todos los problemas de latencias que vemos aquí en el foro, son todos ocasionados por redes de terceros. Sí, algunas veces el problema está dentro de la red de Movistar, y es cuando hay que darles el tirón de oreja y ver que está pasando. Tienes el foro lleno de ello, no hace mucho por cierto vimos un problema de latencia donde realmente estaba causado por un nodo de Movistar.

 

Pero el resto 95% no se puede predecir, controlar ni hacer nada. El jittler por tanto le sucede lo mismo. Tus datos por lo general corren por la red de Movistar (tu ISP) con una latencia estable y baja (repito, por lo general), pero a medida que entran en otras redes o incluso en los servidores finales, esta se ve afectada en mucha mayor medida, haciendo que el jittler aumente considerablemente, y por supuesto tb la latencia final.

 

Siguiendo el mismo ejemplo sencillo, con la imagen que has puesto, antes de salir de la red de Movistar, tu latencia era mínima, una media de 4ms!! En el Salto 9., ya en la red de GTT salta a 10, y en la siguiente el resto.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 2 de 12
1.906 Visitas

Gracias por la contestación Theliel, varias cosas:

 

Primero, faltaría mas que las latencias promedio, que son las que salen ahí, no fueran bajas dentro de España. Por tu post supongo que no te hace falta que te explique como funciona el reenvío de paquetes en TCP, pero resumiendo, aunque haya que reenviar esos paquetes perdidos cuyo % "desconocemos", no tiene por qué ser alta, es fibra óptica, y la centralita está ahí al lado, pero eso SI genera jitter, aunque esté ahí al lado.

 

Sobre la no contestación de ICMPs, en el router (porque es una castaña) vale, en enrutadores ni de coña dejan de contestar un 30% si todo va bien. Para corroborar esto, misteriosamente cuando va mejor (entre semana) no aparece PL o es mucho mas bajo, mientras que cuando son fines de semana son varios nodos y va fatal.

 

Ahora bien, lógicamente al salir de España aumenta la latencia. Pero no es que el servicio de Movistar esté funcionando muy bien y al salir vengan los otros malvados ISPs que dan muy mal servicio, es que sencillamente, está lejos.

 

Y dices que iba bien hasta que sale de la red de Movistar. El tema es que ahí no sale, pero mira este log de hace unos días:

https://share.pingplotter.com/hhMLsEtetWv

72ms de media? En un nodo aún de Movistar? Vaya, pues no va tan bien a veces, eh? Está fallando al medir la latencia además del PL ahí? Emoticono feliz Si está relacionado con que tiren paquetes o no, eso ya tendrían que verlo ellos, pero que funciona de pena se usen las métricas que se usen...

 

Edito: https://share.pingplotter.com/hHwZ1Ud1BRe esto debería ser lo normal. Tomada a las 7 y pico de la mañana, que mucha saturación no hay. [....], si es que es clarísmamente un problema de recursos invertidos, es el obvio "bueno, cuando haya picos de uso que se jodan, damos de media un servicio medio aceptable y pista, para que vamos a gastarnos mas".

Mensaje 3 de 12
1.875 Visitas

Buenas @sqraalq

 

Primero tendríamos que definir que es una latencia alta. Realmente que sea fibra o sea cobre, la única diferencia en cuanto a latencia se refiere es precisamente la que dices, de tu casa a la central, como mucho hasta el tercer salto, nada más. Pese a ello, cualquier elemento causa latencia. Sí, en un mundo idílico todos los dispositivos de red podrían reaccionar a la velocidad de la luz y la distancia ser siempre cero, pero eso no es así.

 

Volviendo al tema... que es una latencia alta?? Es complicado responder, y aunque los Gammers me muerdan, una latencia no es alta o pequeña en función del servicio que usen, estos da igual en las redes, para ellas todo son paquetes de datos. Importa mucho más la congestión de las redes, los dispositivos en medio, los servidores... Simplemente una conexión WIFI interna hace que la latencia pueda dar saltos de 1-50ms sin problemas, imagina lo que puede suceder en la cantidad de saltos que pueden dar los paquetes.

 

No he dicho que Movistar jamás tenga problemas de latencia, de echo te he indicado que no hace ni unos días precisamente lo tratábamos aquí, que tenían algunos problemillas en unos nodos, y es más... se pasó la incidencia y se arregló un poco sobre la marcha. Pero por lo general, en comparación, esto sucede una minoría de las veces. Esto por supuesto no exime a Movistar de no liarla nunca, pero es muy facil decir: "Tengo problema de latencia..." sin ni siquiera tomarse las molestias en ver donde y por qué puede ser. Llevo por aquí algo de tiempo, te aseguro que rara es la semana que alguien no entra con problemas de latencias, y casi siempre está o en su propia red (por conexiones WIFI) o por nodos intermedios y puntos finales.

 

En cualquier modo, siempre digo lo mismo a los problemas de latencia: Poner IP y tracert, así podemos verificar los demás compañeros en nuestras líneas lo mismo, si hay un problema en la red de Movistar que no sea puntual o un pico por cualquier cosa y podemos verificarlo en cierto modo, se deja constancia y que lo miren. Y ojo, de ya te digo que lo miran y lo solucionan. A fin de cuenta es su red, y sobre ella si pueden actuar y conocer el estado en todo momento de su estructura.

 

---

 

Sobre lo que llamas de nuevo pérdida de paquetes... te repito lo anterior, haz el test que te puse y míralo por tus propios ojos. Si me pones de ejemplo el Router, más a mi favor, el propio Router por defecto PERMITE este tipo de tráfico, es decir... que por defecto si hacen un ping a tu IP desde fuera, este va a responder con un ICMP Reply :), y es tan sencillo como activar o desactivar dicha casilla en el Router para que deje de responder a los ICMP Request en particular, o incluso si se prefiere cualquier mensaje ICMP, y tu lo has dicho, es sólo un Router 🙂

 

Te puedo poner si quieres una lista inmensamente grande de este comportamiento. La no contestación de mensajes ICMP no puede verse como paquetes perdidos, es algo totalmente demencial. Evidentemente cada nodo/dispositivo de red establece el comportamiento que debe de tener ante esto... por ejemplo, es extremadamente normal poner límites del tipo permitir 5 peticiones por segundo, con lo que a más tráfico en dicho nodo más "paquetes perdidos" mostrará cualquier aplicación que realice ping a él.

 

Hay cosas que podemos estar de acuerdo o no, como por ejemplo podemos discutir que es una latencia alta o baja, pero te puedo asegurar que esto, lo creas o no, es así. Repito... haz el test que te puse anteriormente 🙂

 

Muchas veces dicen eso de: Ya, pero hay tracerts que no se hacen enviando pings, sino con paquetes TCP/UDP y pasa lo mismo... claro que pasa lo mismo, los tracert hacen uso de la respuesta ICMP TTL Exeeded del nodo/servidor, con lo que es lo mismo.

 

Piénsalo con lógica como decía antes. Si existiese un 30% en un nodo, el que sea, de pérdida de paquetes... el tráfico que circularía por el nodo siguiente tendría al menos la misma pérdida, porque cicularía también por el nodo anterior, del mismo modo que la latencia es igualmente acumulativa. Y evidentemente vemos que eso no es así.

 

Utilidades además como pingplotter o algunas combinadas que hacen tracert y luego bombardean a cada nodo por otro lado con series de ping son aun menos fiables, porque al hacer un uso más extenso de las respuestas ICMP, producen como es natural una mayor no contestaciónpor parte de los nodos/servidores en caso de tener el ratio limitado a lo que estimen.

 

Bien, un ejemplo sencillo de todo esto, realizado ahora mismo, a la hora de publicar este mensaje:

 

Traza a la dirección microsoft.com [23.100.122.175]
sobre un máximo de 30 saltos:

  1     1 ms    <1 ms    <1 ms  router.asus.com [192.168.2.1]
  2     3 ms     2 ms     2 ms  192.168.144.1
  3    10 ms    10 ms    11 ms  71-46-71-5.res.bhn.net [71.46.71.5]
  4     *        *        *     Tiempo de espera agotado para esta solicitud.
  5    12 ms    13 ms    11 ms  217.red-80-58-106.staticip.rima-tde.net [80.58.106.217]
  6    11 ms    11 ms    10 ms  216.184.113.52
  7    11 ms    10 ms    11 ms  microsoft-be9-gramadix1.red.telefonica-wholesale.net [176.52.252.9]
  8    21 ms    19 ms    18 ms  ae20-0.bcn30-96cbe-1a.ntwk.msn.net [104.44.225.11]
  9    19 ms    19 ms    19 ms  ae0-0.bcn30-96cbe-1b.ntwk.msn.net [104.44.226.33]
 10    31 ms    31 ms    32 ms  ae25-0.mrs01-96cbe-1b.ntwk.msn.net [104.44.226.37]
 11    35 ms    35 ms    35 ms  ae0-0.mrs01-96cbe-1a.ntwk.msn.net [104.44.227.12]
 12    37 ms    36 ms    36 ms  ae4-0.par02-96cbe-1a.ntwk.msn.net [104.44.227.5]
 13    40 ms    39 ms    37 ms  ae3-0.pra-96cbe-1a.ntwk.msn.net [204.152.141.244]
 14    49 ms    48 ms    48 ms  ae27-0.lon04-96cbe-1b.ntwk.msn.net [104.44.227.112]
 15   153 ms   151 ms   153 ms  be-8-0.ibr02.nyc04.ntwk.msn.net [104.44.5.28]
 16   151 ms   153 ms   152 ms  be-4-0.ibr02.was05.ntwk.msn.net [104.44.4.28]
 17   150 ms   149 ms   149 ms  be-3-0.ibr02.bn1.ntwk.msn.net [104.44.4.27]
 18   150 ms   149 ms   150 ms  be-1-0.ibr01.bn1.ntwk.msn.net [104.44.4.62]
 19   148 ms   148 ms   148 ms  be-3-0.ibr02.atb.ntwk.msn.net [104.44.4.48]
 20   156 ms   154 ms   156 ms  be-1-0.ibr01.atb.ntwk.msn.net [104.44.4.38]
 21   152 ms   154 ms   153 ms  be-6-0.ibr02.sn4.ntwk.msn.net [104.44.4.47]
 22   160 ms   160 ms   160 ms  ae82-0.sn4-96cbe-1b.ntwk.msn.net [104.44.9.91]
 23     *        *        *     Tiempo de espera agotado para esta solicitud.
...

Se queda ahí... ya sea porque el salto 23 realmente es el nodo final y el servidor bloquea las contestaciones ICMP, o puede que incluso después de ese nodo existan 50 más donde todos ellos bloquean el tráfico ICMP, no lo podemos saber. El nodo 4 por contra es de Movistar, y tampoco contesta, no podemos saber su IP ni sacar ninguna información de él, simplemente sabemos que existe porque cuando se envió un paquete con TTL de +1 el siguiente respondió,

 

A efectos de tracert/ping, tanto el nodo 4 como el 23 de mi tracert, tendrían en este caso concreto un 100% de paquetes perdidos. Este es un extremo, es decir, cuando no se contesta ninguna petición. Muchas veces esto no es así, y la contestaciones es como digo variable. Ambos comportamientos es totalmente normal y esperado.

 

Resultado ahora mismo de NDT:

 

TCP receive window: 261360 current, 261360 maximum
0.00 % of packets lost during test
Round trip time: 30 msec (minimum), 81 msec (maximum), 40 msec (average)
Jitter: -
0.00 seconds spend waiting following a timeout
TCP time-out counter: 231
178 selective acknowledgement packets received

No duplex mismatch condition was detected.
The test did not detect a cable fault.
No network congestion was detected.

0.4544 % of the time was not spent in a receiver limited or sender limited state.
0.5115 % of the time the connection is limited by the client machine's receive buffer.
Optimal receive buffer: - bytes
Bottleneck link: -
178 duplicate ACKs set

Que por cierto, todo hay que decirlo, es la 1º vez que  hago un test real que mida paquetes perdidos y de un 0.0%, siempre existe un % más o menos aceptable, se ve que hoy las cosas funcionan bien ;).

 

Edito: Por cierto... estaba haciendo diferentes test ya de paso para comprobar el bufferbloat y otros, ahora que se ha pasado a los 50Mb como base a la fibra quería ver como está al menos mi OLT... y al menos por mi zona las cosas han mejorado bastante, ya sea equipamiento nuevo en la zona o a una mejora en las infraestructuras, estoy teniendo los mejores resultados que he tenido nunca, espero que no sea sólo la hora del día.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 4 de 12
1.848 Visitas

Buenas de nuevo Theliel,

 

El router deja de contestar icmps a veces pese a estar configurado para hacerlo porque, como dije, es una castaña, lo cual es medio razonable teniendo en cuenta lo que les cuesta darle uno a cada uno de sus millones de usuarios; hablamos de millones de euros de diferencia. Esto no tiene por qué ser así con enrutadores de ISPs. Si dejan de contestar icmps lo mas probable es que sean paquetes perdidos y estén saturados. No lo puse como ejemplo de nada.

 

Hay nodos que no contestan, como tu mismo mencionas sobre el tracert que has mostrado. Pero lo de que hay nodos que contestan "a veces si y a veces no".. Me gustaría saber de donde sacas esos datos de configuración.

 

La "demostración" que das:

"Si existiese un 30% en un nodo, el que sea, de pérdida de paquetes... el tráfico que circularía por el nodo siguiente tendría al menos la misma pérdida, porque cicularía también por el nodo anterior, del mismo modo que la latencia es igualmente acumulativa. Y evidentemente vemos que eso no es así."

es una falacia: Que en un momento determinado haya un 30% de perdida de paquetes en un nodo no significa ni muchísimo menos que todos tus paquetes previos y posteriores vayan a pasar por ese nodo; las conexiones no son circuitos virtuales, los paquetes se envían mediante enrutamiento dinámico, como puede apreciarse con utilidades de las que llamas no fiables, o si quieres, repitiendo tracert a los mismos destinos y viendo por donde pasas.

 

Que menciones que alguna gente viene aquí a quejarse cuando lo que pasa es que tienen el router en la otra punta de la casa y paredes forradas de papel albal, exagerandolo un poco,.. Me da la impresión de que pretendes desvirtuar los datos que exponen la existencia de un problema ajeno a los usuarios.

 

De la latencia superior a 70ms en un nodo que está a menos de 5km de mi casa no dices nada. De que tanto esas respuestas a icmps como la latencia aumenten perceptiblemente fines de semana, y se reduzcan a horas nocturas entre semana, no dices nada tampoco.

 

En serio me dirías que tu piensas que no tiene que ver con picos de uso y cuanta capacidad quieren ofrecer?

 

PS: Para que no te maten los gamers, se dice con una M, no con dos XD Término desafortunado en mi opinión tanto con una como con dos en cualquier caso; debería tomar la gente un poco de consciencia como usuarios, y exigir un mínimo de calidad, usen el servicio para lo que lo usen.

Mensaje 5 de 12
1.823 Visitas

Buenas @sqraalq

 

El propio router, dependiendo de cual tengas, tiene reglas en el Firewall para delimitar las peticiones que se contestan :), no digo que en el que usas tú tenga dichas reglas, pero te puedo mostrar al menos 2 modelos de Movistar que sí lo hacen. De memoria incluso, aunque puedo equivocarme porque me falla, permite un burst de 5 por cada 30 seg... creo, como te digo no lo tengo ahora mismo delante.

 

Sobre de donde saco los datos?? en cualquier lado, es el ABC de como se gestiona una red o un nodo, te lo podrá confirmar con seguridad cualquier técnico de Movistaro de cualquier otro ISP. Te puedo poner si quieres ejemplos a patadas de rutas/trazas de que esto es así, incluso reglas en Iptables establecidas en muchos servidores para tener este comportamiento. No es que sea un ejemplo, es que puedo ponerte miles 🙂

 

No es una falacia lo del 30%, es que de nuevo no sabes interpretar los datos o no quieres. Tu propia captura lo evidencia. Tu dejas pingplotter o cualquier otra app funcionando para recolectar datos... si las rutas cambiasen en ese momento, el tracert lo registraría, y aparecería otra ruta diferente!! Que sean dinámicas y que mañana puedan cambiar, no significa que mientras esté realizando el tracert/ping cambie. De echo, cancélalo, vuelvelo a lanzar, y tendrás seguramente lo mismo.

 

Dicho de otro modo... sí, todos los paquetes que estás enviando pr oese tracert/ping están pasando TODOS por esas rutas, por esos nodos. Sigo pensando que el problema es el mismo, una mala interpretación de los datos. No existe tal 30% de paquetes perdidos, y te lo puedo demostrar gráficamente, técnicamente, y con los datos que quieras, y te lo podrá confirmar igualmente cualquier técnico que tenga acceso a la red.

 

En ningún  momento desoigo los problemas de los compañeros, de echo cuando tengo tiempo atiendo a TODOS del mismo modo. Jamás presupongo que el usuario es un experto y por tanto ayudo del mejor modo posible, y eso implica muchsa veces ver le estado de su propia casa. De nuevo, puedo ponerte si quieres decenas de post sobre ello en este mismo foro. No he dicho jamás que las pesonas se inventen los problemas, y sí, como digo existen problemas de latencia de todo tipo, pero cada problema hay que mirarlo de forma independiente y ver que está pasando, y casi todos son exentos de la red de Movistar, en este caso.

 

Claro que me he pronunciado sobre latencia del tracert que has mostrado, y te lo repito sino lo has leído:

 

He dicho que cuando se detecta un rpobleam de latencia que está en la propia red de Movistar, lo mejor que se puede hacer es exponer tracert y destino que se estaba traceando. Así TODOS podemos comprobarlo igualmente con nuestras líneas y ver si el problema es puntual debido a una saturación dada o una sobrecarga concreta, lo cual se resuelve por lo general en segundos/minutos, o si es un problema REAL que pueda existir en dicho nodo y está afectando realmente a la red.

 

Estos casos EXISTEN, son los menos, pero claro que los hemos visto, y los reportamos, y se solucionan.

 

Por cierto, como dato curioso a todo esto... creo que estás usando pingplotter para ello si no me falla la vista... dices que lo que digo me lo "invento"? Curiosamente ellos mismos, los de PingPlotter tienen este bonito artículo:

 

http://www.pingman.com/kb/24

 

Curioso, verdad?? El mismo programa que usas tiene un documento que dice exactamente lo mismo que te he dicho anteriormente, aunque dicho de otro modo:

 

"The only hop that matters is the final destination. If you're happy with the latency and packet loss being seen at the final destination, then none of the other hops matter.

Some servers (and some routers) may specifically block (or down-prioritize) ICMP echo requests, or might do the same where TTL=0. These routers (or the final destination) might show 100% packet loss, or high packet loss and latency."

 

En cristiano... que medir el porcentaje de paquetes perdidos en función de un tracert/ping es cuanto menos absurdo, a menos claro está, como es natural, que los datos de todo el tracert/ping muestren un comportamiento así.

 

Espero que ahora sí, podamos dejar el tema zanjado, sino me crees a mi a lo mejor crees lo que dicen los creadores del mismo programa que usas 🙂

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 6 de 12
1.806 Visitas

Buenas Theliel,

 

Sigues sin dar datos de como configuran sus enrutadores para contestar a icmps (Y dudo mucho que vaya a aparecer alguien de movistar para contarnoslo :D)

 

Lo del 30% si es una falacia, no sabes como funciona el enrutamiento dinámico de paquetes. Para mas inri, dices: "si las rutas cambiasen en ese momento, el tracert lo registraría, y aparecería otra ruta diferente!!". Bien, es que APARECE UNA DIFERENTE. En pingplotter puedes ver como cada segundo prácticamente aparecen nuevos nodos en el camino y desaparecen otros, con el mismo destino claro. Y con tracert como te he dicho también, si haces unos cuantos.

 

Dices: "Dicho de otro modo... sí, todos los paquetes que estás enviando pr oese tracert/ping están pasando TODOS por esas rutas, por esos nodos". Todo eso es erroneo.

 

https://www.techopedia.com/definition/19047/dynamic-routing

 

Y si no crees que movistar y el resto de ISPs lo usen, usa una herramienta o haz unos cuantos tracert, no tardas nada.

 

Sobre postear aquí tracerts y demás, tienes muchos post de otra gente y alguno mio, como tu bien dices, cada semana tienes unos cuantos. Y muchos de ellos muestran problemas. ¿Estarán teniendo todos problemas con wifi?

 

Sobre el artículo ese, comprendo lo que quieren decir y no digo que sea mentira, ni que lo que tu dices sea mentira. Ahora bien, usemos la cabeza, la gente no se queja aquí porque de casualidad no tienen otra cosa que hacer con su vida y han instalado un programa o se han puesto a hacer tracerts, y han visto que un nodo da determinado packet loss.

"Now, you may see packet loss or latency at the final destination." ES QUE ESTO PASA. "If you do, then it's time to look at some of the prior hops to see where this packet loss and/or latency was first introduced." Y ahí está el fallo/la solución.

 

Básicamente si si hay problemas de latencia/PL al destino, no me creo que los paquetes perdidos en pings a nodos intermedios sean no respuestas intencionadas a icmps. No le veo mucho sentido a pensar eso cuando, como dice el artículo, las cosas no están funcionando como debieran.

 

"If you're happy with the latency and packet loss being seen at the final destination, then none of the other hops matter."

Claro, porque aquí hay mucha gente feliz con su fibra óptica, y no posts con decenas de gente diciendo que ellos también tienen el problema.

 

No es que no te crea, Theliel, es que te equivocas, y a mi ver eres tu el que en parte no quiere/en parte no sabe interpretar los datos que tenemos.

Mensaje 7 de 12
1.788 Visitas

Buenas @sqraalq

 

Por ponerte un ejemplo absurdo y tonto:

 

iptables -I INPUT -p icmp -m hashlimit --hashlimit-name icmp --hashlimit-mode srcip --hashlimit 3/second --hashlimit-burst 5 -j ACCEPT

 

En este caso sería un filtro por IP, o si quieres un filtro global, mi propio Router posee dicha regla por defecto, aunque en el mío permite un burst de 5

 

iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

 

O si lo prefieres en IOS (Cisco):

 

ip icmp rate-limit unreachable df log 1100 12000

 

Reglas de este tipo están enla inmensa mayoría de todos los Routers convencionales. Lo puedes complicar lo que quieras, con QoS para delimitar el burst en función de la carga del servidor, ser más restrictivo, ser menos... lo que quieras. Y repito, esto en un simple router doméstico.

 

Creo que el que no sabe bien como funciona eres tú. Claro que se usa enrutamiento dinámico, Movistar y posiblemente cualquier red del mundo. Protocolos como RIP y tantos otros se encargan de ello. Eso no significa que en una misma comunicación te vaya tirando los datos por un lado o por otro. Que en un momento dado/concreto puda enviar un paquete pro un lado y otro por otro... si, es posible... ahora, si crees que en una misma comunicación con un destino concreto cada paquete va por un lado... no tienes mucha idea, me temo.

 

Sobre los otros post... no, no he dicho que todos tengan problemas de WIFI, creo que he sido bastante expecífico, pero te lo repito si quiers, no me cuesta nada. CADA CASO DE LATENCIA HAY QUE MIRARLO Y VERLO. Por cada caso que me pongas aquí de hilo en el que se muestre que el problema está en la red de Movistar, te pongo yo 10 o 20 en los que el problema no está en su red. Venga, busca, a ver cuantos encuentras. Eso no quiere decir que no existan, sino que son los mínimos. Las personas preguntan y entran porque no son expertos, y no tienen que serlo, y por eso se les contesta y trata como mejor podemos, ya sean los técnicos otros compañeros o quien sea. Y por que un usuario diga: "tengo un problema de latencia" no quiere decir que sea problema de Movistar.... puede serlo, por supuesto, pero ahí tienes los datos, te repito... busca en el foro, por cada 1 que encuentres te pongo 10.

 

Y sobre el artículo... no, no pasa eso. De nuevo no hay mayor ciego que el que no quiere ver. En tu último salto tienes según la app un 100% porque ese nodo no responde, al igual que no responden los que te puse anteriormente en mi tracert a Microsoft. La pérdida de paquetes, al igual que la latencia es acumulativa, así de simple, eso significa que si por ejemplo en el salto 2 tenemos un 30% REAL, en el 3º tendríamos como mínimo un 30%, y en el 4º como mínimo otro 30%... Ni siquiera en el caso NO REAL de que cada paquete fuese por un lado totalmente diferente tendrías esas lecturas... que casualidad!! hay un pico en un nodo concreto que está muy por debajo y no se refleja en los otros!!

 

"When you do a traceroute, you send a packet to the destination with a low time to live number in the header. A router in the path will subtract one from the TTL and if the TTL Is 0, it drops the packet and sends an ICMP message back saying "time exceeded." Traceroute starts sending a packet with TTL of 1 and increments each time to discover the hops. When we see packets dropped in a traceroute, high latency numbers etc., it does not always indicate a real problem. Most Internet border routers are "big" routers; they will have something called the forwarding plane, which is the part responsible of sending/receiving the packets passing through the router. Then we have the control plane, which is the "router." Even in a 7600 it's only a 1200Mhz RISC processor, and it's the one that is responding to pings and sending TTL expired messages. As with anything, TTL expired has been exploited for a DoS attack on routers so it's usually rate limited; so is ICMP and other stuff that could impact the control plane of the router.  The router will answer when it feels like answering these messages. If you ping a router you might see jumps in response time and that is by no mean indication of how it is performing. It could be some indication on the housekeeping of the control plane, but not if it's overloaded. "Routers are usually lazy answering pings""

 

Por si quieres otra buena lectura, a fin de cuentas el saber no ocupa lugar:

 

https://blog.thousandeyes.com/limitations-of-icmp-based-network-measurements/

 

(Vaya... dicen que el 80% del tráfico ICMP se balancea?? no lo sé, no se de donde habrán sacado los datos sinceramente, será un 80% o no, pero seguro que se equivocan también)

 

Los técnicos de Movistar lo que no van a poder hacer como es natural explicarte las reglas que usan sus nodos para el tráfico ICMP porque es información como comprenderás confidencial, pero cualquira de ellos podría sin problemas confirmar todo lo que te estoy diciendo... claro que podrás creerlos a ellos también o no.

 

Por mi parte asunto concluido. Repito, cree lo que te quieras creer :), por suerte en esta vida todos tenemos la libertad de creer lo que se quiera. En lo personal?? me es totalmente indiferente, es más, te repito, vete a ONO si no estás contento con el servicio recibido, paséate por los foros de cualquier ISP para ver siempre las mismas preguntas y problemas... etc etc etc.

 

Saludos y suerte.

 

 

 

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 8 de 12
1.775 Visitas

Buenas Theliel,

 

Nunca dije que no se puedan configurar, dije que desconozco si lo hacen. No se que sistema operativo usarán, pero desde el SO también se puede configurar la respuesta a los icmp. Pero vaya, que se pueda no significa que lo hagan, ni que lo hagan como tu dices, obviamente.

 

"Que en un momento dado/concreto puda enviar un paquete pro un lado y otro por otro... si, es posible... ahora, si crees que en una misma comunicación con un destino concreto cada paquete va por un lado... no tienes mucha idea, me temo."

No te voy a contestar nada diferente, no es plan de repetirnos, coge una herramienta o haz unos cuantos tracert seguidos y mira como cambia el camino tu mismo.

 

"por cada 1 que encuentres te pongo 10."

No digo que no, tampoco. Pero como tu mismo dices, muchas veces si es problema de movistar.

 

"eso significa que si por ejemplo en el salto 2 tenemos un 30% REAL, en el 3º tendríamos como mínimo un 30%, y en el 4º como mínimo otro 30%..."

En los paquetes que pasan por el nodo del salto 2, si. Dado que, insisto, el camino cambia constantemente, no.

Por ejemplo: Si un 1% de los paquetes que mandas pasan por el nodo X, y el nodo X tiene un 30% de PL, significa que el 100% de tus paquetes tendrán al menos un 30% de PL? Obviamente no.

 

"The router will answer when it feels like answering these messages" esto lo ha escrito un chimpancé, no un informático, salvo que esté haciendo aposta un intento de poesía ingenieril muy malo (probablemente sea eso), o el mismo sea el que ha diseñado/configurado el enrutador, o esté suponiendo saturación permanente del mismo.

 

Gracias por el link.

 

Y si, asunto concluido por mi parte también. En lo personal, estoy viendo si no me capan con algún tipo de permanencia y me voy. Si vas como dices a los foros de otros ISPs verás que no tienen estos problemas, casualmente no aparecen allí ni muchísimo menos los que aparecen aquí a quejarse. O si hablas con gente que use otros ISPs pregúntales por la latencia promedio y compara.O pregúntales si twitch, sus juegos, etc van peor los fines de semana o no.

 

Vaya, que nos repetimos, gracias por tus respuestas Theliel. Bai bai.

 

Mensaje 9 de 12
1.760 Visitas

El servicio de internet ofrecido por Movistar y el soporte que se ofrece en este foro me hace sentir vergüenza.

twitch sigue fallando

Mensaje 10 de 12
1.687 Visitas

a ver si algunos entendeis lo que hace movistar.

 

estamos como si fuera una gran red local, entre nosotros y dentro de su red ( y servicios propios) va todo como un cohete, pero como queramos usar servicios externos ahi pone su aduana-embudo y si no pagan pone el canuto estrecho para [....].

 

mientras la CMT permita este atropeyo seguiremos sufriendo esto.

Mensaje 11 de 12
1.642 Visitas

Estos días no sé que ocurre pero esta funcionando fatal el online.. se nota muchísimo, y sobre el QoS..segun tenía entendido ya viene de "serie" para que no ralentice los juegos..

Mensaje 12 de 12
1.628 Visitas