> Le 21 mai 2021 à 10:59, Xavier Beaudouin <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/
