Vuelven los problemas de conectividad con OVH (esta vez fallos en saltos de movistar)

[cuprix]

Lo dicho.

Ya sufrí este catastrófico problema:

http://comunidad.movistar.es/t5/Soporte-T%C3%A9cnico-de-Fibra-%C3%93ptica/Problemas-de-ping-alto-y-m...

Hicieron una ñapa que ahora vuelve a hacer aguas por todos sitios.

Tengo un jitter y pérdida de paquetes enormes en los saltos que hago por :

13.red-80-58-122.staticip.rima-tde.net

90.red-81-46-8.customer.static.ccgg.telefonica.net

et-13-0-0-0-400-grtmadde2.net.telefonicaglobalsolutions.com

ae2-grtmadpe3.net.telefonicaglobalsolutions.com

En este último es donde tengo la mayor acumulación de problemas.

OVH es a día de hoy el principal proveedor de servicios de datacenter, esto no es como cuando no puedes acceder una simple página, no poder acceder de manera correcta a cualquier servidor de OVH significa no poder acceder una gran cantidad de contenido.

[Theliel]

Buenas @cuprix

Puedes poner un tracer completo hacia el servidor que te da dichos problemas?

Primero para que los demás podamos replicarlo, si es un problema de zona, si es puntual... y segundo para poder ver realmente los datos completos, me temo que por poner 4 host poco o nada nos dicen sin el resto de los datos

Saludos.

[JulioC-Movistar]

Hola @cuprix  ¿Nos puedes adjuntar un tracert y unos ping a la IP conflictiva en modo texto ?

[cuprix]

Buenas.

Aquí lo dejo.

Esta es una ip de las 50 - 60 que me fallan actualmente..

:~$ tracepath 87.98.151.63
 1?: [LOCALHOST]                                         pmtu 1500
 1:  gateway                                               0.790ms
 1:  gateway                                               0.611ms
 2:  gateway                                               0.629ms pmtu 1492
 2:  192.168.144.1                                        11.009ms
 3:  13.red-80-58-122.staticip.rima-tde.net                8.230ms asymm  5
 4:  90.red-81-46-8.customer.static.ccgg.telefonica.net    9.124ms
 5:  et-13-0-0-0-400-grtmadde2.net.telefonicaglobalsolutions.com   7.841ms asymm  9
 6:  ae2-grtmadpe3.net.telefonicaglobalsolutions.com       6.603ms asymm  9
 7:  213.140.52.166                                        7.399ms asymm  9
 8:  tengige1-6-0-17.pastr2.Paris.opentransit.net         39.221ms asymm 10
 9:  hundredgige0-7-0-2.ffttr4.FrankfurtAmMain.opentransit.net  40.687ms asymm 11
10:  hundredgige0-13-0-0.ffttr5.Frankfurt.opentransit.net  48.743ms asymm 11
11:  be100-110.fra-1-a9.de.eu                             40.895ms asymm  9
12:  be1-1170.sbg-g1-a9.fr.eu                             41.853ms asymm 11
13:  vac2-0-a9.fr.eu                                      37.501ms asymm  9
14:  vac2-1-n7.fr.eu.firewall                             37.912ms asymm 15
15:  vac2-2-n7.fr.eu.tilera                               37.817ms asymm 14
16:  vac2-3-n7.fr.eu                                      39.012ms asymm 13
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  be50-5.gra-3a-a9.fr.eu                               46.472ms asymm 10
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1492
     Resume: pmtu 1492
:~$
:~$
:~$ ping 87.98.151.63
PING 87.98.151.63 (87.98.151.63) 56(84) bytes of data.
64 bytes from 87.98.151.63: icmp_seq=1 ttl=115 time=44.9 ms
64 bytes from 87.98.151.63: icmp_seq=2 ttl=115 time=44.5 ms
64 bytes from 87.98.151.63: icmp_seq=3 ttl=115 time=44.5 ms
64 bytes from 87.98.151.63: icmp_seq=4 ttl=115 time=44.4 ms
64 bytes from 87.98.151.63: icmp_seq=5 ttl=115 time=44.6 ms
64 bytes from 87.98.151.63: icmp_seq=6 ttl=115 time=44.6 ms
64 bytes from 87.98.151.63: icmp_seq=7 ttl=115 time=45.2 ms
64 bytes from 87.98.151.63: icmp_seq=8 ttl=115 time=45.2 ms
64 bytes from 87.98.151.63: icmp_seq=9 ttl=115 time=44.6 ms
64 bytes from 87.98.151.63: icmp_seq=10 ttl=115 time=44.9 ms
64 bytes from 87.98.151.63: icmp_seq=11 ttl=115 time=44.4 ms
64 bytes from 87.98.151.63: icmp_seq=12 ttl=115 time=44.5 ms
64 bytes from 87.98.151.63: icmp_seq=13 ttl=115 time=44.7 ms
64 bytes from 87.98.151.63: icmp_seq=14 ttl=115 time=44.6 ms
64 bytes from 87.98.151.63: icmp_seq=15 ttl=115 time=44.7 ms
^C
--- 87.98.151.63 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14023ms
rtt min/avg/max/mdev = 44.467/44.744/45.272/0.368 ms
:~$

