--On Sunday, November 24, 2002 02:16:29 PM +0100 Harry Westerman
<hwesterman@cistron.nl> wrote:
> Hello everyone.
>
> I''ve been trying to get Qos to work here for two days now, but it
REALLY
> doesn''t seem to work the way I want to. Here is my situation:
>
> Internet
>
> Wireless LAN Firewall DMZ
>
> Local lan
>
> As you can see, I got a Debian box in the middle as my firewall with 3
> network interfaces and a wireless one. I use Shorewall to configure
> everything and it works. I masquerade LAN, LOC and DMZ towards internet
> and have extra rules for hiding the local lan from the wlan, etc. I have a
> Cistron MAXX abo to the internet (8192/512kbits).
>
> Then I wanted to use QOS, so I patched my 2.4.18 kernel with HTB, and used
> the Wondershaper 1.1a. It works! I see three classes, with traffic in all
> three of them. But it only diferentiates between types of traffic, and I
> would like it to diferentiate based on the source of the packets. I would
> like to have my DMZ and LOC a high priority, and a low priority for the
> mldonkey program on the firewall itself, or for the users on the wlan. So
> I tried this:
>
> $DEV=eth1
> tc qdisc add dev $DEV root handle 1: htb default 40
> tc class add dev $DEV parent 1: classid 1:1 htb rate 480kbit burst 6k
> tc class add dev $DEV parent 1:1 classid 1:10 htb rate 80kbit ceil 480kbit
> burst 6k
> tc class add dev $DEV parent 1:1 classid 1:20 htb rate 120kbit ceil
> 480kbit burst 6k
> tc class add dev $DEV parent 1:1 classid 1:30 htb rate 270kbit ceil
> 480kbit burst 6k
> tc class add dev $DEV parent 1:1 classid 1:40 htb rate 1kbit ceil 480kbit
> burst 6k
>
># all get Stochastic Fairness:
> tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
> tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
> tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10
> tc qdisc add dev $DEV parent 1:40 handle 40: sfq perturb 10
>
># TOS Minimum Delay (ssh, NOT scp) in 1:10:
> tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
> match ip tos 0x10 0xff flowid 1:10
>
># ICMP (ip protocol 1) in the interactive class 1:10 so we
># can do measurements & impress our friends:
> tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
> match ip protocol 1 0xff flowid 1:10
>
># To speed up downloads while an upload is going on, put ACK packets in
># the interactive class:
> tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
> match ip protocol 6 0xff \
> match u8 0x05 0x0f at 0 \
> match u16 0x0000 0xffc0 at 2 \
> match u8 0x10 0xff at 33 \
> flowid 1:10
>
># loc
># iptables -A PREROUTING -t mangle -i $DEV -p tcp -s 192.168.0.0/24 -j
> MARK --set-mark 2
This is roughly equivalent to the following tcrules entry:
2 $DEV 0.0.0.0/0 TCP
In your case, it should be completely equivalent since 192.168.0.0/24 is
the only subnet off of your local net correct?
When you place entries in tcrules, BE SURE TO SET TC_ENABLED=Yes in
/etc/shorewall/shorewall.conf!!!
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 2 fw classid
> 1:20
># tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
># match ip src 192.168.0.0/24 flowid 1:20
>
># dmz
># iptables -A PREROUTING -t mangle -i $DEV -p tcp -s 10.0.0.0/8 -j
> MARK --set-mark 3
3 $DEV 0.0.0.0/0 TCP
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 3 fw classid
> 1:30
># tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
># match ip src 10.0.0.0/8 flowid 1:30
>
># rest is ''non-interactive'' ie ''bulk''
and ends up in 1:40
> tc filter add dev $DEV parent 1: protocol ip prio 18 u32 \
> match ip dst 0.0.0.0/0 flowid 1:40
>
> Ok. Well, this is almost the same as the wondershaper itself. The only
> problem (as you can see) is to mark the packets coming from the DMZ or the
> LOCal lan.
>
> First I tried to mark the packets with the TCRules file of Shorewall and
> use a tc filter to move the packets to the right class id.
Did you set TC_ENABLED=Yes?
> As you can
> see, I also tried to mark them with iptables, but I suspect that
doesn''t
> work because Shorewall doesn''t have a PREROUTING table?
_NetFilter_ has a PREROUTING table that Shorewall couldn''t remove if it
wanted to. You blindly added them to the end though so they may not have
been visible, depending what else your Shorewall config has going on in the
mangle table. "/sbin/shorewall show mangle" will show you the complete
mangle table contents.
Of am I wrong?> Maybe the reason it doesn''t work is that I use masquerading from
the DMZ
> and the loc? So the FROM adresses are already rewritten?
No -- Source NAT/Masquerade occurs in POSTROUTING (just before packets to
out the door).
> Also the tc filter on the src match doesn''t seem to work, I have
NEVER
> seen any traphic on the 1:20 of 1:30 classes.
Works here! If you post the output of "shorewall show tc" and
"shorewall
show mangle", we would be able to see exactly what you are doing.
-Tom
--
Tom Eastep \ Shorewall - iptables made easy
AIM: tmeastep \ http://shorewall.sf.net
ICQ: #60745924 \ teastep@shorewall.net