Bonjour, je rebondis sur ce message d’Arnaud pour vous dire que le coeur de la plate-forme LISP-Lab est désormais opérationnel avec tous les elements du système de mapping strictement en logiciel (MS/MRs, racine DDT, PxTR). La version de développement de OpenLISP avec toutes les fonctionnalités nécessaires est ici: https://github.com/lip6-lisp
Le site du projet est d’ailleurs en mirror sur un serveur LISP: http://eid.lisp-lab.org En accord avec le plan de ce projet ANR, la plate-forme sera bientôt ouverte à tous ceux qui voudrons tester LISP avant de le deployer dans leur infra. Merci à ceux qui seraient intéressés de se manifester ! Cdlt, Stefano Le 28 avr. 2014 à 09:57, Arnaud Fenioux <[email protected]> a écrit : > Salut Stéphane, > > Merci pour ton article, il y a en effet un projet d'implémentation > open-source www.openlisp.org > un consortium francais s'est monté avec des acteur publics tels que le > LIP6, ParisTech et RENATER ainsi que des acteurs privés : > lisplab.openlisp.org > Du coté de rezopole on commence tout juste le déploiement et les tests donc > je ne peux pas encore te faire de retour d'expérience, mais ca pourrait > faire l'objet d'une présentation lors d'un prochain FRnOG! > > Arnaud > > > 2014-04-23 9:10 GMT+02:00 Stephane Bortzmeyer <[email protected]>: > >> Bon, qui ici, a déployé LISP et a une expérience à comparer aux >> conseils du RFC ? [Pas moi] >> >> RFC 7215 : LISP Network Element Deployment Considerations >> >> http://www.bortzmeyer.org/7215.html >> >> ---------------------------- >> >> Auteur(s) du RFC: L. Jakab (Cisco >> Systems), A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual >> (Technical University of Catalonia), D. Lewis (Cisco >> Systems) >> >> ---------------------------- >> >> >> Le protocole réseau LISP a été normalisé il y a plus d'un an et >> plusieurs déploiements de taille significative ont déjà eu lieu. La >> norme LISP n'impose pas un modèle unique de déploiement et laisse bien >> des choix à la discrétion de l'administrateur réseaux sur le terrain, >> notamment pour le placement des différents éléments qui composent un >> réseau LISP. Ce nouveau RFC fait le point sur les différents modèles de >> déploiement possibles. Il est donc orienté vers les opérationnels, ceux >> (et celles) qui vont déployer LISP en production. >> >> Petit rappel, LISP vise à résoudre le problème de la croissance de la >> table de routage globale de l'Internet (problème décrit dans le RFC >> 4984), par le moyen d'une séparation entre *identificateurs*, les EID >> ("Endpoint IDentifiers") et les *localisateurs*, les RLOC ("Routing >> LOCators"). LISP est normalisé dans le RFC 6830. À l'heure actuelle, >> les RFC sur LISP ont le statut « expérimental » (y compris ce RFC >> 7215), reflétant le caractère assez disruptif de ce protocole. Il n'y a >> notamment aucune solution aux différents problèmes de sécurité étudiés >> dans la section 15 du RFC 6830. >> >> Un principe essentiel de LISP est la distinction faite entre les >> réseaux de bordure, qui ne travaillent qu'avec des EID, et le cœur de >> l'Internet qui ne travaille qu'avec des RLOC. Mais où placer la >> frontière, frontière d'autant plus importante que c'est là où vont >> devoir se situer les routeurs LISP (les routeurs de bordure et du cœur >> sont, eux, des routeurs IP non modifiés) ? L'idée initiale était que la >> frontière était aux limites des AS « feuille », ceux qui n'ont pas de >> trafic de transit. Mais, en fait, LISP permet plusieurs choix. Un >> « site LISP » peut être un AS feuille mais peut aussi être un simple >> réseau local. >> >> LISP tunnele les paquets d'un site LISP à l'autre, à travers le cœur. >> Le routeur LISP, connecté à la fois à la bordure et au cœur se nomme un >> ITR ("Ingress Tunnel Router") à l'entrée (encapsulation des paquets) et >> un ETR ("Egress Tunnel Router") à la sortie (décapsulation des >> paquets). Quand on veut parler des deux types en même temps, on dit >> juste « un xTR ». >> >> Passons maintenant aux scénarios, section 2.1. Premier scénario >> possible de déploiement, le « "Customer Edge" ». Le routeur LISP est >> dans les locaux du client, contrôlé par lui, et sur la frontière entre >> réseau du client et réseau de l'opérateur. Ce sera a priori le cas le >> plus fréquent chez les LISPiens et c'est la solution recommandée par >> notre RFC. A priori, si on déploie LISP, c'est qu'on a un réseau de >> grande taille, "multi-homé", et qu'on souhaite faire de la gestion de >> trafic (faire entrer le trafic Internet préferentiellement par un des >> opérateurs, par exemple). Dans le scénario "Customer Edge", le client a >> le complet contrôle des xTR et peut déployer les politiques qu'il veut >> sans rien demander à personne. L'information de joignabilité des ETR, >> si importante en LISP, peut être maintenue correctement, tous les >> routeurs LISP étant sous le contrôle de la même organisation. Les >> "Locator Status Bits" mis par l'ITR sont également toujours conformes à >> la réalité. >> >> Autre avantage, le réseau interne, son plan d'adressage, son protocole >> de routage et ses régles de filtrage ne changent pas. >> >> Comme toutes les techniques utilisant des tunnels, LISP est très >> sensible aux problèmes de MTU (RFC 4459), le tunnel consommant quelques >> octets qui vont diminuer la MTU du lien. Si la connexion entre le >> client et son opérateur a une MTU supérieure aux traditionnels 1 500 >> octets d'Ethernet, il n'y a pas de problème. Sinon, ce scénario peut >> entraîner des problèmes de MTU. >> >> Second scénario possible, le « "Provider Edge" ». Cette fois, on met >> les xTR chez l'opérateur, sous son contrôle. Le client n'a pas à mettre >> à jour ses routeurs, ou à les configurer. Et, avec un seul xTR, >> l'opérateur peut servir plusieurs clients LISP. >> >> Par contre, cela fait perdre à LISP une de ses principales qualités, la >> possibilité de contrôler la répartition du trafic entrant ("ingress >> traffic engineering"). En effet, les xTR ne sont plus sous le contrôle >> du client. Et si le client est "multi-homé", c'est encore pire, les xTR >> étant chez des opérateurs concurrents. >> >> Les xTR qui servent un site LISP n'étant plus coordonnés, ils ne vont >> pas forcément avoir de l'information correcte et à jour sur la >> joignabilité, et ne pourront donc pas servir cette information. >> >> Par contre, ce scénario peut limiter les risques d'un problème de MTU, >> les xTR étant directement dans le réseau de l'opérateur, où la MTU >> disponible est souvent plus grande. >> >> Mais on peut commettre des perversions bien pires avec LISP. Par >> exemple, on peut mettre les xTR derrière des routeurs NAT, par exemple >> si on n'a pas assez d'adresses IPv4. Dans ce troisième scénario, l'ITR >> encapsule les paquets qui sont ensuite NATés. Attention, les paquets >> LISP "Map Requests" n'auront alors pas le même en-tête IP que les "Map >> Reply" correspondants, qui seront alors jetés par le routeur NAT. Il >> faudra une configuration explicite (par exemple diriger tous les >> paquets UDP de port source 4342 vers l'ITR) pour éviter cela. >> >> Ce RFC ne s'arrête pas à ces trois scénarios possibles. Il décrit aussi >> comment les fonctions LISP peuvent être réparties dans divers >> équipements. Par exemple, les fonctions d'ITR et d'ETR ne sont pas >> forcément présentes dans le même boîtier. On a le droit de les placer >> dans deux routeurs différents, par exemple pour mettre les ITR très >> près des machines terminales, afin d'encapsuler le plus tôt possible. >> >> Comme toutes les solutions de séparation de l'identificateur et du >> localisateur, LISP dépend énormément des mécanismes de correspondance >> (RFC 6833), permettant de trouver un localisateur (RLOC) lorsqu'on >> connait l'identificateur (EID). Pour résoudre le problème de >> "bootstrap", les serveurs de correspondance doivent être désignés par >> des RLOC uniquement. Le système de correspondance a deux composants, >> les "Map Servers" et les "Map Resolvers". Voyons d'abord les premiers >> (section 3.1). >> >> Les "Map Servers" apprennent la correspondance EID->RLOC de leurs ETR >> (message "Map Register") et publient ensuite cette information, par >> exemple via le protocole ALT (RFC 6836) ou via le protocole DDT. ALT >> s'inspire plutôt de BGP, DDT plutôt du DNS. Les gérants des "Map >> Servers" se nomment les MSP ("Mapping Service Provider"). Ils peuvent >> être opérateurs réseaux ou bien des organisations spécialisées dans le >> service de correspondance, se faisant payer pour publier un préfixe EID >> (section 5.2). A priori, les bonnes pratiques existantes pour la >> gestion de BGP s'appliquent à ALT, et celles pour le DNS à DDT. Mais >> notre RFC ne va pas plus loin : il est encore trop tôt pour graver dans >> le marbre de strictes politiques pour les gérants de "Map Servers". >> >> DDT est arborescent et repose donc sur une racine >> <http://ddt-root.org/>. Cette racine est actuellement gérée par >> plusieurs organisations volontaires. Comme pour la racine du DNS, elle >> est servie par plusieurs serveurs, chacun géré par une organisation >> différente, et désignés par une lettre de l'alphabet grec. Au moins un >> de ces serveurs est "anycasté". La racine doit normalement vérifier que >> les organisations qui enregistrent un EID sont autorisés à le faire, >> via un RIR qui leur a attribué le préfixe en question. >> >> Et les "Map Resolvers" (section 3.2) ? Leur travail (RFC 6833) est de >> recevoir des requêtes "Map Request", typiquement envoyées par un ITR, >> de trouver une correspondance EID->RLOC dans la base de données >> distribuée, et de la renvoyer au demandeur. (Les habitués du DNS >> peuvent se dire qu'un "Map Server" est un « serveur faisant autorité » >> et un "Map Resolver" un « résolveur » ou « serveur récursif ».) Vu >> leurs « clients », les "Map Resolvers" ont tout intérêt à être situés >> près des ITR qu'ils servent. >> >> Les ITR vont devoir être configurés avec les adresses de leurs "Map >> Resolvers". Un préfixe "anycast" (RFC 4786) commun faciliterait cette >> tâche, l'ITR trouvant ainsi automatiquement le résolveur le plus proche >> et donc en général le plus rapide. >> >> Comme toute technologie nouvelle sur le réseau, LISP doit faire face au >> problème de la coexistence avec les anciens systèmes. Aujourd'hui, il y >> a peu de sites LISP. Ceux-ci doivent donc se poser la question de la >> coexistence avec les sites non-LISP. Plusieurs techniques sont >> envisagées pour cela, comme les P-ITR, "Proxy ITR" du RFC 6832. Un site >> LISP qui veut envoyer des paquets à un site non-LISP peut le faire >> simplement en n'utilisant pas l'encapsulation LISP. Par contre, pour en >> recevoir, il *doit* déployer une technique comme le P-ITR. >> >> Et puisqu'on parle de coexistence avec les sites non-LISP, il faut >> aussi envisager le processus de migration provisoire depuis l'état >> actuel vers LISP (section 5 et annexe A). Le RFC est ambitieux, partant >> de l'état initial (peu de sites LISP) en allant vers un état >> intermédiaire où il y aurait une majorité de sites LISP, pour terminer >> par un Internet complètement LISPisé. >> >> Au début, un site LISP n'a pas le choix. Sauf à ne communiquer qu'avec >> les autres sites LISP, il a intérêt à annoncer ses préfixes dans le >> "Map system" LISP mais aussi en BGP, pour que les sites non-LISP >> sachent où le trouver. On notera donc que, dans cette situation, LISP >> ne contribue guère à la réduction de la table de routage globale, >> puisque tous les réseaux doivent toujours être publiés dans BGP. >> Heureusement, au fur et à mesure que le nombre de sites LISP augmente, >> il y aura de moins en moins besoin d'utiliser les techniques de >> "traffic engineering" pour contrôler les flux de données. Comme ces >> techniques (par exemple la désagrégation des préfixes) sont largement >> responsables de la croissance de la table de routage globale, LISP aura >> donc déjà un intérêt concret à ce stade (encore lointain). >> >> On l'a vu, l'inconvénient de cette méthode (annoncer les préfixes en >> BGP) est qu'on ne diminue pas la taille de la DFZ. Pire, si on est un >> nouveau réseau sans infrastructure BGP existante, on augmente cette >> taille. Pour ces réseaux neufs, notre RFC recommande donc plutôt de ne >> pas déployer BGP du tout et d'utiliser les P-ITR. C'est alors le >> titulaire d'un préfixe englobant qui annonce le préfixe et le route >> vers les ETR du client. Ainsi, il n'y a pas de désagrégation des >> préfixes. Par contre, l'opérateur qui fournit ce service doit router >> tout le trafic non-LISP du client, ce qui n'est pas forcément >> raisonnable si c'est un gros client (comparez cela aux tunnels IPv6 que >> fournissent gratuitement des opérateurs comme Hurricane Electric : cela >> n'est réaliste que si le trafic est faible). Le problème disparaitra >> petit à petit si LISP se développe, lorsqu'il n'y aura plus que des >> reliquats non-LISP (on en est très loin). >> >> L'annexe A du RFC décrit un plan de migration concret pour les >> responsables opérationnels, sous forme d'une liste d'étapes, avec des >> points à vérifier à chaque étape : >> * Faire un état des lieux quantitatif du réseau, pour avoir combien de >> paquets par seconde et de bits par seconde il faudra acheminer. >> * Vérifier les capacités LISP des routeurs existants : peuvent-ils être >> utilisés ou bien va t-il falloir en acheter d'autres ? >> * Faire bien attention aux questions de MTU, LISP utilisant des >> tunnels. Si tous les liens externes peuvent accepter une MTU de 1 556 >> octets, parfait. Dans tous les cas, testez que cela passe et qu'il n'y >> a pas un pare-feu trop zélé qui bloque les messages ICMP indispensables >> à la découverte de la MTU du chemin. >> * Vérifiez que vos préfixes IP sont utilisables pour LISP. Si c'est du >> PI, pas de problème. >> * Configurez les routeurs LISP. >> * Testez la joignabilité des ETR (par exemple avec ping) et >> l'enregistrement des préfixes avec lig (RFC 6835). >> * etc (la liste est longue...) >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Stefano Secci Associate Professor Univ. Pierre and Marie Curie LIP6 - Bureau 25-26/318, BC 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 http://www-phare.lip6.fr/~secci/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
