From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Interesting oopses...
Date: Wed, 22 Dec 2004 13:19:21 +0000 [thread overview]
Message-ID: <41C97459.10908@dsl.pipex.com> (raw)
In-Reply-To: <41AAE484.2020807@expertron.co.za>
Justin Schoeman wrote:
> 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\x10000
> OUTBW\x116
> INBW\x116
>
> # 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
>
If this works OK on other kernels than ignore the following :-)
It's possible that the problems are because HTB doesn't like being a
prio leaf (I know examples show TBF like this - but HTB would normally
wrap the prio so it was rate limited.
I think you could do the same without prio - if you set htb as root with
default 0 then traffic that is unclassified goes unlimited, so just
classify what you need to restrict.
> # 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...
We would need to see the script - I think you should try to do it with
HTB alone.
Andy.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2004-12-22 13:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-29 8:57 [LARTC] Interesting oopses Justin Schoeman
2004-12-19 18:22 ` bert hubert
2004-12-22 13:19 ` Andy Furniss [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41C97459.10908@dsl.pipex.com \
--to=andy.furniss@dsl.pipex.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox