Bonsoir, Je vais sans doute dire des bêtises, mais pour moi SD-WAN n’est juste que l’aboutissement de ce qui se fait depuis longtemps avec DMVPN. Les avantages que j’y vois. Faire du PFR sur plusieurs liens. Si on souhaite ne pas investir sur du WAN, on peut facilement faire du VPN client meshé over IPSEC avec DMVPN phase 3 (sans avoir x VTI de configurés). QOS par tunnel. Mais DMVPN n’est pas nouveau.
Si vous avez une autre vision de la chose, je suis preneur aussi d’avoir votre vision. Cordialement, --------------------------------------------------------------- Christophe LUCAS christo...@lucas.fr.eu.org <mailto:christo...@lucas.fr.eu.org> --------------------------------------------------------------- > Le 14 août 2017 à 15:07, Jérémy RIZZOLI <jeremy.rizz...@gmail.com> a écrit : > > Hello, > > Merci pour ces retours constructifs, je rejoins le point de vue sur > l'aspect "c'est pas nouveau", ça, je l'avais bien vu aussi. > > De ce que j'en comprend, il n'y a rien qui se fait en SD-WAN qui ne > puisse pas se faire en "classique". > > Cela me parait être un package de technos adapté à quelqu'un qui monte > un backbone/business from scratch et qui veut aller très vite, mais pas > vraiment à quelqu'un qui a déjà une infra IP/MPLS en place, puisque le > seul intérêt serait peut être pour de l'extension de réseau en mode > Quick&Dirty ? > > Dans tous les cas, tout se repose sur Internet, et un ou plusieurs > transits, et tu montes toute la logique au niveau applicatif en réalité > et c'est bien fondamentalement ce qui me gène, je m'explique: > > On me demande actuellement dans un contexte d'opérateur télécom pur, de > pousser vers du SD-WAN pour pouvoir se déployer plus rapidement à > l'étranger. La cible qui est visée par mes chefs, c'est en gros de tout > déployer directement dans AWS, dans une instance locale et d'y déployer > complétement toute la panoplie en quelques clics. > > On a déjà notre backbone IP/MPLS, et clairement déjà les pieds dans le > "SDN/NFV" pour le moment par des solutions qui nous sont propres en > Cloud privé. > > Ma première idée était de déployer en DC un bête switch SDN + quelques > hyperviseurs et de tout monter dessus avec des liens IP/MPLS tout ce > qu'il y a de plus classique et dont on maitrise le coût (certe cher) et > les latences, surtout qu'on saurait le faire sans trop de difficultés, > mais voilà .. monter du physique, même si peu, ça prend du temps (trop > de temps). > > En regardant de plus près le déploiement de ce type de solution, le truc > intéressant serait notamment de déployer directement dans AWS ou autre, > or je me suis vite rendu compte qu'on perdrait clairement en maitrise de > l'infra, à savoir: > > Obligé de respecter les contraintes d'interco poussées par le/les > fournisseurs de Cloud AWS, et autres, notamment sur l'entrée/sortie: > passage obligé L3 par les routeurs du Fournisseur de Cloud qui font ce > qu'ils veulent sur le trafic de leurs clients.., utilisation de LEURs IP > publiques, etc etc .. > > Obligé au final de déployer en "overlay" de l'infra de tes fournisseurs > de Cloud ou d'Internet, souvent à grands renforts d'IPSec dans tous les > cas.. automatisé ou non, ça reste une couche en plus. > > Perte de la maitrise de la réalité physique du lien on ne sait plus > finalement ce qui se passe exactement entre le point A et B, même pas un > début d'idée, alors certes, certains répondront "on s'en care" mais pas > complétement quand même .. si c'était si simple ça se saurait.. > > Perte de la maitrise du routage sous une certaine forme, puisque > l'automatisation du ControlPlane SD-WAN fait que beaucoup de choses ne > sont plus vraiment "prévisibles" à force d'empiler les couches .. > certaines décisions pouvant être prises par l'applicatif en lui-même .. > A noter que ça devient aussi une misère à analyser en cas de crash pour > analyser toute la chaîne .. > > De façon générale, ça revient pour moi à déplacer des fonctions du > réseau dans les couches hautes: L5/L6/L7 et à broder autour de ce qui > existe chez les fournisseurs d'infra/Cloud aux couches L2/L3/L4 en leur > faisant confiance à 100%.. ce qui sous une certaine forme peut > apparaitre comme une sorte de déléguation / externalisation complète de > "tout le merdier de l'infra, réseau compris". > > Au final, en dehors du fait de perdre en maîtrise globale sur les > couches basses, chose qui apparait de plus en plus comme acceptable en > 2017, j'ai comme l'impression que c'est surtout un débat entre "on prend > la solution sur étagère qui s'appelle X-SD-WAN et qui fait papa/maman > (et le café) ou on prend 2 ingés réseaux qui vont nous automatiser cela > maison avec un outil qu'ils maitrisent. Je me trompe ? > > Est-ce que au moins les solutions sur étagère tiennent leur promesses ? > Car de ce que j'en ai vu jusque là, il faudra toujours des ingés pour > les mettre en route et les configurer .. et ça prend pas forcément moins > de temps surtout vu le caractère quelque peu expérimental pour le moment > de certaines .. contrairement à ce que nous vantent les prospectus. > > Quant à l'aspect coût global, j'ai tout de même un doute énorme sur la > pérennité financière de ce genre de solutions... c'est peut-être plus > avantageux à déployer en termes d'investissements initiaux, mais par > contre les frais récurrents explosent dès qu'il s'agit de passer à > l'échelle .. notamment à cause du fait que tu vas tout baser sur tes X > fournisseurs de Cloud public qui vont bien entendu se gaver largement au > passage .. et je parle même pas du support associé .. > > Bref, ça fait clairement se poser des questions sur ce qui est attendu > du taff de l'ingé réseau en 2017 .. > > > Jérémy > > > > Le 14/08/2017 à 12:13, Guillaume Barrot a écrit : >>> "Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme >> de cible, ce type de technos." >> >> Cible directe : service provider >> Cible indirecte (les clients du service provider) : retail étendu >> (grosse distrib, grosse distrib de carburant, etc.), multinationales >> avec des agences à l'étranger (ex : boites de com' / pub', gros cabinets >> d'avocats Paris / NY, agences de presse) >> >> Deux choses que tu fais en SD-WAN que tu peux faire en classique mais en >> investissant du temps et des devs : >> - aggregation de liens sur critère layer 7 (mptcp + DPI pour classifier >> et envoyer le trafic dans tel ou tel tunnel) >> - créer des VPN facilement, avec des points de terminaisons qui peuvent >> être dans des clouds publics tiers (= s'affranchir des offres de type >> cloud connect qui sont vendues un bras, et ne pas avoir à monter un >> IPSEC à la main sur une VM Junisco ou PfSense). >> >> Donc gain pour le SP : offrir des accès en redondance actif-actif + >> critères, et étendre son offre VPN en dehors de son backbone MPLS, sans >> les couts de "je fais du DMVPN qui finit dans une VRF, et j'y crois à >> mort, ça va marcher" >> >> C'est pas révolutionnaire du tout, c'est un package de technos déjà >> existantes depuis des années. >> Chez Cisco c'est l'aboutissement d'une stratégie qui a démarré avec PFR >> il y a presque 10 ans, c'est dire. >> >> Après à l'usage, à part le MPTCP qui a un usage concret démontré (cf : >> OTB OVH), le reste est un enrobage bullshitomarketing pour ne pas avoir >> à monter son Ansible soit même. >> Mais ça a l'avantage de fonctionner, contrairement à vouloir réintégrer >> ça soit même dans une Debian + Quagga + DPDK (faisable, ceci dit, mais >> au combien casse gueule). >> >> Le 14 août 2017 à 11:29, Richard Klein <varicap....@gmail.com >> <mailto:varicap....@gmail.com>> a écrit : >> >> Voir : >> >> http://www.zdnet.fr/actualites/sd-lan-et-sd-wan-deux-approches-differentes- >> pour-le-software-defined-networking-39841794.htm >> >> <http://www.zdnet.fr/actualites/sd-lan-et-sd-wan-deux-approches-differentes- >> pour-le-software-defined-networking-39841794.htm> >> >> Ou plus proche des clients GP la Livebox décentralisé. .. >> >> C est assurément une bonne idée mais mon principe à moi c est de >> garder mes >> données chez moi et de rester indépendant ( a 99%) d'une infra que je ne >> maîtrise pas. >> >> Question il se passe quoi quand votre chaîne à le maillont faible >> qui est >> cassé ? >> >> Et sur la sécurité les experts en pensent quoi ? Le jour où il y a une >> faille tous tombe ? >> Principe de base d'un grand penseur de l'internet : tous ce qui >> passe sur >> internet est susceptible d'être publique >> >> Richard >> >> Le 14 août 2017 11:08, "David Ponzone" <david.ponz...@gmail.com >> <mailto:david.ponz...@gmail.com>> a écrit : >> >> C'est rigolo, pour moi, le SD-WAN c'était l'inverse: plus d'intelligence >> dans le CPE pour s'affranchir de la dépendance à un carrier. >> >> David Ponzone >> >> >> >>> Le 14 août 2017 à 17:01, Solarus <sola...@ultrawaves.fr >> <mailto:sola...@ultrawaves.fr>> a écrit : >>> >>> Le 2017-08-14 09:48, Jérémy RIZZOLI a écrit : >>> >>>> Néanmoins, j'ai quand même du mal à voir à qui s'adresse en terme de >>>> cible, ce type de technos. >>> >>> Salut Jérémy. >>> >>> Le principal intérêt que je vois au SD-WAN c’est de pouvoir >> envoyer chez >> les clients des boitiers moins «intelligents» et donc moins chers, >> l’intelligence étant gérée en cœur de réseau. >>> L’avantage c’est que le boitier n’a plus qu’à gérer le lien physique >> (ADSL, SDSL, FO), la couche IP étant gérée au niveau du backbone, ce qui >> limite le risque d’erreur de conf sur les routeurs distants. >>> Les configurations sont récupérées depuis le cœur de réseau, ce qui >> facilite les déploiements. >>> >>> L’autre avantage c’est qu’on centralise l’intelligence réseau et la >> puissance nécessaire sur les contrôleurs SDN et les PE, ce qui >> facilite les >> upgrades puisqu’il y a moins de matériel à changer chez les clients. >>> Sinon oui, le principe c’est équivalent à celui de puppet ou >> ansible, il >> s’agit de tout «masteriser» à distance à partir d’un contrôleur. >>> >>> De toute façon c’est le modèle poussé par Juniper et Cisco qui se >> font la >> guerre sur ce secteur donc on risque d’y passer bon gré,mal gré. >>> >>> Cordialement. >>> Solarus. >>> >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> >> >> >> >> -- >> Cordialement, >> >> Guillaume BARROT > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
