Limiter la bande passante entre 2 hosts (dont l’un en Linux)

closeCet article a été publié il y a 12 ans 3 mois 3 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Dans la série aide-mémoire.
Imaginez : approbation d’une tonne de patchs de sécurité Windows en retard sur un WSUS avec des réplicats. Immédiatement, il commence à downloader, via un proxy Squid sous Linux, donc via une machine Linux.
Et là, votre bande passante est réduite à de la poussière car WSUS, via le proxy, pompe tout, à fond.
Raaaaaaaaaa. M’énerve.

Vite, iptables doit pouvoir m’aider. Je suis une buse en QoS, mais bon, j’ai confiance en Google 🙂

Après quelques recherches, je suis tombé sur LARTC, Linux Advanced Routing & Traffic Control. En quelques mots, une bande de fous-furieux qui aiment les lignes de commandes compliquées (à côté de ça, iptables est un joujou) pour faire de la QoS.
Y’a un howto super complet : http://www.traduc.org/docs/howto/vf/lartc.html. Pas le temps, ça sent le sujet compliqué et vaste. On verra plus tard.

Là je veux juste limiter le trafic entre mon proxy et ce p~!?[n de serveur WSUS.

J’ai trouvé 3 lignes magiques ici (après avoir survolé le man tc histoire de suivre le loin ce que je fais) :

tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 10mbit
tc class add dev eth0 parent 1: classid 1:1 cbq rate 400kbit allot 1500 prio 5 bounded isolated
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.2 flowid 1:1

Je voulais limiter le trafic vers 192.168.1.2 via eth0 à 50 kB/s, soit en gros 400 kbit/s.
Pour annuler, j’ai « annulé » les commandes, si je peux dire. Sans être trop sûr de moi, j’ai simplement tenté ça :

tc filter del dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.2 flowid 1:1
tc class del dev eth0 parent 1: classid 1:1 cbq rate 400kbit allot 1500 prio 5 bounded isolated
tc qdisc del dev eth0 root handle 1: cbq avpkt 1000 bandwidth 10mbit

Je n’ai pas vu d’effet de bord (genre, tout bloqué ou rien qui ne se rétablit une fois le tc annulé). Donc on va dire que c’est probablement un peu crade, que je n’y comprends pas tout, mais que ça marche.

Voilà, si ça peut vous servir, j’en suis content.
noob-powered

4 comments

  1. Très intéressant c’est un bon résumé pour une fonctionnalité bien précise.
    Pour ma part il faut que j’intègre ce méchanisme pour faire des tests réseaux avec des Linux. Le but est de valider par ex une liaison voip à travers une laison avec peu de débit.

    Il ne me manquera plus que le fait de générer de la latence et des pertes de paquets.

    Sous windows il existe un soft dont j’ai oublié le nom qui fait cela, bizarre que personne n’y ait pensé sous linux

  2. A mon avis, c’est car tc+iptables le font déjà
    C’est juste pas super user-friendly.
    Je n’ai pas non plus regardé s’il y a des outils qui enrobent tout ça.
    Si quelqu’un sait, je suis preneur

  3. tiens sinon encore plus simple pour faire appel a tc , je me suis souvenu qu’un super script a l’époque des premières lignes adsl faisait du shaping de façon assez propre, c’était wondershaper.
    A ma grande surprise il est packagé dans Debian.

    wondershaper eth0 56 30 donnera l’illusion d’un accès 56K
    wondershaper clear eth0 annulera l’action

  4. Oui j’utilisais aussi pour prioriser des flux à l’époque des 512/128 kb/s
    Mais c’est du souvenir. Très bien si cet outil permet de gagner en complexité de commande.
    Je testerai à mon prochain besoin

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.