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 <bortzme...@nic.fr>: > 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/
