Bonjour, " C'est à ça que j'identifie le SDN, une entité qui a la connaissance globale du réseau et qui peut intervenir instantanément sur les flux en fonction d'évènements, besoins, etc. "
J'avoue la définition est vague et super marketing certainement pour vendre des solutions constructeurs. Si effectivement nous parlons de "Software Defined Networking" nous reprenons donc un terme déjà utilisé depuis longtemps. Bref si une Infra DevOps qui fait plus qu'ouvrir les portes aux IA. Le gain de temps est juste énorme. Pour déployer une technologie cela devient un gain de temps énorme. En terme de consommation d'Energie et donc des ressources utilisées, c'est juste incroyablement bien pensée. Une Infra Ansible Prometheus Grafana donc TSDB couplé a GITLAB, Openstack pour le code et démarrer des VM ou dockers au besoin d'une action. Génial. Tous cela commandé par API via une simple commande http et ce configurant via un fichier yaml ou jinja2 ou en faite un txt... Bref tu finis par modifier toujours les mm types de fichiers sur 10 technologies différentes qui s'intègrent facilement dans des dockers. Voila l'arrivée de l'IA car on viens de lui donner une ossature maintenant il faut le cerveau qui n'a qu'a modifier un fichier txt sur un GITLAB du coup cela devient très simple. Coupler a un systeme de LOG et de monitoring. Déployez 1 000 000 machines en 30 secondes configurées est opérationnels en un clique... Pouvoir revenir en arrière en un rien de temps ou appliquer une modification. En faire un bouton dans un SI rendant la tache IT compliqué accessible a un simple technicien. Qd tu voie le routeur sur ton SI tu clique configurer et hop tous est configurés en 15 secondes, Téléphonies complètes son monitoring, serveur web, serveur RDP etc en faite tous... Déployer un réseau complet operateur MPLS par exemple et revenir en arrière en un clique... Il est maintenant possible de le faire de façon graphique. Donc un directeur technique peut design son réseau de façon graphique et tester la solution sur un banc de test ou en production. Sans être bloquer par un soucis d'oubli de tel ou tel options sur tel routeur ou tel switch ou tel serveur DNS etc etc. Ca donne le pouvoir de mieux définir les architectures réseaux. Tu fait un POP et tu le réplique c'est juste énorme en gain de temps. Avec Centreon il était déjà possible d'automatiser des réponses a un PB sur un host ou un service. Du SDN dans ce cas? J'ai vue du DHCP dans le lot des réponses exemple est ce que l'API de KEA-DHCP a lui seul est un gros module de SDN? :) Si les technologies que je site sont du SDN dans ce cas pour nous cela est vital pour pouvoir allez a la plage le week-end et dormir la nuit... Par contre on fait déjà tous des choses déjà très proches depuis de nombreuses années. Je penses que maitriser son réseau justement rend la sécurité bien meilleur car tu dégage du temps pour la bichoter et tu as des rapports automatiser des changements sur des machines ou des switch. De type OSSEC pour linux. Accessoirement ton IA fait le tour de ton infra régulièrement en cas de changement elle répare la configuration et t'avertis. A tous les niveaux ce type d'infra est meilleur d'ailleurs adopter par tous ceux qui la test en ce moment. Mais la question de pourquoi on appel cela SDN maintenant? Personnellement j'appel cela une Infrastructure DevOps. Cordialement Hosman. ----- Mail original ----- De: "Gregory CAUCHIE" <greg.cauc...@gmail.com> À: frnog@frnog.org Envoyé: Samedi 22 Mai 2021 17:34:52 Objet: Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ? > Le 21 mai 2021 à 10:59, Xavier Beaudouin <k...@oav.net> a écrit : > > Après le jour où le machin se fracasse ou que la license est venue a > expiration, on peux très vite sortir le camion a popcorn et attendre qu'on > appelle un dino pour réparer le merdier. > > Le cote gênant, c'est surtout le coté privateur de cette mode aka vendor > locked. Je suis en phase avec l’argument du vendor-lock. On peut argumenter qu’aujourd’hui on a déjà du vendor-lock quand on utilise des fonctions type MC-LAG ou HA dans le BNG (PPP, DHCP, …), mais c’est un périmètre moins étendu que toute la solution SD-WAN, i.e. la totalité des équipements et du manager/orchestrateur. Aussi, il y a une solution OpenSource SD-WAN (cf. FLexiWAN) dont l’implémentation équipement est effectivement opensource mais dont le manager/orchestrateur est propriétaire. Le vendor lock est donc moindre du fait qu’on est dans un univers Linux où on peut compléter le SD-WAN « basique » avec ce qu’on veut d’autre. Reste toujours ce vendor-lock du manager/orchestrateur aujourd’hui inhérent au SD-WAN, sans de grosses chances que cela change dans le futur. Pour la partie licence en revanche, beaucoup de constructeur ont une solution où l’expiration de la licences ne provoque pas l’arrêt de la solution. Il n’y a simplement plus de support dans ces cas là. Pour d’autres en revanche, tout s’arrête et le hardware devient clairement inutilisable. Ce point licence se juge donc en fonction du constructeur. > Le 21 mai 2021 à 13:04, Pierre Colombier via frnog <frnog@frnog.org> a écrit : > > J'attends avec impatience le syndrome de la poule et de l'oeuf. > Quand le déploiement automatisé du "software defined" reposera sur lui-même, > et qu'il faudra reseter l'ensemble parce que la manager s'est fait hacker, ça > promet d'être un spectacle amusant… Rien de différent avec ce qui se fait actuellement non ? qui n’a jamais poussé une « grosse bêtise » dans un script appliqué à beaucoup de machines ? le SDN ce n’est pas de l’IA (avec tout ce qu’on pourrait en dire de pour et contre), donc reste toujours la qualité de ce qui est poussé, niveau architecture-ingénierie-configuration. L’avantage d’un SDN utilisant les concept de CI/CD, c’est de pouvoir détecter le plus possible d’erreurs avant déploiement, voire de faire très vite un retour arrière dès la première erreur poussée, et donc de limiter le plus possible la casse. > Le 21 mai 2021 à 11:33, Marc Abel <fr...@harrydico.net> a écrit : > > Pardonnez ma méfiance envers la centralisation du control-plane mais j'ai > déjà subi des déboires à cause de technos censées fiabiliser le réseau... > Certains d'entre vous ont-ils eu des serveurs injoignables parce que le HA > foirait ? ou avec HSRP/VRRP/load ballancer/ etc. quelle que soit la cause. Oui. Le cas le plus simple est quand tu as un problème sur le Tx d’un des routeurs, amenant la situation où les deux passent en master. Dans ce cas pas de soucis sur les flux upstream serveur vers extérieur, mais problème sur les flux downstream, avec autant de différents impacts que d’ingénierie en place. > Le 21 mai 2021 à 12:42, Benjamin CALLAR <callar.benja...@gmail.com> a écrit : > > En ce qui concerne le SD-WAN, simple Bullshit ... faire du routage > intelligent, ce n'est pas nouveau, et ça ne se vends pas aussi cher ! Certes le routage intelligent n’est pas nouveau, mais SD-WAN ne se résume pas à ça. Les Ipanéma, Riverbed, SilverPeak, Streamcore and Co ont du ajouter faire du dev a minima pour la montée de tunnels et pour mettre en place et coupler des mécanisme de mesure de bout-en-bout sur le tunnel pour prendre en compte les comportement du WAN et surtout des différents débits de l’accès distant. -- Grégory --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ -- [ https://www.email-impact.com/group/redirect/company-logo/8cTWQxwXLK/313 ] Hosman BEYROUTI Administrateur Systèmes et Réseaux Mob Fixe [ tel:06 90 88 00 80 | 06 90 88 00 80 ] [ tel:06 90 88 00 80 | 05 90 77 40 80 ] Chez CDS Immo Impasse Vanterpool Maison Decaunes Concordia 97150 Saint-Martin [ http://www.dauphintelecom.com/#?utm_source=email_impact&utm_medium=signature&utm_campaign=nom_de_domaine | www.dauphintelecom.com ] [ https://www.facebook.com/dauphin.telecom/ ] [ https://www.youtube.com/channel/UCaa1IU36j9twokUC3NAjZfQ ] [ https://www.instagram.com/dauphin_telecom/ ] . --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
