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