Buenas pere.vaider
No me sale le mensaje en el foro, pero en la notificación del correo si me llegó. No sé si lo habrás eliminado o algún otro problema. En cualquier caso te contesto.
Para entender que se interpreta con "paquetes perdidos" hay que entender como funciona Ping/Tracert. Es un error muy habitual, y no es que realmente no signifique eso, significa eso pero de otra cosa. Todo ello es debido al protocolo especial ICMP, que se usa para diagnóstico de red, que no tiene absolutamente nada que ver con el tráfico normal.
Un ping. Un ping es una herramienta que lo que hace es enviar un paquete especial usando el protocolo ICMP, específicamente envía un paquete llamado "Echo Request", algo así como "Solicitud de Eco". Ese paquete especial lo que hace es "inducir" al destino a responder con un "Echo Reply", también protocolo ICMP. Así medimos la latencia, porque el PC pone el cronómetro en cuanto envía el Echo Request, y lo detiene en cuanto ha recibido el Echo Reply. El tiempo que ha tardado la contestación es lo que medimos como latencia, que en realidad es el tiempo que tarda el paquete en llegar al destino, y que el destino nos responda.
¿Que tiene esto de malo? Nada, es un protocolo maravilloso, pero se abusa también de él. Y que sucede?? Que cualquier nodo o servidor final puede sencillamente bloquear las respuestas ICMP. Es decir, que cuando le llega un "Echo Request", no responde. Algunos nodos/servidores hacen un bloqueo total de ello, y lo vemos porque directamente no hay nunca retorno, con lo que las utilidades ¿que nos van a mostrar? que hay 100% de paquetes perdidos. Si en vez de bloquear totalmente las peticiones priorizan el tráfico ICMP, o lo discriminan, o hacen bloqueos parciales (por ejemplo, bloqueo 2 de cada )... vemos valores supuestamente de pérdidas de paquetes.
En realidad, en dicho ejemplo, no se ha perdido ningún paquete. El paquete llegó perfectamente, sencillamente el nodo/servidor no respondió al Echo porque no le dio la gana, cosa que es habitual, para ahorrarse una buena porción de tráfico.
Como sabemos que es una discriminación de tráfico ICMP y cuando no?? Pues muy simple también. Una pérdida de paquetes real en la red es acumulativa. Si existiese en algún momento un agujero de un 10% de pérdida (por poner un número), en el siguiente salto tendría que existir un % similar. Esto es obvio, si tienes un agujero por el que se caen 10 de cada 100 SIEMPRE, en todos los saltos siguientes y en el destino final vas a seguir viendo solo 90, porque los otros 0 se cayeron por atrás.
No te voy a explicar como funciona un tracert para no alargar el hilo, pero tb usa ICMP para descubrir los nodos de red intermedios, va incrementando el valor del campo TTL de un paquete desde 1, para forzar a los nodos intermedios a descartar el paquete por TTL cumplido, lo que provoca (de nuevo si no se bloquean contestaciones ICMP) que el servidor/nodo responda con un mensaje ICMP de TTL excedido(Time Exceeded) al origen, con lo que el origen puede conocer la IP del nodo intermedio porque el paquete de TTL excedido procede del nodo que descartó el paquete. Vemos que un nodo bloquea este tipo de prácticas cuando llegamos a un salto y no tenemos IP de él, es como un fantasma que sabemos que está ahí simplemente porque sabemos que hay un nodo después, pero por nada más.
Conclusión?? No existe tal pérdida de paquetes, no es real, hay en algunos nodos una discriminación de dicho tráfico, nada más. Es verdad que algunos nodos solo discriminan el tráfico ICMP cuando la red está mas cargada, lo cual si nos puede servir a veces de indicador de la carga de la red si algunos nodos están soltando lastre, pero no porque exista tal % de paquetes perdidos, repito, no hay tal pérdida.
La pérdida de paquetes en la red local es diferente y depende de que sea o porqué sea, se verá reflejada hacia abajo en el tracert o no. En el segundo que has puesto, yo me decantaría por uno de estos dos motivos
1º. Una sobrecarga puntual del Router, en ese momento estaba algún equipo de la red con tráfico intenso, y sin buenas políticas QoS hay exceso de datos y hay que soltar paquetes. Piensa en un barril con un pequeño grifo debajo del todo. Empiezas a meter líquido a una rapidez de X, y el grifo lo abres de tal forma que coincida con la cadencia de meter líquido dentro. El barril jamás se llenará porque ambos van a la misma velocidad. El barril es grande, incluso no pasa nada si cierras un poco el grifo durante un tiempo... después puedes abrirlo más y el sobrante que hay en el barril puede salir fuera si la salida es más rápida que la entrada. ¿Pero que pasa cuando el barril se llena? Si la entrada sobrepasa la salida y se termina de llenar el barril sin dejar que se vacíe un poco, rebosa. Eso son los paquetes que se pierden. Esto suele pasar en momentos puntuales, generalmente en subidas intensas más que en descargas.
2º. El otro famoso motivo es saturación del Router por bombardeo de algún dispositivo de la red, generalmente el culpable número uno son los Switch mal configurados. Un Switch te puede dejar seca la red por muchos motivos, ya sea provocando tormentas broadcast/multicast, loops, ataques a uno mismo de amplificación... hay que tener cuidado con ellos, es preferible siempre pagar algo más por un Router con más capacidad de configuración y dedicarle tiempo a él, que ir a lo rápido.
Obviamente pueden ser otros dispositivos, pero los Switch ganan por goleada por fallos de configuración, en el caso de Movistar lo más habitual es por mala configuración del tráfico IGMP (que no ICMP), que es el protocolo que controla por así decirlo las transmisiones en multicast.
