Fibra

Pérdida de paquetes a ciertos destinos en fibra Smart Digi

dev-elizabeth 8 diciembre 2023 11:48 ✎

⋮

Desde hace unos días estoy notando que algunas aplicaciones específicas, de vez en cuando, tardan mas de lo normal en cargar. En concreto dos: la app de Caixabank y la app de Telegram.

He revisado a través de Wireshark y he visto que, en los momentos en los que pasa, suele haber unos cuantos paquetes SYN marcados como [TCP Retransmission], y haciendo Mtr en modo TCP veo que suelen perderse mas paquetes de lo normal por el camino.

Ambos casos usan rutas diferentes y pierden paquetes en puntos distintos, así que en primera instancia parecen problemas aislados.

Caixabank

En el primer caso, el de la app de Caixabank, la IP de destino es la 217.148.72.229 (AS16383 ITNow), mientras que yo salgo desde 86.127.242.183 (AS57269 Digi Telecom). Aparentemente el AS de Caixabank sólo hace peering con Telefónica, Orange, y Verizon, y parece que el camino desde Digi hacia la red de Verizon da algo de vuelta, así que me envía unas veces por la IP 80.81.193.1 (DE-CIX Frankfurt, AS702 Verizon), y otras por la 195.66.225.4 (LINX LON1, AS702 Verizon), y es en este hop donde se suelen perder aproximadamente un 30% de los paquetes (y aparentemente eso es suficiente para que la app de Caixabank de error de conexión).

Dejo el output de mtr para que se vea mas sencillamente el problema:

My traceroute  [v0.95]
mars (192.168.1.180) -> 217.148.72.229 (217.148.72.229)          2023-12-07T22:10:14+0100
Keys:  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.4%   269    0.4   0.3   0.1   1.0   0.1
 2. 10.0.0.1                                    0.0%   268    1.4   1.2   0.7   2.4   0.3
 3. 172.16.7.97                                 0.0%   268    2.3   2.2   1.3   5.7   0.5
 4. 10.220.101.192                              0.0%   268    2.4   2.4   1.6   9.3   0.7
 5. 86.120.71.48                                0.0%   268    2.4   8.7   1.7  69.7  13.1
    81.196.118.208
 6. 10.220.203.191                              0.0%   268   26.0  31.7  23.2  78.1   6.4
    10.220.178.230
    10.220.203.197
    10.220.178.28
    10.220.203.193
    10.220.167.220
    10.220.167.72
    10.220.203.164
    10.220.203.187
 7. 195.66.225.4                               34.1%   268   29.1  29.7  28.2  32.5   1.1
    80.81.193.1
 8. 146.188.4.170                               0.0%   268   55.4  53.9  49.8  83.9   4.7
    146.188.4.38
 9. (waiting for reply)
10. (waiting for reply)
11. (waiting for reply)
12. (waiting for reply)
13. 217.148.72.229                             11.9%   268   50.3  58.3  45.4  72.3   8.1

En el segundo caso, el de Telegram, el destino es la IP 149.154.167.92 (AS62041 Telegram). Aquí voy mas a ciegas porque parece que las BBDD de PeeringDB no están tan completas, pero según el mtr la ruta es más directa. Paso por la red de RCS & RDS (propietaria de Digi, aunque con AS distinto) y me lleva siempre por la misma IP de Level3/Lumen, la 212.133.66.141 (AS3356, Lumen, por lo que he visto tienen peering directo con RCS&RDS en Madrid), y es en esta IP donde se empiezan a perder bastantes paquetes.

El output de mtr:

My traceroute  [v0.95]
mars (192.168.1.180) -> 149.154.167.92 (149.154.167.92)          2023-12-08T10:59:53+0100
Keys:  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%   230    0.5   0.4   0.1   0.9   0.2
 2. 10.0.0.1                                    0.0%   230    1.0   1.1   0.6   1.9   0.3
 3. 172.16.6.97                                 0.0%   230    2.2   2.0   1.2   4.4   0.4
 4. 10.220.101.148                              0.0%   230    4.4   6.5   1.1  29.1   5.4
 5. 81.196.118.216                              0.0%   230   13.6   3.7   1.1  36.0   5.5
    86.120.71.50
 6. 212.133.66.141                             77.3%   230   13.8  15.8  13.4  36.5   4.8
 7. 154.54.61.129                              28.5%   229    6.4  13.8   5.8 1021.  79.8
 8. 154.54.61.114                              24.9%   229   34.0  35.3  33.2 103.2   8.0
 9. 130.117.2.141                              31.0%   229   27.7  30.4  26.1 145.2  17.0
10. 154.54.56.154                              25.3%   229   31.9  31.2  27.3  75.1   6.0
    130.117.50.250
11. (waiting for reply)
12. 149.154.167.92                             89.5%   229   26.5  33.0  25.9  36.2   3.0

¿Alguien más capaz de reproducir esto?

No sé muy bien con quién se podría contactar para que le echen un ojo, y tampoco me apetece estar pasando por el soporte técnico de Digi con algo tan específico, y que aún así me hagan hacer lo mismo de siempre de reiniciar router, mandarme técnico a casa, etc.

Aell6782 8 diciembre 2023 12:12

⋮

Edit: ahora en cuanto pueda te dejo por aqui cada traceroute que indicas //

Ocurre lo mismo desde hace 3 dias.

Tengo un servidor en interxion con WireGuard para acceso del trabajo, me ha dado por probarlo de pasar por VPN la red de casa y como dato curioso, en cuanto conectas mediante VPN la conexión va perfecta al salir por la red del vps. Como un tiro y todas las rutas ok.

Alguna tienen liada en la red.

Desde hace 3-4 dias viene pasando, se ha reportado a atención al cliente pero nada, dan largas y cero información, mas allá de respuestas genéricas y que los compañeros están trabajando en ello.

✖

dev-elizabeth 8 diciembre 2023 12:24

⋮

Sí, yo a través la de las VPN de Proton y de Cloudflare WARP tampoco tengo problema… En fin, si se ha quejado más gente imagino que eventualmente lo solucionarán, mientras tocará usar VPN como parche

ka0x007 8 diciembre 2023 12:31

⋮

Yo estoy igual, y cada día va a peor, yo no tengo fibra Smart, Tengo NEBA Movistar y tengo los mismos problemas.

DeadGrowl 8 diciembre 2023 12:57

⋮

En X/Twitter nos estamos quejando cada dos por tres, pero respuesta automática y adiós.

Digi Fibra Smart, zona de Barcelona.

Ya llevo tres días sin poder conectarme a Rockstar Games y Xbox, y muchos otros elementos yendo lentísimos.

Si el lunes la cosa sigue así me cambio de compañía.

✖

GroovyTorpedo 9 diciembre 2023 00:35

⋮

Yo he notado lo mismo, en ciertos juegos la latencia se ha incrementado un 50%. Pensé que seria porque la IP me ha cambiado varias veces estos dias cosa que antes era bastante estable, pero sigo teniendo los mismos problemas, quizas es algo con el peering

ChrJr90 8 diciembre 2023 12:58

⋮

A mi en alguna ocasión me ha pasado eso con la App de Telegram, pero era muy poco tiempo demás el que tardaba en cargar así que no le dí mayor importancia. Por mi parte reinstale la app y he de reconocer que me iba mejor, luego ya pasaron unos días y solo volvió a estar como de costumbre. No dí parte a asistencia ni nada, supongo que el problema lo arreglarían y punto.

No te preocupes, muy rara vez suceden cosas así, al poco tiempo suelen corregirlas.

aliveintheseptictank 8 diciembre 2023 13:01

⋮

Me pasa lo mismo desde el martes. Como dicen más arriba, por VPN cero problemas (por ahora) pero sin VPN la lentitud en la carga de ciertos elementos es bestial, hay veces que el propio móvil me quita el wifi y pone los datos, la mayoría de veces he sido yo, harto de la lentitud. He llamado a soporte y espero respuesta. En grupos de Telegram y en otros foros hay más gente afectada, no parece que sea una sola ciudad sino algo a nivel de Digi España

UzuNext 8 diciembre 2023 13:26

⋮

Otro por aquí con problemas, llevo así ya 4 días

Mick Diaz 8 diciembre 2023 15:27

⋮

Confirmo que en los últimos días la cosa va regulera, tanto a través de NEBA como SMART. Algo habrán tocado.

pupum 8 diciembre 2023 15:49

