[Cerrado] Pérdida de paquetes

Estado
Cerrado para nuevas respuestas.
Hola,

Desde aproximadamente las 11.15h estoy observando malfuncionamiento de la red de Jazztel: algún router intermedio está perdiendo paquetes. Llevo más de media hora intentando que me atienda alguien en el 1565 y cuando al fin lo consigo resulta que el primer paso del procedimiento que me pide que siga el técnico es resetear mi router (que no reiniciar), cosa que lógicamente no puedo hacer porque perdería toda mi configuración.

Lo comento por aquí para ver si otros usuarios han observado anomalías y en qué zona están situados. Yo estoy en la central de Madrid/San Blas, y como he dicho, MI CONEXIÓN PIERDE PAQUETES, y como consecuencia, me va todo fatal: de los 6 Mbps a los que ha sincronizado mi router obtengo un flujo sostenible de tan solo 250 kbps (kbits, no kbytes!!). He reiniciado mi router varias veces y el problema persiste, así que tiene pinta de que algún router interno que les ha cascado o habría que reiniciar...

C:\Documents and Settings\roman>ping -t www.rediris.es

Haciendo ping a babia.rediris.es [130.206.1.22] con 32 bytes de datos:

Respuesta desde 130.206.1.22: bytes=32 tiempo=29ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Tiempo de espera agotado para esta solicitud.
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Tiempo de espera agotado para esta solicitud.
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Tiempo de espera agotado para esta solicitud.
Respuesta desde 130.206.1.22: bytes=32 tiempo=29ms TTL=251
Tiempo de espera agotado para esta solicitud.
Respuesta desde 130.206.1.22: bytes=32 tiempo=31ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=31ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=31ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=30ms TTL=251
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Tiempo de espera agotado para esta solicitud.
Respuesta desde 130.206.1.22: bytes=32 tiempo=31ms TTL=251
Respuesta desde 130.206.1.22: bytes=32 tiempo=29ms TTL=251

Estadísticas de ping para 130.206.1.22:
Paquetes: enviados = 23, recibidos = 16, perdidos = 7
(30% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 29ms, Máximo = 31ms, Media = 30ms
Control-C
^C
C:\Documents and Settings\roman>

En el lado de mi red (la LAN de mi casa) no hay saturación ni nada por el estilo (no sólo porque lo haya comprobado en mi ordenador, sino que incluso mirando el ping anterior cualquier técnico decente lo va a saber interpretar sin problemas ;-)).

En fin, ahí queda reportado eso... Espero que mañana cuando me levante alguien se haya molestado en arreglarlo ;-)

Saludos,
-r
 
Más datos

Por cierto, se me olvidó comentar que el nivel de enlace (sincronización de línea) es correcto:

Line Rate - Upstream (Kbps): 512
Line Rate - Downstream (Kbps): 6144

Por dar alguna idea del segmento de red en el que me encuentro, mi IP actual es 87.217.129.X y mi gw es 87.217.128.1.

El ping al gw es correcto:
C:\Documents and Settings\roman>ping -t 87.217.128.1

Haciendo ping a 87.217.128.1 con 32 bytes de datos:

Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=28ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=32ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254
Respuesta desde 87.217.128.1: bytes=32 tiempo=29ms TTL=254

...

El ping a cualquier sitio de Internet pierde paquetes...

Si intentamos afinar un poquitín, veamos el traceroute:
C:\Documents and Settings\roman>tracert www.rediris.es

Traza a la dirección babia.rediris.es [130.206.1.22]
sobre un máximo de 30 saltos:

1 <1 ms <1 ms <1 ms 192.168.0.230
2 29 ms 29 ms 29 ms 1.128.217.87.dynamic.jazztel.es [87.217.128.1]
3 * * * Tiempo de espera agotado para esta solicitud.
4 29 ms 30 ms * 133.216.106.212.static.jazztel.es [212.106.216.1
33]
5 30 ms 30 ms 29 ms 145.216.106.212.static.jazztel.es [212.106.216.1
45]
6 30 ms 28 ms 29 ms 102.216.106.212.static.jazztel.es [212.106.216.1
02]
7 30 ms * 30 ms rediris-1.espanix.net [193.149.1.26]
8 37 ms 30 ms * XE4-0-0.EB-IRIS4.red.rediris.es [130.206.250.2]

