Perdida de paquetes con fibra simétrica 600 megas

[MomoDarkmotta]

Buenas a todos, soy nuevo en el foro, me presento me llamo Marc y somos usuarios en mi casa desde hace muchísimos años y casi siempre hemos tenido problemas con la compañía y me iría de movistar pero en mi pueblo no llega otra cosa!

Enfin iremos al grano, mi problema esta con perdida de datos, les llame diciendo como siempre que hago puedas y tengo perdida de datos!

Os lo muestro a continuación.

Prueba contra 8.8.8.8 google

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 99 | 67 | 1 | 0 | 5 | 5 | 5 |
| No response from host - 100 | 73 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 74 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 71 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 53 | 0 | 0 | 0 | 0 | 0 |
| 108.170.253.241 - 95 | 72 | 4 | 0 | 14 | 17 | 17 |
| 108.170.234.231 - 96 | 73 | 3 | 0 | 13 | 16 | 16 |
| 108.170.234.231 - 96 | 66 | 3 | 0 | 17 | 17 | 17 |
| dns.google - 99 | 67 | 1 | 0 | 16 | 16 | 16 |

99% perdidas contra google increíble.

Vamos a probar contra una ip de un servidor de counter strike.

| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 14 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 13 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 14 | 0 | 0 | 0 | 0 | 0 |
| 78.red-81-41-230.staticip.rima-tde.net - 87 | 15 | 2 | 0 | 15 | 17 | 17 |
| No response from host - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 16 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 11 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 14 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 15 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 13 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 15 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 13 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 14 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 10 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 15 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 14 | 0 | 0 | 0 | 0 | 0 |
| ip8.ip-178-32-241.eu - 88 | 16 | 2 | 0 | 10 | 19 | 19 |

o dios mio 88% paquetes perdidos

Vamos con otras pruebas!

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=16.192 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=16.766 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=16.681 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=16.221 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=16.639 ms

64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=42.505 ms ----> pico

64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=16.618 ms

64 bytes from 8.8.8.8: icmp_seq=7 ttl=54 time=16.638 ms

64 bytes from 8.8.8.8: icmp_seq=8 ttl=54 time=16.637 ms

64 bytes from 8.8.8.8: icmp_seq=9 ttl=54 time=16.731 ms

64 bytes from 8.8.8.8: icmp_seq=10 ttl=54 time=42.868 ms ----> pico

64 bytes from 8.8.8.8: icmp_seq=11 ttl=54 time=16.538 ms

64 bytes from 8.8.8.8: icmp_seq=12 ttl=54 time=16.418 ms

64 bytes from 8.8.8.8: icmp_seq=13 ttl=54 time=30.714 ms----> pico

64 bytes from 8.8.8.8: icmp_seq=14 ttl=54 time=16.404 ms

64 bytes from 8.8.8.8: icmp_seq=15 ttl=54 time=46.149 ms ----> pico

64 bytes from 8.8.8.8: icmp_seq=16 ttl=54 time=16.904 ms

64 bytes from 8.8.8.8: icmp_seq=17 ttl=54 time=16.435 ms

64 bytes from 8.8.8.8: icmp_seq=18 ttl=54 time=16.470 ms

64 bytes from 8.8.8.8: icmp_seq=19 ttl=54 time=16.694 ms

Como se observa no es estable y ahora los picos da bajos pero los suele de dar de mas

Otra prueba ahora contra uno de los dns de Movistar el 80.58.61.250

iMac-de-darkmotta:~ darkmotta$ ping -c20 80.58.61.250

PING 80.58.61.250 (80.58.61.250): 56 data bytes

64 bytes from 80.58.61.250: icmp_seq=0 ttl=248 time=8.071 ms

64 bytes from 80.58.61.250: icmp_seq=1 ttl=248 time=7.991 ms

64 bytes from 80.58.61.250: icmp_seq=2 ttl=248 time=7.970 ms

64 bytes from 80.58.61.250: icmp_seq=3 ttl=248 time=8.147 ms

Request timeout for icmp_seq 4 ----> que paso aquí? perdidas,,,

Request timeout for icmp_seq 5 -----> que paso aquí? perdidas,,,

64 bytes from 80.58.61.250: icmp_seq=6 ttl=248 time=8.202 ms

64 bytes from 80.58.61.250: icmp_seq=7 ttl=248 time=8.274 ms

64 bytes from 80.58.61.250: icmp_seq=8 ttl=248 time=8.530 ms

64 bytes from 80.58.61.250: icmp_seq=9 ttl=248 time=8.364 ms

64 bytes from 80.58.61.250: icmp_seq=10 ttl=248 time=8.055 ms

64 bytes from 80.58.61.250: icmp_seq=11 ttl=248 time=8.393 ms

64 bytes from 80.58.61.250: icmp_seq=12 ttl=248 time=8.163 ms

64 bytes from 80.58.61.250: icmp_seq=13 ttl=248 time=8.500 ms

64 bytes from 80.58.61.250: icmp_seq=14 ttl=248 time=8.855 ms

64 bytes from 80.58.61.250: icmp_seq=15 ttl=248 time=8.155 ms

64 bytes from 80.58.61.250: icmp_seq=16 ttl=248 time=8.214 ms

64 bytes from 80.58.61.250: icmp_seq=17 ttl=248 time=8.599 ms

64 bytes from 80.58.61.250: icmp_seq=18 ttl=248 time=8.043 ms

64 bytes from 80.58.61.250: icmp_seq=19 ttl=248 time=8.876 ms

--- 80.58.61.250 ping statistics ---

20 packets transmitted, 18 packets received, 10.0% packet loss

Aqui 10% paquetes perdidos...

la misma prueba 5 minutos después para que veáis que no siempre los pierdo en el mismo paso sino que pasa en diferentes también,....

iMac-de-darkmotta:~ darkmotta$ ping -c20 80.58.61.250

PING 80.58.61.250 (80.58.61.250): 56 data bytes

64 bytes from 80.58.61.250: icmp_seq=0 ttl=248 time=11.647 ms

64 bytes from 80.58.61.250: icmp_seq=1 ttl=248 time=8.304 ms

64 bytes from 80.58.61.250: icmp_seq=2 ttl=248 time=7.996 ms

64 bytes from 80.58.61.250: icmp_seq=3 ttl=248 time=7.790 ms

64 bytes from 80.58.61.250: icmp_seq=4 ttl=248 time=31.928 ms----> pico

64 bytes from 80.58.61.250: icmp_seq=5 ttl=248 time=8.262 ms

64 bytes from 80.58.61.250: icmp_seq=6 ttl=248 time=8.103 ms

64 bytes from 80.58.61.250: icmp_seq=7 ttl=248 time=8.067 ms

64 bytes from 80.58.61.250: icmp_seq=8 ttl=248 time=8.045 ms

Request timeout for icmp_seq 9 ---->perdida total

64 bytes from 80.58.61.250: icmp_seq=10 ttl=248 time=8.755 ms

64 bytes from 80.58.61.250: icmp_seq=11 ttl=248 time=8.381 ms

Request timeout for icmp_seq 12 ---->perdida total

64 bytes from 80.58.61.250: icmp_seq=13 ttl=248 time=8.532 ms

64 bytes from 80.58.61.250: icmp_seq=14 ttl=248 time=8.223 ms

64 bytes from 80.58.61.250: icmp_seq=15 ttl=248 time=7.869 ms

64 bytes from 80.58.61.250: icmp_seq=16 ttl=248 time=8.386 ms

64 bytes from 80.58.61.250: icmp_seq=17 ttl=248 time=8.201 ms

64 bytes from 80.58.61.250: icmp_seq=18 ttl=248 time=8.086 ms

64 bytes from 80.58.61.250: icmp_seq=19 ttl=248 time=8.098 ms

--- 80.58.61.250 ping statistics ---

20 packets transmitted, 18 packets received, 10.0% packet loss

lo mismo.... 

la ultima prueba que os mostrare es con un benchmark de dns, veréis que la que sale en rojo esta en conflicto de dns de Movistar... i la que va medio bien tb de cortes perdidas y picos .... vaya tela Movistar como os luces...eso si mis 197euros cada mes me los cobras eeeh.

