Problema enrutamiento con servidores OVH

[EduardoGonzálezRuiz]

Buenas tardes, tenemos un grave problema que debemos solucionar, y es que Movistar no enruta bien con los servidores de OVH.

Antes de que me hagáis hacer pruebas ta os adelanto que no es mi conexión, ya que lo he pobado desde varios puntos diferentes y siempre pasa lo mismo, tanto con mis servidores como con la propia web OVH.

Os pego el TRACEROUTE y MTR para que tengáis datos, cambiaré el nombre del sevidor por MISERVIDOR.COM por temas de privacidad.

Necesitamos una solución a esto porqué lo clientes se están quejando y mucho y con razón, ya que al navegar por las webs nos encontramos con microcortes que coinciden con la pérdida de paquetes.

TRACEROUTE

Traceroute se ha iniciado…

traceroute to MISERVIDOR.COM (IPSERVIDOR), 64 hops max, 72 byte packets

 1  192.168.1.1 (192.168.1.1)  1.011 ms  0.508 ms  0.529 ms

 2  179.red-80-58-67.staticip.rima-tde.net (80.58.67.179)  3.185 ms  2.999 ms  3.040 ms

 3  29.red-80-58-91.staticip.rima-tde.net (80.58.91.29)  3.746 ms  7.288 ms  3.724 ms

 4  46.red-80-58-81.staticip.rima-tde.net (80.58.81.46)  3.522 ms  7.229 ms  3.976 ms

 5  et7-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com (94.142.103.185)  22.697 ms  3.526 ms  3.559 ms

 6  xe0-1-8-0-grtbcnes1.net.telefonicaglobalsolutions.com (84.16.12.201)  3.709 ms  83.152 ms  33.962 ms

 7  * * *

 8  gigabitethernet4-2-2.barcr5.barcelona.opentransit.net (193.251.133.230)  13.755 ms  14.051 ms  13.724 ms

 9  tengige0-8-0-4.pastr2.paris.opentransit.net (193.251.242.245)  33.952 ms  31.541 ms  31.975 ms

10  hundredgige0-15-0-3.ffttr4.frankfurtammain.opentransit.net (193.251.133.221)  38.439 ms  38.055 ms  31.959 ms

11  hundredgige0-13-0-0.ffttr5.frankfurt.opentransit.net (193.251.133.2)  47.675 ms  47.257 ms  47.940 ms

12  be100-110.fra-1-a9.de.eu (37.187.232.46)  35.950 ms  35.966 ms  36.002 ms

13  be1-1170.sbg-g1-a9.fr.eu (37.187.232.86)  31.454 ms  34.534 ms  31.711 ms

14  vac2-0-a9.fr.eu (178.33.100.155)  31.928 ms  31.738 ms  31.691 ms

15  vac2-1-n7.fr.eu.firewall (178.33.100.98)  35.958 ms  36.064 ms  35.919 ms

16  vac2-2-n7.fr.eu (91.121.215.109)  36.219 ms  35.740 ms  36.221 ms

17  vac2-3-n7.fr.eu (91.121.215.111)  31.689 ms  31.499 ms  31.972 ms

18  * * *

19  * * *

20  * * *

21  MISERVIDOR (IPSERVIDOR)  39.952 ms  39.516 ms  39.470 ms

MTR

eys:  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%    27    0.6   0.6   0.4   0.7   0.0

 2. 179.red-80-58-67.staticip.rima-tde.net                                          3.7%    27    3.0   3.2   3.0   3.8   0.0

 3. 121.red-81-46-6.customer.static.ccgg.telefonica.net                    0.0%    27    5.3   5.9   3.7   9.1   1.3

 4. 46.red-80-58-81.staticip.rima-tde.net                                            0.0%    27    6.2   5.8   3.6   7.5   1.1

 5. 213.140.50.246                                                                             0.0%    26   27.1   6.7   3.5  27.1   5.6

 6. xe0-1-8-0-grtbcnes1.net.telefonicaglobalsolutions.com                0.0%    26   97.8  13.7   3.5  97.8  20.2

 7. ???

 8. gigabitethernet4-0-1.barcr5.Barcelona.opentransit.net                0.0%    26   13.8  15.4  13.2  38.4   5.2

 9. tengige0-8-0-3.pastr2.Paris.opentransit.net                                 0.0%    26   40.0  43.3  39.1  47.2   2.6

10. hundredgige0-15-0-3.ffttr4.FrankfurtAmMain.opentransit.net     0.0%    26   34.5  35.4  31.4  48.3   3.5

11. hundredgige0-13-0-3.ffttr5.Frankfurt.opentransit.net                  0.0%    26   39.0  36.6  31.1  43.2   3.5

12. be100-110.fra-1-a9.de.eu                                                           0.0%    26   35.9  36.0  35.6  36.2   0.0

13. be10-1105.rbx-g1-a9.fr.eu                                                          0.0%    26   33.0  33.0  32.7  33.2   0.0

14. ???

15. MISERVIDOR.COM                                                                   0.0%    26   36.8  36.8  36.4  37.4   0.0

[Técnico.Global-Movistar]

Hola @EduardoGonzálezRuiz,

Cuando puedas, envíame un mensaje privado con tus datos ( teléfono, nombre y NIF del titular de la línea, e-mail  y móvil de contacto) y le echamos un vistazo.

Salu2

[Theliel]

Buenas @EduardoGonzálezRuiz

Gracias por los datos, la mayoría no los ponen y no entienden lo importante que es poder verlos, ya que muchas cosas no se pueden probar desde fuera de la red del afectado.

Voy a intentar explicarte un poco tus resultados:

Respecto al Tracert:

No hay absolutamente nada extraño. Una latencia final acumulada de unos 39ms y con un jitller mínimo, +/- 1ms. El salto 7 y los saltos 18-20  veo que no responden al tracert, cosa muy normal, y y teniendo en cuenta los valores anterioes y posteriores a estos, no hay en ellos absolutamente ningún problema.

A eso súmale que los paquetes dejaron la red de Movistar en el salto 7-8, con lo que en ese caso hipotético, Movistar dejaría de tener "culpa" directa a partir de ahí. Luego entra en la red de opentransit, y luego ya si entra en OVH (salto 12).  Como digo no hay ninguna anomalía en ningún salto

Respecto a MTR:

Esto lo he explicado ya muchas veces. Que un tracert o un Ping diga que existen un % de paquetes perdidos, hay que saber que se está refiriendo con eso. No se refiere a que cuando tu navegas se pierde ese % de paquetes cuando circula por un nodo en concreto, no tiene absolutamente nada que ver. Ping/tracert reportan un % perdidos cuando el nodo que están testeando no responde al PING o al paquete TCP/UDP con TTL falseado en el caso de Tracert. En ambos casos se presupone que el nodo de red o el servidor va a responder con un ICMP Reply por TTL o por ECHO

La cuestión es que dichos nodos de red o servidores finales no tienen por qué responder a esas peticiones. Podría no responder a ninguna, como es el caso del salto 7 o 14 en tu caso. Podría responder el 100% de ellos como el salto 5, o podría no responder a todos como en el salto 2. Por qué se responde unos sí y otros no??? Por rendimiento de la red, esas respuestas no son obligatorias, y por lo general se usan filtros para no tener que responder a todos los tracert/ping que se realizan, eso produce un grán trafico ICMP.

