l'ONF qui définie Openflow et le SDN, c'est un peu comme demander à Cisco si OSPF est mieux qu'EIGRP ...
Le 28 mars 2013 22:56, Adrien Pestel <[email protected]> a écrit : > "OpenFlow is the first standard interface designed specifically for SDN" > > > > Le 28 mars 2013 22:53, Kavé Salamatian <[email protected]> a > écrit : > > Et vous un standard et une proposition de norme … :-) >> Le 28 mars 2013 à 22:46, Adrien Pestel <[email protected]> a écrit : >> >> > Et toi tu confonds un concept et un standard... >> > >> > Bonne lecture : >> > >> https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf >> > >> > Adrien >> > >> > >> > Le 28 mars 2013 11:58, Gunther Ozerito <[email protected]> a écrit : >> > >> >> Toujours pas ... >> >> >> >> Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol >> >> quand même, suffit juste de lire les docs pour pas les confondre. >> >> >> >> *SDN* : possibilité donné dans un réseau de modifier les comportements >> de >> >> routing et de forwarding sur des critères normalement pas pris en >> compte >> >> par les protocoles standard. >> >> Ex : par defaut, on route sur la destination, BGP me donne des >> >> informations de reach de destination, qu'il compile pour alimenter la >> RIB, >> >> laquelle elle même impacte la FIB pour savoir par quelle interface vont >> >> sortir les paquets. Je veux faire du routage différencié en fonction >> de la >> >> source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout >> le >> >> reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy >> Based >> >> Routing. >> >> Si en plus je pilote les ACLs de mon PBR avec un script qui par >> exemple va >> >> modifier ces entrées en fonction de la latence mesurée sur les liens = >> SDN. >> >> >> >> *application* : backbone, datacenter, ... >> >> >> >> *Openflow *: protocole en cours de standardisation pour échanger des >> >> infos entre un control plane externe, et un dataplane d'équipement >> réseau >> >> standard. Evite d'avoir à scripter pour passer des commandes en SSH >> sur les >> >> routeurs, et permet aussi de faire des trucs que les commandes CLI ne >> >> permettent pas (au hasard, injecter des infos directement dans la RIB >> ou la >> >> FIB, sans avoir de protocole dynamique). >> >> >> >> *application* : backbone, datacenter, ... >> >> >> >> SDN - openflow interop lab <http://incntre.iu.edu/SDNlab> : lancé en >> 2011 >> >> pour voir comment accoster les deux technos entre elles. >> >> >> >> Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou >> >> totalement compatible Openflow, mais aussi avec des fonctionnalités >> >> propriétaires ou d'autres protocoles (netconf). >> >> VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à >> >> encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou >> UDP). >> >> Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement >> >> mettre en concurrence avec VPLS, L2TPv3, OTV, etc... >> >> >> >> Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis >> >> longtemps, et c'est une notion qui existe depuis très longtemps dans le >> >> backbone (Performance Routing chez Cisco, Path Computation Element< >> http://en.wikipedia.org/wiki/Path_computation_element>depuis des années >> à l'IETF). >> >> >> >> Juste pour bien comprendre, sans SDN, vous me direz comment vous >> injectez >> >> du trafic purement voix dans un MPLS TE entre deux sites distants, en >> >> assurant que le trafic non classifié voix au niveau DSCP ne passe pas >> dans >> >> le tunnel... Et non, ce n'est pas du tout compatible avec la >> "neutralité du >> >> net", mais on s'en fout car on est dans la vraie vie, pas à Standford, >> et y >> >> a des contraintes réelles qui font qu'on doit bosser. >> >> >> >> Aller encore deux bullshits marketing pour bien se mélanger les >> pinceaux : >> >> trill et lisp. SDN ou pas ? >> >> >> >> >> >> Le 28 mars 2013 09:55, Adrien Pestel <[email protected]> a écrit : >> >> >> >> Je reprend pour être plus clair (il faut être vigilant quand on poste >> sur >> >>> FrNog les experts ont vite fait de nous rabaisser :)) >> >>> >> >>> Problématique : >> >>> - Dans un environnement virtualisé (machine virtuelle) les >> >>> caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir >> dynamiquement >> >>> se déplacer dans le Datacanter (au grès de l'hyperviseur) >> >>> >> >>> Concept : >> >>> - Rendre les équipements réseaux (virtual switch, switch physique, >> >>> routeurs) plus "bêtes" (commutation, application de règles en >> remontant les >> >>> flows) piloté par un composant applicatif plus intelligent / >> centralisé >> >>> >> >>> Implementation : >> >>> - Nicira >> >>> - Chaîne Openflow / Openvswitch / NOX | Beacon >> >>> - ... >> >>> >> >>> Si tu prends les éléments de manière individuelle ou atomique cela ne >> >>> constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. >> >>> >> >>> Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais >> >>> derrière cela adresse des contraintes de sécurité, de QoS et surtout, >> >>> surtout d'exploitation. >> >>> >> >>> On peut toujours tout faire maison mais : >> >>> 1) ce sera peut être plus coûteux >> >>> 2) ce sera peut être plus difficile à maintenir et moins industrialisé >> >>> >> >>> Cela revient au débat, moi j'utilise un routeur Quagga parce que je me >> >>> sens capable d'aller modifier le code du daemon BGP alors que je ne >> fais >> >>> pas confiance au support et dans les produits des équipementiers >> (Juniper, >> >>> Cisco...). >> >>> >> >>> Une question me vient à l'esprit, comment adresses tu ces >> problématiques >> >>> (récentes ?) depuis plus de 10 ans ? >> >>> Sachant que pour mener à bien ce genre de mission il faut aller taper >> >>> dans le code du Virtual switch de l'hyperviseur (les switchs virtuels >> >>> distribués n'ont pas 10 ans d'existences) ... >> >>> >> >>> Le sujet n'est pas simple quand tu es à l'interieur d'un DC >> maintenant si >> >>> tu l'étend à plusieurs... >> >>> >> >>> -- >> >>> Adrien >> >>> >> >>> >> >>> Le 28 mars 2013 00:18, Gunther Ozerito <[email protected]> a écrit : >> >>> >> >>>> Et encore faux. >> >>>> Encapsuler du niveau 2 dans du niveau 3 n'est pas du SDN. Openflow et >> >>>> openstack non plus. Nvgre et vxlan non plus... Nexus 1000v et >> Openvswitch, >> >>>> toujours pas... >> >>>> >> >>>> Cloudstack quantum ? Non mais a la limite on se rapproche un peu si >> on >> >>>> scripte un peu autour de cet outil. >> >>>> >> >>>> Une machine sous Linux qui collecte les resultats de sondes ipsla, de >> >>>> stats netflow, les lsa ospf, les annonces bgp, qui mouline tout ca >> et qui >> >>>> se connecte en ssh sur des routeurs pour changer des ACL pour du >> PBR, ou >> >>>> des metriques de routage, la oui. >> >>>> Si en plus cette meme machine surveille des applications et change >> les >> >>>> politiques de routage en fonction du fonctionnement des ces applis, >> polée >> >>>> en SNMP par exemple, alors la on est tres proche du SDN. >> >>>> >> >>>> Encore une fois, c'est un terme marketing pour faire peur, mais c'est >> >>>> des technos connues depuis des années ! >> >>>> Le 25 mars 2013 21:42, "Adrien Pestel" <[email protected]> a >> écrit : >> >>>> >> >>>> Salut, >> >>>>> >> >>>>> Je ne l'ai pas forcément compris comme ça ou tout du moins ce n'est >> pas >> >>>>> ce >> >>>>> que j'en ai retenu. >> >>>>> Je crois que la finalité c'est de dire aujourd'hui votre sécurité et >> >>>>> plus >> >>>>> largement le control plane est traité localement (dans votre switch >> >>>>> physique, dans votre switch virtuel, vos routeurs...). >> >>>>> >> >>>>> Demain on vous propose de remonter le control plane dans des >> appliances >> >>>>> et >> >>>>> de gérer de manière transverse a à votre/vos DC la QoS et la >> sécurité. >> >>>>> >> >>>>> Ce sont principalement les problématiques liés à la >> virtualisation/cloud >> >>>>> qui ont amené à ce genre de réflexion, car le réseau LAN gérer de >> >>>>> manière >> >>>>> traditionnelle trouve ses limites. >> >>>>> >> >>>>> Nicira (racheté par VMWare) propose une implémentation de ce type de >> >>>>> modèle >> >>>>> (des tunnels GRE de ce que j'en ai compris entres les hyperviseurs). >> >>>>> >> >>>>> Adrien >> >>>>> >> >>>>> >> >>>>> Le 25 mars 2013 19:19, Olivier Cochard-Labbé <[email protected]> a >> >>>>> écrit : >> >>>>> >> >>>>>> Bonjour, >> >>>>>> >> >>>>>> Il y a un truc qui semble être de plus en plus à la mode: le >> >>>>>> software-defined networking (SDN). >> >>>>>> J'ai donc regardé de plus prêt la solution OpenFlow et le concept >> du >> >>>>>> «flow» me fait tiquer. >> >>>>> >> >>>>>> Si j'ai bien compris, dans un SDN on ne route plus un paquet en >> >>>>>> fonction de son IP de destination mais en fonction de plusieurs >> >>>>>> paramètres tel que: IP source, IP dest, TCP source, TCP dest, etc… >> >>>>>> >> >>>>>> Or la définition de la neutralité du réseau «exclut ... toute >> >>>>>> discrimination à l'égard de la source, de la destination ou du >> contenu >> >>>>>> de l'information transmise sur le réseau» (Wikipedia). >> >>>>>> >> >>>>>> J'ai donc comme l'impression qu'un SDN ne peut, par nature, être un >> >>>>>> réseau neutre. >> >>>>>> Est-ce que je me trompe ? >> >>>>>> >> >>>>>> Merci >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> --------------------------- >> >>>>>> 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/ >> >> > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
