Bonjour,
> 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.
Merci de cette réponse, Xavier, parce que la dernière fois que j'ai
parlé de MPLS, on ma répondu avec mépris : "Pfff, mpls c'est has-been,
nous on fait du *SD-WAN* maintenant".
Et après m'être renseigné.... ben en fait j'ai pas tellement vu de
différence entre un "SD-WAN" et un tinc :-/ , hormis le fait que c'était
vendu hors de prix par un intégrateur, qu'il y avait parfois un
clickodrome et qu'on y perdait toute notion de GTR ou de QoS.
Dans le cas d'usage hyper-spécifique de Grégoire, oui, OK (faisant moi
même un peu de multicast je conçois la galère).
Pour le SDN, je peux tout à fait concevoir l'intérêt d'avoir une conf
réseau unifiée et applicable à n'importe quelle marque de routeur (il me
semble que j'avais déjà vu un projet qui "traduisait" des conf en yaml
en cisco/arista/junip/microtik/...)
Pour une grande équipe et dans un souci de documentation vis à vis du
turn-over, je peux vois l'intérêt. Aujourd'hui, je pense que
j'utiliserais Ansible pour ça... mais ce n'est que moi.
Julien
Salut,
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/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
