C'est bien cela qui me fait peur. Je n'irai pas jusqu'à dire qu'il n'y a jamais de bugs sur du matériel réseau, mais franchement ce que j'ai pu vivre et voir chez mes différents clients est de la rigolade au regard des problèmes que génèrent les OS, BDD, applis mal codées etc
Si c'est pour appliquer le même modèle au monde des réseaux (qui globalement tourne bien) je suis pas sur du réel intérêt ;) -----Message d'origine----- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Michel Moriniaux Envoyé : jeudi 25 juin 2015 11:30 À : Romain De Rasse Cc : Olivier Cochard-Labbé; Thomas Barandon; Jérôme Nicolle; Liste FRnoG Objet : Re: [FRnOG] [TECH] SDN chez Google 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/ __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 11840 (20150625) __________ Le message a t v rifi par ESET NOD32 Antivirus. http://www.eset.com --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