Prueba contra un dns principal de Movistar
80.58.61.250 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
+ Cached Name | 0,005 | 0,039 | 0,293 | 0,071 | 88,6 |
+ Uncached Name | 0,019 | 0,089 | 0,277 | 0,083 | 92,3 |
+ DotCom Lookup | 0,034 | 0,048 | 0,072 | 0,010 |91,7 |
---<-------->---+-------+-------+-------+-------+-------+
250.red-80-58-61.staticip.rima-tde.net
TELEFONICA_DE_ESPANA, ES

Como podeis ver tengo problemas, cuando llamo a los incompetentes que me cojen el teléfono no saben muchas veces ni que es un ping imaginaros XD i ui el tracert ya menos hahaha, a lo que vamos, veo que por aquí el foro os ayudáis mucho y hay algún que otro buen técnico de movistar, haver en mi caso que tengo que hacer??? no me vengáis con reset de router ni [....] que ya me habéis cambiado uno este martes pero e ojo uno igual -xD ... penoso... en fin acabo de reportar mis problemas como lo solucionamos??? llendome de la compañía no???

venga un abrazo!!!

P.D pruebas echas por cable cat.6e directo al router con todo parado!

[Theliel]

Buenas @MomoDarkmotta 

Por lo general suelo contestar este tipo de mensajes con total diligencia y empatía, pero me molesta mucho los malos modos. Y es que arremetes contra la compañía (que la verdad es que patina muchas veces) y tildas al 1004 de "incompetentes" por no saber siquiera que es un ping (y a lo mejor es verdad que no lo saben, por lo que dicen muchos la verdad es que el 1004 va regular).

Pero a lo que voy es que si aplicando exactamente tu mismo sesgo, me pregunto si te gustaría que, yo por ejemplo, usuario/cliente también de Movistar, te llamase incompetente a ti, no por no saber lo que es un ping, sino por no saber diferenciar un salto local de uno externo, y por no saber diferenciar un problema que podría tener la red de Movistar (que con los datos que aportas no existe) a un problema que, de echo, tienes en tu propia red. Hay que tener cuidado siempre con los modos y el buen hacer, o muchas veces puede jugar en nuestra contra, compañero.

Dicho eso, te contesto, ahora sí, de forma diligente.

Tus pruebas muestran exactamente el problema que tienes, y sí, tienes un problema. Pero al contrario de lo que crees o piensas, no está en la red de Movistar, está en tu casa, de puertas para dentro:

| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 99 | 67 | 1 | 0 | 5 | 5 | 5 |
| No response from host - 100 | 73 | 0 | 0 | 0 | 0 | 0 |

Ese salto, es la latencia y paquetes perdidos entre el equipo que realiza la prueba y el Router, y en ese salto tienes un 99% de pérdidas. Es ahí donde se están perdiendo, no en Google, no en la centralita de Movistar, no en la red de Movistar. Se están perdiendo casi en su totalidad en algún punto entre tu Router, medio de conexión con el  Router y tu equipo, ni más ni menos.

Llegados a este punto, y en orden de que es lo habitual que pueda producir estos problemas tenemos. Copio/pego lo mismo que le puse a otro compañero hace unas horas

1º. WIFI/PLCs: No lo dices, pero paquetes perdidos, latencia alta en picos... esa es la firma inequívoca de usar una conexión WIFI o por medio de un PLC. Y esto obviamente incluye cualquier conexión que se haga a un AP conectado al Router, a un repetidor que a su vez va conectado al Router... etc etc. Esto básicamente no se puede evitar mientras uses WIFI, tu propio entorno es el que va a dictaminar a cada segundo lo bien o mal que va a funcionar. En caso de WIFI es aun peor porque cada equipo que conectas a tu red afecta inmediatamente a la latencia y a otros posibles problemas. Y eso sin hablar ya de posibles interferencias tb del entorno. El entorno es totalmente dinámico y cambiante, puede variar de un día a otro, de un segundo a otro. Depende de tus propios dispositivos, tus aparatos electrónicos, los materiales de la casa, los adornos, el mobiliario... y 100 metros a la redonda de cualquier dispositivo electrónico que igualmente emita ondas de radio, como equipos de los vecinos, por poner solo un ejemplo. Solución?? La única forma de asegurar un jitter bajo (estabilidad por así decirlo de la latencia), latencia baja y estabilidad general es cable directo, todo lo demás es hablar para poco, opciones muchas, que te aseguren una buena conexión solo cable.

