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@xxxxxxxxxxxxxxx [mailto:lartc-admin@xxxxxxxxxxxxxxx]On Behalf Of Stephan M. Ott Sent: Saturday, July 10, 2004 5:03 PM To: lartc@xxxxxxxxxxxxxxx Subject: 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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
