All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Qos and bandwidth control
Date: Fri, 13 Jan 2006 22:56:41 +0000	[thread overview]
Message-ID: <20060113225641.GA11542@EIS> (raw)
In-Reply-To: <BAY22-F24E9B6F4C838F69173BC9FAA270@phx.gbl>

On Thu, Jan 12, 2006 at 07:01:57PM +0000, Beto . wrote:
> 1.2.3.1 has 256kbit bandwidth "guaranteed"
> clients 1.2.3.2 and 1.2.3.3 has 256kbit bandwith

So I guess that means 512kbit in total?

> so im marking every packet using layer7 iptables module

I have not used layer7 so far, only IPP2P, but the basic idea of 
classifying and prioritizing should be the same.

> iptables -t mangle -A POSTROUTING -m layer7 --l7proto ssh -j MARK 
> --set-mark 2

No connmark? Does layer7 actually detect every single packet of this 
protocol, or only the first ones of a connection? In the latter case, 
you'd have to mark the connection, not just a single packet.

> the problem im facing is that i also have to limit client's bandwidth and 
> im not sure that my solution is the best. i've searched for an example like 
> this in the web but i have found nothing.

I don't know what's best either. My solution was to give every user 
a separate HTB class, to limit their bandwidth. Further prioritization 
of packets has then to be done inside this user class. Your setup 
looks like you're trying to do something similar.

> it could have some errors. Basic protocol detection and enqueue was working 
> fine, but im not sure now, with "bandwidth restrictions" additions.

The most common error with HTB classes is that the sum of the children 
class rates is not equal to the parent class rate. You got it right for 
the root class 1:1 and it's children 1:2, 1:3 (256+256Q2kbit), but 
it's wrong for the children of 1:2 (200+128+2048kbit, whereas the 
parent can only offer 256kbit in total).

Also, I don't see where in your setup the classification by user is 
taking place.

Regards,
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

      reply	other threads:[~2006-01-13 22:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-12 19:01 [LARTC] Qos and bandwidth control Beto .
2006-01-13 22:56 ` Andreas Klauer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060113225641.GA11542@EIS \
    --to=andreas.klauer@metamorpher.de \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.