On September 1, 2018 5:26 PM, Guillaume Barrot <[email protected]> wrote:
> Ah ben tu peux faire de l'EEM + NBAR + PBR + TE, mais y a aussi des moyens > plus simples de se faire mal quand on est sadomaso. > La vraie question est plutot : ok, on a eu l'idée, mais en fait, est-ce que > ça a un intérêt quelconque ? > J'ai quand même vu des gars qui sur du SD-WAN envoyaient le trafic "critique" > via un lien type SDSL 8M vers un site central (HQ de la boite). > Problème, le trafic critique en question était ... Office 365. Alors envoyer > sur une 8M débit garanti, un trafic fondamentalement best-effort et qui de > toutes façons va finir sur du best-effort traditionnel ... non, vraiment, je > ne vois pas, non... On est strictement d’accord, il y a aura toujours des personnes pour détourner des outils prévus pour un usage pour en faire un autre usage. Les équipementiers intègrent des éléments ensemble pour les clients qui n’ont pas le temps, les compétences ou les moyens de le faire. C’est pour que des entreprises qui innovaient beaucoup par le passé peuvent être remplacées par des solutions open source. > Il y a quelques années, je bossais pour une boite multinationale, siége en > Suisse, avec des dizaines d'agences dans le monde. > En Suisse, ils avaient un MPLS VPN via l'opérateur national, moyennant un > second trou du cul. > A l'international, ils avaient des liens à la con d'opérateurs locaux, avec > un Cisco 8xx en DMVPN vers de l'ASR1000 en central en Suisse (2 sites). > Y avait même de la VoIP qui transitait là dessus. > > Devinez : > 1) combien de temps on mettait à configurer un 8xx avant de l'envoyer sur > site (hint : ça se compte en sec) > 2) sur quels liens on avait statistiquement le moins de problème (hint : > c'est quand même vachement stable le DSL dans le monde, en fait ...) > 3) comment on fait pour mettre un lien de backup sur un 8xx qui tourne DMVPN, > et ce, sans avoir le moindre problème (hint : nat interface sur chaque WAN, > et zou, problème réglé) Je suis totalement d’accord qu’internet est un moyen efficace et pas cher de transporter entre deux sites d’un groupe et qu’on moins on ne se menotte pas un opérateur génial qui facture grassement sa prestation, surtout quand ce dernier sous-traite avec d’autres opérateurs nationaux pas bon marché pour livrer sa solution. Loin de moi l’idée de remettre en doute ce que tu as dit ci-dessus, mais j’ai quand même de la peine à imaginer une session SIP survivre à un souci de lien saturé entre deux opérateurs internationaux. Il faut vraiment bien choisir ses opérateurs quand on part sur cette politique (y.c. leurs transitaires) et prier pour que la politique ne change pas du jour au lendemain, parce que deux opérateurs qui passent d'une bonne qualité à une latence douteuse et avec du packet-loss, c'est pas du jamais vu. > Une boite comme ça, le gain du SDWAN serait uniquement de pouvoir agréger les > bandes passantes des liens WAN en nominal. Ca va pas chercher bien loin quand > même... > Une simple recherche Google et on trouve des dizaines de ressources > opensource sur MPTCP, donc qu'on aille pas me faire croire que ça coûte cher > en R&D la fonctionnalité d'agrégation (ou le scheduler : http://progmp.net/), > ça ne serait pas des masses crédibles... Il existe certes des options, mais je doute que grand mode se lance dans cette entreprise avec une libraire open source, mais je me trompe peut-être. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
