Auteur Sujet: Saturation Hibernia -> Akamai ?  (Lu 3764 fois)

0 Membres et 1 Invité sur ce sujet

Jeelo

  • Abonné Orange Fibre
  • *
  • Messages: 3
  • Gif-sur-Yvette (91)
Saturation Hibernia -> Akamai ?
« le: 03 décembre 2018 à 23:33:43 »
Bonjour,

Depuis ce weekend je constate des problèmes de connexion depuis ma fibre Orange, vers les serveurs d'Origin (ou plus précisèment sur l'IP 92.122.203.206, qui appartient à Akamai : AS16625).
J'ai environ 30% de perte de paquets. Mais je ne comprends pas totalement comment calcule WinMTR (ci-joint la capture d'écran) car le nombre de paquets envoyés (et, a fortiori, reçus) au dernier host est bien plus faible que le nombre de paquets envoyés aux routeurs intermédiaires.

D'un côté, il semblerait que le problème vienne d'un transit entre l'AS 5580 et l'AS 16625. D'un autre, j'ai demandé un traceroute à un ami chez Free, et qui n'a aucune perte de paquet, dont voici le résultat :
1 <1 ms * <1 ms FREEBOX [192.168.1.254]
2 24 ms 25 ms 25 ms sez51-1-78-231-189-254.fbx.proxad.net [78.231.189.254] (AS12322)
3 26 ms 26 ms 26 ms 213.228.29.190 (AS12322)
4 29 ms 31 ms 30 ms strasbourg-crs8-1-be1009.intf.routers.proxad.net [194.149.161.169]
5 * 31 ms 31 ms p11-crs16-1-be1109.intf.routers.proxad.net [194.149.160.197]
6 32 ms 31 ms 32 ms 194.149.166.38
7 32 ms 32 ms 31 ms be4204.ccr31.par04.atlas.cogentco.com [149.11.115.13] (AS174)
8 31 ms 32 ms 31 ms be3183.ccr41.par01.atlas.cogentco.com [154.54.38.65] (AS174)
9 31 ms 32 ms 32 ms be3625.rcr21.par05.atlas.cogentco.com [130.117.0.166] (AS174)
10 32 ms 31 ms 33 ms gttnet.par05.atlas.cogentco.com [130.117.15.106] (AS174)
11 33 ms 32 ms 32 ms as5580-gw.cr0-par2.ip4.gtt.net [46.33.93.10] (AS3257)
12 33 ms 33 ms 35 ms akamai-20940-gw.par02-1.fr.as5580.net [78.152.32.98] (AS5580)
13 32 ms 32 ms 32 ms a92-122-203-206.deploy.static.akamaitechnologies.com [92.122.203.206] (AS16625)

Comme on le voit dans son traceroute l'avant-dernière étape est identique à celle que j'ai avec WinMTR, donc ça ne corrobore pas l'idée d'un problème de saturation entre l'AS 5580 et l'AS 16625.

Pour info, j'utilisais les résolveurs DNS de Cloudflare (1.1.1.1) qui m'ont donné l'IP 92.122.203.206 pour origin.com. En utilisant les serveurs de Google (8.8.8.8), j'obtiens une IP différente (23.210.42.34), ce qui résout mon problème.
De plus, je n'ai pas constaté de problème sur d'autres sites.

Avez-vous plus d'informations à ce sujet ou des explications à la situation ?

Merci d'avance.
Julien.

Damien06

  • Abonné Free fibre
  • *
  • Messages: 530
  • CANNES 06
