Ouais ni vu ni connu on explique qu'on passe par Londres après plusieurs jours par les US...

Le réseau OVH doit être sûrement conçu à la base comme un backbone unicontinental, avec des priorités locales qui supplantent les problèmes géographiques. A savoir qu'un peering aux US prendra le pas sur un transit en Europe même si on est en Europe...

C'est bien de l'avoir corrigé mais est-ce que c'est du "fix" de ce cas où est-ce qu'ils ont revenu le backbone pour mieux le cloisonner entre les continents ?

root@raspberrypi:/home/pi# wget -O /dev/null $(youtube-dl -g )
--2013-07-29 00:53:27--  http://r5---sn-hpa7ln7e.c.youtube.com/videoplayback?mv=m&id=f5b664a7bab5f5fd&cp=U0hWSlBSU19LS0NONl9ITFdCOlQyRjlSTXBJemFC&fexp=919113%2C918112%2C932204%2C916807%2C914090%2C916611%2C909546%2C906397%2C929117%2C929121%2C929906%2C929907%2C925720%2C925722%2C925718%2C925714%2C929917%2C929919%2C912521%2C904830%2C919373%2C904122%2C932216%2C908534%2C919387%2C936303%2C909549%2C900816%2C936301%2C912711%2C935000&key=yt1&ratebypass=yes&source=youtube&gcr=fr&sver=3&mt=1375051947&ip=81.28.200.100&sparams=cp%2Cgcr%2Cid%2Cip%2Cipbits%2Citag%2Cratebypass%2Csource%2Cupn%2Cexpire&itag=37&upn=YDzpbQw-sBw&ms=au&expire=1375075161&ipbits=8&signature=3BAD1349D4538C0AEEA78F2055287C06C1E5BDEC.A2D02F05BE09A0EC1A29BED0F2B6BEFDF8162AE3
Résolution de r5---sn-hpa7ln7e.c.youtube.com (r5---sn-hpa7ln7e.c.youtube.com)... 74.125.14.10, 2a00:1450:4002:8::a
Connexion vers r5---sn-hpa7ln7e.c.youtube.com (r5---sn-hpa7ln7e.c.youtube.com)|74.125.14.10|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 171592965 (164M) [video/mp4]
Sauvegarde en : «/dev/null»

100%[===================================================>] 171 592 965 9,56M/s   ds 19s

2013-07-29 00:53:46 (8,82 MB/s) - «/dev/null» sauvegardé [171592965/171592965]


Je monte à peine à 10 mo /s.

root@raspberrypi:/home/pi# mtr -4rwc100 r5---sn-hpa7ene7.c.youtube.com                       
HOST: raspberrypi                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                  0.0%   100    0.9   0.9   0.8   1.6   0.1
  2.|-- border1-sgp.kwaoo.net        0.0%   100    4.1   4.0   3.8   9.4   0.6
  3.|-- border1-lyonix.kwaoo.net     0.0%   100    6.9   6.9   6.7   8.9   0.3
  4.|-- rr-l2-vlan500.ix.lyonix.net  0.0%   100    6.8   7.1   6.8  11.7   0.6
  5.|-- google-pub.topix.it          0.0%   100   16.3  17.1  16.0  75.6   6.0
  6.|-- 72.14.237.195                0.0%   100   16.3  17.8  16.3  45.5   3.4
  7.|-- 173.194.2.10                 0.0%   100   16.7  17.4  16.1  33.0   3.1

Le défaut des tests de traceroute, c'est que vous obtenez le chemin pour joindre Google mais que ce n'est pas nécessairement le chemin des paquets au retour.
Exemple de chez nous pour joindre une machine Completel :

traceroute to 195.167.195.194 (195.167.195.194), 30 hops max, 60 byte packets
 1  xe-1-3-0-bgp.cr01.th2.net.mediactive-network.net (178.248.208.2)  0.586 ms  0.583 ms  0.580 ms
 2  83.167.40.253 (83.167.40.253)  0.511 ms  0.519 ms  0.516 ms
 3  xe1-2-0.tcr1.rb.par.as8218.eu (83.167.56.178)  0.702 ms  0.703 ms  0.699 ms
 4  46.255.176.189 (46.255.176.189)  1.210 ms  1.210 ms  1.327 ms
 5  212.99.75.105 (212.99.75.105)  1.138 ms  1.140 ms  1.137 ms
 6  reverse.completel.net (213.244.0.229)  1.805 ms  1.905 ms  1.898 ms
 7  reverse.completel.net (213.244.0.225)  1.961 ms  1.952 ms  1.875 ms
...

et le chemin retour obtenu par le looking glass Completel

traceroute to 178.248.208.21 (178.248.208.21), 30 hops max, 38 byte packets
 1  reverse.completel.net (195.167.195.194)  0.343 ms  0.321 ms  0.269 ms
 2  172.17.40.129 (172.17.40.129)  0.218 ms  0.217 ms  0.210 ms
 3  reverse.completel.net (213.244.0.226)  0.920 ms  0.897 ms  0.903 ms
 4  reverse.completel.net (213.244.0.230)  1.503 ms  1.494 ms  1.462 ms
 5  reverse.completel.net (213.244.0.242)  1.919 ms  1.939 ms  1.916 ms
 6  jaguar-network.sfinx.tm.fr (194.68.129.128)  2.114 ms  2.073 ms  2.085 ms
 7  vl80.er01.par02.jaguar-network.net (85.31.194.174)  112.479 ms  206.723 ms  208.003 ms
 8  cpe-et000626.cust.jaguar-network.net (95.143.66.78)  2.374 ms  2.370 ms  2.367 ms
 9  * * *

Ca sort par Neo à TH2 et ça rentre par Jaguar à Equinix PA2 (source et destination étant la même machine)

On peut tricher en filtrant les routes annoncées sur chaque lien ou en les rallongeant artificiellement avec du prepend mais l'hébergeur en face peut lui aussi forcer ses routes. Ce n'est donc pas totalement maitrisable à moins de discuter et de s'entendre avec lui.

Malheureusement pour Google, je n'ai pas trouvé de serveur Looking Glass qui permettrait de faire ces tests....on ne tombe que sur des articles relatifs à leurs lunettes !! 

En temps normal l'interco Google-Free dépend du contenu : pour les vidéos YT, plusieurs routes possibles, mais 100% peering :

72.14.216.98 --> cbv-9k (78.254.249.157)
74.125.50.116 --> cbv-9k
72.14.238.228 --> google-pni-3 (212.27.40.102) --> cbv-9k
72.14.238.234 --> google-pni-3 --> cbv-9k
213.239.48.190 --> google-pni-3 --> cbv9k

Mais encore faut-il faire le tracert vers un serveur de vidéo (r11---sn-aigllm7s.c.youtube.com par exemple) et non vers youtube.com qui n'est qu'un site web.

Et pour les autres services (Google Maps, Gmail, etc...), on passe par un seul point de transit Tata (ix-15-547.tcore1.PVU-Paris.as6453.net).

Mais là effectivement il y a un gros problème avec le peering Google, Free va chercher Google en UK, comme OVH : http://travaux.ovh.net/?do=details&id=9041

Je confirme le retour du PNI à 14h40 après 3 jours de coupure.

Effectivement : coupure du 26/07 15h au 29/07 14h35