Retourner aux forums || Retourner au forum Linux.debian
Linux.debian : Brider volontairement le débit de son port ethernet
Posté par tcheuck (Jabber id, ) le 10 novembre 2007J'ai un serveur dédié et mon hébergeur facture assez chez le dépassement de bande passante. Mon serveur est assez surdimensionné par rapport à l'utilisation que j'en fait (web / mail), mais je ne voudrais pas me retrouver à la fin du mois avec une facture que je ne pourrais pas payer, en cas de DDoS par exemple...
Je cherche donc une solution de préférence logicielle, afin de limiter à X Mbps l'utilisation de la carte réseau de mon serveur.
En vous remerciant d'avance pour votre aide;)
> Lire le message (3 commentaires, moyenne: 5,3).
TC
Salut,
avec "tc" tu peux limiter ta bande passante en upstream..
Pour limiter & 1 Mbits/s par exemple :
# tc qdisc del dev eth0 root
# tc qdisc add dev eth0 root handle 1: tbf rate 1Mbit burst 1kb"
Tu peux augmenter la valeur du burst si tu vois que le débit est limité à moins de 1Mbit.
-
[^]Re: TC
Posté par tcheuck (Jabber id, ) le 11/11/2007 à 13:36. (lien). Évalué à 1.Merci Remi !
Ta solution me convient parfaitement, mais je pose quand même la question:
qui connaît une manière de limiter "globalement" le débit (download et upload) ?
-
[^]Re: TC
Posté par dguihal () le 12/11/2007 à 10:46. (lien). Évalué à 6.Tu ne peux pas explicitement limiter le débit entrant sur ta carte puisque tu ne peux pas gérer la vitesse à laquelle on t'envoie des paquets.
Par contre par effet de bord, limiter la BP sortante limite naturellement le débit entrant (congestion des paquets ACK donc saturation des fenêtres d'émissions de trames pour les clients)
-
Revenir en haut de page || Retourner aux forums || Retourner au forum Linux.debian
Cette page a été générée par Templeet en 0.0524s (dont 0.0075 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.