BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate
Fibra

Problemas de conectividad de fibra Movistar a Amazon AWS con TLS handshake timeouts

1
layoaster
✎
3
⋮

Trabajo desde casa y desde esta mañana estoy teniendo problemas de conexión intermitentes. Estoy en Santa Cruz de Tenerife.

Básicamente, muchas páginas tardan mucho en cargar o directamente hacen time out. Mucho TLS handshake fallando y sesiones de SSH que se cierran.

No creo que sea algo local, porque otros colegas con O2/Movistar también experimentaban los mismos fallos.

Jav9i
1
⋮

Si haces un ping continuo a un servicio tipo Google que latencias tienes media? Hay paquetes perdidos? Si haces un tracert la latencia se dispara en un salto?

🗨️ 1
✖
layoaster
⋮

ping:

> ping www.google.com
PING www.google.es (216.58.215.163) 56(84) bytes of data.
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=1 ttl=117 time=31.1 ms
64 bytes from waw02s06-in-f4.1e100.net (216.58.209.68): icmp_seq=2 ttl=117 time=33.5 ms
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=3 ttl=117 time=33.7 ms
64 bytes from waw02s06-in-f4.1e100.net (216.58.209.68): icmp_seq=4 ttl=117 time=33.3 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=5 ttl=117 time=34.1 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=6 ttl=117 time=32.6 ms
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=7 ttl=117 time=32.4 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=8 ttl=117 time=33.2 ms
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=9 ttl=117 time=32.9 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=10 ttl=117 time=32.1 ms
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=11 ttl=117 time=32.4 ms
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=12 ttl=117 time=33.5 ms
64 bytes from waw02s06-in-f4.1e100.net (216.58.209.68): icmp_seq=13 ttl=117 time=33.9 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=14 ttl=117 time=33.1 ms
64 bytes from waw02s06-in-f68.1e100.net (216.58.209.68): icmp_seq=15 ttl=117 time=32.4 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=16 ttl=117 time=30.3 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=17 ttl=117 time=30.1 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=18 ttl=117 time=32.6 ms
64 bytes from waw02s06-in-f4.1e100.net (216.58.209.68): icmp_seq=19 ttl=117 time=33.8 ms
64 bytes from mad07s22-in-f4.1e100.net (216.58.209.68): icmp_seq=20 ttl=117 time=33.2 ms
--- www.google.com ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 30.061/32.701/34.079/1.089 ms

traceroute:

> traceroute -I www.google.com
traceroute to www.google.com (142.250.201.68), 64 hops max
  1   192.168.0.1  1,825ms  2,100ms  2,424ms 
  2   192.168.144.1  3,335ms  2,120ms  2,343ms 
  3   81.41.252.41  3,133ms  3,393ms  2,556ms 
  4   *  *  * 
  5   *  *  * 
  6   *  *  * 
  7   72.14.211.154  30,739ms  31,072ms  30,405ms 
  8   74.125.242.161  30,855ms  30,978ms  31,011ms 
  9   74.125.37.87  30,136ms  29,259ms  28,990ms 
 10   142.250.201.68  27,742ms  27,988ms  27,768ms

Igualmente veo que la mayoria de los fallos son de TLS handshake, como si estuviera descartando paquetes …

image
pjpmosteiro
⋮

Ahora mismo, desde Coruña y fibra O2. No detecto fallos.

Eso si, a nivel interno hemos tenido problemas con las VPN, pero no puedo discernir si es por los servidores de mi empresa o por O2

ping google.es -t
Haciendo ping a google.es [142.250.184.163] con 32 bytes de datos:
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=13ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=14ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=13ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Respuesta desde 142.250.184.163: bytes=32 tiempo=12ms TTL=117
Estadísticas de ping para 142.250.184.163:
Paquetes: enviados = 11, recibidos = 11, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 12ms, Máximo = 14ms, Media = 12ms
image
x4b1
⋮

Hola!

Yo desde ayer a la noche he tenido algunos problemas para alcanzar servidores del trabajo en el datacenter de R, y la VPN de la empresa (también con R) tenía cortes intermitentes. Yo me encuentro en la provincia de Pontevedra y si que he notado en algunos días pequeños cortes sobre todo a partir de las 0:00, por ejemplo con los servidores de Netatmo. Si me cambio para el backup 4G con Orange todo va correcto.

Supongo que andarán toqueteando algo.

Un saludo,

Spam
1
⋮

Otro por aquí con Movistar con problemas todo el día de hoy para conectar a servidores alojados en AWS.

✖
layoaster
⋮

Pues la verdad es que justo uso cluster de kubernetes en AWS y he estado todo el dia sufriendo con los TLS handshake timeouts.

Aún así no estoy seguro que se limite a servicios backed by AWS …

🗨️ 1
✖
Jav9i
⋮

Un compañero de trabajo se ha quejado de carga lenta de webs alojadas en AWS, por lo que tiene pinta de que el problema esta en el propio canuto hacía AWS

Darkro
1
⋮

Hola, me he registrado solo para responder con la solucion que he dado

En mi adapatador de red he reducido el MTU en 100 bytes, seguramente con 50 tambien valga

Por defecto suele ser 1500, pues lo he establecido a 1400 (GNU/Linux) y reiniciado el adaptador/conexion (en mi equipo, wifi en mi caso). Tras eso todo me ha funcionado correctamente

Tened en cuenta cosas como VPNs que seguramente debais reducir el MTU, yo uso Wireguard por ejemplo

Tambien alguien en mi empresa ha tenido problemas desde docker tras reducir el MTU y hemos tenido que configurar el MTU de su red interna a 1300 mediante docker-compose

Cosmonauta
⋮

Aquí no he notado nada raro.

¿En qué provincia estás?

🗨️ 1
✖
layoaster
⋮

Se me olvidó incluirlo, Santa Cruz de Tenerife

Ossian
⋮

Yo en Ourense tengo problemas de carga intermitentes por WiFi con O2, de repente una pagina da timeout, la app de Amazon carga como el carajo, y los servidores de actualización de Samsung ídem, por datos moviles sin problemas

🗨️ 2
✖
Tete84
1
⋮

Me pasó exactamente lo mismo ayer. Ya está solucionado, parece.

🗨️ 1
✖
Ossian
⋮

esta mañana todavía me pasó alguna vez, pero ahora parece que va todo bien

skgsergio
⋮

Yo he estado currando todo el día con cero problemas pero el kubernetes y las máquinas a las que me conecto están en Azure.

Desde Madrid.

Spam
⋮

Los problemas de conectividad también están afectando a la península. No es una incidencia localizada.

layoaster
1
⋮

EL problema parece estar resuelto a día de hoy … La verdad es que increíble que tarden tanto en arreglar estos problemas. Tener problemas con un cloud como AWS es como dejarte sin medio internet.

1