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 capable 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/
