"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, "
Oui c'est clairement un cas d'usage "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 ?" Absolument pas, tu fais un procès d'intention. A moins que tu saches terminer un MPLS VPN directement chez Azure ou AWS, où que tu ais des portes de collecte partout dans le monde, des solutions tunnelisées sont souvent la seule solution pour d'étendre vite. Quick oui, Dirty c'est abusif. Comme la majorité des services providers je suppose que tes routeurs utilisent ta GRT comme control plane générique et que ton MPLS est monté en overlay de tes routes publiques. Si tu as un PNI avec Amazon par exemple quelle différence de qualité entre un IPSEC de chez toi à une IP AWS, une option 10C en NNI ? De mon point de vue, aucun. Tu peux même tagguer tes entêtes IPSEC avec une valeur de QOS qui matche un trafic critique, ou faire de la copie de champs DSCP inner vers outer. "Dans tous les cas, tout se repose sur Internet, et un ou plusieurs transits" Pas plus qu'une porte de collecte xDSL ou tués annonces tes blocs LNS a ton opérateur tiers. Si tu montes des PNI direct et que tu annonces les blocs de terminaisons, tu as la même qualité qu'en faisant une interco MPLS 10a/10c avec un opérateur tiers. Je prend l'exemple des LNS a dessein car L2tp/PPP est un overlay, c'est même le premier et le plus déployé dans le monde. Le seul argument valable contre les overlay / tunnels IPSEC c'est le coût en MTU et l'impact du temps de serialisation sur ta latence. Qui n'est pas négligeable. Contrainte déjà connue depuis le L2TP / PPP sur le xDSL ... Le 14 août 2017 3:07 PM, "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/