9 29 ms 30 ms 30 ms XE3-0-0-264.EB-IRIS6.red.rediris.es [130.206.206
.133]
10 30 ms 30 ms 29 ms babia.rediris.es [130.206.1.22]

Traza completa.


El ping empieza a ir mal a partir de (e incluyendo a) 212.106.216.133.

Espero que ayude.
-r
 
Yo estoy igual

 
Buenas,

Ya parece que va bien. Aproximadamente el servicio ha estado degradado, perdiendo paquetes, desde las 23.15h (21/oct) a las 0:50 (22/oct). Es decir, más de 1h y media. Supongo que esto no te lo compensan de ninguna manera, ¿verdad? :)

Lo que me escama es que este tipo de incidencias generalizadas no consten nunca cuando llamas a Atención al Cliente... es lo primero que pregunté en el 1565... pero nada, ellos sólo piensan en resetearte el router ;-)

Se agradecería un reporte técnico por parte de Jazztel confirmando exactamente cuál fue la avería.

Saludos,
-r
 
En Windows el comando ping no tiene el parametro -t (rectificado)
que datos obtiene el parametro -t del comando ping?

Por otro lado algunos servidores pueden estar configurados para no responder a ping o configurados con menor prioridad. El comando ping envia un eco y los servidores lo devuelven, siempre y cuando esos servidores esten configurados para responder a ping.

En el enrutado, los primeros servidores son de Jazztel, los siguientes servidores son de carriers y los ultimos servidores son de la web de destino, si un servidor de un carrier o una web no responde a ping y no devuelve los paquetes los tecnicos no pueden hacer nada, solo en aquellos servidores que esten en la red de Jazztel.

Lo digo porque hay usuarios que se quejan de un ping en un salto de un servidor en Estados Unidos y esperan que los tecnicos se lo solucionen, si un servidor se ha caido o no funciona correctamente, y ese servidor no esta en la red de Jazztel, que esperais que hagan los tecnicos?

Supongamos que el servidor babia.rediris.es esta sobrecargado de descargas de usuarios y tiene configurado el servidor ping con menor prioridad, esos servidores estan configurados para hacer descargas, no para responder a ping, los datos de ping son una estimacion y deben hacerse con destino a distintos servidores o en horarios diferentes para que los datos sean mas fiables.

edito: ahora veo el parametro -t
" -t Ping el host especificado hasta que se pare.
Para ver estadísticas y continuar - presionar Control-Inter;
Parar - presionar Control-C."
 
Tequis, con todos mis respetos, todo lo que comentas lo se (y lo sabe cualquiera que entienda un mínimo de redes, es bastante básico). No dudo que tu intención sea ayudar, pero tu comentario simplemente no aplica en absoluto a este hilo ni al problema en concreto.

Dicho esto, te respondo:
1) ping -t. Ya lo has visto tú pero por completar, indicar que no es más que una tool y como tal la implementación (que no el protocolo por debajo) puede cambiar. En Linux por ejemplo no es necesario poner un -t (por defecto, hasta que hagas ctrl-c el ping es indefinido). En Solaris, por ejemplo, no es indefinido por defecto (al menos en los viejos Solaris 8, supongo que esto no habrá cambiado).
2) Efectivamente los pings pueden estar filtrados, o incluso "shapeados". Pero en mi caso, cuando "denuncio" algo hago mis propias verificaciones. Para empezar ese host de rediris estoy harto de usarlo para verificar y va de pm (y te podría dar varias razones técnicas de por qué es una buena opción... conexión directa a Espanix, la red académica por las noches está "medio muerta" dificil que se sature, quiero decir-, etc). Y por otro lado hice muchas más verificaciones que no comenté (por ejemplo, conexiones FTP a una máquina *mía* que se que no tiene carga, ping a rediris desde *otras* ubicaciones -para asegurarme de que no es rediris el que me está engañando, etc).
3) Respecto al enrutado, ahí esta el traceroute que dejé. Ya en el segundo salto "visible" (puede haber routers entre medias, que filtran y por tanto no se pueden identificar), se observan problemas, y si te molestas en hacer un whois verás que corresponde a Jazztel:
% Information related to '212.106.216.0/22AS12715'

route: 212.106.216.0/22
descr: Jazz Telecom S.A.
descr: Global Spanish ISP
origin: AS12715
remarks: SPAM, Net Abuse and Security-Issues: abuse@jazztel.com
mnt-by: JAZZSEC
source: RIPE # Filtered