2º. Te conectas por cable, pero a través de un Switch intermedio: Saturación del propio Switch, generalmente por no ser compatible y tener habilitado IGMP Snooping, el cual es imperativo. Solución?? Un switch decente

3º. Te conectas con cable directo al Router, pero sigue fallando... problema con el equipo, algún software instalado que está interfiriendo, arrancar en modo seguro con conexión a la red a ver si mejora.

4º. Un equipo de tu red está provocando un DDOS en el Router, haciendo que esté totalmente saturado y colapsado.

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

Una conexión entre cualquier equipo de tu red al Router, por cable obviamente, tendría que dar valores de 0%, con una latencia mínima de 0ms, media de 0-1ms y no mas alta que 3-4ms de forma totalmente estable.

Da igual el Router de Movistar que tengas, todos son en ese aspecto decentes, en el 99% de los casos estás en uno de los 4 puntos anteriores, si sabes en cual te encuentras ya tenemos la solución, si crees que no te encuentras en ningun de ellos dime cual podemos descartar seguro y buscamos otros posibles motivos que acaparan el 1% restante, que seguirá siendo de cualquier modo un problema de tus equipos/red, no de tu conexión.

[alpripe]

No creo que estés en situación de llamar incompetente a alguien y mucho menos de generalizar de esa manera por no saber que es un ping, cuando en tu mensaje leo un "lléndome" y un "haver" que me han provocado un importante sangrado de ojos. La respuesta la tienes arriba. A lo mejor no controlas tanto como te piensas...

[MomoDarkmotta]

Primero de todo pedir disculpas por haberme exaltado, pero esquema cuando llamas a un técnico de Movistar por teléfono hay cada uno,,, pero bueno pido perdón,

segundo lo que me dices de que el 192.168.144.1 es problema mío no estoy de acuerdo, tal ve si y me equivoque, mira paso lo que dijo también un chico hace un tiempo

Buenos dias,

Ayer sobre las 10:00 me llamo un technico de Leon, sobre el problema, le explique que desde el dia 31 del mes pasado cuando me cambiaron de 100/10 a 300/30 empezaron los problemas y lo mas ovio era que cuando realizaba un trace me aparecia un IP que no existe (192.168.144.1)  despues del IP de la Default Gateway (192.168.1.1 ) del router, y rima no solia aparecer hasta el 4 salto si tenia suerte , ya que en la mayoria de ocasiones transcurrian muchos saltos antes de aparecer rima como he mencionado anteriormenete. Esto ensi provoca una perdida enorme de paquetes que a su vez provocaba una transmision de datos muy baja al punto de solo tener 80K de transmission con USA.

Lo que el technico, el cual creo que se llamaba JunaCarlos, hizo fue mover mi registro de IP fijo de la red virtual en los equipos de Valencia a los equipos de Leon.

Desde entonces tengo los 300/30 contratados ( comprovado a lo largo de ayer y de hoy), y lo mas importante es que cuando realizo un trace, el primer salso es 192.168.1.1 (Defaul Gateway en el router) el segudo salto es rima, no hay perdida de paquetes y la transmision de datos a USA es ahora correcta unos 2-3 Mbs

Perdonar que no mandara este correo ayer, pero estuve progamando curtafuegos, servidores, etc todo el dia, ya que al moverme mi IP de Valencia a Leon, tuvieron que cambiarme la IP fija que tenia.

Saludos

nose podriamos mirar haver si es eso'?? tengo solo el dhcp del router configurado del rango 192.168.1.33 al 192.168.1.100, mi pregunta es como esque da esa ip? i porque hay gente como ese chico que tiene el mismo problema? 

y otra vez os pido perdón

[MomoDarkmotta]

https://comunidad.movistar.es/t5/Soporte-Fibra-y-ADSL/Perdida-de-paquetes-192-168-144-1/td-p/2410259

aqui dejo el enlace con personas con el mismo problema

[alpripe]

La cosa es que tu tienes un 99% de pérdidas en el salto al router (192.168.1.1). Ahí es donde creo que está el problema.

