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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
