Auteur Sujet: SDN (software-defined networking)  (Lu 37198 fois)

0 Membres et 1 Invité sur ce sujet

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
SDN (software-defined networking)
« le: 28 octobre 2015 à 11:46:44 »
-snip-, perso j'ai du mal avec le SDN, ça ne me plait pas du tout).

Je suis en train de changer d'avis sur le sujet en travaillant sur le SDN de Cisco: j'ai 2 DC (enfin ceux de mon client) en N9K, l'un en ACI, l'un en NX-OS. Le 1er a été (et est toujours) une galère à configurer, le 2ème c'est du connu, fastoche. Par contre, au quotidien, le SDN gagne haut la main sur ses capacités... pour peu qu'on sache attaquer l'API en Python.

Si y'a de la demande, je peux en faire un topic dédié.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
SDN (software-defined networking)
« Réponse #1 le: 28 octobre 2015 à 11:51:57 »
Je suis en train de changer d'avis sur le sujet en travaillant sur le SDN de Cisco: j'ai 2 DC (enfin ceux de mon client) en N9K, l'un en ACI, l'un en NX-OS. Le 1er a été (et est toujours) une galère à configurer, le 2ème c'est du connu, fastoche. Par contre, au quotidien, le SDN gagne haut la main sur ses capacités... pour peu qu'on sache attaquer l'API en Python.

Si y'a de la demande, je peux en faire un topic dédié.

Oui ça m'intéresse, jusqu'ici je n'ai eu que des présentations d'équipementiers, forcèment orientées avantages et oubliant les risques et contraintes techniques.

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • Delta S 10G-EPON sur Les Ulis (91)
SDN (software-defined networking)
« Réponse #2 le: 28 octobre 2015 à 11:57:58 »
Si y'a de la demande, je peux en faire un topic dédié.

