Re: Extending Wondershaper a bit

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sunday 24 November 2002 14:09, Harry Westerman 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
> 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
> 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. 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? Of am I wrong? Maybe the
> reason it doesn't work is that I use masquerading from the DMZ and the loc?
You have to mark on the interface of the DMZ and the loc.  The mark can later 
be used on the internet NIC.  Each linux box can do that, even if it's 
running shorewall.

> So the FROM adresses are already rewritten?
Yes, so mark on the interface of the DMZ/loc.

> 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.
Like you said, that's because you are masquerading.  So the src address is 
rewritten.

I have some other remarks.  "burst 6k" is too low.  If you use the latest htb, 
you can remove the burst parameter so htb will calculate the most optimal.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux