Initiale releaseHEADmaster

1 files changed, 275 insertions, 0 deletions

diff --git a/Fabriquer_son_internet_5.txt b/Fabriquer_son_internet_5.txt
new file mode 100644
index 0000000..fd43734
--- /dev/null
+++ b/Fabriquer_son_internet_5.txt
@@ -0,0 +1,275 @@
+Titre: Fabriquer son internet (5)
+Auteur: Bruno
+Date: Fri 12 Apr 2013 11:29:19 +0200
+Lien: https://blog.spyou.org/wordpress-mu/2013/04/12/fabriquer-son-internet-5/
+
+[image 1]
+
+LG Tetaneutral
+
+Dans les articles précédents[2], nous avons vu comment s’approprier petit à 
+petit (presque) tous les maillons de la chaîne entre tatie Martine et Internet.
+
+Je suis, volontairement, passé un peu vite[3] sur la question de la bordure 
+entre le réseau et Internet. Reprenons donc, vous êtes l’opérateur A et vous 
+disposez de deux machines situées à proximité immédiate d’autres réseaux (par «
+proximité immédiate » j’entend « dans le même bâtiment », mais vous pouvez 
+aussi tirer des fibres longue distance si vous avez une bonne pelle) et vous 
+avez fait le choix de la redondance et de la qualité en souscrivant :
+
+ 1.un contrat de transit avec un opérateur B
+ 2.un contrat de transit avec un opérateur C
+ 3.un port sur un point d’échange 1
+ 4.un port sur un point d’échange 2
+
+Si on résume donc, chacun de vos deux routeurs dispose de 4 connexions :
+
+  * un lien vers l’un des transitaires
+  * un lien vers l’un des points d’échange
+  * un lien vers la collecte ADSL
+  * un lien vers l’autre routeur
+
+C’est bien joli, mais il faut à présent configurer  tout ça. Sur internet, tout
+est affaire de routes. J’en ai déjà parlé pas mal ici[4], ici[5] et ici[6] mais
+essayons de reprendre sous un angle encore différent, un angle un peu 
+opérationnel.
+
+Lorsqu’on est totalement étranger à cette couche d’internet qu’est le BGP, on 
+connait principalement la route par défaut (celle que toute machine se doit de 
+connaître pour parler à internet). Au niveau des interconnexions entre réseau, 
+on peut aussi l’utiliser. Cela revient donc à dire à nos deux routeurs « si 
+vous ne savez pas où envoyer les paquets qui vous arrivent, balancez chez le 
+transitaire, lui, il trouvera ».
+
+C’est pas très « state of the art », mais ça a l’avantage de marcher et de 
+pouvoir faire tourner votre bordure de réseau avec du vieux matériel (genre 
+cisco 3550 a 150 € pièce). On aura donc :
+
+  * le lien vers nos utilisateurs ADSL qui supportera les tunnels L2TP et qui 
+    créera une (ou plusieurs) interface(s) virtuelle(s) par utilisateur ADSL 
+    sur le routeur
+  * le lien vers le transitaire sur lequel il y aura une route par défaut
+  * le lien vers l’autre routeur sur lequel il y aura la route par défaut du 
+    transitaire de l’autre routeur (dès fois que le nôtre soit cassé)
+  * et le lien vers le point de peering
+
+C’est quoi donc un point de peering ? Je la joue rapide, il y a déjà une 
+abondante littérature ici et ailleurs sur le sujet : c’est juste un switch sur 
+lequel se connectent plusieurs opérateurs. Etant tous branchés sur le même 
+switch, ils peuvent s’échanger des paquets entre eux. Les us et coutumes 
+ancestrales imposent généralement qu’on ne se serve pas d’un point d’échange 
+pour se vendre du transit, la résultante étant donc que le trafic qui y passe 
+est généralement local : un paquet qui va de chez moi à chez numéricable passe 
+par un point d’échange, mais s’il s’agit d’aller chez un opérateur australien, 
+sauf si cet opérateur est présent sur le point d’échange, ça passera par le 
+transit.
+
+On a donc, si on se concentre sur la bordure :
+
+  * le lien vers le transit qui supporte UNE connexion BGP avec UN opérateur 
+    sur lequel il y a UNE route par défaut
+  * le lien vers le point d’échange qui supporte X connexions BGP vers X 
+    opérateurs sur lesquelles il y a Y(x) routes
+
+Vous trouverez par exemple, sur le point d’échange FranceIX[7], le réseau de 
+Google qui annonce 327 routes mais aussi celui de Tetaneutral qui n’en annonce 
+qu’une. Un petit réseau noue généralement quelque chose comme une centaine de 
+sessions de peering, un moyen entre 200 et 500 et un gros en a plusieurs 
+milliers.
+
+Intéressons-nous à présent au transit. Nous avons pour l’instant une route par 
+défaut, ce qui signifie que tout le trafic qui n’est pas à destination de nos 
+clients ADSL ou d’un réseau avec lequel nous disposons d’un peering passe par 
+le transit local au routeur. Il en va de même pour le routeur d’à côté. Si 
+notre trafic ADSL est concentré sur un seul des  deux LNS, ça veut donc dire 
+que tout le trafic sortira par un transitaire et rien par l’autre, ce qui est 
+loin d’être optimal, surtout si ces transitaires ont des zones d’achalandage 
+différentes.
+
+Pour pouvoir avoir une meilleure granularité dans la destination du trafic, il 
+va falloir oublier la route par défaut et se manger les 438828 routes 
+d’internet (vous avez vu, ça a encore augmenté depuis mon article d’il y a une 
+semaine (435905). Si le gonflement d’internet vous passionne, vous trouverez 
+plein de chiffres et de jolis graphs ici[8].
+
+Si les routeurs qu’on utilise sont capables de manger cette quantité de routes,
+on dispose alors de deux vues fidèles de l’ensemble d’internet, dans le détail.
+Je vais prendre un exemple concret sur un réseau que j’ai sous la main, 
+AS29608, avec une route appartenant à Twitter (AS13414). En utilisant un outil 
+relativement connu, traceroute, on obtient le trajet que vont faire les paquets
+entre AS29608 et AS13414 :
+
+  traceroute to twitter.com (199.59.150.7), 64 hops max, 40 byte packets
+  1 fe-0-1.core1.th2.absolight.net (79.143.241.157) 0.618 ms 1.788 ms 2.075 ms
+  2 ge-1-1.br1.th2.absolight.net (79.143.241.25) 0.971 ms 0.424 ms 0.403 ms
+  3 ge-2-10.br2.th2.par.w2my.net (79.143.241.30) 0.657 ms 0.368 ms 0.393 ms
+  4 ge-6-24-162.car1.Paris1.Level3.net (212.73.204.197) 3.589 ms 12.254 ms 
+  108.039 ms
+  5 ae-51-51.csw1.Paris1.Level3.net (4.69.139.215) 8.317 ms 8.000 ms 12.299 ms
+  6 ae-56-111.ebr1.Paris1.Level3.net (4.69.161.37) 7.823 ms
+  ae-58-113.ebr1.Paris1.Level3.net (4.69.161.45) 7.691 ms
+  ae-57-112.ebr1.Paris1.Level3.net (4.69.161.41) 7.795 ms
+  7 ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 8.779 ms
+  ae-46-46.ebr1.London1.Level3.net (4.69.143.105) 8.515 ms
+  ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 8.011 ms
+  8 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 8.576 ms 8.411 ms
+  ae-59-114.csw1.London1.Level3.net (4.69.153.126) 7.734 ms
+  9 ae-1-51.edge4.London1.Level3.net (4.69.139.74) 8.003 ms 8.121 ms 7.923 ms
+  10 TWITTER-INC.edge4.London1.Level3.net (212.113.14.238) 8.134 ms 8.378 ms 
+  8.224 ms
+  11 xe-1-2-1.iad-cr2.twttr.com (199.16.159.125) 80.171 ms
+  xe-0-2-1.iad1-cr1.twttr.com (199.16.159.123) 80.487 ms
+  xe-1-2-1.iad-cr2.twttr.com (199.16.159.125) 80.191 ms
+  12 ae60.pao1-cr2.twttr.com (199.16.159.87) 148.771 ms 149.139 ms 148.553 ms
+  13 ae51.smf1-er1.twttr.com (199.16.159.29) 153.855 ms
+  ae52.smf1-er1.twttr.com (199.16.159.49) 153.518 ms
+  ae51.smf1-er1.twttr.com (199.16.159.29) 158.001 ms
+  14 r-199-59-150-7.twttr.com (199.59.150.7) 153.049 ms 153.089 ms 152.980 ms
+
+On y apprend, en vrac :
+
+  * que notre trafic sort par notre fournisseur de transit Level3 (AS3356)
+  * que celui-ci dispose d’un réseau ou les paquets n’empruntent pas 
+    systématiquement le même chemin (voyez, sur les points 6 7 et 8, plusieurs 
+    routeurs différents nous répondent)
+  * qu’il dispose d’une interconnexion avec le réseau Twitter à Londres
+  * que Twitter nomme les noeuds de son réseau en fonction des codes IATA[9] 
+    des aéroports voisins
+  * que Twitter dispose manifestement d’un lien en propre entre Londres et 
+    Dulles en Virginie
+  * que Twitter dispose aussi d’un réseau où les paquets se promènent n’importe
+    où (voir les points 11 et 13)
+  * qu’après un petit tour par Palo-Alto (pao), le trajet se termine du coté de
+    Sacramento (smf), ce qui est corroboré par la presse[10]
+
+Mais ceci ne nous renseigne que sur le chemin possible à l’instant T et dans un
+seul sens. BGP va plus loin et nous permet de connaître d’éventuels chemins 
+alternatifs existants et pouvant prendre la relève au pied levé. Pour les 
+connaître, on va utiliser les looking glass des opérateurs. Par exemple, celui 
+de notre réseau cobail[11], et lui donner à manger l’adresse IP déjà utilisée 
+avec un routeur situé à Paris[12] :
+
+  BGP routing table entry for 199.59.148.0/22, version 69664663
+  Paths: (3 available, best #1, table Default-IP-Routing-Table)
+  Multipath: eBGP
+    Advertised to update-groups:
+       9          11        3356[13] 13414, (aggregated by 13414 199.16.159.247), (received & used)    79.143.241.12 (metric 100) from 79.143.241.12[14] (79.143.241.12)      Origin IGP, metric 11, localpref 130, valid, confed-internal, best      Community: 3356:2[13] (Europe) 3356:22 3356:100 3356:123[13] (Customer route) 3356:500[13] (UK) 3356:2064[13] (LON - London) 29608:306005511[15]5511[15]5511[15]5511[15] 2914 13414, (aggregated by 13414 199.16.159.247)
+      193.251.251.33 from 193.251.251.33[16] (193.251.245.123)
+        Origin IGP, metric 11, localpref 129, valid, external
+        Community: 5511:666 5511:710 5511:5511 29608:30400
+    5511[15] 2914 13414, (aggregated by 13414 199.16.159.247), (received-only)
+      193.251.251.33 from 193.251.251.33[16] (193.251.245.123)
+        Origin IGP, metric 0, localpref 50, valid, external
+        Community: 5511:666 5511:710 5511:5511
+
+L’expression est un peu moins évidente à lire, mais ça se fait :
+
+  * Cette IP est contenue dans une route qui a un masque de /22
+  * Le routeur à qui nous avons demandé connaît à priori 3 chemins différents 
+    pour joindre cette route (en vérité il n’en a que deux)
+  * La première est celle qui est active actuellement
+  * On y retrouve l’information du traceroute ci-dessus, à savoir que pour 
+    joindre Twitter (AS13414) on passe par Level3 (AS3356)
+  * Suivent un tas d’informations internes au routeur sur l’origine de la 
+    route, les préférences qui lui sont appliquées
+  * Puis une ligne fort intéressante détaillant les communautés de la route ou 
+    l’on apprend, de Level3, que la route a pour origine une connexion en 
+    Europe, de l’un de ses client (Twitter), plus précisément au Royaume Uni, 
+    et encore plus précisément à Londres, ce qui confirme encore une fois 
+    l’info trouvée dans le traceroute (notez que ces informations ne sont pas 
+    toujours écrites au format humain, bien souvent, on n’a que des chiffres)
+  * Suivent les mêmes informations pour deux autres routes, passant par AS5511 
+    (OpenTransit, le réseau longue distance d’Orange) puis par un autre 
+    opérateur (AS2914, NTT) avant d’arriver chez Twitter
+  * Les deux routes en question ne sont en fait qu’une seule et même route, la 
+    seconde étant celle qui a été reçue par le transit (indiquée 
+    received-only), la première étant celle réellement prise en compte par le 
+    routeur après le passage dans nos filtres locaux (qui ont manipulé le 
+    metric, la local pref et le listing de communautés).
+
+On sait donc maintenant qu’en cas de panne de Level3, notre connectivité vers 
+twitter est à minima assurée par OpenTransit via NTT. Mais en posant la même 
+question à un autre routeur[17] de l’infrastructure, on apprend 
+également l’existence d’une route via AS6453 (TataCommunications) qui elle-même
+repasse par AS2914.
+
+Essayons à présent d’obtenir des informations sur la route de retour. Manque de
+pot, j’aurais dû mieux choisir mon exemple, il semble que Twitter ne propose 
+pas d’outils looking glass publics. On va donc devoir se contenter des 
+informations collectée par des tiers. En vrac, on trouve :
+
+  * Les informations qu’ils ont bien voulu publier sur leurs points de présence
+    dans la base peeringdb[18]
+  * L’analyse de leur connectivité effectuée par Robtex[19] où on voit 
+    clairement que Twitter compte beaucoup sur Level3 pour sa connectivité et 
+    où on retrouve AS2914 qui sert d’intermédiaire à OpenTransit et 
+    TataCommunications.
+
+La compilation de toutes ces informations laisse à penser que le trafic 
+remontant de Twitter vers nous doit également passer par Level3, puisqu’il 
+semble que ce soit le fournisseur le plus utilisé par Twitter. On a également 
+appris, via peeringdb, que Twitter était présent à Londres et à Amsterdam sur 
+les points d’échanges AMS-IX et LINX, et qu’on pouvait donc espérer le joindre 
+directement si on se donnait la peine d’étendre notre réseau jusqu’à l’un de 
+ces deux points d’échange.
+
+Malheureusement, même si certains offrent des possibilités peu onéreuses pour 
+rejoindre ces points, une petite association aura du mal, au début, à se les 
+offrir. Fort heureusement, un tas de petits boulangers du réseau peuvent aider,
+en fournissant par exemple, presque gratuitement, un bout de leur bande 
+passante, l’important étant, alors de faire attention à la redondance en se 
+posant la bonne question : mes deux fournisseurs partagent-ils beaucoup 
+d’infrastructures communes ?
+
+Par infrastructure on entend principalement les fournisseurs de transit, les 
+salles d’hébergement et les réseaux de transports. On pourrait par exemple être
+tenté, lorsqu’on est une association, de prendre la combinaison Gitoyen 
+(AS20766) et Gixe (AS31576). On va donc aller voir ce qu’on trouve comme 
+informations. Restons sur les outils fournis par Robtex pour plus de 
+simplicité, même s’il ne sont pas parfaits ni exhaustifs :
+
+  * Gitoyen[20] semble utiliser principalement AS6453 (TataCommunications), 
+    AS29608 (Wan2many) et AS29075 (Ielo)
+  * Gixe[21], lui, utilise manifestement AS8928 (Interoute) et AS29075 (Ielo)
+
+Nos deux fournisseurs partagent donc au moins un fournisseur commun (Ielo) mais
+ont aussi d’autres moyens  de sortie, ce qui semble suffisant pour s’assurer 
+une redondance convenable en cas de problèmes.
+
+Pour ce qui est des salles d’hébergement et des liens physiques, c’est plus 
+difficile à trouver soi-même, dans la mesure où il est impossible de connaitre 
+les propriétaires ou exploitants finaux des fibres utilisées. Il faudra donc 
+poser la question aux fournisseurs sélectionnés avant d’arrêter un choix.
+
+Un dernier petit mot pour vous montrer le très réussi looking glass[22] de 
+l’association Tetaneutral. On y apprend, en un seul dessin, que Tetaneutral 
+dispose d’au moins 4 transits et d’une liaison directe avec l’AMS-IX. C’est 
+l’image qui a servi d’illustration au présent article.
+
+Dans le prochain épisode, on causera de conception du réseau et d’accès out of 
+band[23] pour avoir la main même quand tout est pété.
+
+Liens:
+[1]: http://blog.spyou.org/wordpress-mu/files/2013/03/20130324-tetaneutral-286x300.png (image)
+[2]: http://blog.spyou.org/wordpress-mu/2013/03/20/fabriquer-son-internet/ (lien)
+[3]: http://blog.spyou.org/wordpress-mu/2013/03/19/fabriquer-son-internet-3/ (lien)
+[4]: http://blog.spyou.org/wordpress-mu/?s=%22comment+c%27est+dedans+bgp%22&x=-1231&y=-146 (lien)
+[5]: http://blog.spyou.org/wordpress-mu/2010/04/23/internet-comment-trouver-la-bonne-route-5/ (lien)
+[6]: http://blog.spyou.org/wordpress-mu/2010/08/04/bgp-quand-pourquoi-et-comment/ (lien)
+[7]: https://tools.franceix.net/lg (lien)
+[8]: http://www.cidr-report.org/as2.0/ (lien)
+[9]: http://fr.wikipedia.org/wiki/Liste_des_codes_AITA_des_a%C3%A9roports (lien)
+[10]: http://www.datacenterknowledge.com/archives/2010/12/15/twitter-scouting-sites-in-sacramento/ (lien)
+[11]: http://lg.as29608.net/ (lien)
+[12]: http://lg.as29608.net/?query=bgp&protocol=IPv4&addr=199.59.150.7&router=br1.th2.par (lien)
+[13]: http://www.ripe.net/perl/whois?AS3356 (lien)
+[14]: http://lg.as29608.net/?query=bgp&protocol=IPv4&addr=neighbors+79.143.241.12&router=br1.th2.par (lien)
+[15]: http://www.ripe.net/perl/whois?AS5511 (lien)
+[16]: http://lg.as29608.net/?query=bgp&protocol=IPv4&addr=neighbors+193.251.251.33&router=br1.th2.par (lien)
+[17]: http://lg.as29608.net/?query=bgp&protocol=IPv4&addr=199.59.150.7&router=br2.eqx.par (lien)
+[18]: http://www.peeringdb.com/view.php?asn=13414 (lien)
+[19]: http://as.robtex.com/as13414.html (lien)
+[20]: http://as.robtex.com/as20766.html (lien)
+[21]: http://as.robtex.com/as31576.html (lien)
+[22]: http://lg.tetaneutral.net/prefix_bgpmap/gw+h3/ipv4?q=199.59.148.0/22 (lien)
+[23]: http://blog.spyou.org/wordpress-mu/2013/05/06/fabriquer-son-internet-6/ (lien)