Je serais intéressé, je n'ai toujours pas bien compris ce qu'était le SDN, par rapport aux commutateurs traditionnels (on pourrait penser que si c'est software, il n'y a plus de matériel, ce qui n'est pas le cas...).

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
SDN (software-defined networking)
« Réponse #3 le: 28 octobre 2015 à 18:32:23 »
Je serais intéressé, je n'ai toujours pas bien compris ce qu'était le SDN, par rapport aux commutateurs traditionnels (on pourrait penser que si c'est software, il n'y a plus de matériel, ce qui n'est pas le cas...).
En résumé (mais alors très résumé), la partie intelligence et configuration de tes routeurs/switches n'est plus exécutée en local, mais déportée vers des serveurs centraux. Tes switches/routeurs deviennent de simples esclaves quasiment sans intelligence, sans "pouvoir décisionnel". Pour les avantages/inconvénients, je n'y connais rien, et je suis preneur aussi d'un retour d'utilisateurs réels.

Leon.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
SDN (software-defined networking)
« Réponse #4 le: 28 octobre 2015 à 19:20:39 »
En résumé (mais alors très résumé), la partie intelligence et configuration de tes routeurs/switches n'est plus exécutée en local, mais déportée vers des serveurs centraux. Tes switches/routeurs deviennent de simples esclaves quasiment sans intelligence, sans "pouvoir décisionnel". Pour les avantages/inconvénients, je n'y connais rien, et je suis preneur aussi d'un retour d'utilisateurs réels.

Leon.

Pour ceux qui font du système, c'est un peu adapter Puppet/Chef/Capistrano au monde réseau, on déploie les modifications de manière centralisée et le soft gère de pousser les confs de chacun des équipements (mais de manière plus intelligente que juste pousser des confs modifiées en centralisé).

C'est super pratique quand on a beaucoup d'équipements pour déployer très rapidement un service, dans un monde de plus en plus cloud ça devient même parfois indispensable.

Le principal défaut c'est qu'on peut tout aussi vite faire une connerie et qu'un potentiel bug pourrait impacter l'ensemble des équipements également. La solution étant donc d'avoir 2 univers SDN distincts sans interaction, avec les coûts qui peuvent aller avec.

De mon côté la quantité d'équipements ne justifie pas encore d'y passer même si le gain de temps serait non négligeable.


C'est toujours la question de la centralisation VS séparation qui revient sur le tapis au gré des modes. J'ai trop vu de stacks de switchs partir en vrille avec un élèment défaillant dans le pile, ça m'a un peu rendu fermé sur le fait de centraliser le contrôle en réseau. Comme dit au dessus, centraliser ok, mais toujours avec 2 ensembles séparés pour parer au pire des cas.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
SDN (software-defined networking)
« Réponse #5 le: 28 octobre 2015 à 19:31:06 »
2 univers SDN ? un pour gérer la moitié des switch et le second pour l'autre moitié ?

Si tes serveurs sont connecté sur un seul switch, cela n'apporte rien ou je n'ai pas compris ?

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 689
SDN (software-defined networking)
« Réponse #6 le: 28 octobre 2015 à 19:43:23 »
Il faut partir du principe qu'on fait de la redondance pour que ça ait un sens c'est sûr. Avoir les serveurs sur 2 switchs ou 2 serveurs redondants sur 2 univers différents.

Chez nous tout est redondé de A à Z, c'est un principe de base.

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
SDN (software-defined networking)
« Réponse #7 le: 28 octobre 2015 à 20:52:54 »
En résumé (mais alors très résumé), la partie intelligence et configuration de tes routeurs/switches n'est plus exécutée en local, mais déportée vers des serveurs centraux. Tes switches/routeurs deviennent de simples esclaves quasiment sans intelligence, sans "pouvoir décisionnel". Pour les avantages/inconvénients, je n'y connais rien, et je suis preneur aussi d'un retour d'utilisateurs réels.

Leon.

Pas tout à fait ou plutot ça dépend des visions.

Chez Cisco, en mode ACI (gamme Nexus 9000 uniquement):
 - Si la configuration est centralisée, l'intelligence reste sur tes équipements, voir meme descend jusqu'aux "extrémités", c'est-à-dire qu'il n'y a plus d'équipements avec un role central pour les fonctions de routage par exemple.
 - La configuration est gérée par des contrôleurs (APIC en terminologie Cisco), au nombre de 3. Les contrôleurs ne sont pas nécessaire au fonctionnement de la Fabric, ils ne servent qu'à la piloter. 1 seul contrôleur suffit à configurer la Fabric mais le TAC exige 3 contrôleurs.
 - S'il y a 3 contrôleurs, c'est qu'il est strictement impossible de configurer un équipement en local, les commandes config sont inaccessibles, il n'y a pas de running-config visible comme sous IOS/NX-OS. On peut néanmoins se connecter en SSH pour faire des "sh int" ou "sh vpc"
 - On peut se connecter indépendemment sur l'un des 3, il n'y a aucune différence.
 - Les APIC gèrent la configuration mais aussi l'état du réseau : chemins, adresses MAC,... Les APIC voient tout ce qui permet de n'avoir qu'un point d'observation
 - Les APIC effectuent beaucoup de contrôles avant de pousser une configuration, ce n'est pas juste mettre un Vlan sur interface, il y a (des tonnes) d'autres choses à faire avant
 - On se connecte aux APIC via une interface Web mais on peut les adresser via une API en Python et c'est là où ça déménage : on peut faire des controles en masse (sur la config notamment, vu la complexité des paramètres) et pousser des configurations sur des centaines/milliers d'interfaces. Du fait que les APIC font des controles de config, si un Vlan n'est pas prévu sur un profil d'interface, ça sera bloqué.
 - ACI étant récent, il y a pas mal de contraintes et/ou de features non disponibles comme par exemple sur le transit BGP, l'impossibilité d'utiliser des tags de Vlans entre EndPointGroup, le dual-homing des FEX Cisco, etc.

Bon là, comme ça, c'est un très rapide résumé, je ferai un topic dédié pour mieux expliquer. Croyez-moi, en 15 ans de métier où j'ai automatisé beaucoup de taches sur du Cisco, et bien là, il y a vraiment de quoi faire. Le changement entre ACI et avant c'est le travail amont : la 1ère étape de mise en place de la Fabric avec tous les profils nécessaires prend de temps mais ce temps on le gagne après, sur le nombre de changements.

FdB

  • Abonné Free adsl
  • *
  • Messages: 100
  • Mulhouse, 68
    • Perdus ?
SDN (software-defined networking)
« Réponse #8 le: 29 octobre 2015 à 10:36:46 »
Merci pour le résumé  :)

Citation de: BadMax link=topic=18883.msg270963#msg270963
- On se connecte aux APIC via une interface Web mais on peut les adresser via une API en Python et c'est là où ça déménage : on peut faire des controles en masse (sur la config notamment, vu la complexité des paramètres) et pousser des configurations sur des centaines/milliers d'interfaces
Quand je lis interface Web et/ou API Python, je me dis nouveaux vecteurs d'attaque et donc mise à jour de sécurité plus nombreuses, donc plus de fenêtre de maintenance et de risques de planter une partie de l'infra... A voir

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
SDN (software-defined networking)
« Réponse #9 le: 29 octobre 2015 à 11:37:10 »
C'est pour cela que tu utilises un réseau "Out-Of-Band" dédié et physiquement séparé :)
Ca reste quand meme du HTTPS avec une auth, API Python ou pas.

Les Nexus "classiques" imposent déjà cela avec leur port Mgmt dédié qu'on utilise pour le keepalive du VPC mais c'est pareil pour les ASR et la plupart des matériels récents chez les autres constructeurs.


miky01

  • Expert. Réseau RESO-LIAin (01)
  • Abonné K-Net
  • *
  • Messages: 3 829
  • Farges (01)
SDN (software-defined networking)
« Réponse #10 le: 29 octobre 2015 à 13:12:24 »
Je suis en train de changer d'avis sur le sujet en travaillant sur le SDN de Cisco: j'ai 2 DC (enfin ceux de mon client) en N9K, l'un en ACI, l'un en NX-OS. Le 1er a été (et est toujours) une galère à configurer, le 2ème c'est du connu, fastoche. Par contre, au quotidien, le SDN gagne haut la main sur ses capacités... pour peu qu'on sache attaquer l'API en Python.

Si y'a de la demande, je peux en faire un topic dédié.

Ca serait pas mal de faire un topic sur le sujet, meme si  peux de personnes sont concernées.

Pour ma part je n'ai pas conseiller/ implementé le SDN dans les DC, car si ca facilite beaucoup les configs, il y a pas mal de risques, un couillon qui fait une mauvaise config sur le controleur et tu mets a genoux des 100 ene de switch.

mattmatt73

  • Expert.
  • Abonné Bbox fibre
  • *
  • Messages: 7 340
  • vancia (69)
SDN (software-defined networking)
« Réponse #11 le: 29 octobre 2015 à 21:59:23 »
Ca serait pas mal de faire un topic sur le sujet, meme si  peux de personnes sont concernées.

Pour ma part je n'ai pas conseiller/ implementé le SDN dans les DC, car si ca facilite beaucoup les configs, il y a pas mal de risques, un couillon qui fait une mauvaise config sur le controleur et tu mets a genoux des 100 ene de switch.

Par ce que si un couillon plante le contrôleur hard cisco, tu crois que ça va bien se passer ?