Por otro lado, es simple ver la veracidad de esto. Si el salto 2 de MTR realmente tuviese un 4% de paquetes perdidos, estos serían reflejados en los demás saltos. Es simple, para llegar al salto 3 los paquetes han circulado antes por el salto 2. Si en el salto 2 caen un 4%, en el salto 3% llega como mínimo un 4% menos Dicho de otro modo... si se mandan 100 paquetes al hacer el tracert y se va probando nodo a nodo, en el salto 2 dice que se quedan 4 (4 de 100), al probar el siguiente nodo con otros 100 paquetes deberían de llegar como mucho 96 (si es consistente la pérdida en el salto 2. Y esto se repetiría en los demás saltos. Y vemos que no es así, que simplemente al bombardear un nodo, este dice que no responde a todas esas peticiones, pero eso no quiere decir que el tráfico no circule por ellos con total normalidad.

Para hacer un test de pérdida de paquetes real, tanto origen como destino tienen que medir especificamente ello, como por ejemplo este test:

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

Conclusión... del tracert y MTR, no se muestra absolutamente ninguna anomalía, en todo caos que el MTR usa una ruta diferente al tracert, pero nada más. No hay ningún problema de enrutado

[EduardoGonzálezRuiz]

Ok, voy a seguir haciendo pruebas a ver qué tal....  el problema es que a medida que navego por la mi web principal, tengo cortes con el servidor, y lo mismo me pasa cuando navego por OVH... en cambio, si lo hago desde el 3G no se producen estos cortes.... por eso lo atribuyo a Movistar Fibra ya que me pasa con las conexiones de fibra que he probado.

Gracias.

[Theliel]

Buenas @EduardoGonzálezRuiz

No lo dudo ni mucho menos, pueden ser mil cosas, pero por los datos que nos pones de tracert y MTR no hay nada que haga sospechar ningún comportamiento [....]. Podría ser a lo mejor un problema de DNS de Movistar, o...

si quieres, puedes probar con poner un tracert desde el móvil a ver, o dime por privado si quieres la dirección y puedo ver si funciona bien desde mi propia línea o desde algunas otras si hay algún problema o si la navegación es buena o que está pasando.

Otra opción que tienes es usar las herramientas de desarrollador de Firefox/Chrome para ver la carga de las web como se realiza, a lo mejor no es problema con OVH y es algún CDN que usen el que está dando el problema

[EduardoGonzálezRuiz]

Te paso por privado los datos para que compruebes, ya que desde otras líneas no me da problemas. Desde el 3G he comprobado que me pasa lo mismo. Además he lanzado tests desde otros servidores de Estados unidos, francia y españa con ONO, y ninguno me causa problemas.

[Theliel]

Ok perfe, manda y echo un vistado, puedo probar con diferentes líneas, y ya te digo si veo algo raro

saludos.

[Persy]

* ELIMINADO *

[manuel.vazquez]

Buenas dias, yo soy usuario movistar con fibra 300MB , desde Ecija - Sevilla, y desde hace dos dias vengo exprimentando una latencia importante hacia la red de de OVH, la cual uso para correo, servidores, etc , el problema esta probado que solo ocurre desde movistar, desde cualquier otra red ONO, por ej probado, el funcionamiento es correcto, ya me ocurrio hace unos meses y vuelve a ocurrir de nuevo

[fundacion]

Hola,

Tenemos un servidor cloud en OVH y desde hace días hay problemas intermitentes de conexión, sobre todo por las mañanas, que se solucionan llamando al ST de OVH.

Nuestro administrador de red les ha llamado y le han dicho que sufren ataques de denegación de servicio en su red, y que el sistema de seguridad corta la conexión.

Pero... otros usuarios del servidor con distinto proveedor (Orange), no han tenido estos problemas de conexión.

Saludos.

[F650]

Helo.

http://www.digitalattackmap.com/

Salu2.

[Persy]

* ELIMINADO *

[Persy]

* ELIMINADO *

[manuel.vazquez]

Recibido de OVH esta tarde ...

Estimados/as clientes:

En el servicio que ofrecemos a nuestros clientes incluimos la gestión de ataques DDoS, que consiste en recibir los ataques DDoS y mitigarlos. Para ello, tenemos mucha capacidad de red con internet (7.500 Gbps) y hemos desarrollado el VAC, que permite mitigar los DDoS. Anteriormente ya hemos recibido y mitigado con éxito ataques DDoS de 800 Gbps.

Desde hace varios días, estamos recibiendo un ataque procedente de una red en concreto, la del operador histórico español: Telefónica. Este ataque está dirigido a un cliente en particular que está alojado en nuestro centro de datos de BHS (Canadá).

No se trata de un ataque DDoS (Distributed Denial of Service), sino DoS (Denial of Service), ya que no es distribuido: el ataque no procede de varios lugares del mundo, sino de uno concreto, por lo que utiliza una ruta específica: AS3352 Telefónica de España <> AS12956 Telefonica International <> AS16276 OVH.

Nuestros enlaces de conexión con AS12956 son los siguientes:
    •    30G + 20G en Madrid
    •    40G en París
    •    20G en Ashburn, VA
    •    20G en Miami, FL

Es decir, tenemos un total de 130 Gbps con AS12956. Sin embargo, el DoS que recibimos es de 150 Gbps. Normalmente podemos recibir sin problema 150 Gbps, si se trata de un DDoS que procede de Asia, Europa y EE.UU. al mismo tiempo. Cada parte de la red recibe una parte del DDoS y cada VAC mitiga una parte del DDoS.

En este caso, los hackers utilizan específicamente la red de Telefónica de España para enviar un ataque de gran envergadura. El tipo del DoS es muy básico, de modo que podríamos mitigarlo sin problemas, pero, en este caso concreto, no podemos, ya que no llegamos a recibirlo: los enlaces que tenemos con Telefonica International se saturan antes.

Lo primero que hicimos fue cortar los anuncios BGP con AS12956 para utilizar otros enlaces que tenemos con internet y hacer llegar el tráfico por AS5511 OpenTransit <> AS3352 Telefónica de España <> AS12956 Telefonica International <> AS5511 OpenTransit <> AS16276 OVH.

Tenemos 1x 100G con OpenTransit (OTI) en Frankfurt. El ataque saturó el enlace que tenemos con OTI, causando que se vieran afectados otros ISP de España, ya que utilizamos OTI para recibir el tráfico desde Orange España, Jazztel, etc. Entonces cortamos los anuncios BGP con AS5511.

El tráfico nos llega ahora por Level3 AS3356 <> AS3352 Telefónica de España <> AS12956 Telefonica International <> AS3356 Level3 <> AS16276 OVH.

Con Level3 tenemos 800 Gbps de capacidad y varios enlaces de 200 Gbps, de modo que ya podemos recibir este DoS de 150 Gbps. El problema es que entre AS12956 y AS3356 no hay suficiente capacidad para permitir el paso del DoS sin saturar los enlaces entre los operadores.

Seguimos trabajando para solucionar el problema. Estamos en contacto con AS12956, que ha solicitado a AS3352 que apague la red de botnets que origina el DoS. También modificamos nuestras respectivas configuraciones para permitir que el DoS pase entre AS12956 y AS16276.

No podemos ofreceros más detalles, ya que esta intervención será leída por los hackers que han realizado el DoS y utilizarán esta información para saltarse las medidas que implementemos. Esta es también la razón por la que no hemos creado hasta ahora la tarea en Travaux. En los casos de (D)DoS, cuantos menos datos demos, menos incentivamos a los hackers y mejor gestionamos los ataques, pero, teniendo en cuenta cómo está afectando a nuestros clientes españoles, debíamos informaros sobre el origen del problema.

Hemos encontrado la forma de permitir el paso del DoS sin saturar los enlaces. En las próximas horas veremos si aguanta. En cualquier caso, estamos manteniendo conversaciones con Telefonica International para aumentar las capacidades con su red. También vamos a instalar un nuevo router en Madrid antes de lo que estaba previsto (octubre en lugar de marzo). Esto nos permitirá conectar en octubre en 200G con Telefónica, mejorar Espanix en 2x 200G, OpenTransit en 200G y tener estas mismas mejoras con Telia y Cogent. Paralelamente, vamos a añadir más enlaces con Telefónica, especialmente en París de 200G y Ashburn, VA, de 200G.

Los hackers han conseguido encontrar una debilidad en nuestra red. Vamos a subsanarla lo antes posible. Esta experiencia nos servirá para mejorar aún más la protección que ofrecemos a nuestros clientes por defecto en nuestros servicios.

Sentimos sinceramente los inconvenientes generados para los visitantes procedentes de Telefónica de España.

http://gsw.smokeping.ovh.net/smokeping?&target=EU.AS3352

Cordialmente,

Octave

[fundacion]

También hemos recibido ese mensaje de OVH.

Y... https://www.hispazone.com/Noticia/11166/Los-datacenters-del-gigante-OVH-colapsados-por-un-ataque-rea...

Por otro lado, Octave Klaba CEO de OVH acusa a "algún ISP español" de ser incapaz de controlar el tráfico del ataque.

Y el ataque continúa...

Comment by OVH - Tuesday, 06 September 2016, 14:10PM

Le DoS continue. Tous les 4 à 6 heures durant 2 heures
on reçoit entre 150Gbps et 300Gbps à partir Telefonica
Spain uniquement. Le DoS ne nous vient pas d'ailleurs.
L'origine de l'attaque est spécifiquement AS3352 qui
doit héberger un sacré grand Botnet.

Nous avons mis en place plusieurs astuces pour limiter
les impacts. Ca se passe plus tôt bien, mais on est
loin de la perfection qu'on veut proposer. On continue
discuter avec AS12956 pour avoir de nouveaux 100G de
capacité afin de savoir réceptionner ce DoS dans les
bonnes conditions et le nettoyer.