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/
