From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] question about tc and ip aliasing
Date: Mon, 28 Apr 2003 19:26:43 +0000 [thread overview]
Message-ID: <marc-lartc-105155806112584@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105130626704816@msgid-missing>
On Monday 28 April 2003 10:45, Szymon Miotk wrote:
> Enric Ramos Mas wrote:
> > I have implemented a traffic control / advanced router server using
> > iproute2 and tc (using htb). For all my outgoing tc policies, all
> > it's ok (all the traffic goes out using eth0, and therefore I'm able
> > to catch it using the corresponfing tc filter).
> >
> > However, the incoming traffic has to be treated in eth1, which has
> > several virtual ifaces (eth1:0, eth1:1, eth1:2 and so on).
> > Even I have introduced all the tc rules correctly, the kernel is not
> > matching any filter rule and there is no way to match any destination
> > into any queue discipline.
> >
> > Anyone knows some way to implement that ?
>
> I'm also very interested about this question as I have similiar link
> configuration.
> One question about classes on eth0: do leaf rates (1:10 - 1:??) sum up
> to 3256kbit (parent rate)?
> I have to split 1040 kbit for 700 users and HTB manual advices
> a) that children rates should sum up to parent rate
> b) that the rate should not be less than 4kbit
This is the first time I hear about this rule. You can have a problem with
quantum if you have a low rate. But you can overrule quantum when you add a
htb class (rule : quantum > MTU).
> I expect that I should go by the b) rule, as used rates will never sum
> up over 1040kbit (there will never be 700 users using this link at the
> same time).
> Am I right?
Yes. The problem is that the parent rate is not respected. So if each class
is sending, it will exceed the parent rate. This can be "bad" because you
send more data then your router/modem can handle so it's possible that you
your shaping will not be that perfect.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-04-28 19:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-25 21:18 [LARTC] question about tc and ip aliasing Enric Ramos Mas
2003-04-28 8:45 ` Szymon Miotk
2003-04-28 19:26 ` Stef Coene [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=marc-lartc-105155806112584@msgid-missing \
--to=stef.coene@docum.org \
--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.