Saturation Hibernia -> Akamai ?
« Réponse #1 le: 03 décembre 2018 à 23:56:50 »
ça ne vient pas d'Orange mais d'akamai cote SFR Câble pas de problème.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.0.1 -    0 | 16217 | 16217 |    0 |    0 |   26 |    0 |
|                              10.93.80.1 -    0 |  408 |  408 |    5 |    7 |   33 |    7 |
|        213-245-0-136.rev.numericable.fr -    0 |  386 |  386 |    5 |    8 |   37 |   10 |
|                          172.19.132.146 -    0 |  104 |  104 |   23 |   31 |   53 |   32 |
|    xe-10-0-1.mpr1.cdg11.fr.zip.zayo.com -    0 |  130 |  130 |   21 |   24 |   51 |   24 |
|          zayo-gtt.cdg11.fr.zip.zayo.com -    0 |  128 |  128 |   21 |   25 |   51 |   23 |
|          as5580-gw.cr0-par2.ip4.gtt.net -    0 |  129 |  129 |   21 |   24 |   51 |   24 |
|   akamai-20940-gw.par02-1.fr.as5580.net -    0 |  122 |  122 |   23 |   25 |   53 |   27 |
|a92-122-203-206.deploy.static.akamaitechnologies.com -    0 |  127 |  127 |   21 |   24 |   52 |   23 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)

Symbol

  • AS52075 Wifirst
  • Expert
  • *
  • Messages: 349
Saturation Hibernia -> Akamai ?
« Réponse #2 le: 04 décembre 2018 à 00:40:43 »
Depuis ce weekend je constate des problèmes de connexion depuis ma fibre Orange, vers les serveurs d'Origin (ou plus précisèment sur l'IP 92.122.203.206, qui appartient à Akamai : AS16625).
[...]
Pour info, j'utilisais les résolveurs DNS de Cloudflare (1.1.1.1) qui m'ont donné l'IP 92.122.203.206 pour origin.com. En utilisant les serveurs de Google (8.8.8.8), j'obtiens une IP différente (23.210.42.34), ce qui résout mon problème.
Voilà pourquoi il faut utiliser les DNS de son ISP, pour tomber sur les IPs des CDN les plus proches plutôt que d'obtenir une IP située n'importe où.
Le problème est donc coté utilisateur: dégrader finalement volontairement sa connectivité en changeant de DNS, ce qui ruine le fonctionnement des CDN.

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 009
  • FTTH >500 Mb/s (13)
Saturation Hibernia -> Akamai ?
« Réponse #3 le: 04 décembre 2018 à 01:09:44 »
Le resolver DNS publique est censé fournir l'EDNS Client Subnet ce qui permet au geodns de fonctionner.
Mais  le resolver de Cloudfare ne le fait pas soi-disant pour des raisons de "privacy".
Privacy alors que tu vas te connecter au service juste après....

Enfin bref, c'est pas la première fois qu'une mesure contre productive techniquement est prise au prétexte d'un anonymat inexistant.

@Symbol: un CDN n'est pas obligé d'utiliser geodns pour être utile.

Symbol

  • AS52075 Wifirst
  • Expert
  • *
  • Messages: 349
Saturation Hibernia -> Akamai ?
« Réponse #4 le: 04 décembre 2018 à 12:18:44 »
@Symbol: un CDN n'est pas obligé d'utiliser geodns pour être utile.
GeoDNS n'est qu'une petite partie du mode de fonctionnement d'un CDN Unicast comme Akamai.
En pratique le système d'Akamai surveille les DNS resolveurs les plus utilisés et notamment leur joignabilité par leurs différents clusters (notamment par ping et latence), et fournit les IPs du meilleur cluster en conséquence. En parallèle ils observent les résultats avec les clients qui ont effectivement été redirigés vers tel ou tel cluster afin d'ajuster les réponses DNS ultérieures.

On est bien dans autre chose que du geoDNS de base.

Au cas où un gros opérateur de DNS récursif (Google, OpenDNS) ait signé un accord avec eux, ils peuvent tenir compte de l'EDNS Client Subnet, en l'absence d'autre info pertinente (vu que le DNS est sur un réseau différent du client).
Mais les statistiques seront généralement moins bonnes.