4) Cuando se detecta un problema que corresponde al carrier (y no es el caso, pero bueno), lo normal es que sea el cliente del carrier, es decir el propio Jazztel el que trate el problema con ellos. Lo cual no quita que si no se ha coscado ni uno (el carrier) ni el otro (Jazztel) de un problema, pues nosotros se lo podamos indicar. A pesar de los complejos sistemas de monitorización, ¿sabes cuál es el mejor sistema de monitorización? Por desgracia, el propio usuario :)))

5) Y lo de los horarios queda fuera de lugar. Si yo diagnostico una avería de ahora, las pruebas las tengo que hacer ahora, como es lógico (aunque obviamente hay que saber distinguir un comportamiento anómalo de aquel que se da en situación normal).

Siento el tostón, pero por favor cada cosa en su lugar. No te lo tomes a mal.

Saludos,
-Román
 
No lo tomo a mal, ademas agradezco el poder aprender de los posts de otros usuarios.
Los administradores de los servidores tienen sistemas que avisan cuando un servidor se ha caido, tambien pueden configurar el ancho de banda para "cerrar el grifo" en determinados horarios de menos trafico, por ahorrar ancho de banda y costes.

Lo que queria decir es que los tecnicos de este foro solo pueden solucionar problemas en la red de Jazztel, y tambien puede pasar incidencia a los carriers, pero pasar una incidencia que es temporal y con unos datos insuficientes para saber que servidor tiene el problema, pues es sobrecargar de trabajo a los administradores de sistemas.

En este foro se plantean muchos temas, para eso estan los tecnicos que dan soporte, imaginad que cada vez que un usuario hace una consulta por un ping alto o perdida de paquetes en un servidor, y que los tecnicos tengan que pasar incidencia a los administradores de sistemas, y en unos casos estara justificado y en otros no, seria sobrecargarlos de trabajo.

edito: un par de veces he entrado en rediris.es para comprobar la velocidad de descarga por FTP y no estaban disponibles, con esto quiero decir que hasta rediris.es tiene problemas.
En AdslZone han publicado un articulo de operadores en Estados Unidos que tienen problemas con el ancho de banda, porque son muchos los usuarios, las descargas y aumenta el trafico de datos.
Si ATT tiene problemas con el trafico de datos pues tambien lo tendra rediris, incluso mas, porque ATT puede priorizar el trafico de datos, pero rediris no, y por ello es mas probable que se le caigan los servidores.
 
Por supuesto que rediris tiene problemas, los carriers tienen problemas y hasta los usuarios tenemos problemas en nuestros aparatos de vez en cuando...

Pero yo no estoy hablando de eso. Yo estoy hablando de una incidencia palpable, sobre la cual he aportado pruebas y que ha sido confirmada por más usuarios, y que si además si te paras a analizar, no hace falta ser CCIE (lo más de lo más en Cisco, para el que no lo sepa) para ver donde está el problema (y donde *no* está, dicho sea de paso).

Tampoco te estoy hablando de un problema transitorio de 3 minutos y que afecta a un host. Lo de ayer fue (mínimo) más de hora y media, y afectaba a la navegación a cualquier sitio (porque el problema era claramente de Jazztel). En cuanto a los usuarios/zonas de jazztel afectadas no te puedo decir, pero vamos, que no fui solo yo ni mi ordenador :)

En fin, simplemente trato de luchar contra la desinformación. Si cuando se produjera una avería generalizada avisaran (en su blog, este foro, por email, ... anda que no habría formas) nos ahorraría a los usuarios volvernos locos para ver qué esta pasando (y a algunos -pobres de ellos- que tengan que resetear el router aunque la incidencia no tenga nada que ver con eso...).

En este caso concreto, ¿tan dificil es reconocer que de tal a tal hora hubo una avería que afectó a las zonas x,y,z? ¿Qué es mejor: asimilar y reconocer tus errores o bien tratar de esconderlos? Cualquiera que sea honesto respondería rápidamente a esta pregunta... Y es lo que debería de haber hecho Jazztel en vez de callarse como una xxxx.
 