Lo de la dirección 192.168.144.1 es totalmente normal, es una IP de salida gateway que tiene configurada el router para el tráfico de internet en clientes que tengas IP dinámica  (en mi linea si hago un tracert también pasa por esa IP), no tiene nada que ver con el servidor dhcp que es el que le da ip's a tus equipos. Por lo tanto no te preocupes por esa IP... más no podría ayudarte.

Si entras a la tabla de encaminamientos del router podrás ver:

192.168.144.1

0.0.0.0

255.255.255.255

UH

0

6

ppp0.1

SAludos

[MomoDarkmotta]

doi un poco mas de datos haver si podemos encontrar soluciones por favor!!!

                           My traceroute  [v0.93]

iMac-de-darkmotta.local (192.168.1.42)                 2020-04-25T21:55:15+0200

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                       Packets               Pings

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. 192.168.1.1                       0.0%    59    4.5   5.6   4.4  31.2   3.7

 2. 192.168.144.1                     0.0%    59    6.2   6.8   5.8  32.5   3.4

 3. 229.red-81-41-229.staticip.rima- 75.9%    59    6.5   7.4   6.2  17.3   2.9

 4. 70.red-81-41-230.staticip.rima-t  0.0%    59   15.2  18.0  14.8  58.5   8.2

 5. 1.red-80-58-106.staticip.rima-td  0.0%    59   14.4  17.2  14.4  38.4   5.1

 6. 176.52.253.93                     0.0%    59   15.0  16.4  14.7  43.2   4.5

 7. google-be4-grcmadno1.net.telefon  0.0%    58   15.1  17.6  14.8  56.0   7.0

 8. 108.170.253.241                   0.0%    58   16.5  17.6  15.9  31.2   3.3

 9. 108.170.230.191                   0.0%    58   15.8  17.0  15.8  32.5   2.8

10. dns.google                        0.0%    58   15.5  16.4  15.0  44.5   4.9

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

[MomoDarkmotta]

Otra prueba pero veis ahora tengo 0% perdidas en la 192.168.1.1 i en la 192.168.1.44 pero ya luego cuando pasa a fuera de mi casa hay perdidas, a que se debe y que tengo que hacer !! help me pleaseeee:)

My traceroute  [v0.93]

iMac-de-darkmotta.local (192.168.1.42)                 2020-04-25T22:01:17+0200

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                       Packets               Pings

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. 192.168.1.1                       0.0%    35   12.7   7.2   4.6  36.5   6.4

 2. 192.168.144.1                     0.0%    35    6.0   6.5   6.0   8.3   0.5

 3. 225.red-81-41-229.staticip.rima- 67.6%    35    6.4   6.8   6.2   8.0   0.6

 4. 78.red-81-41-230.staticip.rima-t  0.0%    35   20.3  18.3  14.7  34.3   5.4

 5. 61.red-81-46-7.customer.static.c  0.0%    35   16.9  17.2  14.4  48.5   6.5

 6. gramadix2-ae10.net.telefonicaglo 42.9%    35   16.0  20.8  15.8  50.4   8.4

 7. (waiting for reply)

 8. 151.101.134.133                   0.0%    35   16.2  17.5  15.4  49.5   6.0

[MomoDarkmotta]

Por cierto chicos aclaro que el no hice las primera puerta del test en el primer post porque usaba winmtrportable usando win en un mac y creo que eso daba fallos, ahora estos últimos informes que pase es con mtr de mac usando el comando sudo /usr/local/sbin/mtr (host)

creo que los primeros informes daban error por eso, ahora como podéis comprobar no da fallos ni al 192.168.1 ni al 168.1.141.1 así quue viene de fuera no? o perdonar mi ignoracnica, haver si podemos solucionarlo muchas gracias chicos

[MomoDarkmotta]

perdón estava en wifi en estas ultimas ahora en cable

 My traceroute  [v0.93]