Du coup, si:
  • tu tournes ton propre DNS récursif sur ta beigebox, qui représentera des clopinettes en nombre de requêtes (donc pas de statistiques chez Akamai)
  • tu utilises un DNS récursif extérieur à ton réseau, sans EDNSClientSubnet et/ou sans accord avec Akamai
tu seras probablement dirigé vers un cluster dont le routage sera peu pertinent pour te fournir les performances attendues.

Et c'est bien ce qui s'observe dans la pratique, et notamment ici dans le cas d'espèce.

Donc, il est préférable d'utiliser les DNS de son ISP si on veut que ça marche.
D'autant que la plupart du temps les gens ne savent pas pourquoi ils ont changé de DNS récursifs, ou leurs raisons sont foireuses ce qui revient au même, et ensuite ils se plaignent que ça rame.


Sur les limitations de l'EDNSclientsubnet: https://www.quora.com/OpenDNS-Why-doesnt-Akamai-support-the-EDNS-client-subnet-extension

OpenDNS, sur les limitations du geoDNS via EDNSclientsubnet pour sélectionner le bon cluster Akamai: https://support.umbrella.com/hc/en-us/articles/230563447-Akamai-Content-and-Cisco-Umbrella-Understanding-issues-with-CDNs-and-troubleshooting-steps

Jeelo

  • Abonné Orange Fibre
  • *
  • Messages: 3
  • Gif-sur-Yvette (91)