[cuprix]

Y aquí el pingplotter.

[img]http://i.imgur.com/8q5EP6Q.jpg[/img]

http://i.imgur.com/8q5EP6Q.jpg

[cuprix]

La incidencia desaparece por completo si uso mi conexión de internet del teléfono móvil o si uso la wifi del vecino que es vodafone.

O si uso una VPN para conectarme a esos servidores y evitar salir desde mi conexión directamente.

El jitter que hay en la parte de telefónica asusta....

[Theliel]

Buenas @cuprix

En principio no hay problema con el tracert, es correcto, y pingplotter lo mismo.

bombardeados de forma independiente es cierto que los nodos de Movistar muestran un jittler elevado, pero dado que no se replica en otros host, es irrelevante. Es decir, ping plotter hace un tracert para descubrir los host y luego los va bombardeando a la par con ping, si existiese un gran jittler en los nodos de Movistar que afectase el tráfico en general, no podríás tener un jittler plano en otros saltos superiores, con lo que el jittler lo da solo cuando los bombardeas directamente para generar respuestas ICMP DE ESE NODO, no deja de ser tráfico ICMP con lo que es muy normal que el tráfico de este tipo se discriminice.

Al discriminar este tipo de tráfico, posiblemente dádole una prioridad muy baja, la respuesta de estos paquetes, cuando la hay, es totalmente errática. La latencia, el Jitter, la "pérdida de paquetes", hay que verlo individualemnte y como un todo, los datos en solitario de ellos no nos cuentan nunca nada, de ahí a que te dijese que era necesario el completo.

Como digo no veo ningun problema destacable, buena latencia y jitter final, tampoco hay pérdida de paquetes reales en ningún salto, puesto en los nodos que hay, vemos claramente que luego ese comportamiento desaparece, cuando como digo la latencia, jitter o "perdida" reales son acumulativos por saltos, a mayor salto, mas aumenta.

[cuprix]

A mi me da igual la excusa que se de mientras se solucione.

Desde que tengo movistar desde este verano han sido problemones para conectar a todo lo que sea OVH.

Ni con vodafone, ni orange ni yoigo tengo esos problemas, solo al usar una flamante conexión simétrica de 300Mb que tengo en casa.

No tienes mas que darte una vuelta por el foro para ver la gran cantidad de gente con problemas, de hecho si dejo el ping plotter acaban apareciendo zonas rojas con pérdida de paquetes.

El juego online contra servidores de OVH es imposible con latencias absurdas según le viene (a ratos), cosa que no ocurre con cualquier conexión que no sea movistar...

Es un poco triste tener que andar con VPN de pago para saltarse las rutas de movistar, que es el principal problema que nos atañe aquí.

El camino por donde llegamos a cualquier servidor de OVH es una castaña, cosa que no ocurre si conectamos desde otro operador o VPN.

[Theliel]

Buenas @cuprix

En primer lugar, sobre los diferentes ISP, eres libre de irte al que prefieras si crees realmente que Movistar o cualquier proveedor de servicios que tengas no te da lo que crees que debe de darte, de echo te animo a hacerlo, no hay nada peor que estar en un sitio que no gusta estar

En segundo lugar, lo que tu llamas excusas son explicaciones completamente demostrables, y si quisieses leer o aprender un poco sobre como funciona Internet y otras cosllas,llegarías a las mismas conclusiones... repito, conclusiones, no excusas. Y ya no te lo dice un técnico q a fin de cuenta trabaja para la empresa y puede tener razones partidistas, también te lo puedo asegurar yo que llevo unso cuantos años en esto y sé de lo que estoy hablando (No me preguntes de coches, de tecnolgía casi lo que quieras)

En tercer lugar,los problemas de latencia existen en todos los ISP, algunos funcionan a veces unas cosas mejor, otras veces peor. Puedes darte una vuelta si quieres también por TODOS los foros de soporte y o de ayuda independiente, y verás siempre los mismso problemas, siempre hay prolbemas de latencia, cuando no es enA, es en B es en C. Es norma, cada ISP puede usar rutas muy diferentes, y tenner sus propios problemas, y...

