Re: [LARTC] How to limit a dev bandwidth.

["Martin A. Brown" <mabrown-lartc@securepipe.com>]

Madhuri,

 : > So, shape your "upload" traffic on wan0 (ACKs, maybe the packets with a
 : > TCP source port of 25 from your internal mailserver).
 :
 : Here one could use plain htb qdisc (without imq) to shape the outgoing
 : (upload) traffic.

Absolutely correct.  Traffic bound for the Internet (on wan0) can be
shaped using an HTB qdisc containing an HTB class. (Remember the shaping
only happens in a leaf HTB qdisc.)

 : > Shape the "download" traffic on eth0.  Here you have the opportunity of
 : > deliberately delaying the traffic before it reaches the client in the
 : > private network.

 : Now for shaping "download" ( means effectively incoming) traffic on
 : eth0 one would need to use IMQ.

Not true.  [ see below for more clarification ]

 : 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.

 : It will not be possible to use just plain htb qdisc without ImQ to
 : shape incoming traffic, is that correct?

It is possible to use a plain HTB qdisc with an HTB class to shape traffic
transmitted to the internal network.

[ Ignoring IMQ for a minute ] This rule still holds:

  "You can only shape what you transmit."

Your firewall will transmit outbound traffic on wan0 (Internet-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 outbound
traffic.

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!

 : Also, even with IMQ you cannot face situations such as flooding. If
 : that happens with incoming traffic then the imq is useless. Is that
 : correct?

I'm not sure what you mean here.

 : What would be other ways(other than imq) to shape incoming traffic on
 : eth0?

Did I answer this question above, or is this a different question?

 : (I am planning to take a look at tcng)

Traffic Control Next Generation is an excellent and uniform abstraction
layer (language) for describing traffic control structures.  Keep in mind
that you still need to understand the structures, elements and rules of
linux traffic control.  The tcng tool doesn't free you from the rules--it
frees you from the pile of hexadecimal numbers and arcane syntax.  What
tcng allows is a less arcane and less confusing way to describe traffic
control.

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/