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 <pestoui...@gmail.com> 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 <gozer...@gmail.com> 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" <pestoui...@gmail.com> 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é <oliv...@cochard.me> 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/
