Sans rentrer dans la polémique "ouais mais ça fait vingt fois qu'on nous le sort, mais ça marche jamais" et autre "c'est poussé par un constructeur donc caca", moi j'y vois un intérêt : - j'ai dans mon entourage proche des gens du système qui ne jure que par le Vmotion, et qui n'ont pas compris que ça ne servait pas à faire du HA. Du coup, ils me demandent des vlans étendus entre plusieurs sites à chaque fois... bien entendu, on leur a dit d'aller mourir, mais ces immondes systèmeux sont super resistants. - il faut quand même admettre que le GSLB a ses limites (du genre temps de bascule limité par le cache DNS, et autre ttl pas pris en compte) - conserver son @IP (ie, gérer la mobilité au niveau 3) c'est un poil foireux : depuis quand l'@IP est un gage d'identité ??? (C'est philosophique comme question) N'empèche que quand on a pas le choix (cas d'une VM qui se déplace), c'est bien pratique de pouvoir conserver son @IP en mobilité. - or Cisco a déjà implémenté LISP sur ASR1K (super), et Nexus7K : LISP sur un routeur de Datacenter ? Du coup, ça ouvre la possibilité de l'utilisé pour un serveur se déplaçant d'un site à un autre !
Or comme le code du Nexus est en partie commun entre N7K, N5K et surtout N1000v, on peut espérer que LISP sera un jour dispo sur le premier équipement réseau traversé par un flux d'une VM : le switch intégré à l'hyperviseur. Et là du coup, on peut envisager d'avoir une VM se déplaçant d'un site A à un site B sans pour autant utiliser de vlan étendu, en gardant un vrai réseau routé et pas du bricolage de haut niveau (VPLS and Co) pour étendre un vlan mais sans vraiment l'étendre ... Perso j'avais commencé à bosser sur un proto à base de DHCP sur les interfaces physiques, d'un démon de routage et le service porté sur une "loopback", mais l'idée d'avoir une table de routage peuplée de /32 dans tous les coins ... du bricolage je vous dit ! Evidemment, si ça marche pour une VM qui se déplace, ça peut marcher pour un téléphone ou un PC qui se déplace et connecté en wireless (adieu GTP). L'avantage c'est que le client n'est pas conscient de la couche LISP, donc pas de modification à y apporter, donc c'est mieux. A vous de voir si c'est philosophiquement pas bien, mais moi, sur le terrain et avec des VMs, ça me tente bien. Le 14 octobre 2011 15:24, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit : > On Fri, Oct 14, 2011 at 12:37:28PM +0200, > Jérôme Nicolle <jer...@ceriz.fr> wrote > a message of 88 lines which said: > > > > Léger ? Même d'un seul octet, cela abaisse la MTU et cela veut dire > > > tous les problèmes qu'on a actuellement avec les tunnels, généralisés. > > > > Mais non, voyons, avec PMTUd on devrait plus avoir de problème ! > > C'est une blague ? > > > > Le nouveau truc à apprendre. En effet, *toute* solution de séparation > > > de l'identificateur et du localisateur a ce problème. C'est bien joli > > > d'ajouter une indirection, mais comment on la suit, de manière > > > sécurisée ? > > > > Alors là, je veux bien profiter de tes lumières, j'ai pas l'impression > > que ce soit spécifié encore... > > En effet. Et pour cause, c'est *la* difficulté de tout projet de > séparation identificateur/localisateur, le reste étant relativement > simple. > > > Ah il build lig ? > > % make > gcc -Wall -Wno-implicit-function-declaration -c -o lig.o lig.c > lig.c: In function 'main': > lig.c:100:10: warning: variable 'eid_length' set but not used > [-Wunused-but-set-variable] > lig.c:99:10: warning: variable 'eid_addrtype' set but not used > [-Wunused-but-set-variable] > gcc -Wall -Wno-implicit-function-declaration -c -o send_map_request.o > send_map_request.c > gcc -Wall -Wno-implicit-function-declaration -c -o lib.o lib.c > gcc -Wall -Wno-implicit-function-declaration -c -o cksum.o cksum.c > gcc -Wall -Wno-implicit-function-declaration -c -o print.o print.c > gcc -Wall -Wno-implicit-function-declaration -c -o get_my_ip_addr.o > get_my_ip_addr.c > gcc -o lig lig.o send_map_request.o lib.o cksum.o print.o get_my_ip_addr.o > % > > % ./lig -m l3-london-mr-ms.rloc.lisp4.net 153.16.10.254 > Send map-request to l3-london-mr-ms.rloc.lisp4.net for 153.16.10.254 ... > Received map-reply from 173.36.254.163 with rtt 0.23900 secs > > Mapping entry for EID '153.16.10.254': > 153.16.10.0/24, via map-reply, record ttl: 1440, auth, not mobile > Locator State Priority/Weight > 173.36.254.163 up 1/100 > > > Quelqu'un à un binaire à slapper dans un JunOS ? > > Et, pourquoi dans JunOS ? On utilise rarement un Juniper comme console > d'administration :-) > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > -- Cordialement, Guillaume BARROT