En cuarto lugar, siento decirte que pingplotter, ping, tracert... no miden lo que tu estás llamando pérdida de paquetes, y no, no es otra excusa, y te inso a leer sobre como funciona un tracert/ping, el protocolo ICMP y otros, también sacarías la misma conclusión. Cuando haces uso de estos programas, estos miden en función e la premisa de que el servidor o nodo de red intermedio responde a ese tráfico específico, y lo que no sabes es que ni unos ni otros tienen por qué responder a ellos, y esas no respuestas es lo qeu recogen esos programas. Y no solo pueden responder si/no, sino que pueden discriminar ese tráfico cmo quieran, tanto bloqueandolo por completo como para permitir 1 de cada 2, como simplemente darle baja prioridad y si no se responden por tráfico no se responden.

Por cierto... sabías que la propia utilidad pingplotter tiene un artículo sobre ello que lo explica perfectamente??

https://www.pingman.com/kb/article/but-i-hear-that-traceroute-and-pingplotter-is-not-accurate-46.htm...

Los datos de estas herramientas hay que saber leerlos e interpretarlos, usar un software sin saber que está midiendo y como, y que significa esos datos... es algo totalmente inutil, porque uno puede estar viendo una cabra cuando realmente hay una vaca.

Por último, actualmente Movistar es el ISP con mayor número de Peerings (al menso en España), lo que potencialmente (aunque no tiene por qué ser así) se traduce con más capacidad de ruteo hacia cualqueir destino del mundo. Por otro lado se te olvida otro punto...

Imaginemos que tu quieres llegar a Z, que está en Una zona concreta de Alemania. Para esa zona Movistar tiene un Peering Aleman con una gran red que sabe que lleva a ella, así qeu es lo que usa. A su vez en cambio, esa re Alemana pueede depender de otras redes secundarias o incluso terciarias para poder llegar al destino... etc etc etc. Movistar en un momento dado puede cambiar de peering por el que lanzarel tráficico, pero no puede controlar por donde la red enla que suelta su tráfico manda a su vez el tráfico. Es decir, que el ISP tiene una responsabilidad siempre directa dentro de su propia red, y como mucho indirecta en la siguiente red, pero de ahí a la siguiente... poco o nada puede hacer.

Generalmente el problema sucede por el contrario. Los prveedores de serviciso como OVH o tantos otros se conectan igualmente al mundo ocn sus propios Peering, y estos suelen ser mucho más limmitados a los de los ISP. Eso significa que las vías de entradas por las que se les puede enviar tráfico son mucho menores que por las que puede enviarlo el ISP, ocasionando generalmente latencias y otros en los peering del proveedor destino. En el caso concreto de Movistar, añade que Telefónica es un tier1, con el que evidentemente tiene conexión directa

Peers IPv4:

