Bonjour, ce n'est qu'une question de s'y mettre, il y a énormément d'outils libres sur lesquels on peut se baser aujourd'hui.
la CLI est un dinosaure qu'il faut laisser s’éteindre mais malheureusement c'est la seule "API" universellement disponible. (bon, peut-être pas vu que beaucoup d'APIs constructeurs ne sont que des wrappers XML de CLI) https://github.com/criteo/netcompare netcompare est une des premières briques que nous publions d'un framework complet d'automatisation développé chez nous qui nous permet de gérer nos DC et WAN programmatiquement, nous allons bientôt publier d'autres modules pour équipements a commit non-atomiques qui s'intègrent dans Ansible et qui pourront étendre Napalm. le SDN est un acronyme galvaudé qui comme le "cloud" veut tout et rien dire. Pour nous le SDN ce n'est pas programmer un dataplane mais gérer tous les aspects d'un réseau par des algorithmes. 2015-06-25 6:59 GMT+02:00 Romain De Rasse <rom...@de-rasse.fr>: > 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/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
