Le ven. 31 août 2018 à 11:12, Alex Martino <alex.mart...@protonmail.com> a écrit :
> Faire de la décision basé sur latence, jitter, packet-loss et > reconnaissance > d'application au niveau L7 pour faire du TE, c'est certainement possible, > mais je doute beaucoup que grand monde y arrive, avec des effectifs > réduits. > 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... > Certainement d'accord que c'est pas une solution magique, mais finalement > ça > fait déjà longtemps que des PME/TPE font de l'IPSec pour connecter des > sites > distants. Si en plus on peut prendre en compte des problèmes réels de > réseau > et influencer le sens du trafic, je pense que le produit à une valeur. > 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é) 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... --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