Movistar España: 174 Peers (http://bgp.he.net/AS3352#_peers)

Telefonica Wholesale Int. : 278 (http://bgp.he.net/AS12956#_peers)

OVH: 191 (http://bgp.he.net/AS16276#_peers)

Y si quieres ver ordenados por numero de Peers todas las redes de España, por si quieres comparar los ISP:

http://bgp.he.net/country/ES

Creo que está basante claro quien potencialmente está en ventaja

Saludos compañero

[cuprix]

Querido cibervoluntario (por que lo eres), la otra vez que iba mal fue problema por la parte de telefónica, que a pesar de que OVH les avisó de que se estaba usando su red para realizar un ataque no hicieron nada y tuvieron que ingeniárselas para aguantar el ataque.

Y te recuerdo que no fue hasta que OVH dijo de cortar el grifo cuando telefónica empezó a moverse.

Así que si no te importa, vete por donde has venido. Aunque algo me dice que eres algo mas que un cibervoluntario típico.

[JulioC-Movistar]

@cuprix  El ping final a 87.98.151.63 es correcto,  básicamente es lo único que importa. El jitter que indicas se calcula según la respuesta al ping que se lanza a cada nodo, la respuesta al ping, no es obligatoria y en caso de responder no es prioritaria, la prioridad de cada nodo es encaminar el tráfico que le llegue hacia el destino siguiente, eso lo ejecuta sin ningún problema, se puede observar en los tiempos del ping final.

Lo de que lo único que importa es el ping final y que hay que descartar todos los intermedios aunque den muy mal no lo digo yo, lo dice el desarrollador de Pingplotter que es la herramienta que usas para medir.  (traducción via google "El único salto que importa es el destino final. Si está satisfecho con la latencia y pérdida de paquetes que se ve en el destino final, entonces ninguno de los otros saltos importa.")

[cuprix]

Buenas Julio.

No tengo que decirte que el ping final en un momento concreto no dice nada, cuando a lo largo plazo hay subidas constantes de latencia y pérdida de paquetes que es lo que está provocando el problema.

Está claro que el cibervoluntario os lo ha dejado en bandeja, pero el mes pasado (o el anterior) desde vuestra red se estaba realizando un ataque masivo el ping plotter lo usábais con descaro para decir que el problema estaba en la parte de OVH, ahora me vienes con lo contrario.

Cuál es la respuesta oficial ?

Mas que nada por que tengo un caso abierto con OVH y están esperando vuestra respuesta, a la inversa desde cualquier servidor de OVH ocurre exactamente lo mismo, la parte de movistar es la que da problemas.

De paso esto también sirve para aclarar futuras situaciones en las que pingplotter marque el primer salto de OVH como el culpable y evitar así que lo uséis como excusa.

[JulioC-Movistar]

No, no es una excusa, es simplemente su funcionamiento.  Sí, un ping en un momento concreto solo indica el problema concreto en ese momento, eso es cierto, pero nos vale para discriminar si hay algo constante, en caso de que sea algo anárquico en el tiempo puedes poner un ping constante a esa dirección IP  y darnos los resultados de la estadística.

Lo que no puedo probar es si no me das datos reales de IP destino IP origen.

[cuprix]

IP origen la mía.

IP destino por ejemplo 5.196.203.198  o 87.98.151.63

Lo primero es un servidor de TS lo segundo un servidor de juego.

Desde mi conexión de telefónica imposible utilizarse en ciertos momentos, y cuando es usable se nota perfectamente que hay un problema.

El servidor de juego imposible lag, ping alto, etc.. a ratos.

Todos los problemas desaparecen si se usa VPN de pago, la conexión 3G que tengo de yoigo y vodafone o usando la wifi del vecino con vodafone, también hemos probado otro compañero con Orange que también tiene telefónica en casa y sus problemas se resuelven al cambiar de ISP.

Mismamente, yoigo va por telia.net y no tiene problemas.

Mientras que movistar va por opentransit.net y son todo pegas..... y realmente esto lo decidís vosotros usando la explicación del cibervoluntario que ha posteado antes.

[JulioC-Movistar]

Lanza desde tu línea 50 pines a esas dos IP para ver los resultados, pásamelo en modo texto por un privado. Yo estoy lanzando esos mismos pines ahora desde una de nuestras líneas para comparar.

[cuprix]

Me ahorro lanzarlos.

Van a salir bien y me vas a decir que está todo perfecto y volvemos al punto inicial.

Prefiero dejar un ping plotter 2 días enteros y colgar los pantallazos para que se vea el problema real.

[JulioC-Movistar]

Como prefieras, ya sabes la respuesta de antemano, el pingplotter no es valido, si puedes lanzar un ping constante y poner su estadística. Ya que tienes acceso a otra red puedes lanzar con otro Pc un ping constante a las mismas IP y comparamos los resultados.

En principio desde seguridad no tienen constancia de un nuevo ataque de DoS a OVH

[cuprix]

Bueno, pues dejo un ping lanzado si me dices que con eso vale ....

Pero eso y ping plotter apuntando al último salto es lo mismo, solo que en pingplotter te colorea en rojo la pérdida de paquetes y te pinta la latencia para verlo todo de un vistazo.

[JulioC-Movistar]

@cuprix Creía que había quedado claro que lo único que vale es la respuesta del último equipo, que las perdidas intermedias no tienen ninguna importancia, son perdidas de Ping no de paquetes.....  No, no es lo mismo.

[cuprix]

Lo digo por si no lo sabías.

En pingplotter puedes seleccionar el último equipo o salto como quieras llamarlo.

Y monitorizas eso.

Eso y lanzar un ping en una shell es exactamente lo mismo, solo que pingplotter te lo pone bonito.

De qué manera sería buena monitorizar los cortes ???

A mi se me ocurren varias pero quiero la oficial que le valga a telefónica como para abrir un caso.

[JulioC-Movistar]

Lo desconocía, si se comporta como un ping final en principio debiera ser valido.

[cuprix]

Es que ya me extrañaba a mí.

Pingplotter efectivamente lanza pings a todo.

Y si tiene 22 saltos lanza 22 pings diferentes.

De hecho si te fijas en la ventana según funciona ves como va actualizando los tiempos de respuesta de arriba abajo.

Luego si quieres monitorizar varios servidores a la vez seleccionas de cada servidor el último salto y le dices que te lo enchufe al sumario y desde la ventana de sumario ves todos los servidores a la vez.

[Theliel]

Buenas @cuprix

Llevo algún tiempo por aquí, y te digo que @JulioC-Movistar no suele necesitar que alguien diga o deje de decir, y cuando ha sido un problema de Movistar igualmente lo ha reconocido. Yo mismo arremeto con ellos, y sin piedad, cuando veo que el forero tiene toda la razón del mundo, pero eso no significa que Movistar sea culpable de la guerra del mundo. Por supuesto hacen mil cosas mal, y para nada estoy de acuerdo con la mayoría de las políticas que llevan a cabo, pero de ahí a creer que todo lo que dicenes falso... por favor..

Sí, posiblemente Julio ha puesto la captura de depingplotter porque lo explicaba yo anteriormente e incluso he citado ese artículo más de una ocasión... pero es que es la verdad, me temo. Como le he dicho a otro compañero en otro hilo, esto es muy sencillo muy muy sencillo:

-Cualquier ISP puede comprobar en todo caso el funcionamiento de su red, y como mucho dar un toque al peering que esté usando para la ruta que sea, punto y se acabó. Por supuesto que los técnicos de Movistar tienen herramientas para monitorizar y ver el estado de SU red, pero es indiferente. Si dentro de dos días Julio te dice que por parte de Movistar es todo correcto, te lo vas a creer y vas a adminitirlo?? O por el contrario lo único que te vale es que realmente existiese un problema por su parte??

-Te lo quieras creer o no, quieras interpretar los datos como los quieras interpretar.... ICMP, Ping, Tracert, Jitter... funciona así, como se te ha dicho. Es más, si no te lo crees, que estás en tu derecho, te animo a leer sobre el tema y aprender un poco, y sacar tus propias conclusiones. Por suerte no vivimos en la oscuridad, y a día de hoy se tiene en el bolsillo más información de la que haya podido existir en la antigua libreria de alejandría. Te repito... no te lo quieres creer?? Me parece bien, aprende sobre ello entonces, y cuando lo hayas estudiado y entendido, vienes y me lo rebates si eres capaz.

-Tracert/Ping/ICMP/PingPlotter... no es que se usen con descaro, es que son una herramienta ESENCIAL en el mantenimiento, testeo y otros de cuaquier red. El problema no son esas herramientas, el problema es no saber como interpretarlas :). Creer que existe una périda de paquetes porque lo dice ipngplotter o tracert o ping es no saber como interpertar esos resultados y demuestra no tener ni idea sobre el tema. Yo uso casi de forma diaria dichas herramientas, y me sirven tanto para detectar problemas como para descartarlos. En el caso de que no seas médico o alguien muy muy interesado por ello... eres capaz de coger una radiografía de torax y decir si alguien tiene o no una neumonia?? Si, cualquiera podemos mirarla, pero no todas las zonas blancas son huesos. Nadie dice que no valgan para nada, o que no se use, lo que significa es que no entender una herramienta como funciona y que sentido tienen esos datos, es lo mismo que cuanto menos ser muy muy cauto a la hora de querer sacar una conclusión de ello.

-OVH puede decir lo que le de la gana, evidentemente. El problema, es que Movistar no tiene nada que ver o tratar con OVH, no tienen peering con él como no lo tienen el resto de ISP, así que OVH podrá decir lo que quiera de que espera una respuesta. Efectivamente el tráfico ahoramismo de Movistar hacia OVH pasa por dicha red que citas... y?? Puede ser problema de opentraffic o de la siguiente red, puede ser puntual o algo más habitual... pero creo que no entiendes bien eso de apuntar con un dedo para discernir quien es el culpable o no de q algo no funcione correctamente en Internet, y mucho menos, de uqien puede ser la culpa... si es que existe culpa

Saludos,

Un cibervoluntario 

[JulioC-Movistar]

Aun así es sobrecargar al resto de nodos de ping innecesarios, por lo que entiendo va a seguir lanzando ping a todos los pasos intermedios, aunque luego solo te fijes en el final.

Realmente con un ping normal al último servidor y viendo las respuestas del ping sería suficiente, pero si prefieres usar el pingplotter.... adelante.

[Theliel]

Y luego no entienden la razón por la que los servidores bloquean o priorizan ICMP...

Ping Plotter por lo general lo que hace es tracert y ping masivo a todos los nodos de forma independiente, y si, hay queines lo dejan dias y noches... después nos quejamos