bonjour quand on veut faire bouger des VMs d’un serveur à un autre par exemple qui n’est pas dans le même domaine de Broadcast…VXLAN permet de faire un tunnel de niveau 2 dans un réseau de niveau 3 compatible avec VMWare et donc on peut le faire en software dans l’hyperviseur ou NSX et/ou en hardware dans les switches supportant le VTEP…on peut ainsi monter un DC tout niveau 3 (Fabric IP) entre les TOR et le backbone (ou Leafs et Spine) interoperable entre plusieurs marques tout en préservant la possibilité de bouger les VMs… On peut même l’utiliser pour de l’inter Datacenter et utiliser un backbone classique IPv4 (c’est de l’UDP) (pas besoin de MPLS/VPLS) et faire transiter des VMs d’un site à un autre comme cela…nous avons plusieurs clients qui font cela pour info
C’est donc utile et devenu un « standard » de fait car supporté par VMWare, Alcatel, Arista, A10, Brocade, Cisco, Fortinet, F5, HP, Juniper, Palo Alto (ordre alphabétique) …et j’en passe surement (pardon pour les oubliés)... dans leurs switches de Datacenter, ADC et firewalls récents avec un excellente intéroperabilité En espérant être utile à la discussion > Le 25 juin 2015 à 11:15, Louis <luigi.1...@gmail.com> a écrit : > > VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une couche > supplémentaire pour maintenir l'existence de domaines de broadcast Ethernet > entre serveurs ? > > je dirais que parmi les intérêts, il y a : > - possibilité d'avoir plus de zones de broadcast. On est plus limité à 4096 > - ne plus faire dépendre une zone de broadcast d'un site géographique > > > Le 25 juin 2015 06:59, Romain De Rasse <rom...@de-rasse.fr> a écrit : > >> Bonjour, >> >> Je n'ai pas testé mais il y a l'air d'y avoir des pistes niveau "devops" >> réseau par exemple : >> https://github.com/spotify/napalm/blob/master/README.md qui vient avec un >> plugin ansible. >> >> RDR >> >> Le 25 juin 2015 06:33:31 GMT+10:00, "Olivier Cochard-Labbé" < >> oliv...@cochard.me> a écrit : >> >>> 2015-06-24 21:01 GMT+02:00 Thomas Barandon <t.baran...@gmail.com>: >>> >>> Hi, >>>> >>>> >>>> Bref, le SDN c'est bon. Mangez en. De toute façon il faudra composer avec. >>> >>> >>> >>> Juste un «détail» qui me chiffonne avec les solutions SDN du moment: Ou >>> est passé le principe KISS ? >>> Prenons l'exemple de Juniper Contrail (je prends cet exemple uniquement car >>> la solution fonctionne pas mal et la doc bien foutue): >>> >>> cf le white paper "CONTRAIL ARCHITECTURE", Figure 1 "Contrail system >>> overview": >>> http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf >>> >>> Donc sur ce schéma d'introduction simplifié (car réduire OpenStack à un >>> seul bloc, j'appelle cela de la simplification) je >>> découvre un joli mélange >>> de: >>> - XMPP, pour que routeur fasse des échanges multimédias ou du chat entre >>> eux et le contrôleur ? :-) >>> - BGP, normal c'est du réseau >>> - Netconf, tiens… enfin! >>> - API Rest, car c'est la mode de tout encapsuler dans HTTP… quelle connerie >>> d'avoir prévus 65535 ports pour TCP, alors qu'il en suffisait de trois: 53, >>> 80 et 443. >>> - Une couche d'overlay MPLS over GRE/UDP ou d'overlay VXLAN… >>> - Pourquoi absolument du MPLS over quelques chose et pas le faire >>> nativement ? >>> - VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une couche >>> supplémentaire pour maintenir l'existence de domaines de broadcast Ethernet >>> entre serveurs ? >>> - hyperviseur >>> - Comment garantir le jitter minimum lorsque l'on doit traverser >>> plusieurs hyperviseurs ? (chainage de VMs) >>> >>> Et le pire: C'est que ça fonctionne. >>> Par contre le jour il y aura un problème: Qui est capabl >>> e de >>> maitriser et >>> comprendre l'ensemble des technos mis en œuvre dans une telle solution ? >>> >>> >>> Cela me donne l'impression que la révolution SDN va vraiment trop vite. >>> J'aurai aimé une étape intermédiaire plus simple avant, comme par exemple >>> juste trouver une solution de déploiement automatisée de configuration d'un >>> réseau hétérogène. Netconf, après des années de réflexions et je ne sais >>> plus combien de RFC n'est toujours pas utilisable à grande échelle dans un >>> environnement vraiment multi-constructeurs. >>> Le monde de l'IT n'ont pas perdus leur temps en discussion: Ils disposent >>> désormais de plusieurs solutions éprouvées qui leur permet de gérer leur >>> énormes parc de serveurs (ansible, puppet, chef, salt, etc...). Et pendant >>> ce temps là, nous au réseau: Que dalle! Pourtant un serveur est autrement >>> plus complexe à gérer qu'un simple switch/routeur. >>> Cela nous aurai permis de commencer >>> tranquillement notre migration en mode >>> "devops" au lieu de nous prendre la grosse claque SDN d'un coup. >>> >>> My two cents, >>> >>> Olivier >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >>> >>> > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
