Hi folks,
I read the fantastic LARTC How-to and after that i tried to limit one
host in my LAN for both down-and upload bandwidth usage.
I took section 15.9. and added uplink-limiting as I understood it from
the previous chapters.
Unfortunately it doesn''t work.
I ran the script and went to the specified PC, started a download, and
watched the rate. The rate was always about 2000 kbit/s, though I
defined (well, at least I thought so) 768 kbit/s as maximum rate.
Can anyone please look at the script and tell me, what must be corrected
in order for it to work ?
Thanks in advance.
This is the script:
#!/bin/bash
LIMITDOWN=768
LIMITUP=96
DEV=ppp0
# clean up qdiscs
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
# limit up- and downlink for benni
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 2mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${LIMITDOWN}kbit
allot 1500 prio 5 bounded isolated
tc class add dev $DEV parent 1: classid 1:2 cbq rate ${LIMITUP}kbit
allot 1500 prio 5 avpkt 1000
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst
192.168.0.51 flowid 1:1
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src
192.168.0.51 flowid 1:2
#tc qdisc add dev $DEV parent 1:1 sqf perturb 10
#tc qdisc add dev $DEV parent 1:2 sqf perturb 10
I commented out the last 2 lines for testing so that the rate is always
limited.
Any ideas ?
Thanks.
Stephan
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
"Stephan M. Ott" wrote:> tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst > 192.168.0.51 flowid 1:1 > tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src > 192.168.0.51 flowid 1:2Wild guess: You are trying to match a masqueraded IP address. On your external interface, 192.168.blah just is not very damn likely to exist. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I also sent this to Stephan, hopefully I''m not too far offbase :-)
A.
------------
1) It''s sfq not sqf, you should be getting errors when your two lines
are
not commented out
2) Your statement that commenting these lines out "so that rate is always
limited" makes no sense. Adding the sfq''s does not affect whether
or not
rate is limited, it only changes how packets belonging to the classes to
which the sfq''s are attached are ordered/scheduled.
3) Why use cbq at all? htb gives more reliable results and is easier to
correctly configure.
4) You cannot shape downlink packets the way you are trying to do it. You
must use an IMQ device, and to do that you probably have to patch your
kernel and/or iptables/tc (google IMQ).
Regarding why you gor 2Mbit: Perhaps your filters simply did not hit. Were
you sending to/from .51? What did tc show tell you about the number of
packets assigned to each class?
Regarding downlink shaping: The word "shaping" vs
"policing" or "limiting"
implies that you are going to queue up out-of-rate packets so that you can
resend them a bit later in order to "flatten out" the usage. Policing
and
limiting imply that anything out-of-rate just gets dropped/clipped.
When you are talking about downlink packets, remember that you are at the
far end of a link through which the packets have already been sent.
What''s
the point of queueing them in order to "shape" the arrival profile,
unless
you are going to forward them further to another box??? If they are meant
for this box, then they''ve already "used" the link.
They''ve already
"arrived" at their destination. No point in "shaping" them.
On the other
hand, if you are going to send them further (forward/route/bridge) then you
are really shaping the OUTBOUND traffic on the given ethernet port, not the
inbound traffic on the inbound port.
That''s why shaping is only relevant "on the way out". If
what you want to
do is forcibly limit downlink speed, it is more appropriate to call that
"policing"--i.e., dropping packets on the floor which fall outside
your rate
parameters. Now think about this: If you just drop those packets, which
have already "used" the link, will you benefit down the road?
First, it should be obvious that ignoring incoming packets makes no sense
unless you are trying to limit to some rate below the actual link speed
rate. But secondly, you should also be thinking "hmm, the packet already
used the link, if I ignore it what''s the point?"
Well, it turns out that if you ignore TCP packets, the TCP implementation on
the sender should back-off and transmit more slowly--it will "train"
to your
policed speed. However, if you drop UDP packets, UDP has no such concept.
Who knows what the application sending UDP will do. Most likely it will
just keep sending at the same rate. Worse, it might try to resend them. So
you''re just making your life worse. When limiting downstream, drop
only TCP
packets. Look around, and you''ll find sample scripts that use IMQ etc.
and
set up downstream rate limiting that keep ACK/SYN-ACK/etc. packets flowing.
A.
-----Original Message-----
From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On
Behalf Of Stephan M. Ott
Sent: Saturday, July 10, 2004 5:03 PM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] limiting doesn''t work
Hi folks,
I read the fantastic LARTC How-to and after that i tried to limit one
host in my LAN for both down-and upload bandwidth usage.
I took section 15.9. and added uplink-limiting as I understood it from
the previous chapters.
Unfortunately it doesn''t work.
I ran the script and went to the specified PC, started a download, and
watched the rate. The rate was always about 2000 kbit/s, though I
defined (well, at least I thought so) 768 kbit/s as maximum rate.
Can anyone please look at the script and tell me, what must be corrected
in order for it to work ?
Thanks in advance.
This is the script:
#!/bin/bash
LIMITDOWN=768
LIMITUP=96
DEV=ppp0
# clean up qdiscs
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
# limit up- and downlink for benni
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 2mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${LIMITDOWN}kbit
allot 1500 prio 5 bounded isolated
tc class add dev $DEV parent 1: classid 1:2 cbq rate ${LIMITUP}kbit
allot 1500 prio 5 avpkt 1000
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst
192.168.0.51 flowid 1:1
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src
192.168.0.51 flowid 1:2
#tc qdisc add dev $DEV parent 1:1 sqf perturb 10
#tc qdisc add dev $DEV parent 1:2 sqf perturb 10
I commented out the last 2 lines for testing so that the rate is always
limited.
Any ideas ?
Thanks.
Stephan
_______________________________________________
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/
Hi Andrew (and hi to all others on the list). ### 1) It''s sfq not sqf, you should be getting errors when your two lines are not commented out Of course you''re right. I did not uncomment them by now. But thanks for the hint anyway. Saves me a little time when I activate it. ### 2) Your statement that commenting these lines out "so that rate is always limited" makes no sense. Adding the sfq''s does not affect whether or not rate is limited, it only changes how packets belonging to the classes to which the sfq''s are attached are ordered/scheduled. Hmm, as far as I understood it, these lines allow the limited host to take unused bandwidth even if over the limit. Did I get this wrong ? ### 3) Why use cbq at all? htb gives more reliable results and is easier to correctly configure. Well, would take too long to explain it completely. To be short, I have no other choice as cbq. I cannot use htb unfortunately. ### 4) You cannot shape downlink packets the way you are trying to do it. You must use an IMQ device, and to do that you probably have to patch your kernel and/or iptables/tc (google IMQ). Hmm, sounds logical. I just started with all this and when I saw this short piece of script in the How-to I thought "well, give it a try. Maybe this will do the trick". In the How-to one can read: --- 15.9. Rate limiting a single host or netmask Although this is described in stupendous details elsewhere and in our manpages, this question gets asked a lot and happily there is a simple answer that does not need full comprehension of traffic control. This three line script does the trick: tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit tc class add dev $DEV parent 1: classid 1:1 cbq rate 512kbit \ allot 1500 prio 5 bounded isolated tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \ match ip dst 195.96.96.97 flowid 1:1 --- Did I miss something ? ### Regarding why you gor 2Mbit: Perhaps your filters simply did not hit. Were you sending to/from .51? What did tc show tell you about the number of packets assigned to each class? Now it starts getting myterious for me. My complete downlink bandwidth is 2mbit, that''s why I defined it. (I have ADSL-connection which is called "DSL 2000" here in germany.) Yes, I was sending from and to client .51. I physically went to this computer *g* and checked everything from there. So my tests really took place at .51. But the filters really didn''t hit... Here''s what tc show tells me: linux-gw:~ # tc -s class show dev ppp0 class cbq 1: root rate 2Mbit (bounded,isolated) prio no-transmit Sent 706511167 bytes 1396938 pkts (dropped 117, overlimits 0) borrowed 0 overactions 0 avgidle 3027 undertime 0 class cbq 1:1 parent 1: rate 768Kbit (bounded,isolated) prio 5 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 0 undertime 0 class cbq 1:2 parent 1: rate 96Kbit prio 5 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 0 undertime 0 What did I do wrong ? As far as I understand it, I should have specified the client .51 correctly. But why is no single packet hitting the filters ? ### Regarding downlink shaping: The word "shaping" vs "policing" or "limiting" implies that you are going to queue up out-of-rate packets so that you can resend them a bit later in order to "flatten out" the usage. Policing and limiting imply that anything out-of-rate just gets dropped/clipped. When you are talking about downlink packets, remember that you are at the far end of a link through which the packets have already been sent. What''s the point of queueing them in order to "shape" the arrival profile, unless you are going to forward them further to another box??? If they are meant for this box, then they''ve already "used" the link. They''ve already "arrived" at their destination. No point in "shaping" them. On the other hand, if you are going to send them further (forward/route/bridge) then you are really shaping the OUTBOUND traffic on the given ethernet port, not the inbound traffic on the inbound port. That''s why shaping is only relevant "on the way out". If what you want to do is forcibly limit downlink speed, it is more appropriate to call that "policing"--i.e., dropping packets on the floor which fall outside your rate parameters. Now think about this: If you just drop those packets, which have already "used" the link, will you benefit down the road? First, it should be obvious that ignoring incoming packets makes no sense unless you are trying to limit to some rate below the actual link speed rate. But secondly, you should also be thinking "hmm, the packet already used the link, if I ignore it what''s the point?" Well, it turns out that if you ignore TCP packets, the TCP implementation on the sender should back-off and transmit more slowly--it will "train" to your policed speed. However, if you drop UDP packets, UDP has no such concept. Who knows what the application sending UDP will do. Most likely it will just keep sending at the same rate. Worse, it might try to resend them. So you''re just making your life worse. When limiting downstream, drop only TCP packets. Look around, and you''ll find sample scripts that use IMQ etc. and set up downstream rate limiting that keep ACK/SYN-ACK/etc. packets flowing. Okay, I think I got what you tell me. Of course I just can limit tcp packets. And that''s all I want to do. Obviously I misunderstood what the How-to wants to say. I read it the way that these few lines will DO limiting and will drop packets coming in out of the limit and thereby "train" the netflow. Can you give me some hint where I should take a look for scripts doing well ? On the other hand... limiting upstream also does not work. Tc show tells that no packet hits the filter. And limiting the upstream should work, because I catch these packets before they reach the internet. What goes wrong here ? As you can see, I''m a newbie to all of this. I''m interested in improving the network and LARTC sounds great. But it seems as if I get wrecked even at the start :-( Thanks in advance for your assistance. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/