Pour le test de débit, impossible d'utiliser wget, si vous avez une solution en ligne de commande sous linux...

wget -O /dev/null https://webmail.tutomatik.fr/1000Mb.test
--2017-01-07 16:42:31--  https://webmail.tutomatik.fr/1000Mb.test
Résolution de webmail.tutomatik.fr (webmail.tutomatik.fr)… 2400:cb00:2048:1::6818:76dd, 2400:cb00:2048:1::6818:77dd, 104.24.119.221, ...
Connexion à webmail.tutomatik.fr (webmail.tutomatik.fr)|2400:cb00:2048:1::6818:76dd|:443… connecté.
requête HTTP transmise, en attente de la réponse… 503 Service Temporarily Unavailable
2017-01-07 16:42:31 erreur 503 : Service Temporarily Unavailable.

Traceroute IPv4 OVH Gravelines (59) : 6,6ms (via AMS-IX)
# mtr -b4zrwc100 webmail.tutomatik.fr
Start: Sat Jan  7 15:38:01 2017
HOST: ovh.testdebit.info                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS16276 37.187.131.252                               0.0%   100   36.6  13.6   0.8  79.7  16.7
  2. AS16276 po109.gra-g2-a75.fr.eu (37.187.231.89)       0.0%   100    0.3   0.4   0.2   1.3   0.0
  3. AS4565  10.95.33.10                                  0.0%   100    8.1   8.1   7.8  13.4   0.5
  4. AS16276 be100-1112.ams-5-a9.nl.eu (213.251.128.67)   0.0%   100    6.8   6.8   6.3   9.3   0.3
  5. AS1200  ams-ix.as13335.net (80.249.211.140)          0.0%   100    6.9   7.2   6.6  12.7   0.9
  6. AS13335 104.24.118.221                               0.0%   100    7.1   6.9   6.6   8.2   0.1

Traceroute IPv6 OVH Gravelines (59) : 4,7ms (via Equinix-Paris)
# mtr -b6zrwc100 webmail.tutomatik.fr
Start: Sat Jan  7 15:40:45 2017
HOST: ovh.testdebit.info                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS16276 2001:41d0:a:41ff:ff:ff:ff:fe                          13.0%   100   39.1   8.9   0.8  39.4   9.8
  2. AS16276 po109.gra-g2-a75.fr.eu (2001:41d0::8ad)                0.0%   100    0.7   0.4   0.3   0.7   0.0
  3. AS16276 be10-20.gra-g2-a9.fr.eu (2001:41d0::234)               7.0%   100    2.4   4.9   0.8  42.9   7.3
  4. AS16276 be99-1191.th2-1-a9.fr.eu (2001:41d0::28f)              2.0%   100    4.8   5.0   4.7   5.6   0.0
  5. AS???   equinix-paris.cloudflare.com (2001:7f8:43::1:3335:1)   0.0%   100    4.8   4.9   4.8   5.7   0.0
  6. AS13335 2400:cb00:2048:1::6818:77dd                            0.0%   100    4.8   4.8   4.7   5.1   0.0

Il y a visiblement un problème en IPv4 uniquement, vu qu'avec IPv6 on va sur Paris.

Je pense qu'il y a suffisamment pour ouvrir un incident.

Pour l'incident, j'ai envoyé un ticket la première fois que ce problème est apparu, le problème a été résolu quelques jours avant la réponse, que voici (j'ai cut l'entête du ticket) :

Thank you for contacting Cloudflare Support. I am very glad that everything has resolved, in the future if you see a similar routing or any other network issues, you can refer to the status page, https://www.cloudflarestatus.com/ That will show if we are having locations down for maintenance or other issues.

Alternatively you would want to check into the status of the ISPs that are involved in the change and it's possible they could have a temporary network outage that is causing this.

Pour les non-anglophones :

Merci d'avoir contacté le support CloudFlare. Je suis heureux que tout ait été résolu, si vous rencontrez un problème de routage similaire ou un autre incident réseau dans le futur, vous pouvez vous rendre sur la page d'état ; cela vous montrera si des points de présences sont en maintenance ou en panne.

Autrement, vous devriez vérifier l'état des FAIs qui sont impliqués dans ces changements, il est possible qu'ils aient un incident réseau temporaire qui causerait cela.

J'avais joint au premier ticket un fichier texte contenant tous les traceroutes que j'avais fait et que vous m'avez fourni (merci à tous !), et un graphe smokeping montrant la hausse du ping et du léger packet loss.

J'ai ré-envoyé un ticket dans la nuit, pas encore de réponse (priorité aux offres payantes), que voici (j'avais prévenu dans le 1er ticket que j'étais naze niveau écriture de lettres en anglais ^^) :

Hi,

