Bonjour Guillaume, Je suis tout à fait d’accord. Aucune machine ne rendra intelligent un DSI/RSSI/admin/manager/ingé/tech/prof d'univ con :-). Ce que tu décris est une dérive classique que je vois fréquemment en audit. On met tout par défaut sur le VPN archi-sensible de la boite et après on va s’acheter des boiboites de compression+étrangleur de flot et on se plein que c’est lent …
Il va falloir apprendre qu’avant de dépenser de l’argent il faut réfléchir et aucun investissement ne remplacera le travail de réflection et de conception de son SI. Et ça se fait sur du papier, avec du concentré de matière grise, pas avec des prospectus de commercial :-). A+ Kv > Le 1 sept. 2018 à 17:26, Guillaume Barrot <[email protected]> a > écrit : > > Le ven. 31 août 2018 à 11:12, Alex Martino <[email protected]> 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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
