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