iMac-de-darkmotta.local (192.168.1.42)                 2020-04-25T22:49:52+0200

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                       Packets               Pings

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. 192.168.1.1                       0.0%    32    8.2   8.3   8.0   9.5   0.3

 2. 192.168.144.1                     0.0%    31    9.8  10.0   9.4  11.6   0.5

 3. 225.red-81-41-229.staticip.rima- 64.5%    31   10.0   9.9   9.4  10.2   0.2

 4. (waiting for reply)

 5. 90.red-81-46-1.customer.static.c  0.0%    31   12.6  14.6  12.2  26.3   2.5

 6. 118.red-80-58-82.staticip.rima-t  0.0%    31   12.3  12.5  11.7  15.6   0.9

 7. 86.red-81-46-75.customer.static.  0.0%    31   12.1  12.7  11.8  26.7   2.6

 8. 250.red-80-58-61.staticip.rima-t  3.2%    31   12.5  13.3  11.5  54.3   7.8

no se desde mi ignorancia, mi pregunta es no podría pasar mi linea por otra ruta diferente y no tener esas perdidas en el punto 3?

fua necessito ayudaaaaa amigos

[Theliel]

Buenas @MomoDarkmotta 

Esa pérdida no es real, y es totalmente normal.

La pérdida de paquetes real, al igual que la latencia, es acumulativa. Es dcir, que si existiese realmente una pérdida de un 65% en el salto 3, en el salto 4 y siguientes habría una pérdida similar, digo similar porque como son paquetes diferentes y el número de paquetes que podemos lanzar son limitados, afectan cuestiones estadísticas.

Pero que es lo que pasa?? En los siguientes saltos tienes un 0%. Eso nos dice que no existe tal pérdida. Para ver los paquetes perdidos mira siempre al final, el  salto final. Si pone 0% es que no tienes pérdida real. Si pone por ejemplo un 20% al final, habría que analizar el resto hacia atrás poco a poco.

Bien, la explicación?? Es sencillo

Las herramientas tipo Ping o Tracert funcionan gracias a un protocolo especial llamado ICMP. Los tracert y los ping funcionan de forma totalmente diferente, pero ambos usan ICMP para medir la latencia (ping) o descubrir nodos intermedios (tracert). Es un tráfico que solo se usa para fines de testeo y comprobaciones, y el problema es que el abuso que se hace de ellos obliga a veces a que algunos nodos prioricen su tráfico, o lo discriminen del modo que sea, algunas veces sencillamente se bloquea del todo, por ejemplo mira el salto4. En tus datos solo pone que existe un salto 4 pero no hay respuesta de nada. Por qué?? Porque el tracer envió un paquete con TTL 4 obligando a ese nodo a responder con un ICMP de TTL sobrepasado, pero ese nodo no respondió, está configurado para no responder ICMP por TTL superado. El siguiente paquete se envió con TTL5, así que pasó por el nodo 4 sin ningún problema, y el nodo 5 si respondió con TTL superado, haciendo "visible" el nodo 5 para que se llevasen a acabo las pruebas de ping.

Obviamente el nodo 4 existe, de lo contrario no habría podido verse el nodo 5, simplemente el nodo 4 bloquea las respuestas ICMP por TTL. Lo mismo sucede en el nodo 8, no pones el resto de los nodos pero seguramente son 0%, sobre todo el final. Tres cuartos de lo mismo.

Pero esto tiene mucho sentido si lo piensas. Si realmente se perdiese en el salto 3, pongamos para redondear un 50%, en el salto 4 al llegar allí el 50% se habría perdido en el salto anterior, con lo que allí aparecería también dicha pérdida reflejada. Cuando vemos pérdidas de paquetes reales se ve perfectamente esto, es más, podemos identificar perfectamente donde se inició la pérdida, y vemos como esa pérdida se arrastra siempre hacia abajo.

Conclusión?? No tienes ninguna pérdida de paquetes en tu línea compañero, aunque tus ultimo tracert sigue teniendo unos resultados horribles para tu conexión con el Router, no digo de pérdida, sino de latencia:

1. 192.168.1.1                       0.0%    32    8.2   8.3   8.0   9.5   0.3

un 8.3ms de media y un mejor de 8ms es un desastre, no sé si de nuevo estabas usando WIFI... si es así, desde luego yo me lo pensaría dos veces para jugar o cualquier app en tiempo real. Si es por cable revisa tu equipo, 8ms en el primer salto es algo sinceramente muy alto

[MomoDarkmotta]

