[LARTC] How to limit a dev bandwidth.

[LARTC] How to limit a dev bandwidth.

[anzp]

The device is 100M.
How to limit it to 1M?



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

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

[Stef Coene]

On Friday 08 August 2003 08:59, anzp wrote:
> The device is 100M.
> How to limit it to 1M?
lartc.org
docum.org

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

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

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

[Martin A. Brown]

Hello there,

 : The device is 100M.
 : How to limit it to 1M?

Maybe you wish to use IMQ? [1]

Are you trying to simulate a 1MBit link?

If not IMQ, is this a router, or an endstation?

If a router, using HTB:

  tc qdisc add dev $OUTSIDE root handle 1: htb default 1
  tc class add dev $OUTSIDE parent 1: classid 1:1 htb rate 1Mbit

  tc qdisc add dev $INSIDE  root handle 1: htb default 1
  tc class add dev $INSIDE  parent 1: classid 1:1 htb rate 1Mbit


If an endstation, using HTB and policing:

  tc qdisc add dev $OUTSIDE ingress
  tc filter add dev $OUTSIDE parent ffff: protocol ip \
    u32 match ip src 0.0.0.0/0 flowid :1              \
    police rate 1Mbit mtu 12k burst 10k drop

  tc qdisc add dev $OUTSIDE handle 1: htb default 1
  tc class add dev $OUTSIDE parent 1: classid 1:1 htb rate 1Mbit

-Martin

  [1] http://trash.net/~kaber/imq/

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

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

[Raghuveer]

Hi Stef,

You have mentioned in "
http://www.docum.org/stef.coene/qos/docs/BB/BB.html" that "It's very
important to understand that you can only shape outgoing traffic". 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. 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.

Regards
-Raghu



Stef Coene wrote:

>On Friday 08 August 2003 08:59, anzp wrote:
>  
>
>>The device is 100M.
>>How to limit it to 1M?
>>    
>>
>lartc.org
>docum.org
>
>Stef
>
>  
>


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

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

[Martin A. Brown]

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/

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

[Madhuri Patwardhan]

Hi Martin,

You have explained it so well that it is very clear now.
I am trying to do something similar on our linux firewall machines
which connect to the internet.

I have few questions regarding this.

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

Here one could use plain htb qdisc (without imq) to shape the outgoing
(upload) traffic.

> 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. Because it is not really possible to schedule
the incoming traffic without simulating it as being transmitted from IMQ
device.  It will not be possible to use just plain htb qdisc without ImQ
to shape incoming traffic, is that correct?

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?

What would be other ways(other than imq) to shape incoming traffic on
eth0?
(I am planning to take a look at tcng)

Thanks a lot.


Madhuri


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

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

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

[Martin A. Brown]

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

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

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

[Madhuri Patwardhan]

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

















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

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

[Raghuveer]

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/