[FRnOG] [TECH] RFC 6820: Address Resolution Problems in Large Data Center Network
http://www.bortzmeyer.org/6820.html Auteur(s) du RFC: T. Narten (IBM), M. Karir (Merit Network), I. Foo (Huawei Technologies) Lorsque des dizaines de milliers, voire des centaines de milliers de machines, sont connectées au même réseau (ce qui peut être le cas dans un grand data center), certains protocoles TCP/IP, pas forcément prévus pour cela, peuvent avoir des problèmes. C'est le cas d'ARP et de NDP, protocoles utilisés pour trouver l'adresse MAC d'une machine voisine. ARP n'avait pas été prévu pour les data centers modernes et ses limites se font parfois sentir. ND pose pas mal de problèmes similaires. D'où ce document qui définit précisement le problème. Il n'y aura par contre pas de solution de si tôt : le groupe de travail armd http://tools.ietf.org/wg/armd, qui devait travailler sur ce sujet, a été dissous immédiatement après avoir produit ce RFC de description du problème. Il ne semblait pas qu'il soit possible de travailler sur des solutions et l'IESG a donc choisi de dissoudre le groupe http://www.ietf.org/mail-archive/web/armd/current/msg00472.html alors qu'il était loin du résultat. Il reste cet intéressant RFC 6820 qui sera lu avec plaisir par tous les passionnés de réseaux informatiques. ARP (RFC 826) et ND (RFC 4861) s'attaquent tous les deux (le premier pour IPv4 et le second pour IPv6) au problème de la résolution d'adresses sur le réseau local. Une machine veut parler à une autre machine dont l'adresse IP indique qu'elle est sur le même réseau local. Pas besoin de routage, donc, on peut lui envoyer directement un paquet mais, pour cela, il faut d'abord trouver son adresse MAC. ARP et ND procèdent de façon très proche : ils diffusent un paquet à tout le monde « qui est 2001:db8:1::af:41 ? » et la machine qui se reconnait répond. Cela veut dire que ce paquet de demande va être transmis à toutes les machines du réseau local, jusqu'aux routeurs qui marquent la limite du « domaine de broadcast » (l'ensemble des machines touchées par la diffusion « L2 », c'est-à-dire utilisant les mécanismes de la couche 2). Des détails comme les VLAN compliquent encore le tableau. Pour notre RFC, un « domaine de broadcast L2 » est l'ensemble des liens, répéteurs et commutateurs traversés pour atteindre tous les nœuds qu'on touche avec une diffusion. (Il existe une légère différence entre ARP et ND, ND utilisant le multicast et pas le broadcast mais, en pratique, cela ne change pas grand'chose : ce point est traité plus loin.) Depuis longtemps, on sait que les grands domaines de diffusion (réseaux « plats », sans routeurs) créent des tas de problèmes. La totalité des machines du réseau doit traiter les paquets de diffusion. Une machine méchante ou détraquée qui envoie des paquets de diffusion en boucle peut sérieusement perturber un réseau. Dans certains cas (« tempêtes de diffusion », provoquées par exemple par une boucle non détectée dans la topologie du réseau), ces paquets diffusés suscitent la création d'autres paquets diffusés et, là, on peut arrêter complètement le réseau. La sagesse des administrateurs réseaux est donc depuis longtemps « ne faites pas de grands domaines de diffusion ; partitionnez en mettant des routeurs au milieu »). Par exemple, si on architecture son data center en mettant un sous-réseau IP par armoire, la charge résultant d'ARP et de ND sera confinée à une seule armoire. Et les éventuelles tempêtes de diffusion resteront dans une armoire. Le problème est que cette configuration est plus rigide : avec les techniques de gestion modernes (buzzwords : cloud, élasticité, agilité, etc), on souhaite pouvoir déplacer une machine très facilement, sans la renuméroter. Les grands réseaux L2 plats permettent cela. Au contraire, les réseaux très partitionnés nécessitent de changer l'adresse IP de la machine selon sa position physique dans le data center, faisant perdre en souplesse de gestion. Même problème lorsqu'on veut ajouter des nouvelles machines : avec un réseau plat, on configure les machines et on les installe là où il y a de la place. Avec un réseau très partitionné, on doit les configurer en fonction de l'endroit où elles vont être installées, ajoutant ainsi une contrainte de gestion. Et la virtualisation, très utilisée dans les data centers actuels, pousse encore plus dans ce sens. Avec la virtualisation, déplacer une machine ne nécessite même plus d'opérations physiques : on copie la VM, c'est tout. Si l'alimentation électrique d'une machine physique menace de défaillir, on copie toutes les VM hébergées dans l'armoire vers d'autres machines physiques, puis on peut arrêter l'armoire tranquillement. Une architecture où chaque armoire est son propre sous-réseau ne permet plus cela : changer d'armoire veut dire changer d'adresse IP, donc sérieusement impacter le service. Autre conséquence de la virtualisation : le nombre de machines augmente. Il est
[FRnOG] [TECH] 10Gbps Open Source Routing
« 10Gbps Open Source Routing » de Bengt Gördén, Olof Hagsand et Robert Olsson. http://www.iis.se/docs/10G-OS-router_2_.pdf Excellent article technique sur les performances d’un PC/Linux comme routeur sur de l’Ethernet 10 Gb/s. Les auteurs ont mesuré le débit qu’ils arrivaient à faire passer par un PC du commerce, dans différents cas (par exemple avec une DFZ complète ou seulement quelques routes). Conclusion : c’est faisable, mais pas avec toutes les cartes et tous les pilotes, il faut passer du temps à faire des réglages et, le coût par paquet étant important, ce débit n’est atteint que pour les paquets de plus de 256 octets. Deux avantages à de tels routeurs : 100 % logiciel libre (je sors du Forum International sur le Cybersécurité où on a parlé des méchants routeurs chinois pendant deux jours) et le prix. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] À propos des attaques DNS
Les attaques HTTP visent en général une application ou bien un serveur HTTP custom (essayez de vous souvenir de la dernière attaque réussie contre Apache). Le dernier dont je me souviens n'est pas si éloigné que ça : http://thread.gmane.org/gmane.comp.apache.announce/58 En demandant à Apache des intervalles de données se chevauchant, celui-ci se mettait à consommer toute la mémoire disponible afin de pouvoir répondre à la requête. Donc si les tests aident à rendre un logiciel plus robuste, il restera toujours des bugs biens cachés quelque part. -- Jimmy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 6820: Address Resolution Problems in Large Data Center Network
Stephane Bortzmeyer, le Wed 30 Jan 2013 09:34:04 +0100, a écrit : La principale différence est qu'ARP utilise le broadcast et ND le multicast. En théorie, cela permet que les requêtes n'aillent pas dans tout le réseau, seulement dans les parties où il y a des machines IPv6. Mais aussi, puisque les 24 bits de poids faibles de l'IPv6 à résoudre sont utilisés comme bits de poids faible de diffusion multicast (ff02::1:ff00:0/104), et donc comme bits de poids faible de diffusion Ethernet (33:33:ff:00:00:00/24, donc), de hasher quelles cartes réseaux vont effectivement remonter le paquet NDP au CPU. Cela protège les feuilles du réseau donc, au moins, ce qui n'a pas lieu en IPv4. C'est déjà ça... En théorie, la diffusion avec MLD permet aussi de limiter la diffusion NDP sur le réseau, mais comme en IPv4, Derniers équipements à souffrir (le RFC ne considère pas le cas des machines terminales), les commutateurs. Pour n'envoyer les paquets que sur le bon port physique (au lieu de le diffuser partout), le commutateur doit garder en mémoire une table des adresses MAC. Si le réseau « couche 2 » est très grand, cette table le sera aussi. cette remarque s'applique, bien sûr. Il n'y a de toutes façons pas de miracle, soit on s'embête à router, soit on s'embête à diffuser... Samuel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 10Gbps Open Source Routing
Hello Pour parler uniquement du hard, de nombreuses nouveautés ont été annoncées à l'IDF San Francisco 2012, dont Scott Lowe avait fait un bon résumé sur son blog http://blog.scottlowe.org/2012/09/12/clds006-exploring-new-xeon-e5-optimizations-for-10-gb-ethernet/ Globalement, l'architecture Intel repose sur deux points : - coté motherboard, on permet aux cartes réseaux de discuter directement avec les CPU, et donc la RAM (PCIe root port et surtout DDIO) - coté carte réseau, on intègre des modules globalement très proche dans l'idée d'un ASIC ou d'un SOC (mais en moins cher). En tous cas c'est la théorie, il faudra voir en pratique L'article parle beaucoup de l'intérêt de telles innovations pour la virtualisation (augmentation des débits VM to VM, virtualisation des cartes réseaux avec SRIOV) mais globalement le raisonnement est aussi valable uniquement pour faire passer du packet sur un soft opensource de routage. Intel bosse beaucoup sur des optimisation d'OpenVSwitch pour utiliser les performances de ces cartes. On parle plus de performances N x 10G que purement 10G sur ce type d'infra. Niveau cout, on est inférieur à 1000$ pour 2 ports 10G base T. Deux types d'intégration possible : Controller, intégré à la motherboard : http://ark.intel.com/products/60021/Intel-Ethernet-Controller-X540-BT2 Carte dédiée en PCIe2.1 : http://ark.intel.com/products/58953/Intel-Ethernet-Converged-Network-Adapter-X540-T1 Le plus intéressant c'est qu'il n'y pour l'instant aucune carte en PCIe3.0, donc les débits devraient encore pouvoir progresser. Le 30 janvier 2013 10:38, Stephane Bortzmeyer bortzme...@nic.fr a écrit : « 10Gbps Open Source Routing » de Bengt Gördén, Olof Hagsand et Robert Olsson. http://www.iis.se/docs/10G-OS-router_2_.pdf Excellent article technique sur les performances d’un PC/Linux comme routeur sur de l’Ethernet 10 Gb/s. Les auteurs ont mesuré le débit qu’ils arrivaient à faire passer par un PC du commerce, dans différents cas (par exemple avec une DFZ complète ou seulement quelques routes). Conclusion : c’est faisable, mais pas avec toutes les cartes et tous les pilotes, il faut passer du temps à faire des réglages et, le coût par paquet étant important, ce débit n’est atteint que pour les paquets de plus de 256 octets. Deux avantages à de tels routeurs : 100 % logiciel libre (je sors du Forum International sur le Cybersécurité où on a parlé des méchants routeurs chinois pendant deux jours) et le prix. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 10Gbps Open Source Routing
On Wed, 2013-01-30 at 10:38 +0100, Stephane Bortzmeyer wrote: « 10Gbps Open Source Routing » de Bengt Gördén, Olof Hagsand et Robert Olsson. http://www.iis.se/docs/10G-OS-router_2_.pdf Excellent article technique sur les performances d’un PC/Linux comme routeur sur de l’Ethernet 10 Gb/s. Les auteurs ont mesuré le débit qu’ils arrivaient à faire passer par un PC du commerce, dans différents cas (par exemple avec une DFZ complète ou seulement quelques routes). Conclusion : c’est faisable, mais pas avec toutes les cartes et tous les pilotes, il faut passer du temps à faire des réglages et, le coût par paquet étant important, ce débit n’est atteint que pour les paquets de plus de 256 octets. Deux avantages à de tels routeurs : 100 % logiciel libre (je sors du Forum International sur le Cybersécurité où on a parlé des méchants routeurs chinois pendant deux jours) et le prix. Bonjour, Les travaux de Luigi Rizzo - Universita di Pisa, Italy - sur netmap sont aussi tres interessants : http://info.iet.unipi.it/~luigi/netmap/ http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf netmap - a novel framework for fast packet I/O netmap has been implemented in FreeBSD and Linux for several 1 and 10 Gbit/s network adapters. In our prototype, a single core running at 900 MHz can send or receive 14.88 Mpps (the peak packet rate on 10 Gbit/s links). This is more than 20 times faster than conventional APIs. http://info.iet.unipi.it/~luigi/papers/20120601-dxr.pdf Towards a Billion Routing Lookups per Second in Software Our transform distills a real-world BGP snapshot with 417,000 IPv4 prefixes and 213 distinct next hops into a structure consuming only 782 Kbytes, less than 2 bytes per prefix. Experiments show that the corresponding lookup algorithm scales linearly with the number of CPU cores: running on a commodity 8-core CPU it yields average throughput of 840 million lookups per second for uniformly random IPv4 keys Sincèrement, Laurent PS: des liens en vrac sur le sujet routage logiciel ici http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/AtelierPPS2012 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Patriot Act - Datacenter
Si vous etes interesses par les questions d'acces des USA aux donnees personnelles des citoyens europeens, patriot act et cloud computing, a lire: EU urged to scrap use of personal data measures for cloud computing amid US surveillance concerns http://www.out-law.com/en/articles/2013/january/eu-urged-to-scrap-use-of-personal-data-measures-for-cloud-computing-amid-us-surveillance-concerns/ Clarinette. 2012/12/3 Renaud RAKOTOMALALA ren...@rakotomalala.com Le 22/11/2012 14:16, JC a écrit : Le tout dans un cadre légal, cf. loi n°91-646, avec contrôle parlementaire à la clé La loi de 91 sur les écoutes a été abrogée en mars de cette année. http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT06077781 C'est cool ça, je rebondis dessus car du coup aux états-unis ça bouge aussi à ce niveau ... http://www.wired.com/threatlevel/2012/11/ecpa-reform-approved/ ils sont pas passé loin du libre service dans le email stockés chez eux ... Ceci dit si ton mail à 6 mois de toute façon ils peuvent fouiller sans aucun ordre judiciaire ... J'espère que la partie non critique du SI du CG de Bretagne ne concerne pas les emails :) Any comment ? --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Internet Privacy Lawyer - LLM Keep the internet safe http://FlyAKite.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] PSN-2013-01-823 Juniper
Bonjour, Quelqu’un d'entre vous a vu ce bultin juniper : PSN-2013-01-823 qui vient de tomber. Ils disent que si la RE est bien protégé en V6 V4 on risque rien. Mais sauf erreur de ma part (et heureusement) ils ne disent pas quel(s) genre de paquet il faut filter exactement. Quelqu’un à de l'info? Ou on est bon pour une tournée de JunOSupdate? SBU --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 10Gbps Open Source Routing
❦ 30 janvier 2013 10:38 CET, Stephane Bortzmeyer bortzme...@nic.fr : Conclusion : c’est faisable, mais pas avec toutes les cartes et tous les pilotes, il faut passer du temps à faire des réglages et, le coût par paquet étant important, ce débit n’est atteint que pour les paquets de plus de 256 octets. L'article semble un peu vieux (2008?). Toutes les cartes 10G sont maintenant capable de faire du multiqueue sans réglages particuliers ce qui est la principale optimisation. Les cartes type bnx2x ou ixgbe ont toutes au moins 16 queues dans les deux sens et peuvent donc faire travailler tous les cores de 2 Xeon récents type X5650, y compris en usant de fonctionnalités telles que Netfilter ou LVS. La seule optimisation à faire est de sticker les queues sur un CPU chacune (et de ne surtout pas laisser irqbalance faire le boulot, à moins de tester avec une version = 1). -- /* Nobody will ever see this message :-) */ panic(Cannot initialize video hardware\n); 2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 6820: Address Resolution Problems in Large Data Center Network
La virtualisation du réseau des utilisateurs sur le cloud permet aussi de résoudre ces problèmes. Chaque domaine de broadcast fourni aux utilisateurs (ou client) est encapsulé sur le réseau physique (grâce à des techno comme NVGRE, STT, VXLAN...) et est capable d'être routé sur ce réseau physique. Ainsi, l'opérateur du cloud peut définir l'architecture de son réseau physique comme il le souhaite (1 sous-réseau par baies de serveurs par exemple, pour ne pas avoir de trop gros domaine de broadcast) sans se soucier des réseaux virtuels des utilisateurs. Cela permet de conserver la flexibilité nécessaire au cloud (plus d'adhérence géographique des VM pour leur configuration IP) et les réseaux des utilisateurs deviennent flexibles et administrables par le Cloud Operating System indépendamment du réseau physique. Et cela permet aussi de fournir un plus grand panel de services réseau aux utilisateurs (création de domaine de broadcast à la volé en leur laissant le choix de l'adressage (IP overlapping), routage entre ces domaines de braodcast, load-balancing...). Édouard. 2013/1/30 Samuel Thibault samuel.thiba...@ens-lyon.org Stephane Bortzmeyer, le Wed 30 Jan 2013 09:34:04 +0100, a écrit : La principale différence est qu'ARP utilise le broadcast et ND le multicast. En théorie, cela permet que les requêtes n'aillent pas dans tout le réseau, seulement dans les parties où il y a des machines IPv6. Mais aussi, puisque les 24 bits de poids faibles de l'IPv6 à résoudre sont utilisés comme bits de poids faible de diffusion multicast (ff02::1:ff00:0/104), et donc comme bits de poids faible de diffusion Ethernet (33:33:ff:00:00:00/24, donc), de hasher quelles cartes réseaux vont effectivement remonter le paquet NDP au CPU. Cela protège les feuilles du réseau donc, au moins, ce qui n'a pas lieu en IPv4. C'est déjà ça... En théorie, la diffusion avec MLD permet aussi de limiter la diffusion NDP sur le réseau, mais comme en IPv4, Derniers équipements à souffrir (le RFC ne considère pas le cas des machines terminales), les commutateurs. Pour n'envoyer les paquets que sur le bon port physique (au lieu de le diffuser partout), le commutateur doit garder en mémoire une table des adresses MAC. Si le réseau « couche 2 » est très grand, cette table le sera aussi. cette remarque s'applique, bien sûr. Il n'y a de toutes façons pas de miracle, soit on s'embête à router, soit on s'embête à diffuser... Samuel --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