Since ~2 days, the problem is here again : All IPv4 traffic with my CloudFlare IP is going to Brussels or somewhere else, but doesn't use Paris location.
(The traceroutes in the attachment I sent ~1 week ago are the same, all ISPs and IP transits don't use traffic from Paris but from Brussels, Frankfurt, Marseille...)

The problem is only for my CloudFlare cache IPs : 104.24.119.221 and 104.24.118.221
But for example if I traceroute to cloudflare.com, it goes directly to Paris datacenter.

Thank you a lot!

Soit en français :

Depuis environ 2 jours, le problème est de nouveau présent : Tout le trafic IPv4 depuis/vers mon IP CloudFlare va à Bruxelles ou autre part, mais n'utilise pas le point de présence situé à Paris.
(Les traceroutes dans le fichier joint il y a environ une semaine sont identiques, tous les FAIs et transitaires IPs utilisent un point de présence autre que Paris: Bruxelles, Marseille, Francfort...)

Le problème est uniquement présent pour mes IPs 104.24.119.221 et 104.24.118.221
Mais si, par exemple, j'effectue un traceroute vers cloudflare.com, le trafic part directement au datacenter de Paris.

Merci

Les LG des tier1: pas forcèment pertinent dans ce contexte, il faut plutôt des réseaux qui peerent à Paris et Amsterdam avec Cloudflare, pour bien illustrer la différence d'annonces.

Je ne connais pas de petit opérateur qui a une LG avec bgp ...

Tu peux commencer par celui de IELO: http://as-ielo.net/lg

Je vois pas grande différences ...

Bah si...

Je note juste que sur la route qui serait la plus "directe" (AS13335 directement), la Local Pref est 0 pour mon domaine et 1 pour CloudFlare.com

Pas du tout. C'est d'ailleurs un choix d'ingénierie très discutable de Ielo qui met les transits et les peerings à la même localpref de 90.


Pour le préfixe à problème (104.24.112.0/20) on voit notamment cet unique chemin en peering (en retirant toutes les routes vers les transits de Ielo - Cogent, Tata et Opentransit):

BGP routing table entry for 104.24.112.0/20
Paths: (7 available, best #7)
  Path #7: Received by speaker 0
  13335 13335 13335, (aggregated by 13335 141.101.65.1)
    80.249.211.140 (metric 1120) from 185.96.187.244 (185.96.187.244)
      Origin IGP, metric 100, localpref 90, valid, internal, best, group-best, import-candidate, import suspect


Si le choix d'ingénierie de Ielo de ne pas faire de next-hop self est aussi très discutable, il est vrai qu'il nous est utile dans le cadre du looking-glass, car on voit directement le next-hop final et donc un simple reverse DNS suffit pour voir où ça va (pas besoin d'aller regarder les communautés BGP).

Ici on a: 80.249.211.140 = ams-ix.as13335.net



En revanche pour un préfixe qui fonctionne comme il faut (ici 198.41.214.0/23), on a en peering (et en virant les received-only, redondantes):


BGP routing table entry for 198.41.214.0/23
Paths: (10 available, best #8)
[...]
  Path #7: Received by speaker 0
  13335 13335, (aggregated by 13335 141.101.65.1)
    80.249.211.140 (metric 1120) from 185.96.187.244 (185.96.187.244)
      Origin IGP, metric 100, localpref 90, valid, internal, import-candidate
  Path #8: Received by speaker 0
  13335 13335, (aggregated by 13335 141.101.67.1)
    195.42.144.143 from 195.42.144.143 (141.101.67.1)
      Origin IGP, metric 100, localpref 90, valid, external, best, group-best, import-candidate
  Path #10: Received by speaker 0
  13335 13335, (aggregated by 13335 141.101.67.1)
    37.49.237.49 (metric 120) from 212.85.145.241 (212.85.145.241)
      Origin IGP, metric 100, localpref 90, valid, internal, import-candidate


Avec:

• Path 7: 80.249.211.140 =  ams-ix.as13335.net
• Path 8: 195.42.144.143 = equinix-paris.cloudflare.com (best)
• Path 10: 37.49.237.49 = cloudflare.par.franceix.net

Bref, on a bien des routes annoncées partout d'un coté et pas annoncées partout de l'autre, et c'est clairement visible avec Ielo qui peere à Paris et à Amsterdam avec Cloudflare.

Voici pour le graphe curl 100k depuis ma machine ONET vers Adeli, pour "innocenter" ma machine:



URL du fichier derrière CloudFlare :
https://webmail.tutomatik.fr/100k.iso et en HTTP: http://webmail.tutomatik.fr/100k.iso

Graphe du Curl depuis ma machine ONET pour télécharger le fichier derrière CloudFlare:
En HTTPS :


En HTTP :


Les ralentissements se sentaient surtout depuis SFR.