Correcto en informar de un problema en la red para que lo arreglen, suponiendo que el problema estuviera en un servidor de Jazztel y no en rediris, lo que ocurre que en este foro muchos usuarios plantean consultas sobre ping y perdidas de paquetes en un servidor de un enrutado, unas veces justificadas y otras no.
Se supone que los tecnicos tienen que pasar incidencia a los administradores de sistemas para que encuentren la incidencia y la resuelvan, pero las empresas pueden que lo solucionen de otra manera.
Si hay muchas consultas con incidencias de servidores en la red justificadas o injustificadas, ocupando a tecnicos y administradores, los operadores resolveran el problema y los costes que ello conlleva de una manera resolutiva, cual es la mayor causa de las caidas de los servidores? el aumento de trafico de datos, pues ello se resuelve con la priorizacion de datos.

Un simil, en las carreteras hay accidentes de trafico y ello crea retenciones de vehiculos, solucion: limitar la velocidad a 90 km/h y prohibir el trafico de vehiculos pesados, ello disgustara a unos y a otros no tanto, lo mismo puede ocurrir con la priorizacion de datos.
Hay una consulta de un usuario que no le funcionaban las dns de opendns, se habra caido el servidor, cosa normal en los servidores que soportan mucho trafico de datos para los recursos que disponen, habra que aceptarlo o de que manera queremos que resuelvan las caidas de los servidores? no solo de los operadores, de carriers, de webs de juegos online, de todas las webs.

Este es el enlace al que hacia referencia: http://www.adslzone.net/article3363-los ... ernet.html
copy/paste: "Los proveedores señalan que la demanda actual de tráfico es insostenible y se "deben priorizar las conexiones o cobrar por uso""
Teniendo en cuenta el coste en ampliar la capacidad de las redes (millones) y lo poco que cuesta un aparato para priorizar el trafico de datos, que crees que harian?
 
romansoft dijo:
Por supuesto que rediris tiene problemas, los carriers tienen problemas y hasta los usuarios tenemos problemas en nuestros aparatos de vez en cuando...

Pero yo no estoy hablando de eso. Yo estoy hablando de una incidencia palpable, sobre la cual he aportado pruebas y que ha sido confirmada por más usuarios, y que si además si te paras a analizar, no hace falta ser CCIE (lo más de lo más en Cisco, para el que no lo sepa) para ver donde está el problema (y donde *no* está, dicho sea de paso).

Tampoco te estoy hablando de un problema transitorio de 3 minutos y que afecta a un host. Lo de ayer fue (mínimo) más de hora y media, y afectaba a la navegación a cualquier sitio (porque el problema era claramente de Jazztel). En cuanto a los usuarios/zonas de jazztel afectadas no te puedo decir, pero vamos, que no fui solo yo ni mi ordenador :)

En fin, simplemente trato de luchar contra la desinformación. Si cuando se produjera una avería generalizada avisaran (en su blog, este foro, por email, ... anda que no habría formas) nos ahorraría a los usuarios volvernos locos para ver qué esta pasando (y a algunos -pobres de ellos- que tengan que resetear el router aunque la incidencia no tenga nada que ver con eso...).

En este caso concreto, ¿tan dificil es reconocer que de tal a tal hora hubo una avería que afectó a las zonas x,y,z? ¿Qué es mejor: asimilar y reconocer tus errores o bien tratar de esconderlos? Cualquiera que sea honesto respondería rápidamente a esta pregunta... Y es lo que debería de haber hecho Jazztel en vez de callarse como una xxxx.

Estimado romansoft

En primer lugar, recordamos que el hilo fue planteado luego del horario de atención por lo cual no se le ha podido contestar en ese momento.

Asimismo tenga en cuenta que en el hilo de consultas mas comunes se explica como se responde y en que orden aqui en el foro.

Finalmente y con respecto a su consulta, no hemos recibido una notificación al respecto y es por eso que no se ha comentado.

Agradecemos su respuesta para finalizar el hilo habiéndose solucionado el fallo que ha comentado.

Saludos
 
El usuario romansoft no ha comentado en el hilo que ha creado dentro de los 5 días desde su último post.
De acuerdo a las reglas de inactividad del foro [1] lamentablemente se procede al cierre del mismo.

Saludos!

[1] http://www.adslzone.net/postt126841.html


Para más información u otras consultas, debe abrir otro hilo en el foro AQUI :arrow:.
Si desea dejar su comentario de la calidad del servicio prestado en el foro, hágalo aqui :arrow:
 
Estado
Cerrado para nuevas respuestas.
Arriba