• Primero thiael muchas gracias por respondee pro el ultimo punto que comentas el de la ida i vuelra de 8 que dices que es horrible es por cable, e leido que a alguna gente se le saca el punto 192.168.144.1 y va directo al punto 3, osea algo asi, tu tienes constancia de eso???? Eso es viable?
• He visto pruebas de gente que los tracert  les va ee 192.168.1.10 y el paso 2 ya por rima y no pasa por la 192.168.144.1
• Otra cosa thiael, los dns 80.58.61.250 cuando les hago prueba la me da muchissimos fallos en cambio la dns 254 no, en el benchmark la 250 llega a decir unrealiable, trneis mas dns de movistar??? Y porque funcions la 254 i el dns 25p ds la tira de fallos? Puedo poner de dns principal em 254 que no ds fsllos i de secundsrio por ejemplo el 1.1.1.1 o tienen q ser el primario i el secundario los mismos dns?
• Como puedo mirar si mi router esta saturado?
• Y os vuelvo a pedir perdon y muchas gracias por la ayuda

[Theliel]

Buenas @MomoDarkmotta 

Compi, preguntar, mientras que nunca se pierda la educación y con buenas formas, por mi al menos puedes preguntar las veces que quieras, que si tengo un ratito y lo leo, encantado de poder echar un cable

-El salto 192.168.144.1 es el servidor PPPoE, dependiendo del Router y de la centralita aparecerá o no, pero es irrelevante, el tráfico pasa por él aunque no aparezca

-Respondida también en el caso anterior.

-Las DNS de Movistar suelen tener unos tiempos de respuesta bastante buenos, pero en mi experiencia al menos no son muy confiables, por supuesto cada cual que haga lo que estime. Puedes usar los servidores DNS que quieras, el secundario, el principal o cualquier otro diferente. Si tu Router enruta bien 1.1.1.1 puedes usarla también.

-Pues si estás conectado por cable y tienes de media 8ms...  te conectas por medio de algún Switch?? es más, tienes algún Switch/AP/PLC/Repetidor en la red? en caso todo negativo, es tu equipo el que se comporta incorrectamente, no por pérdida de paquetes como decía, sino por lo que tarda en procesar los paquetes

[MomoDarkmotta]

Buenos dias thiael, en la red hay dos AP videobrodge pero tienen cerrado el dhcp lo del el router lo que no entiendo es como tu dices el tiempo de respuesta! Mirare haver cosas de mi equipo!! Gracias por tu tiempo si encuentro solucion avisooo y usare las de 1.0.0.1 i la 1.1.1.1 me van mejor mas estable gracias thiael

[Theliel]

Buenas @MomoDarkmotta 

Da igual que tengan o no DHCP habilitado para ello, si los has colocado tu, y no son de Movistar, asegúrate que ambos posee IGMP Snooping tanto por WIFI como en el Switch, o podrían estar saturando.

[Técnico-Movistar]

Hola @MomoDarkmotta, bienvenid@ a la Comunidad Movistar. 

Te pedimos disculpas por la demora en contestar y las molestias ocasionadas. ¿Podrías confirmarnos si con la información que ha facilitado @Theliel (muchas gracias por tu aportación), ha queda resuelta tu consulta, por favor?

Un saludo. 

Angela.

[Técnico-Movistar]

Buenos días @MomoDarkmotta,

No hemos recibido respuesta por tu parte.

¿Ya tienes resuelta la consulta? Si es así, te agradeceríamos que en el hilo que has abierto, pulsases en el botón “Aceptar como solución” del post en el que se ha resuelto tu caso. Es importante para nosotros que vuestras consultas queden resueltas y para otros usuarios es útil utilizar estas respuestas para sus dudas.

En caso contrario, háznoslo saber para que podemos seguir ayudándote.

Nos mantenemos a la espera de tu respuesta.

Un saludo,

Natalia.

[Técnico-Movistar]

Buenas tardes @MomoDarkmotta

No hemos recibido mas comunicaciones por tu parte, por lo que creemos que ya no necesitas mas ayuda desde el foro.

Por nuestra parte, procedemos al cierre de este hilo, para cualquier otra duda o consulta en el futuro ya sabes donde encontrarnos.

Un saludo.

Nacho.