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

[Raghuveer <raghuveer-rc@naturesoft.net>]

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


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