Hi Martin, Thanks for such a clear explanation. Now if I take scenario where I use IMQ with HTB for shaping outgoing and incomming traffic both, will it be as follows...? Outgoing:-- LAN interface------------->NATwith <--set-mark>option(wan)--------->IMQ+HTB(wan)---------->Internet Incomming:-- Internet------------->NAT(wan)----------->IMQ+HTB(wan)--------------->LAN Interface Just for my knowledge, can I use CBQ instead of HTB for the same scenario....? Regards -Raghu Martin A. Brown wrote: >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 > > >
