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@xxxxxxxxxxxxxx