On Thu, May 20, 2021 at 12:54:28PM +0200, Cécile MORANGE wrote: > Hello la liste ! Je commence à me renseigner sur le SDN et je me suis dit > que ce serait sympa d'écrire un article sur mon blog (blog.ataxya.net) à > propos de ça. Vu que sur internet je trouve beaucoup plus de présentations > commerciales que d'avis réels sur la solution, je me suis dit que j'allais > demander à mon groupe d'expert préféré ce qu'il pense de cette techno. Mes > questions sont donc : - Pourquoi passer au SDN ? - Il y a-t-il un réel > intérêt de passer au SDN ? (Hormis l'aspect commercial) - En avez-vous déjà > mis en place ? Comment ça s'est passé ? Avez-vous remarqué un réel > changement dans la façon de faire vos réseaux ? (et du gain de temps ?) - > Pensez vous que dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à > l'écoute de tous vos retours, ça me permettra de mieux comprendre le SDN et > l'intérêt (s'il y en a un) ! > (Je sens que je vais lancer un long thread plein de débats :D) > Merci d'avance !
Salut, Alors, le SDN étant un terme marketing et à la mode, tout le monde a un peu sa définition pour pouvoir y coller ses produits. Je vais donc commencer par définir pour moi ce que c'est. Et je me limiterais au réseau de "datacenter" parce que je n'ai pas encore vue de différence entre du SD-WAN et un lien VPN. Donc, pour moi, le SDN c'est le fait de pouvoir utiliser une API pour configurer ton réseau. C'est-à-dire que tu peux utiliser un produit existant ou développer un truc maison pour configurer ton parc. Dans le cas de virtualisation de réseau (quand tu utilises des VM), cela va aller jusqu'au branchement des câbles virtuels. Pourquoi passer au SDN et quels sont les avantages ? Déjà, beaucoup de monde en fait déjà en partie à coup d'outils existant ou de scripts maison. Mais je dirais que le plus gros avantage est la reproductibilité et le déploiement automatique. Tu vas pouvoir avoir la même configuration Terraform en DEV et en PROD aux variables prêt (par exemple le plan d'adressage, même si avec des VRF, ça pourrait même être strictement le même), ça permet d'éviter les erreurs de la config qui fonctionne en dev mais pas en prod. Toujours en restant avec l'exemple Terraform, tu vas pouvoir avoir le même projet pour la configuration réseau que pour les VM, ce qui veut dire que tu le jour où tu supprime tes VM, la configuration réseau spécifique est aussi supprimée, ça évite d'avoir des relicats que plus personne ne connaît. Tout cela permet de simplifier la partie "self-service" et évite de passer du temps à copier la configuration sur tous les switchs et routeurs impactés. En avez-vous déjà mis en place ? Oui, mais dans un cas particulier avec VMWare NSX-T, donc qui implique la virtualisation de réseau (en gros, tous les paquets sont encapsulés), ce qui veut dire, pas de configuration du réseau physique. Au niveau gain de temps, oui. Quand une VM doit être déployée, il suffit de mêttre les bon paramètres Terraform et avec quelques modules, on a la VM, le switch virtuel, le routeur et mêmes les règles firewall spécifiques qui sont déployées automatiquement. Gain de temps mais surtout moins d'erreurs de manipulation. Cela n'a bien sûr de l'intérêt que pour les tâches courantes, automatiser la configuration qui sera faite une fois tous les 5 ans est une perte de temps et dans 5 ans, plus personne ne se souvient de comment le script fonctionne. Voilà mon retour sur un cas spécifique d'utilisation. Bonne journée. Xavier --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
