La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Incidents Orange => Discussion démarrée par: jeremmm le 11 mars 2022 à 15:57:48
-
Bonjour,
Bon, j'ai un soucis bizarre depuis quelques jours. J'ai de grosses lenteurs en allant sur différents sites (Netflix, AWS, ...).
Par moment, ca chargement bien, mais la plus part du temps ca mouline pendant bien 30s-1min avant d'avoir quelques choses a l'ecran.
J'ai fait pas mal de chose pour voir si ca venait de chez moi mais sans grand resultat.
- restart du router (mikrotik) x fois
- upgrade du router
- debrancher tout ce que j'ai sur mon reseau (lab, wifi, ...)
- reinstall d'un de mes PC pour etre sur
- test de debit/latence (3-5ms, 950+ download, 380+ upload)
- changement de dns (test avec les dns de google, cloudflare, opendns)
Avec tout ceci, pas vraiment d'amelioration
J'ai test de faire passer tout mon traffic vers le VPN du taf et la par contre tout semble bien fonctionner (serveur VPN chez AWS).
Je me demande si il n'y aurai pas des soucis d'interco avec certains cloud provider ces derniers temps qui pourrait expliquer ce que je subis.
Avez-vous deja eu ce genre de soucis (bouteille a la mer)?
Gracias
-
Même chose ici.
Surtout en IPv6 (systématique), aléatoire en IPv4.
└─# mtr -r 2a05:d014:8f1:7520:2be5:1dd4:75d:1262
Start: 2022-03-11T15:21:20+0000
HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev
1.|-- livebox.home 0.0% 10 0.7 0.7 0.5 1.5 0.3
2.|-- 2a01cb08a0040200019302530 0.0% 10 2.1 2.2 1.7 3.2 0.4
3.|-- 2a01:cfc4::b 0.0% 10 2.9 3.2 2.7 4.7 0.6
4.|-- bundle-ether104.pastr4.pa 60.0% 10 2.9 2.8 2.5 3.0 0.2
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 2001:688:0:3:4::64 0.0% 10 2.6 3.1 2.6 4.6 0.6
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- 2a01:578:0:13::10 0.0% 10 2.8 4.0 2.7 8.9 2.5
9.|-- 2a01:578:0:8002::84 0.0% 10 10.2 12.2 9.8 24.7 4.5
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Sa copine en IPv4 :
└─# mtr -r 18.185.132.34
Start: 2022-03-11T15:22:26+0000
HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev
1.|-- livebox.home 0.0% 10 0.6 0.5 0.4 0.6 0.1
2.|-- 80.10.239.9 0.0% 10 2.1 2.1 2.0 2.6 0.2
3.|-- ae102-0.ncidf103.rbci.ora 0.0% 10 2.3 2.8 2.2 5.4 1.0
4.|-- ae41-0.niidf101.rbci.oran 0.0% 10 2.9 2.9 2.8 3.2 0.1
5.|-- 193.252.137.10 60.0% 10 3.1 3.0 2.9 3.1 0.1
6.|-- bundle-ether303.partr1.pa 0.0% 10 3.0 3.2 3.0 3.4 0.1
7.|-- 193.251.248.148 0.0% 10 9.4 3.9 2.8 9.4 2.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
-
Et j'ai exactement le même problème avec le VPN (maison) du travail.
-
Bon, je me sens moi seul :'(
Avec la meme commande en IPv4
mtr -r 18.185.132.34
Start: 2022-03-11T16:52:21+0100
HOST: ip-192-168-10-15.eu-west-1. Loss% Snt Last Avg Best Wrst StDev
1.|-- ip-192-168-10-1.eu-west-1 0.0% 10 0.4 0.4 0.3 0.5 0.1
2.|-- 80.10.235.169 0.0% 10 1.7 1.7 1.7 1.9 0.1
3.|-- ae107-0.ncidf203.rbci.ora 0.0% 10 2.4 2.3 2.2 2.4 0.1
4.|-- ae41-0.niidf201.rbci.oran 0.0% 10 2.7 2.7 2.6 2.8 0.1
5.|-- 81.253.184.182 0.0% 10 2.9 3.4 2.7 9.0 2.0
6.|-- bundle-ether311.partr1.pa 50.0% 10 3.4 3.3 3.2 3.4 0.1
7.|-- amazon-29.gw.opentransit. 0.0% 10 2.7 2.9 2.7 3.3 0.2
Pas mal de perte. Je monte a 70% par moment.
-
Bon, je me sens moi seul :'(
Avec la meme commande en IPv4
mtr -r 18.185.132.34
Start: 2022-03-11T16:52:21+0100
HOST: ip-192-168-10-15.eu-west-1. Loss% Snt Last Avg Best Wrst StDev
1.|-- ip-192-168-10-1.eu-west-1 0.0% 10 0.4 0.4 0.3 0.5 0.1
2.|-- 80.10.235.169 0.0% 10 1.7 1.7 1.7 1.9 0.1
3.|-- ae107-0.ncidf203.rbci.ora 0.0% 10 2.4 2.3 2.2 2.4 0.1
4.|-- ae41-0.niidf201.rbci.oran 0.0% 10 2.7 2.7 2.6 2.8 0.1
5.|-- 81.253.184.182 0.0% 10 2.9 3.4 2.7 9.0 2.0
6.|-- bundle-ether311.partr1.pa 50.0% 10 3.4 3.3 3.2 3.4 0.1
7.|-- amazon-29.gw.opentransit. 0.0% 10 2.7 2.9 2.7 3.3 0.2
Pas mal de perte. Je monte a 70% par moment.
0 perte et moins de 3 ms entre toi et AWS, le problème est ailleurs que chez Orange, d'autant plus que le PNI AWS sur PARTR1 est loin d'être blindé (moyenne de 15 à 20% de charge en v6 comme en v4.
-
En IPv4 c'est aléatoire.
-
Chez moi ça commence à perdre quand ça arrive chez OpenTransit...
-
Pour illustrer.
-
Ce n'est pas de la perte.
C'est juste que les équipements chez Orange n'ont pas vocation à répondre et idem pour ceux côté AWS.
-
Je sais que certains équipements n’ont pas vocation à répondre à l’ICMP, mais il y a clairement un souci entre Orange et AWS. Ne serait-ce que niveau débit.
-
Je sais que certains équipements n’ont pas vocation à répondre à l’ICMP, mais il y a clairement un souci entre Orange et AWS. Ne serait-ce que niveau débit.
Non, les liens sont loin, mais alors très loin d'être chargés.
-
J’ai 6 personnes en fibre Orange avec ce problème, dont certaines hors d’IdF donc c’est qu’il y a un problème…
-
d'accord :)
Et moi je regarde les différents liens backbone ainsi que les différents PNI AWS et c'est laaaaarge .... bien dimensionné, 0 loss
-
Si tu penses autrement n’hésites pas à développer ou à suggérer, c’est très pénalisant sur certains sites.
Depuis OVH, Scaleway je tape mon Gbps sans problème.
-
Je ne constate pas d'anomalie avec ma connexion.
-
TI@RY, c'est pas parce qu'il n'y a pas de saturation évidente qu'il n'y a pas un problème réel.
On voit sur les traceroutes que le chemin ipv6 n'est pas le même qu'en ipv4. Un lien avec des erreurs par exemple ?
-
Si cela peut aider :
Start: 2022-03-11T23:38:04+0100
HOST: atom Loss% Snt Last Avg Best Wrst StDev
1.|-- livebox.home (2a01:cb08:xxx:xxxx:xxx:c6ff:fee9:f8b0) 0.0% 10 0.5 0.7 0.4 2.1 0.5
2.|-- 2a01cb08a00402020193025300770002.ipv6.abo.wanadoo.fr (2a01:cb08:a004:202:193:253 0.0% 10 1.9 1.9 1.7 2.3 0.2
3.|-- 2a01:cfc4:0:500::b 0.0% 10 2.4 2.5 2.3 2.8 0.2
4.|-- bundle-ether104.auvtr5.aubervilliers.opentransit.net (2a01:cfc4:0:500::7) 60.0% 10 2.6 2.6 2.5 2.6 0.1
5.|-- bundle-ether311.partr1.paris.opentransit.net (2001:688:0:2:8000::c0) 30.0% 10 3.0 2.6 2.4 3.0 0.2
6.|-- 2001:688:0:3:8::18 0.0% 10 2.4 4.0 2.3 11.7 3.3
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- 2a01:578:0:13::f 0.0% 10 2.6 2.4 2.2 3.0 0.2
9.|-- 2a01:578:0:8002::82 0.0% 10 10.1 14.0 9.7 34.8 8.8
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Start: 2022-03-11T23:38:20+0100
HOST: atom Loss% Snt Last Avg Best Wrst StDev
1.|-- livebox.home (192.168.1.1) 0.0% 10 0.3 0.4 0.3 0.5 0.0
2.|-- 80.10.232.85 0.0% 10 1.8 1.8 1.6 2.0 0.1
3.|-- ae109-0.ncidf304.rbci.orange.net (193.253.82.70) 0.0% 10 1.8 1.9 1.7 2.3 0.2
4.|-- ae42-0.niidf302.rbci.orange.net (193.252.159.153) 0.0% 10 2.4 2.3 2.2 2.6 0.1
5.|-- 193.252.137.78 0.0% 10 2.4 13.9 2.4 115.9 35.8
6.|-- bundle-ether311.partr1.paris.opentransit.net (193.251.131.0) 0.0% 10 3.0 3.1 2.9 4.0 0.3
7.|-- 193.251.248.148 0.0% 10 2.4 8.0 2.4 29.6 11.3
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
20.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
21.|-- ec2-18-185-132-34.eu-central-1.compute.amazonaws.com (18.185.132.34) 0.0% 10 10.3 10.4 10.2 10.5 0.1
Pas de lenteur pour télécharger le fichier Termius.exe (13.249.9.64)
-
Bonjour à tous,
En faisait des recherches sur mes problèmes de lenteur vers AWS je suis tombé sur ce post
J'ai exactement les mêmes problèmes que ceux mentionnés plus haut... L'ensemble des FQDN internes à AWS sont extrêmement lents et/ou ne se chargent pas.
Je suis abonné Orange/Fibre, sur Paris et je m'ajoute au témoignages précédents
Je n'arrive pas à faire de tracert concluants puisque les 3/4 des équipements sur le chemin ne répondent pas
Mais en passant sur les dev tool des navigateurs on voit bien des sous domaines chargées en 20s (oui s et non ms)
En passant en 4G plus aucun problème...ce qui démontre bien le lien avec la fibre Orange.
J'ai tenté un appel support sans franc succès...
-
Bonjour,
FTTH Orange sur Rouen, aucun souci rencontré pour moi.
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| LIVEBOX - 0 | 10 | 10 | 0 | 1 | 4 | 1 |
| 80.10.236.201 - 0 | 10 | 10 | 1 | 3 | 13 | 1 |
| ae105-0.ncrou102.rbci.orange.net - 0 | 10 | 10 | 1 | 4 | 13 | 3 |
| ae44-0.niidf202.rbci.orange.net - 0 | 10 | 10 | 4 | 6 | 13 | 4 |
| 193.252.137.74 - 0 | 10 | 10 | 5 | 6 | 13 | 5 |
|bundle-ether303.partr1.paris.opentransit.net - 0 | 10 | 10 | 4 | 6 | 13 | 5 |
| 193.251.248.38 - 0 | 10 | 10 | 4 | 7 | 13 | 5 |
|ec2-18-185-132-34.eu-central-1.compute.amazonaws.com - 0 | 10 | 10 | 12 | 14 | 20 | 12 |
|________________________________________________|______|______|______|______|______|______|
-
J'ai toujours ce problème de débit de mon côté.
A côté de ça, vers OVH ou Scaleway je peux taper tout mon débit, que ce soit en IPv4 ou en IPv6.
Idem chez Speedtest, Fast, etc.
-
Bonjour à tous,
En faisait des recherches sur mes problèmes de lenteur vers AWS je suis tombé sur ce post
J'ai exactement les mêmes problèmes que ceux mentionnés plus haut... L'ensemble des FQDN internes à AWS sont extrêmement lents et/ou ne se chargent pas.
Je suis abonné Orange/Fibre, sur Paris et je m'ajoute au témoignages précédents
Je n'arrive pas à faire de tracert concluants puisque les 3/4 des équipements sur le chemin ne répondent pas
Mais en passant sur les dev tool des navigateurs on voit bien des sous domaines chargées en 20s (oui s et non ms)
En passant en 4G plus aucun problème...ce qui démontre bien le lien avec la fibre Orange.
J'ai tenté un appel support sans franc succès...
Problème similaire pour moi, Orange Fibre dans le 92.
Latence + perte de paquet sur les sites AWS, dès que je passe en 4G (Orange) ou par un VPN (PureVPN) le problème disparait.
Exemple :
Détermination de l’itinéraire vers ticketswap.com [52.215.70.196]
avec un maximum de 30 sauts :
1 4 ms 3 ms 4 ms lan.home [192.168.0.1]
2 8 ms 5 ms 6 ms 80.10.236.113
3 9 ms 8 ms 10 ms ae99-0.ncidf103.rbci.orange.net [193.253.80.78]
4 6 ms 6 ms 9 ms ae41-0.niidf101.rbci.orange.net [193.252.159.42]
5 11 ms 32 ms 5 ms 193.252.137.10
6 9 ms 6 ms 8 ms bundle-ether303.partr1.paris.opentransit.net [193.251.131.8]
7 7 ms 7 ms 8 ms 193.251.248.36
8 * * * Délai d’attente de la demande dépassé.
9 * * * Délai d’attente de la demande dépassé.
10 * * * Délai d’attente de la demande dépassé.
11 * * * Délai d’attente de la demande dépassé.
12 * * * Délai d’attente de la demande dépassé.
13 * * * Délai d’attente de la demande dépassé.
14 * * * Délai d’attente de la demande dépassé.
15 * * * Délai d’attente de la demande dépassé.
16 * * * Délai d’attente de la demande dépassé.
17 * * * Délai d’attente de la demande dépassé.
18 * * * Délai d’attente de la demande dépassé.
19 * * * Délai d’attente de la demande dépassé.
20 * * * Délai d’attente de la demande dépassé.
21 * * * Délai d’attente de la demande dépassé.
22 * * * Délai d’attente de la demande dépassé.
23 24 ms 24 ms 28 ms ec2-52-215-70-196.eu-west-1.compute.amazonaws.com [52.215.70.196]
-
RAS sur Lyon.
$ wget -O /dev/null https://autoupdate.termius.com/windows/Termius.exe
--2022-03-13 17:25:15-- https://autoupdate.termius.com/windows/Termius.exe
Résolution de autoupdate.termius.com (autoupdate.termius.com)… 52.222.174.78, 52.222.174.120, 52.222.174.37, ...
Connexion à autoupdate.termius.com (autoupdate.termius.com)|52.222.174.78|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 196169040 (187M) [application/octet-stream]
Sauvegarde en : « /dev/null »
/dev/null 100%[==========================================================>] 187,08M 35,4MB/s ds 6,2s
2022-03-13 17:25:22 (30,2 MB/s) — « /dev/null » sauvegardé [196169040/196169040]
$ mtr 52.222.174.78 -zrwc10
Start: 2022-03-13T17:27:11+0100
HOST: [redacted] Loss% Snt Last Avg Best Wrst StDev
1. AS??? 172.16.1.254 0.0% 10 0.3 0.3 0.3 0.4 0.0
2. AS??? 80.10.235.21 0.0% 10 1.1 1.2 0.8 1.7 0.3
3. AS??? lag-10.nelyn29z.rbci.orange.net 60.0% 10 0.8 1.0 0.8 1.3 0.2
4. AS??? ae83-0.nclyo201.rbci.orange.net 0.0% 10 1.9 1.5 1.1 2.0 0.3
5. AS??? ae41-0.nilyo201.rbci.orange.net 0.0% 10 1.1 1.5 1.0 2.0 0.4
6. AS??? ae40-0.nilyo202.rbci.orange.net 0.0% 10 1.8 1.9 1.4 2.3 0.3
7. AS??? 81.253.184.102 0.0% 10 7.5 7.1 6.7 7.5 0.3
8. AS??? bundle-ether311.partr1.paris.opentransit.net 0.0% 10 7.3 7.7 7.3 8.1 0.3
9. AS??? 193.251.248.148 0.0% 10 7.2 9.7 6.9 20.1 4.2
10. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18. AS16509 server-52-222-174-78.cdg50.r.cloudfront.net 0.0% 10 6.9 7.2 6.7 7.6 0.3
-
Au vu de vos traceroutes, il y a plusieurs liens en ecmp (niveau 3 - pas un lag de niveau 2) en sortie du routeur PARTR1 vers aws.
Certains liens n'ont pas de problèmes, comme par exemple les nexthops 193.251.248.148 et 193.251.248.38, alors qu'avec 193.251.248.36 et 193.251.249.168 certains d'entre vous ont constaté le problème.
De mon coté j'ai constaté le pb en téléchargeant termius.exe sur 52.222.149.103 depuis chez moi. Je passe par 193.251.248.36 :
$ mtr -rwc10 52.222.149.103
Start: 2022-03-13T23:09:47+0100
HOST: amnesia Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 10 0.6 0.6 0.5 1.1 0.2
2.|-- 80.10.237.121 0.0% 10 9.6 9.4 8.7 10.1 0.3
3.|-- ae112-0.ncren101.rbci.orange.net 0.0% 10 9.0 9.6 8.0 13.6 1.6
4.|-- ae43-0.niidf301.rbci.orange.net 0.0% 10 14.1 13.9 13.3 14.3 0.3
5.|-- 81.253.184.6 0.0% 10 15.4 14.3 13.1 15.4 0.6
6.|-- bundle-ether303.partr1.paris.opentransit.net 0.0% 10 14.2 14.4 13.6 15.1 0.5
7.|-- 193.251.248.36 0.0% 10 13.9 14.2 13.4 14.8 0.4
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- server-52-222-149-103.cdg52.r.cloudfront.net 0.0% 10 13.9 14.1 13.8 14.5 0.2
Le même traceroute depuis une autre connexion me fait passer par 193.251.248.148. Donc le hashing vers la destination ne dépend pas uniquement de l'ip, probablement d'autres paramètres de niveau 4.
$ mtr -rwc10 52.222.174.103
Start: 2022-03-13T23:10:04+0100
HOST: link Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 0.0% 10 14.8 14.9 14.7 15.4 0.2
2.|-- lag-43.arc2-ig3.archives.transitip.raei.francetelecom.net 0.0% 10 15.5 15.2 15.0 16.0 0.3
3.|-- lag-43.arc2-ig3.archives.transitip.raei.francetelecom.net 0.0% 10 14.7 14.7 14.5 15.1 0.2
4.|-- intf-fogi-arc2-ig3.nmidf306.rbci.orange.net 0.0% 10 14.7 14.8 14.6 14.9 0.1
5.|-- ae25-0.ncidf304.rbci.orange.net 0.0% 10 14.9 16.7 14.7 21.5 2.8
6.|-- ae42-0.niidf302.rbci.orange.net 0.0% 10 67.0 20.6 15.2 67.0 16.3
7.|-- 193.252.137.78 0.0% 10 15.4 16.0 15.4 20.4 1.6
8.|-- bundle-ether311.partr1.paris.opentransit.net 0.0% 10 16.4 16.4 16.3 16.6 0.1
9.|-- 193.251.248.148 0.0% 10 15.8 18.4 15.5 29.5 5.2
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- server-52-222-174-103.cdg50.r.cloudfront.net 0.0% 10 15.9 16.0 15.9 16.2 0.1
L'ip 52.222.174.37 me fait passer par la .36 :
$ mtr -rwc10 52.222.174.37
Start: 2022-03-13T23:21:44+0100
HOST: link Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 0.0% 10 35.3 17.0 14.9 35.3 6.4
2.|-- lag-41.aub1-ig3.aubervilliers.transitip.raei.francetelecom.net 0.0% 10 15.5 19.4 15.4 54.2 12.2
3.|-- lag-41.aub1-ig3.aubervilliers.transitip.raei.francetelecom.net 0.0% 10 15.0 15.1 15.0 15.4 0.1
4.|-- intf-fogi-arc2-ig3.nmidf305.rbci.orange.net 0.0% 10 15.2 15.1 14.9 15.2 0.1
5.|-- ae25-0.ncidf303.rbci.orange.net 0.0% 10 15.3 22.9 15.2 90.7 23.8
6.|-- ae42-0.niidf301.rbci.orange.net 0.0% 10 15.0 15.1 14.8 15.3 0.2
7.|-- 81.253.184.6 0.0% 10 15.4 15.7 15.4 16.0 0.2
8.|-- bundle-ether303.partr1.paris.opentransit.net 70.0% 10 15.7 15.9 15.7 16.0 0.2
9.|-- 193.251.248.36 0.0% 10 15.8 19.7 15.4 36.4 7.3
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- autoupdate.termius.com 0.0% 10 16.3 16.3 16.2 16.4 0.1
En forçant l'ip 52.222.149.103 pour autoupdate.termius.com j'atteins toutefois des débits très corrects de plusieurs Mo/s, en passant par la .36...
Le soucis peut venir du chemin retour pour lequel nous n'avons pas de visibilité (et dépend donc de l'ip source), ou bien d'un lien dans le réseau aws après cette fameuse IP.
(a noter, les ip des serveurs changent d'une requete à une autre, j'obtiens des fois une ip dans 52.222.174.0/24, des fois dans 13.225.26.0/24, 52.222.149.0/24... Cela ne facilite pas le diag.
Pas de solution évidente au problème vu de l'extérieur...
-
En regardant 13.249.9.65 (utilisé pour une mise à jour Firefox qui a été très longue à télécharger), les traceroutes varient entre 193.251.248.36, 193.251.248.148 et 193.251.249.168.
Il y a également des pertes de paquets.
Pour l'URL Termius, ça semble aléatoire.
Par exemple, en forçant l'IP 13.225.26.24, c'est souvent lent (< 200Ko/s), et parfois rapide (>100Mo/s).
Les traceroutes varient entre 193.251.248.36, 193.251.248.38, 193.251.248.148, et 193.251.249.168, mais je n'arrive pas à faire de corrélation avec la vitesse.
-
ça devrait aller mieux désormais.
-
Je suis en congés donc je ne peux pas trop parler pour la partie VPN du travail, mais pour Termius, c'est instantané désormais.
-
ça devrait aller mieux désormais.
Effectivement, nickel maintenant !
-
Bonjour à tous,
Le problème semble résolu, merci à ceux qui ont corrigé et/ou alerté
Dans la mesure du possible, et pour alimenter ma curiosité, preneur de la root-cause :)
-
Idem c'est toujours instructif
-
Bonjour à tous,
Je ressort ce thread (je ne sais pas s'il vaut mieux en lancer un nouveau ?), parce que je rencontre un problème qui m'a l'air extrêmement similaire.
Download & upload qui paraissent cappés à 1mo/s depuis/vers les serveurs aws US (testé sur s3 & scp depuis ec2), alors que j'obtiens facilement 8-9 mo/s sur la plupart des autres sites.
Pas de problème non plus si connecté en 5g au travers du téléphone (orange).
Comportement similaire de traceroute aussi :
google:
HOST: *** Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.5.1 0.0% 10 7.2 10.7 3.9 42.7 12.0
2.|-- 192.168.1.1 0.0% 10 20.3 29.0 5.2 99.0 36.8
3.|-- 80.10.235.125 0.0% 10 7.7 28.3 5.8 91.7 31.9
4.|-- ae108-0.ncidf203.rbci.orange.net 0.0% 10 36.9 14.8 8.1 36.9 9.5
5.|-- ae41-0.niidf201.rbci.orange.net 0.0% 10 7.3 14.0 6.2 30.6 8.5
6.|-- 81.253.184.182 0.0% 10 12.9 15.0 8.1 31.9 7.5
7.|-- 72.14.211.234 0.0% 10 7.3 41.0 7.3 166.5 63.8
8.|-- 108.170.231.111 0.0% 10 13.9 99.2 13.9 167.5 64.8
9.|-- 142.251.49.137 0.0% 10 145.0 70.3 14.2 145.0 41.8
10.|-- par21s20-in-f14.1e100.net 0.0% 10 46.4 26.3 8.3 49.8 15.8
vs aws s3:
HOST: *** Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.5.1 0.0% 10 72.4 20.2 3.8 87.4 31.7
2.|-- 192.168.1.1 0.0% 10 18.2 135.1 18.2 221.5 84.0
3.|-- 80.10.235.125 0.0% 10 7.4 87.1 7.4 167.5 71.8
4.|-- ae108-0.ncidf203.rbci.orange.net 0.0% 10 8.0 68.2 6.6 133.4 51.5
5.|-- ae41-0.niidf201.rbci.orange.net 0.0% 10 6.8 30.7 5.9 63.8 20.6
6.|-- ae40-0.niidf202.rbci.orange.net 0.0% 10 7.1 38.3 7.1 272.8 82.8
7.|-- 193.252.137.74 0.0% 10 8.8 30.3 6.6 173.2 51.2
8.|-- 81.52.166.173 70.0% 10 84.6 93.2 84.6 109.9 14.5
9.|-- 81.52.187.238 0.0% 10 86.7 124.8 83.0 475.7 123.3
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- s3-1.amazonaws.com 0.0% 10 159.6 118.3 82.1 168.7 36.8
A noter qu'une connaissance rencontrait le même problème, chez SFR, qui a apparemment été résolu par une intervention de quelqu'un de chez eux:
https://la-communaute.sfr.fr/t5/wifi-connexion-filaire-et-d%C3%A9bit/ressources-aws-extr%C3%AAmement-lentes/td-p/2390499
Auriez-vous plus de détails sur comment le problème avait été résolu précedemment?
-
Tu as un lien qu'on puisse tester nous aussi ?
-
https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv
- fibre : 500 à 1mo/s (jamais au dessus)
- 5g : 3 à 30 mo/s
-
romain@Millenium:~$ wget -4 https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv
--2023-03-07 17:52:56-- https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv
Resolving gp-s3-speed-test.s3.amazonaws.com (gp-s3-speed-test.s3.amazonaws.com)... 54.231.202.113, 52.216.142.244, 52.216.29.140, ...
Connecting to gp-s3-speed-test.s3.amazonaws.com (gp-s3-speed-test.s3.amazonaws.com)|54.231.202.113|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 192699914 (184M) [text/csv]
Saving to: ‘random_data.csv’
random_data.csv 100%[=================================================>] 183.77M 36.7MB/s in 5.5s
2023-03-07 17:53:02 (33.3 MB/s) - ‘random_data.csv’ saved [192699914/192699914]
romain@Millenium:~$ wget -6 https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv
--2023-03-07 17:53:07-- https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv
Resolving gp-s3-speed-test.s3.amazonaws.com (gp-s3-speed-test.s3.amazonaws.com)... failed: Name or service not known.
wget: unable to resolve host address ‘gp-s3-speed-test.s3.amazonaws.com’
-
j'obtiens un peu près le même résultat que ro78
-
C’est pas fou sur les 2 Gbps que j’ai mais c’est quand même plus raisonnable que les chiffres évoqués
-
j'obtiens un peu près le même résultat que ro78
La même chose pour moi également !
-
Même débits pour moi avec https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv.
Je constate que le démarrage est assez lent, à cause de la latence de 80ms.
Mais c'est très similaire à http://ping-90ms.online.net/1000Mo.dat.
Avec la valeur de tcp_rmem par défaut (4096 131072 6291456), je plafonne à 30Mo/s.
Avec "sudo sysctl -w net.ipv4.tcp_rmem="8192 262144 536870912", je gagne parfois en vitesse maximale (jusqu'à 1Gbps à la fin du transfert).
Mais parfois ça n'a pas d'effet, je me demande si la limite globale côté serveur n'est pas trop faible.
Pour le test AWS le fichier est trop petit pour voir l'effet.
-
Bonsoir, aucun problème de débit majeur de mon côté, avec le même ping:
wget https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv -O /dev/null
--2023-03-07 23:46:31-- https://gp-s3-speed-test.s3.amazonaws.com/random_data.csv
Résolution de gp-s3-speed-test.s3.amazonaws.com (gp-s3-speed-test.s3.amazonaws.com)… 54.231.234.153, 52.216.8.171, 3.5.17.101, ...
Connexion à gp-s3-speed-test.s3.amazonaws.com (gp-s3-speed-test.s3.amazonaws.com)|54.231.234.153|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 192699914 (184M) [text/csv]
Sauvegarde en : « /dev/null »
/dev/null 100%[=================================================>] 183,77M 33,7MB/s ds 6,2s
2023-03-07 23:46:38 (29,7 MB/s) — « /dev/null » sauvegardé [192699914/192699914]
-
"problème" similaire sur scaleway (burst vers 100Mo/s quelque secondes, puis ~30Mo/s).
En attendant, aucun pb sur le Microsoft store