⋮

Ídem, estamos muchos igual. El canal de Digi en Telegram está que arde

Emerge 8 diciembre 2023 19:38

⋮

Me uno al problema. Lo noté el pasado martes, pero como he cambiado el router por uno propio recientemente, dudé si podía ser el router.

Lo noté sobre todo al hacer login en la web de BBVA y en la consola de AWS.

Hasta el lunes no estaré por casa, comentaré por aquí si sigue igual.

GroovyTorpedo 9 diciembre 2023 01:11

⋮

Bueno probando el tracert a la IP que indicas pierdo la gran mayoría de paquetes, pero yo diría que estan teniendo algun problema con el Peering… probando con IPs en españa no he encontrado problemas de perdidas de paquetes o latencia, pero al probar IPs de fuera de España he notado que la latencia se ha incrementado bastante respecto a hace ~3 días.

De hecho tengo un pod de monitoring hacia varios destinos que uso por trabajo y he visto que se ha incrementado bastante la latencia y a veces pierde tambien algun paquete… asi que me temo algo deben estar haciendo con el peering / routing - ya que incluso estos días mi IP publica ha cambiado bastante sin reiniciar router ni nada, cosa que no me había pasado en +1 año que llevo con ellos.

Tengo todo mi equipo propio (ONT + Router + Switch & AP's) así que tampoco tengo claro que soporte me podria dar Digi al ser mis equipos.

MX17R4 9 diciembre 2023 08:06

⋮

corroboro Motril, fibra smart 1g, subida de latencia y de jitter injustificada, he pasado a mismo server de 20 a 34ms… y el jitter de menos de 1ms a 6ms… así que algo le pasa a la red.

pupum 9 diciembre 2023 15:16

⋮

Esto de pérdida de paquetes y de rutas de Digi o lo que sea me está fastidiando todas las conexiones de los dispositivos y tengo toda la domótica desvinculada y fuera de red cada dos por tres. No pueden tenernos así. Les doy tres días sino contrato O2.

✖

Tornadin 9 diciembre 2023 17:41

⋮

Pues según mi conexión y según consta en grupos y foros ya estaría resuelto, así que mira a ver si no tienes otra causa.

Agustin Lorenzo 1 enero 2024 19:20

⋮

Buenas tardes chicos,

Feliz año.

Creo que volvemos a las andadas con este tema, noto que cuando abro Telegram tarda mas de la cuenta en "Conectando…" y también me lleva pasando desde hace unas noches que al utilizar YouTube se queda en buffering o cuando lo consigue es demasiado corto, sin embargo al cambiar a datos móviles de otra compañía empieza a cargar el buffer como lo hacia normalmente.

Hablando con algunos compañeros que también tienen Digi reportan problemas de buffering con Disney Plus también.

Zona: Alcala de Henares

Fibra: SMART - 1GB con Conexión Plus

He realizado un par de MTR en modo TCP y he visto esto.

Disney+ (mtr -T disneyplus.com):

Telegram (mtr -T telegram.org):

YouTube (mtr -T rr10–sn-gqn-h5qs.googlevideo.com) (el hacerlo contra los servidores de googlevideo es porque el contenido lo cargan via GGC y Digi tiene nodos)

Contra YouTube, podría entender que es un problema de capacidad de Digi con Google o de capacidad de los GGC de Google alojados en Digi porque los MTR salen limpios y no salen de la red como es obvio.

¿Alguien esta notando algo raro con estos servicios?

Un saludo, Agustin

✖

pepejil 1 enero 2024 19:40

⋮

¿Dices que Digi tiene servidores de Google para pre-buffering? Si es así, entonces el problema no está en sus nodos de intercambio, sino más bien en un cuello de botella entre las centrales y el core de Digi.

Si es tal y como lo digo, tendrás problemas en todos los sitios que te conectes.

✖

Agustin Lorenzo 1 enero 2024 20:51

⋮

Hola @pepejil

No solamente Digi, tienen GGC lo tienen casi todos los operadores en España para hacer offload del trafico de Google (Drive, YouTube, etc… de servicios pesados)

No no, cuando sucede esta "saturación" el resto de navegación es correcta y los test de velocidad con servidores en España y Europa (Alemania, Francia) son correctos.

Un saludo, Agustín