Ta réponse est effectivement intéressante, elle décrit les processus qui permettent d'arriver à une agrégation qui fonctionne même avec des lignes de capacité différente, indépendamment des opérateurs. C'est ce que nous faisons (Agrégateur dans le data center, modem ou routeur flashé coté client, calcul dynamique des bandes passantes, encapsulation etc...).
Notre solution permet d'économiser ce développement et d'avoir une solution commercialisable et déployable immédiatement, maintenant il me parait normal que la société qui a investi dans le développement protège un peu son travail par des patents/brevets, même si ça vous fait tous rire :-(( Sur la fibre : Je suis d'accord que la fibre c'est mieux mais aujourd'hui ou en est le déploiement ? je suis à 1 Km de TH3 et je dois me contenter de lignes ADSL à 1.6Mb/s (Free) et 2.3Mb/s (SFR), le DSLAM le plus proche est à Guyancourt (5.5km).... concrètement, en me branchant sur un serveur d'agrégation en Hollande, j'ai pu avoir pratiquement 4Mb/s en DL et surtout presque 1Mb en UL. On m'a fait des offre en SDSL mais ça ne résout pas le problème de l'éloignement du DSLAM et du faible débit en download, le 3G ne passe pas, ça aurait peut-être pu être une alternative. @+, Didier -----Message d'origine----- De : Jérôme Nicolle [mailto:jer...@ceriz.fr] Envoyé : jeudi 24 janvier 2013 10:45 À : Didier Clapier Cc : frnog@frnog.org Objet : Re: [FRnOG] [BIZ] Agregation de liens internet Le 24/01/13 09:06, Didier Clapier a écrit : > Eh bien, je vois que l'ouverture d'esprit n'est une pratique commune. > Oh, si, surtout ici. Avec quelques mois ou années sur la liste, tu aurais surement saisi l'esprit et compris que le sujet aurait pu/du être abordé différemment. > Que tu m'expliques que tu es septique parce que ci parce que ça je > comprends , c'est constructif. Oui, et si ça t'intéresse, je peux développer quelques points. > Maintenant dire que c'est de la m... pour la beauté du geste .... Pardonnes moi, mais il ne me semble pas avoir critiqué le produit, que je ne connais pas. C'est la démarche qui me dérange. > Je m'adresse à cette liste car la question de l'agrégation touche les > opérateurs et que le sujet est intéressant. Le sujet est certes intéressant, mais ne touche pas tout le monde, car la montée en débit se fait de plus en plus par le changement de media (fibre). Ainsi, pour les opérateurs d'infra ou les locaux se mettant à la partie "couche 0", le problème du débit sur les supports cuivre se posera de moins en moins. > Les utilisateurs qui me > disent utiliser Microtik apporte une information intéressante pour > tous qui fait avancer le sujet. Ce que je propose est une autre > solution, cela permet à tous d'avoir l'information, d'ailleurs > annoncer sur cette liste est aussi le moyen de s'adresser à des > personnes compétentes et de prendre le risque d'avoir des questions > que d'autres ne poseront jamais. OK, alors on va entrer ensemble dans le vif du sujet. Les techniques d'agrégations classiques (round-robin par bonding de tunnels ou multipath) sont en général des approches trop naïves quand on dispose de liens hétérogènes : on ne fera que multiplier le débit du lien le plus lent. Une pondération au prorata de la capacité de chaque lien est préférable, et se fait assez facilement par simples scripts. Une méthode élégante consiste à bencher une ligne hors de l'agrégat, en déduire un coefficient, et mettre à jour une règle (iptables ou pf) ajoutant un marqueur aléatoire sur chaque paquet pour le router vers un lien ou un autre en fonction de la valeur dont la distance entre les bornes sont fixées par le coeff. Alors le lien est intégré dans l'agrégat, on retire le suivant, bench, calcul, et ainsi de suite. Cette approche, 100% scriptée, pose deux problèmes : * Paquets presque toujours dans le désordre * Le débit des liens peut varier (congestion, dégradation) Pour le premier point, il faut envisager une encapsulation des paquets et un ré-ordonnancement à la réception. Ca coûte en latence, mais ça se fait bien avec vtun ou OpenVPN en TCP. Point noir : ça coûte du MTU. Pour le second point, on peut y pallier en refaisant périodiquement les mesures, ou au moyen d'un protocole d'encapsulation un peu plus subtil qui permette de monitorer les liens en live (par mesure de décalages en temps, perte ou corruption, en plus d'un système de fenêtres façon TCP). De base, le problème qu'on cherche à contourner est la limite de débit. Il n'est pas inutile de coupler à cette solution du proxy-cache et de la compression (attention, ça pue c'est pas neutre, hein ;) ). Dans le cas ou l'on aie en plus des liens très hétérogènes (ADSL + SDSL + 3G + whatever), alors on pourrait vouloir préferer certains liens pour certaines applications (DNS, SSH, X, RDP sur le SDSL, HTTP sur l'ADSL, ...). Ca se fait aussi avec l'approche de routage précédemment évoquée. Dans tous les cas, on va avoir besoin de deux extrémités : un routeur coté "opérateur" (quoi que ça peut se faire en totale indépendance d'un opérateur) et un coté client. Les systèmes de load-balancing classiques, boitiers à quelques centaines d'euros pour natter au cul de lignes ADSL classiques, fonctionnent sans serveur mais sont incapable d'être transparents. Je suppose donc que le fonctionnement de ton produit est très similaire à ce que je viens d'expliquer, qui existe depuis une bonne dizaine d'année, et que j'avais intégré en 2007 (en croyant que c'était révolutionnaire...) pour une petite SSII qui a tenté de le vendre (sans trop de succès). Donc, connaissant un peu le sujet, lire "brevet", solution propriétaire, ou quelconque mention d'innovation, bha... ça me fait bien marrer :) Allez, sans rancune ;) -- Jérôme Nicolle 06 19 31 27 14 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
