Re: [LARTC] HTB does not respect the prio parameter
Is quantum not perhaps a bit high? Try setting it lower, and see what happens? -justin On 2007-08-29 08:06, Martin Björnsson wrote: Hi all, I'm experimenting with HTB and the prio parameter and it does not give me results I expect. I've created 4 HTB classes: 1:10 TCP ACKs (prio 0) 1:20 TCP traffic on dst port 10001 (prio 1) 1:30 TCP traffic on dst port 1 (prio 2) 1:40 Default(prio 3) ceil and rate parameters are the same for all 4 classes (rate is 1000kbit and ceil is 55000kbit). Then I start 2 TCP flows on src/dst ports 1 and 10001. The packets seem to be correctly classified by the filter (I get hits on classes 10, 20 and 30). The problem is that I get the same throughput on both TCP flows. Shouldn't I get about 1000kbit through class 30 and much more through class 20 since it has higher priority? Here's my setup script: #!/bin/sh /bin/tc qdisc add dev eth0 root handle 1: htb default 40 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Traffic shaping questions and possible extensions
Hi, It has been quite a while since I looked at what was happening in Linux traffic shaping, so I am not sure if this has been discussed / improved on since I last looked. We use a traffic shaper based on HTB. The basic principals work fine, but we have a problem with 'intermittent trafic' like http and interactive ssh sessions. Each of these categories of traffic have their own class, and are allocated a certain 'guaranteed' rate. However, if other traffic is bursting into this bandwidth, we see that very often it takes so long for the other traffic to throttel back that the effective QoS is very bad. If we hard cap the other traffic to leave the guarantee open, then web and ssh access is very very good. So the problem seems to lie with getting other traffic to slow down quicker. Are there any current solutions/suggestions to working around this? If not, I have one possible solution, and I would appreciate any feedback on it: At the moment, if traffic cannot be sent immediately (there is no bandwidth available for it), then it is first queued, and if the queue gets too long, packets are dropped. This will slow down the sender, but relies on the expiry of TCP timers to acheive this. What I was thinking was that for bulk traffic that needs (and can tolerate aggresive throtling), instead of queueing the packet, keep a history of the last ACK packet sent, and resend it. The receiver will see this as a duplicate ack, and immediately enter a congestion avoidance algorithm, throtling the data. Is this feasible, or is it a Really Stupid Idea (TM)? Thanks! Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Ethernet packet loss - frame errors
OK - Just finished more testing, and it seems to be a bug in the sky2 driver... ping -s 1450 -f xxx.xxx.xxx.xxx works perfectly, but ping -s 1500 -f xxx.xxx.xxx.xxx fails 100% with all packets being logged as frame errors. -justin Justin Schoeman wrote: Hi all, I have the following problem. A Linux box configured as a bridge. One interface connects to the router via a crossover cable, the other connects to a switch via the cable that used to go to the router. Now I get the following: [EMAIL PROTECTED] net]# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 00:03:2D:07:61:5D UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1969134 errors:0 dropped:0 overruns:0 frame:176459 TX packets:2186662 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:492595115 (469.7 Mb) TX bytes:579725462 (552.8 Mb) Interrupt:17 eth3 is the interface that connects to the switch. As you can see, 1 in 10 rx packets are framing errors. What are possible causes for this? The cable is a constant, so is not likely to cause problems, so what else can possibly cause such a high number of frame errors? Any help appreciated. Thanks, Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Ethernet packet loss - frame errors
Stephen Hemminger wrote: On Fri, 13 Oct 2006 10:26:14 +0200 Justin Schoeman <[EMAIL PROTECTED]> wrote: Hi all, I have the following problem. A Linux box configured as a bridge. One interface connects to the router via a crossover cable, the other connects to a switch via the cable that used to go to the router. Now I get the following: [EMAIL PROTECTED] net]# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 00:03:2D:07:61:5D UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1969134 errors:0 dropped:0 overruns:0 frame:176459 TX packets:2186662 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:492595115 (469.7 Mb) TX bytes:579725462 (552.8 Mb) Interrupt:17 eth3 is the interface that connects to the switch. As you can see, 1 in 10 rx packets are framing errors. What are possible causes for this? The cable is a constant, so is not likely to cause problems, so what else can possibly cause such a high number of frame errors? Any help appreciated. Thanks, Justin What speed and driver? sky 2 driver, hardcoded for 100Mbps full duplex. -justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Ethernet packet loss - frame errors
Andrei Sandu wrote: Possibly the length of the cable ? It is a 5m cable. It is also the 'common' cable - it is unplugged from the router and plugged into the bridge (the other side stays in the switch). -justin On 10/13/06, *Justin Schoeman* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Hi all, I have the following problem. A Linux box configured as a bridge. One interface connects to the router via a crossover cable, the other connects to a switch via the cable that used to go to the router. Now I get the following: [EMAIL PROTECTED] net]# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 00:03:2D:07:61:5D UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1969134 errors:0 dropped:0 overruns:0 frame:176459 TX packets:2186662 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:492595115 ( 469.7 Mb) TX bytes:579725462 (552.8 Mb) Interrupt:17 eth3 is the interface that connects to the switch. As you can see, 1 in 10 rx packets are framing errors. What are possible causes for this? The cable is a constant, so is not likely to cause problems, so what else can possibly cause such a high number of frame errors? Any help appreciated. Thanks, Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl <mailto:LARTC@mailman.ds9a.nl> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Ethernet packet loss - frame errors
Hi all, I have the following problem. A Linux box configured as a bridge. One interface connects to the router via a crossover cable, the other connects to a switch via the cable that used to go to the router. Now I get the following: [EMAIL PROTECTED] net]# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 00:03:2D:07:61:5D UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1969134 errors:0 dropped:0 overruns:0 frame:176459 TX packets:2186662 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:492595115 (469.7 Mb) TX bytes:579725462 (552.8 Mb) Interrupt:17 eth3 is the interface that connects to the switch. As you can see, 1 in 10 rx packets are framing errors. What are possible causes for this? The cable is a constant, so is not likely to cause problems, so what else can possibly cause such a high number of frame errors? Any help appreciated. Thanks, Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] netfilter patch-o-matic: where did all the patches go?
Hi all, I haven't been paying attention to this for a while, but now that I download the latest patch-o-matic-ng, I see that most of the patches are gone... Anybody have an idea where I can download the 'extras' repository? Specifically geoip. Thanks! -justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Netfilter/Iptables does not NAT all packets?
Hi all, I am having a small problem with netfilter on Linux kernel 2.6.11.4. It seems not all packets are hitting the pre-routing chain. In pre-routing, I have the following rules: $IPTABLES -t nat -A PREROUTING -i $IF_OUT -d 10.50.18.22 -j DNAT --to-destination 192.168.1.22 $IPTABLES -t nat -A PREROUTING -i $IF_OUT -d ! 10.50.18.21 -m limit --limit 5/second -j LOG --log-prefix "non-nat input: " As you can see all packets arriving for 10.50.18.22 should be natted to 192.168.1.22, and anything else should be logged. If I look at the rule stats, there are no matches on the log rule, so in theory, all packets are DNAT'ed? However, when looking at the logs for the filter:INPUT chain, I see packets destined for 10.50.18.22 are being logged and dropped. So somehow, these packets made it through the nat:PREROUTING chain WITHOUT being natted. Any ideas? It also seems like some response packets (only seen ack and fin-ack packets so far) are not being successfully connection tracked. Could this be part of the problem? Any help/info appreciated. Thanks, Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Hmmm... Weird results with HTB in kernel 2.6.11
Hi all, I have been getting some strange results with HTB in kernel 2.6.11, and was wondering if anybody could give me some advice. Also, if someone could direct me to the changelog for the recent versions so I can see if it is worth upgrading? Anyway, the problem can best be summed up by looking at the output of 'tc -s -d class show dev eth0'. Some of the relevant results are: class htb 1:1 root rate 1686Kbit ceil 1686Kbit burst 1809b/8 mpu 0b overhead 0b cburst 1809b/8 mpu 0b overhead 0b level 7 Sent 1964319339 bytes 2514673 pkt (dropped 0, overlimits 0 requeues 0) rate 1694Kbit 244pps backlog 0b 0p requeues 0 lended: 1257439 borrowed: 0 giants: 0 tokens: -29826 ctokens: -29826 class htb 1:8 parent 1:1 rate 32000bit ceil 1686Kbit burst 1603b/8 mpu 0b overhe ad 0b cburst 1809b/8 mpu 0b overhead 0b level 6 Sent 27361971 bytes 52043 pkt (dropped 0, overlimits 0 requeues 0) rate 32704bit 6pps backlog 0b 0p requeues 0 lended: 16076 borrowed: 2007 giants: 0 tokens: -1796566 ctokens: 16310 class htb 1:39 parent 1:1 rate 8000bit ceil 1686Kbit burst 1600b/8 mpu 0b overhe ad 0b cburst 1809b/8 mpu 0b overhead 0b level 6 Sent 258423850 bytes 281091 pkt (dropped 0, overlimits 0 requeues 0) rate 132152bit 19pps backlog 0b 0p requeues 0 lended: 5241 borrowed: 270604 giants: 0 tokens: -1073545 ctokens: 1525 As you can see, the parent class is pretty much maxxed out, which is fine, but two of the child classes are not OK... 1:8 with a target rate of 32kbit is getting 32kbit, while 1:39 with a target rate of 8kbit is getting 132kbit! Looking at the states, this seems to be the normal state while the link is saturated. Can anybody see something obvious wrong (perhaps an underflow, or something?), or is more info needed? If so, what info? Thanks! Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb: HowTo identify squid cache hits
I haven't tried this myself, but I see l7filter (l7-filter.sf.net) has patterns for matching cache hits and misses... This may just work for your application? -justin Peter Kaagman wrote: Hi list... I work for a school in the netherlands with a 2mbit Internet uplink and about 3800 eager student who want to play games on the Internet using one of our 800 workstations. Problem was that those game playing students are concentrated in 2 of our 6 physical locations... and they consumed the bandwidth which the other location would like to use for educational purposes. The thing we did first was use squid... with success. The hit ratio on data transfer is 25-30%... "free" bandwidth. Today I took the plunge and started to use HTB traffic shaping... and (to my surprise) I got it going without much troubles. The setup I have chosen first divides the load over two classes: - one for Internet rate 2mbit and a 2mbit ceil - a second for our DMZ rate 98mbit and a 100mbit ceil Next I sub-classed the Internet bucket into 6 classes each with a 333kbit rate and a 2mbit ceil. This has had the effect that my DMZ can be accessed at full speed while they fairly share the Internet uplink. And the way it looks now it works :D Hail to all those people who wrote those fine docs _o_ This is enough reason to address this list... just to say "Thank you!", but there is more. At the moment I do not max out my Internet link... reason for this is I guess the squid proxy... The way it works now is that I have 2 types of filters in effect: - The DMZ: all packages with a src ip from my DMZ go to the big 98/100 bucket. - The Internet: all packages with a dst ip in one of our 6 networks gets placed in one of the 6 333/2000 buckets. But there is of course a src of packages I do not catch this way... and these are the squid cache hits. Because I filter on destination the cache hits get treated the same as cache misses. But cache hits are in effect local traffic... they do not originate from the Internet. So here (finally) the question.. Is there a way to identify cache hits from misses? I took a look at the advanced filtering chapter of course, but am really dazzled by that (and I thought I understood TCP/IP a bit ;)). Some further info that would perhaps help is that squid is run as a transparant proxy on the router/firewall. regards Peter Kaagman ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IP2P & Skype question
I don't think Skype works very well with any of these. I have tried the l7-filter pattern, with no luck. Apparently, the big problem is that Skype traffic is encrypted, and so it is not possible to match it using fixed patterns. In some cases, it is possible to block Skype, as the existing pattern seems to match an important, but not yet encrypted packet. Shaping is however not possible, as the matched packet makes up very little of the traffic. -justin Andreas Klauer wrote: On Monday 25 April 2005 15:08, Gary Smith wrote: I need to detect Skype traffic using (I think it can be done) IP2P. What's IP2P? I only know IPP2P, and I can't find anything about Skype on the official homepage (www.ipp2p.org). It's only for P2P filesharing networks. Maybe you could test Skype support of l7-filter and give the authors some feedback (http://l7-filter.sourceforge.net/protocols lists Skype as supported, but untested). HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] GeoIP?
Hi all, does anybody know what happened to GeoIP (www.geoip.net)? It seems I just get an empty page if I try go to the site now... Thanks, Justin ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ESFQ?
Thanks - really appreciate the help!
-justin
Andy Furniss wrote:
Justin Schoeman wrote:
Woohoo - that would be great!
-justin
Andy Furniss wrote:
Justin Schoeman wrote:
Ouch... Is there any other way to do host-based fair sharing (well,
other than actually classifying each host :-( )?
I don't think it will take much to get it to work - though I haven't
tried :-) .
I'll have a look at doing a 2.6.10 in the next few days.
Well I gave it a go (first patches I've made) and they work for me
though Thomas or Stephen may notice something :-) .
Hopefully they won't be needed in the future if Thomas gets esfq in
mainline.
They are based on Alexander Clouters patches at www.digriz.org.uk. I
only used the first iproute one.
I was hampered a bit because kernel.org have turned off the diff viewer.
The remove db iproute patch is from LFS, you may not need it if you have
Berkley DB installed ( search for db_185.h ).
If you don't have it *and* you don't use arpd then use the patch, it
just removes arpd from the build.
Andy.
diff -urN iproute2-2.6.9.orig/include/linux/pkt_sched.h iproute2-2.6.9/include/linux/pkt_sched.h
--- iproute2-2.6.9.orig/include/linux/pkt_sched.h 2004-10-19 21:49:02.0 +0100
+++ iproute2-2.6.9/include/linux/pkt_sched.h 2005-01-11 11:46:45.395401296 +
@@ -126,6 +126,13 @@
/* SFQ section */
+enum
+{
+ TCA_SFQ_HASH_CLASSIC,
+ TCA_SFQ_HASH_DST,
+ TCA_SFQ_HASH_SRC,
+};
+
struct tc_sfq_qopt
{
unsigned quantum; /* Bytes per round allocated to flow */
@@ -133,6 +140,7 @@
__u32 limit; /* Maximal packets in queue */
unsigned divisor; /* Hash divisor */
unsigned flows; /* Maximal number of flows */
+ unsigned hash_kind; /* Hash function to use for flow identification */
};
/*
@@ -142,6 +150,8 @@
*
* The only reason for this is efficiency, it is possible
* to change these parameters in compile time.
+ *
+ * If you need to play with this values use esfq
*/
/* RED section */
diff -urN iproute2-2.6.9.orig/tc/Makefile iproute2-2.6.9/tc/Makefile
--- iproute2-2.6.9.orig/tc/Makefile 2004-10-19 21:49:02.0 +0100
+++ iproute2-2.6.9/tc/Makefile 2005-01-11 11:46:45.396401144 +
@@ -6,6 +6,7 @@
TCMODULES :=
TCMODULES += q_fifo.o
TCMODULES += q_sfq.o
+TCMODULES += q_esfq.o
TCMODULES += q_red.o
TCMODULES += q_prio.o
TCMODULES += q_tbf.o
diff -urN iproute2-2.6.9.orig/tc/q_esfq.c iproute2-2.6.9/tc/q_esfq.c
--- iproute2-2.6.9.orig/tc/q_esfq.c 1970-01-01 01:00:00.0 +0100
+++ iproute2-2.6.9/tc/q_esfq.c 2005-01-11 11:47:29.424707824 +
@@ -0,0 +1,168 @@
+/*
+ * q_esfq.c ESFQ.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Alexey Kuznetsov, <[EMAIL PROTECTED]>
+ *
+ * Changes: Alexander Atanasov, <[EMAIL PROTECTED]>
+ * Added depth,limit,divisor,hash_kind options.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "utils.h"
+#include "tc_util.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]\n\t[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]\n");
+ fprintf(stderr,"Where: \n");
+ fprintf(stderr,"HASHTYPE := { classic | src | dst }\n");
+}
+
+#define usage() return(-1)
+
+static int esfq_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nlmsghdr *n)
+{
+ int ok=0;
+ struct tc_sfq_qopt opt;
+
+ memset(&opt, 0, sizeof(opt));
+
+ opt.hash_kind= TCA_SFQ_HASH_CLASSIC;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "quantum") == 0) {
+ NEXT_ARG();
+ if (get_size(&opt.quantum, *argv)) {
+fprintf(stderr, "Illegal \"quantum\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "perturb") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.perturb_period, *argv, 0)) {
+fprintf(stderr, "Illegal \"perturb\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "depth") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.flows, *argv, 0)) {
+fprintf(stderr, "Illegal \"depth\"\n");
+return -1;
+ }
+ ok++;
+ } else if (strcmp(*argv, "divisor") == 0) {
+ NEXT_ARG();
+ if (get_integer(&opt.divisor, *argv, 0)) {
+fprintf(stderr, "Illegal \"divisor\"\n");
+return -1;
+ }
+ if(opt.divisor >= 15) {
+fprintf(stderr, "Illegal \"divisor\" must be < 15\n");
+return -1;
+ }
+ opt.divisor=pow(2,opt.divisor);
+ ok++;
+ } else if (strcmp(*argv, "limit") == 0) {
+
Re: [LARTC] ESFQ?
Woohoo - that would be great! -justin Andy Furniss wrote: Justin Schoeman wrote: Ouch... Is there any other way to do host-based fair sharing (well, other than actually classifying each host :-( )? I don't think it will take much to get it to work - though I haven't tried :-) . I'll have a look at doing a 2.6.10 in the next few days. Andy. ___ 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/
Re: [LARTC] ESFQ?
Ouch... Is there any other way to do host-based fair sharing (well, other than actually classifying each host :-( )? Thanks, -justin Jonathan Day wrote: To the best of my knowledge, ESFQ for Linux is essentially dead. There's a patchset - QNet - which does port ESFQ to the 2.6.8/2.6.9 kernels, but ESFQ is not split out, so it looks like an all-or-nothing deal. http://kem.p.lodz.pl/~peter/qnet/ I don't know if QNet is still being maintained - the last update on the page refers to October 2004 - and there's nothing to indicate how well the forward ports actually work in practice. A search using Google shows only older ESFQ versions (one for 2.6.0-test11, for example) but nothing newer. There was one posting about ESFQ to the kernel developers mailing list, but I couldn't see any follow-ups to it. Nor does it appear to be in Andrew Morton's patchset (an excellent indicator of interest level and the probability of ending up in the official kernel). Unfortunately, this seems to be fairly common in Linux QoS - too many one-man projects and too few resources too keep them going. --- Justin Schoeman <[EMAIL PROTECTED]> wrote: Hi again, I was just looking around for ESFQ sources, and I see that the main site is down, and only has kernel 2.6.4 patches. Is ESFQ maintained? If so, where can I find patches for 2.6.10? Thanks, -justin ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ESFQ?
Hi again, I was just looking around for ESFQ sources, and I see that the main site is down, and only has kernel 2.6.4 patches. Is ESFQ maintained? If so, where can I find patches for 2.6.10? Thanks, -justin ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Interesting oopses...
OK - this is starting to get frustrating... Are there any known issues
with 2.6.9 and traffic shaping? I am using 2.6.9 with geoip 20041115,
and get odd oopses. The following script oopses my box:
-
#!/bin/sh -x
IFOUT='eth1'
IFIN='eth0'
TC='/sbin/tc'
IPT='/usr/local/sbin/iptables'
# BW definitions:
# units of kbit/s
NETBW=1
OUTBW=116
INBW=116
# Clear old shapers...
echo "Clearing old shapers..."
$TC qdisc del dev $IFIN root 2> /dev/null > /dev/null
$TC qdisc del dev $IFOUT root 2> /dev/null > /dev/null
# Clear old iptables...
echo "Clearing old iptables..."
$IPT -t mangle -F POSTROUTING
$IPT -t mangle -F NATI
$IPT -t mangle -X NATI
$IPT -t mangle -N NATI
$IPT -t mangle -F INAT
$IPT -t mangle -X INAT
$IPT -t mangle -N INAT
# Match local traffic
$IPT -t mangle -A POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -j CLASSIFY
--set-class 1:1
$IPT -t mangle -A POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT
# Classify local / international traffic
$IPT -t mangle -A POSTROUTING -s 10.0.0.0/8 -m geoip --dst-cc ZA -j NATI
$IPT -t mangle -A POSTROUTING -s 196.23.147.49/32 -m geoip --dst-cc ZA
-j NATI
$IPT -t mangle -A POSTROUTING -d 10.0.0.0/8 -m geoip --src-cc ZA -j NATI
$IPT -t mangle -A POSTROUTING -d 196.23.147.49/32 -m geoip --src-cc ZA
-j NATI
$IPT -t mangle -A POSTROUTING -j INAT
# Rules for international traffic
$IPT -t mangle -A INAT -j CLASSIFY --set-class 20:100
$IPT -t mangle -A INAT -j ACCEPT
# Rules for local traffic
$IPT -t mangle -A NATI -j CLASSIFY --set-class 20:200
$IPT -t mangle -A NATI -j ACCEPT
# Build output rules
$TC qdisc add dev $IFOUT root handle 1: prio bands 2 priomap 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1
$TC qdisc add dev $IFOUT parent 1:1 handle 10: pfifo limit 10
$TC qdisc add dev $IFOUT parent 1:2 handle 20: htb default 100 r2q 1
$TC class add dev $IFOUT parent 20: classid 20:10 htb rate ${OUTBW}kbit
ceil ${OUTBW}kbit prio 0
$TC class add dev $IFOUT parent 20:10 classid 20:100 htb rate 60kbit
ceil 60kbit prio 0
$TC class add dev $IFOUT parent 20:10 classid 20:200 htb rate 56kbit
ceil ${OUTBW}kbit prio 1
$TC qdisc add dev $IFOUT parent 20:100 handle 100: pfifo limit 10
$TC qdisc add dev $IFOUT parent 20:200 handle 200: pfifo limit 10
# Build input rules
$TC qdisc add dev $IFIN root handle 1: prio bands 2 priomap 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1
$TC qdisc add dev $IFIN parent 1:1 handle 10: pfifo limit 10
$TC qdisc add dev $IFIN parent 1:2 handle 20: htb default 100 r2q 1
$TC class add dev $IFIN parent 20: classid 20:10 htb rate ${INBW}kbit
ceil ${INBW}kbit prio 0
$TC class add dev $IFIN parent 20:10 classid 20:100 htb rate 60kbit ceil
60kbit prio 0
$TC class add dev $IFIN parent 20:10 classid 20:200 htb rate 56kbit ceil
${INBW}kbit prio 1
$TC qdisc add dev $IFIN parent 20:100 handle 100: pfifo limit 10
$TC qdisc add dev $IFIN parent 20:200 handle 200: pfifo limit 10
-
The script as-is oopses my box every time. If I changed the initial
classification for local traffic from 1:1 to 10: (an initial
misunderstanding ;-) ), then it does not oops.
If, instead of a prio qdisc, I use a single HTB class for distributing
local and external traffic, then it also works, but after a while, one
of the classes will simply stop sending traffic...
Does anybody have any idea what is going on here?
Thanks,
-justin
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] HTB dropping packets while tokens available?
Hi again,
I just ran into a seriously strange glitch, and was wondering if anybody
had experienced this...
I have an HTB class with an iptables classifier. The iptables
classifier shows packets hitting the rule for this class.
Now, HTB drops these packets ('dropped' increases), even although the
packets are small, and there are over 1 tokens available.
Is there any other reason HTB may decide to discard these packets?
Restarting the classifier script seems to have solved the problem, but I
need to avoid it happening again.
Thanks,
Justin
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Shaping traffic on heavily oversubscribed links?
Thanks everybody for your advice... This is going to be an interesting one to try and solve ;-). -justin Justin Schoeman wrote: Hi all, I am having some fun with traffic shaping, and have run into an interesting situation. Here is South Africa, most internet links are heavily oversubscribed, which means that in most cases the local link is _not_ the bottleneck, and shaping on the local link does not help that much... Does anybody have some tips on shaping such links? How can you get interractive traffic if you don't know how much bandwidth to reserve for it? How can you give fair access to a link if you don't know what the link capacity is? Are there perhaps some tools to monitor retransmissions to try and determine congestion levels, and from that adjust shaped bandwidth? Am I perhaps missing something simple in this scenario? Thanks! -justin ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Shaping traffic on heavily oversubscribed links?
Hi all, I am having some fun with traffic shaping, and have run into an interesting situation. Here is South Africa, most internet links are heavily oversubscribed, which means that in most cases the local link is _not_ the bottleneck, and shaping on the local link does not help that much... Does anybody have some tips on shaping such links? How can you get interractive traffic if you don't know how much bandwidth to reserve for it? How can you give fair access to a link if you don't know what the link capacity is? Are there perhaps some tools to monitor retransmissions to try and determine congestion levels, and from that adjust shaped bandwidth? Am I perhaps missing something simple in this scenario? Thanks! -justin ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Traffic control and logging?
OK - judging by the lack of response, I am assuming this is not possible?
I have started hacking on a simple patch to add support to qdiscs to dup
their traffic to a dummy interface.
Simple test code for the prio qdisc, hardcoded for device id 5 as the
dummy qdisc is attached.
The eventual idea is to add an optional argument 'dupdev' to all qdiscs.
If the qdisc has this argument set, then the packet is duplicated to
that device, if not, nothing is altered.
The only real overhead is one NULL check in each enqueue function, so
this should not really affect performance.
Is it worth while doing up this solution as a proper kernel patch (does
it have any chance of being accepted, or should I just do it
'quick-and-dirty' for my personal use?
Thanks,
Justin
Justin Schoeman wrote:
Hi all, I am new to tc on Linux, and am having some problems. The basic
set-up and use works wonderfully, but now I have run into a slight
problem...
I am using tc qdiscs and filters to do my traffic shaping. Now, I have
a whole bunch of filters to classify the data, and they work well,
however, after all my classifications are done, I still have data
reaching the default flow. ALL of the data should have been classified -
so I would really like to look at the data that is still not classified.
Is there any way to log these packets? Can any of the qdiscs log queued
traffic in a sane way? Can I forward the traffic back to iptables in
some way?
Any help would be greatly appreciated.
Thanks,
Justin
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--- sch_prio.c.old 2004-11-04 04:21:46.0 +0200
+++ sch_prio.c 2004-11-04 03:36:07.0 +0200
@@ -44,6 +44,7 @@
struct tcf_proto *filter_list;
u8 prio2band[TC_PRIO_MAX+1];
struct Qdisc *queues[TCQ_PRIO_BANDS];
+ struct net_device * dup_dev;
};
@@ -99,7 +100,21 @@
prio_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
struct Qdisc *qdisc;
+ struct prio_sched_data *q = qdisc_priv(sch);
int ret = NET_XMIT_SUCCESS;
+
+ if(q->dup_dev) {
+ struct sk_buff * dup_skb = skb_copy(skb, GFP_ATOMIC);
+ if(!dup_skb) {
+ printk(KERN_ERR "Error copying packet.\n");
+ } else {
+ dup_skb->dev = q->dup_dev;
+ if(dev_queue_xmit(dup_skb) < 0) {
+ printk(KERN_ERR "Error queueing duplicate packet on
'%s'.\n", q->dup_dev->name);
+ kfree_skb(dup_skb);
+ }
+ }
+ }
qdisc = prio_classify(skb, sch, &ret);
@@ -210,6 +225,11 @@
for (prio=0; priobands; prio++)
qdisc_destroy(q->queues[prio]);
+
+ if(q->dup_dev) {
+ dev_put(q->dup_dev);
+ q->dup_dev = NULL;
+ }
}
static int prio_tune(struct Qdisc *sch, struct rtattr *opt)
@@ -237,6 +257,13 @@
if (child != &noop_qdisc)
qdisc_destroy(child);
}
+
+ q->dup_dev = dev_get_by_index(5);
+ if(!q->dup_dev) {
+ printk(KERN_WARNING "PRIO: Network device 5 does not seem to
exist?\n");
+ return -EINVAL;
+ }
+ printk(KERN_DEBUG "PRIO: Using device '%s' for dup'ing packets.\n",
q->dup_dev->name);
sch_tree_unlock(sch);
for (i=0; i<=TC_PRIO_MAX; i++) {
[LARTC] Traffic control and logging?
Hi all, I am new to tc on Linux, and am having some problems. The basic set-up and use works wonderfully, but now I have run into a slight problem... I am using tc qdiscs and filters to do my traffic shaping. Now, I have a whole bunch of filters to classify the data, and they work well, however, after all my classifications are done, I still have data reaching the default flow. ALL of the data should have been classified - so I would really like to look at the data that is still not classified. Is there any way to log these packets? Can any of the qdiscs log queued traffic in a sane way? Can I forward the traffic back to iptables in some way? Any help would be greatly appreciated. Thanks, Justin ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
