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.