From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- Fabriquer_son_internet_5.txt | 275 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 275 insertions(+) create mode 100644 Fabriquer_son_internet_5.txt (limited to 'Fabriquer_son_internet_5.txt') 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) -- cgit v1.2.1