Saturation Hibernia -> Akamai ?
« Réponse #5 le: 04 décembre 2018 à 15:29:44 »
Concernant la partie DNS :
En fait, j'utilise le résolveur DNS de Cloudflare pour tester la fonctionnalité DNS over TLS. Le service DNS de mon ISP ne propose pas cette fonctionnalité. La fonctionnalité ECS n'est pas vraiment compatible avec le DoT (on perd l'intérêt du DoT sauf si le résolveur réécrit le champ ECS avec sa propre adresse IP). De plus, les serveurs de Cloudflare étant anycastés, et présent en France (à Paris), c'est tout de même un serveur proche qui est censé répondre, donc la geoDNS doit fonctionner "assez bien".

Concernant la partie routage sur Internet :
Je ne comprends tout de même pas comment, pour moi j'ai une perte importante de paquets entre akamai-20940-gw.par02-1.fr.as5580.net et a92-122-203-206.deploy.static.akamaitechnologies.com, alors que vous n'avez pas ce soucis. Ou alors il s'agirait d'un problème au niveau du chemin retour.

En finalité, je vais simplement changer de résolveur, ce qui contournera le problème.

Symbol

  • AS52075 Wifirst
  • Expert
  • *
  • Messages: 349
Saturation Hibernia -> Akamai ?
« Réponse #6 le: 04 décembre 2018 à 17:30:22 »
De plus, les serveurs de Cloudflare étant anycastés, et présent en France (à Paris), c'est tout de même un serveur proche qui est censé répondre, donc la geoDNS doit fonctionner "assez bien".
Pas du tout, ici il est question du cluster Akamai qui sert le mieux le trafic vers toi, et de la connectivité entre toi et ce cluster.
Le DNS anycasté Cloudflare a beau être proche, tu obtiens une IP d'un cluster Akamai qui a peut-être une bonne connectivité vers le DNS Cloudflare, mais pas vers toi.

Je ne comprends tout de même pas comment, pour moi j'ai une perte importante de paquets entre akamai-20940-gw.par02-1.fr.as5580.net et a92-122-203-206.deploy.static.akamaitechnologies.com, alors que vous n'avez pas ce soucis. Ou alors il s'agirait d'un problème au niveau du chemin retour.
Ce cluster est chez GTT, donc accessible via du transit depuis Orange France: GTT/OTI/OF. Il n'a sûrement pas vocation à servir des clients Orange France.
Clairement il y a des chances que ça rame (comme avec un certain nombre d'intercos entre OTI et ses peers, cf les peering disputes entre Orange et *).

Pour que ça marche au mieux, il faut être servi par un cluster accessible via un lien bien dimensionné, en l'occurrence soit du peering payant soit du cluster directement hébergé ; ce qui a des chances d'être le cas en utilisant les DNS d'Orange.

Du reste entre Free et ce cluster ça passe par leur transit (Cogent), il y aurait peu de chance que ce soit optimal s'il était question de faire vraiment passer du trafic (cf les peering disputes entre Free et *).

En finalité, je vais simplement changer de résolveur, ce qui contournera le problème.
La bonne démarche.


Par ailleurs, Akamai propose des outils pour voir quel DNS récursif les a interrogés (l'IP unicast), et s'il y avait prise en compte d'un éventuel ECS, comme indiqué sur https://developer.akamai.com/blog/2018/05/10/introducing-new-whoami-tool-dns-resolver-information.

Par exemple
dig +short txt whoami.ds.akahelp.net
dig +short txt whoami.ds.akahelp.net @8.8.8.8
dig +short txt whoami.ds.akahelp.net @1.1.1.1
« Modifié: 04 décembre 2018 à 19:12:00 par Symbol »

alarig

  • AS204092 Association Grifon
  • Expert
  • *
  • Messages: 113
    • SwordArMor
Saturation Hibernia -> Akamai ?
« Réponse #7 le: 05 décembre 2018 à 10:20:44 »
Concernant la partie DNS :
De plus, les serveurs de Cloudflare étant anycastés, et présent en France (à Paris), c'est tout de même un serveur proche qui est censé répondre, donc la geoDNS doit fonctionner "assez bien".

Un serveur proche ne veut pas forcèment dire un serveur avec un bonne connectivité.

J’utilise des résolveurs dans AS204092 depuis AS3215, akamaï me répond un serveur qu’Orange atteint en transit (via OTI).

alarig@airmure ~ % dig -t A download.virtualbox.org @drogon.grifon.fr

; <<>> DiG 9.11.2-P1 <<>> -t A download.virtualbox.org @drogon.grifon.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29203
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;download.virtualbox.org.       IN      A

;; ANSWER SECTION:
download.virtualbox.org. 10751  IN      CNAME   download.oracle.com.edgekey.net.
download.oracle.com.edgekey.net. 251 IN CNAME   e14618.d.akamaiedge.net.
e14618.d.akamaiedge.net. 20     IN      A       2.19.60.219

;; Query time: 26 msec
;; SERVER: 2a00:5884::7#53(2a00:5884::7)
;; WHEN: Wed Dec 05 10:15:56 CET 2018
;; MSG SIZE  rcvd: 147

alarig@airmure ~ % mtr -bzwe 2.19.60.219
Start: Wed Dec  5 10:16:07 2018
HOST: airmure                                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.44.1                                                                  0.0%    10    0.3   0.3   0.3   0.5   0.0
  2. AS???    80.10.236.165                                                                0.0%    10    1.6   1.4   0.8   2.2   0.0
  3. AS???    lag-107.ncren201.Rennes.francetelecom.net (193.253.150.142)                 70.0%    10    1.1   1.0   0.7   1.4   0.0
  4. AS???    ae43-0.niidf301.Paris15eArrondissement.francetelecom.net (193.252.159.158)   0.0%    10    5.9   8.4   5.6  17.1   4.3
  5. AS???    ae40-0.niidf302.Paris13eArrondissement.francetelecom.net (193.252.103.38)    0.0%    10    5.8   6.2   5.5   8.8   0.8
  6. AS???    193.252.137.78                                                               0.0%    10    6.6   6.6   5.9   7.1   0.0
  7. AS???    hundredgige0-11-0-2.auvtr4.aubervilliers.opentransit.net (193.251.242.166)   0.0%    10   11.0  10.6   7.3  13.4   2.3
  8. AS5511   et-18-1-3-0.pastr3.paris.opentransit.net (193.251.128.80)                    0.0%    10   10.1   7.9   6.0  12.6   2.2
  9. AS2914   ae-26.r04.parsfr01.fr.bb.gin.ntt.net (129.250.66.141)                        0.0%    10    6.5   6.8   6.4   7.3   0.0
 10. AS2914   ae-3.r03.parsfr02.fr.bb.gin.ntt.net (129.250.5.39)                           0.0%    10   20.4  20.2  19.6  20.8   0.0
       [MPLS: Lbl 24051 Exp 0 S 1 TTL 1]
 11. AS2914   ae-8.r02.parsfr02.fr.bb.gin.ntt.net (129.250.4.133)                          0.0%    10   23.3  24.1  22.5  33.9   3.4
       [MPLS: Lbl 24051 Exp 0 S 1 TTL 1]
 12. AS2914   ae-7.r25.londen12.uk.bb.gin.ntt.net (129.250.4.24)                           0.0%    10   14.0  15.8  13.7  25.9   3.6
       [MPLS: Lbl 570432 Exp 0 S 1 TTL 1]
 13. AS2914   ae-1.r24.londen12.uk.bb.gin.ntt.net (129.250.2.26)                           0.0%    10   13.8  14.7  13.2  21.6   2.4
       [MPLS: Lbl 476769 Exp 0 S 0 TTL 1]
       [MPLS: Lbl 301872 Exp 0 S 1 TTL 1]
 14. AS2914   ae-6.r24.frnkge08.de.bb.gin.ntt.net (129.250.3.13)                           0.0%    10   24.1  20.9  19.5  24.1   1.2
       [MPLS: Lbl 301872 Exp 0 S 1 TTL 1]
 15. AS2914   ae-1.r04.frnkge08.de.bb.gin.ntt.net (129.250.3.218)                          0.0%    10   20.3  20.0  19.4  21.0   0.3
 16. AS2914   83.231.214.25                                                                0.0%    10   20.2  20.2  19.1  22.7   0.9
 17. AS9002   ae4-5.RT.TC2.LON.UK.retn.net (87.245.234.114)                                0.0%    10   30.0  30.2  29.7  32.3   0.7
 18. AS9002   GW-Akamai.retn.net (87.245.245.25)                                           0.0%    10   30.1  30.0  29.4  30.4   0.0
 19. AS20940  a2-19-60-219.deploy.static.akamaitechnologies.com (2.19.60.219)              0.0%    10   31.1  31.0  30.1  34.7   1.2


Mais la même requête sur le résolveur d’Orange me donne bien un serveur chez Orange (même si ça passe par OTI) :
alarig@airmure ~ % dig -t A download.virtualbox.org @80.10.246.130

; <<>> DiG 9.11.2-P1 <<>> -t A download.virtualbox.org @80.10.246.130
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1568
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
;; QUESTION SECTION:
;download.virtualbox.org.       IN      A

;; ANSWER SECTION:
download.virtualbox.org. 10529  IN      CNAME   download.oracle.com.edgekey.net.
download.oracle.com.edgekey.net. 29 IN  CNAME   e14618.d.akamaiedge.net.
e14618.d.akamaiedge.net. 20     IN      A       23.210.40.186

;; Query time: 8 msec
;; SERVER: 80.10.246.130#53(80.10.246.130)
;; WHEN: Wed Dec 05 10:17:23 CET 2018
;; MSG SIZE  rcvd: 147

alarig@airmure ~ % mtr -bzwe 23.210.40.186
Start: Wed Dec  5 10:17:29 2018
HOST: airmure                                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.44.1                                                                  0.0%    10    0.5   0.4   0.3   0.5   0.0
  2. AS???    80.10.236.165                                                                0.0%    10    1.4   1.7   0.8   4.1   0.8
  3. AS???    lag-107.ncren201.Rennes.francetelecom.net (193.253.150.142)                 70.0%    10    1.2   1.4   1.2   1.8   0.0
  4. AS???    ae43-0.niidf301.Paris15eArrondissement.francetelecom.net (193.252.159.158)   0.0%    10    9.3   7.0   5.6   9.9   1.3
  5. AS???    ae40-0.niidf302.Paris13eArrondissement.francetelecom.net (193.252.103.38)    0.0%    10    6.5   6.6   5.9   8.6   0.7
  6. AS???    193.252.137.78                                                               0.0%    10    6.8   6.4   5.9   6.9   0.0
  7. AS???    81.52.188.194                                                                0.0%    10   65.1  18.3   7.3  65.1  19.5
  8. AS16625  a23-210-40-186.deploy.static.akamaitechnologies.com (23.210.40.186)          0.0%    10    5.8   6.3   5.8   7.5   0.3

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 009
  • FTTH >500 Mb/s (13)
Saturation Hibernia -> Akamai ?
« Réponse #8 le: 05 décembre 2018 à 22:40:20 »
Du coup, si:
  • tu tournes ton propre DNS récursif sur ta beigebox, qui représentera des clopinettes en nombre de requêtes (donc pas de statistiques chez Akamai)
tu seras probablement dirigé vers un cluster dont le routage sera peu pertinent pour te fournir les performances attendues.

Il ne faut pas exagérer non plus.
Akamai ne t'enverra pas chercher un node externe à ton ISP si tu utilises ton propre resolver.


;; ANSWER SECTION:
download.virtualbox.org. 10794   IN   CNAME   download.oracle.com.edgekey.net.
download.oracle.com.edgekey.net. 294 IN   CNAME   e14618.d.akamaiedge.net.
e14618.d.akamaiedge.net. 14   IN   A   23.212.224.188



$ mtr -4wc10 23.212.224.188
Start: 2018-12-05T22:34:00+0100
HOST: Lyoko.in.ByMe.at                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- Styx.WiFi.mrs.in.byme.at                              0.0%    10    2.0   1.7   1.5   2.3   0.2
  2.|-- AstriaPorta.vl100.mrs.in.byme.at                      0.0%    10    1.7   1.9   1.7   2.4   0.3
  3.|-- ???                                                  100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 193.249.213.54                                       70.0%    10    3.3   5.7   3.3  10.2   3.9
  5.|-- 193.252.161.29                                        0.0%    10    3.0   3.5   2.4   6.4   1.3
  6.|-- 193.252.137.54                                        0.0%    10   13.0  12.5  11.9  13.0   0.4
  7.|-- et-17-0-0-0.pastr3.paris.opentransit.net              0.0%    10   19.7  14.4  11.5  21.4   3.5
  8.|-- akamai-84.gw.opentransit.net                          0.0%    10  135.7  30.5  12.8 135.7  37.5
  9.|-- a23-212-224-188.deploy.static.akamaitechnologies.com  0.0%    10   13.1  12.8  11.9  13.9   0.6

Symbol

  • AS52075 Wifirst
  • Expert
  • *
  • Messages: 349
Saturation Hibernia -> Akamai ?
« Réponse #9 le: 05 décembre 2018 à 23:08:27 »
Akamai ne t'enverra pas chercher un node externe à ton ISP si tu utilises ton propre resolver.
Les résultats sont très variables, pour avoir testé plusieurs fois.

petrus

  • Expert AS206155
  • Expert
  • *
  • Messages: 1 064
Saturation Hibernia -> Akamai ?
« Réponse #10 le: 06 décembre 2018 à 10:13:05 »
Je suis de l'avis de Symbol ici. Ca peut être vraiment aléatoire.

Et sinon le soucis qui nous concerne ici (de perfs vers le cdn akamai via oti puis gtt) est trouvé, ça va être corrigé.