[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Agrégation de liens Internet



Olivier a écrit :
> Le 20 avril 2014 13:02, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
> 
>> La répartition par route multipath risque de ne plus être utilisable
>> avec des liens internet indépendants, le cache de routage ayant été
>> retiré des versions récentes du noyau Linux.

A partir de la version 3.6.

>> Explications :
>> Une route multipath sélectionne un chemin parmi ceux spécifiés, pour un
>> couple source-destination donné,
> 
> Ah, bon ?
> En testant (très très sommairement), j'avais compris qu'il ne tenait compte
> que de la destination, pas de la source.

La décision de routage, oui (hors routage avancé). Pas le cache de
routage. Ça empêcherait de faire de la répartition lorsque plusieurs
clients font des connexions vers le même serveur. Déjà que ça ne fait
pas de répartition lorsque le même client fait plusieurs connexions au
même serveur...

Démonstration :
# ip route add 172.16.0.0/16 nexthop via 192.168.0.2 nexthop via 192.168.0.3
# ip route get 172.16.0.1 from 10.0.0.2 iif eth1
172.16.0.1 from 10.0.0.2 via 192.168.0.2 dev eth0  src 10.0.0.1
# ip route get 172.16.0.1 from 10.0.0.3 iif eth1
172.16.0.1 from 10.0.0.3 via 192.168.0.3 dev eth0  src 10.0.0.1

Même destination, sources différentes -> passerelle différente.

> Dans l'article en anglais que j'avais cité, l'auteur mentionnait plusieurs
> algorithmes différents pour répartir les requêtes.
> Si ma mémoire est bonne, un algorithme tenait compte de la bande passante.
> Je n'ai pas essayé d'en savoir plus.

Quel article ? Le seul article que je vois cité dans ce fil vient de
Daniel, et ne semble pas parler de ça.

>> Reste le routage par marquage avec iptables.
> 
> Comment répartir la charge avec le marquage ?

Grâce à la correspondance "statistic" d'iptables et la cible CONNMARK.
Mais cela n'a qu'une efficacité relative car d'une part on ne peut pas
anticiper quel sera la demande en bande passante d'une connexion et
surtout il n'y pas de moyen de privilégier le lien le moins chargé.


Reply to: