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

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

Raghuveer,

 : "It's very important to understand that you can only shape outgoing
 : traffic".

Be careful with terminology.  Stef is absolutely correct above*.

It is true that you can only "shape"  outgoing traffic.  Please don't
confuse shaping with other types of traffic control mechanisms, such as
scheduling, policing or filtering.  Shaping can only be done on the
traffic you transmit.  You can't delay a packet that is arriving on your
device.  It's already there!

 : So is it not possible to shape the incomming traffic at all...? I
 : already got some useful links and suggestion from Martin for ingress
 : mode.

Yes, the link I sent [1] was a link to IMQ [2]...you can shape incoming
traffic by using IMQ.  IMQ simulates a real device, so that you can apply
mechanisms which perform shaping (an HTB class inside an HTB qdisc, for
example) on that IMQ device.  Now you push your incoming traffic through
that device, and you are transmitting (even if only virtually) that
traffic, allowing you to shape.

I also suggested that you could use policing to limit the amount of
bandwidth that you accept.  This isn't at all like shaping.

  shaping:   delaying packets to meet a certain average rate
  policing:  applying an action (frequently dropping the packet) to any
             packet which exceeds a rate

Policing is not as elegant as shaping, and (in my experience) offers less
granularity of control.  It is also not as easy to use under linux as is
shaping.  I welcome contradictory opinions and superior expertise.

 : Can you pls suggest how to do incomming traffic control, if the
 : incomming traffic hitting the firewall at WAN interface eth0 with LAN
 : interface at eth1. I would like to do traffic control based on LAN IP's
 : and protocols like HTTP, FTP, SMTP, POP etc, for incomming traffic
 : only. Meanwhile Iam going through the links send by Martin.

Let's try this with a little diagram:

            +---------------+
 Internet --| wan0     eth0 |-- private network
            +---------------+
       qdisc here       qdisc here
       will shape       will shape
     traffic sent       traffic sent
      to Internet       from Internet


So, shape your "upload" traffic on wan0 (ACKs, maybe the packets with a
TCP source port of 25 from your internal mailserver).

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.

Once again, I would like to recommend tcng [3].  If you are not yet
familiar with the linux traffic control subsystem, you may (will) find
tcng considerably more approachable than the raw tc commands.  I have
written a crash course in using tcng with HTB [4], which should provide
you enough detail to get started with tcng.

Best of luck,

-Martin

* ...although clever people have found a way around this rule, by creating
  a device which allows us to simulate packet transmission on inbound
  traffic.  See my note on IMQ above.

  [1]  http://mailman.ds9a.nl/pipermail/lartc/2003q3/009616.html
  [2]  http://trash.net/~kaber/imq/
  [3]  http://tcng.sourceforge.net/
  [4]  http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/

-- 
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/