From: Madhuri Patwardhan <madhuri@cc.iitb.ac.in>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] How to limit a dev bandwidth.
Date: Sat, 16 Aug 2003 18:43:59 +0000 [thread overview]
Message-ID: <marc-lartc-106105883023859@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106032592806296@msgid-missing>
Hi,
Thanks a lot for the really clear explanation.
> : Because it is not really possible to schedule the incoming traffic
> : without simulating it as being transmitted from IMQ device.
>
> I really have no idea what you are trying to say here. Scheduling is a
> function of the queuing discipline (e.g., SFQ, FIFO, ESFQ, WRR, RED and,
> taken as a whole CBQ and HTB qdiscs). The reason for IMQ is to allow
> shaping to occur on a single box for incoming traffic destined to a local
> IP.
>
Sorry, what I meant was it is not possible to shape ( I used the wrong
word schedule in my earlier message. It was a typo.) the incoming
traffic. It is only possible to shape the transmitted traffic. So I was
under the impression that we may need to use IMQ.
However, it is now clear that the "download" traffic which is passing thro
the firewall ( not the locally generated traffic) is transmit
"download" data to my internal network on the inside interface
eth0. So plain htb qdisc and classes will work as you have explained
below.
Thanks,
Madhuri
>
> Your firewall will transmit inbound traffic on eth0 (private-facing
> interface). Because the traffic is transmitted on this interface you can
> add an HTB qdisc with an HTB class and perform shaping on the inbound
> traffic.
>
> If you take care to distinguish between traffic which is locally generated
> traffic on your firewall (it would pass the INPUT and OUTPUT netfilter
> chains in the filter table) and traffic which is passing through your
> firewall, you'll see that your firewall has the opportunity to transmit
> "download" data to your internal network on the inside interface. Here is
> your opportunity to use an HTB class to perform shaping!
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2003-08-16 18:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-08 6:59 [LARTC] How to limit a dev bandwidth anzp
2003-08-08 17:06 ` Stef Coene
2003-08-10 0:16 ` Martin A. Brown
2003-08-14 10:57 ` Raghuveer
2003-08-15 4:16 ` Martin A. Brown
2003-08-16 4:36 ` Madhuri Patwardhan
2003-08-16 17:18 ` Martin A. Brown
2003-08-16 18:43 ` Madhuri Patwardhan [this message]
2003-08-19 9:26 ` Raghuveer
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-106105883023859@msgid-missing \
--to=madhuri@cc.iitb.ac.in \
--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.