News: This forum is now permanently frozen.
Pages: [1]
Topic: Not Shaping  (Read 3355 times)
« on: June 29, 2007, 20:18:08 »
javs *
Posts: 4

Hello

I'm testing inbound traffic shaping whith m0n0wall 1.231

According to

unparsed ipfw rules
add 50000 set 4 pass all from 192.168.0.1 to any
add 50001 set 4 pass all from any to 192.168.0.1
add 50002 set 4 queue 6 all from any 80 to 192.168.0.12 in via rl2
add 50003 set 4 queue 7 all from any 80 to 192.168.0.11 in via rl2
pipe 1 config bw 288Kbit/s
pipe 2 config bw 973Kbit/s
queue 1 config pipe 1 weight 100
queue 2 config pipe 1 weight 80
queue 3 config pipe 1 weight 65
queue 4 config pipe 1 weight 4
queue 5 config pipe 1 weight 3
queue 6 config pipe 2 weight 10
queue 7 config pipe 2 weight 1
queue 8 config pipe 2 weight 100
queue 9 config pipe 2 weight 5
queue 10 config pipe 2 weight 3
queue 11 config pipe 1 weight 22
queue 12 config pipe 1 weight 6

from http://myip/status.php

When downloading simultaneously two big files from lan hosts 192.168.0.11 and 192.168.0.12, download speed rates are 50% on both computers instead of expected shaped values 90%, 10%.


is something wrong in my test?


Thanks

« Reply #1 on: June 30, 2007, 03:49:48 »
clarknova ***
Posts: 148

First, your language is somewhat ambiguous: your rules say "from any 80 to 192.1688.0.11(12)", but your example says "files from lan hosts 192.168.0.11(12)". Are you really downloading from these addresses, or are you downloading to them? If the former, then the sense of your rule is wrong.

Somebody will correct me if I'm wrong, but if the latter, then I think the problem is that the rule is being parsed on incoming packets from the WAN, and NAT has not yet been performed on them, thus they will all be destined to your WAN address and not match your rules.

You could modify your rules to say "out via [LAN_interface]" instead of "in via rl2". This may not have the desired effect if you have multiple LAN interfaces. If you must do your shaping at the WAN, then you may have to use criteria other than LAN IP address.

That's my hypothesis.

db
« Reply #2 on: June 30, 2007, 21:31:36 »
javs *
Posts: 4

Sorry,

You're right, it seems a bit ambiguous.

I'll try to explain it better.

rl2 is WAN interface. The traffic shaper has been set up to shape incoming
WAN traffic, from any source address on source port 80 to lan computers
192.168.0.11(12)

Files (freebsd iso) are been downloaded running Firefox on computer
192.168.0.11 and on computer 192.168.0.12 at the same time.

The purpouse of the test is to split incoming traffic, originated on source
port 80 to lan computers, to a 10:1 ratio.


thanks for your reply.

 

« Reply #3 on: July 01, 2007, 06:57:18 »
clarknova ***
Posts: 148

The traffic shaper has been set up to shape incoming
WAN traffic, from any source address on source port 80 to lan computers
192.168.0.11(12)...
The purpouse of the test is to split incoming traffic, originated on source
port 80 to lan computers, to a 10:1 ratio.

Yes, so I think that attempting to match traffic incoming on the WAN and destined to a NATed address will always fail. You must either filter based on another criterion or put your filters on the outgoing interface, the interface that 192.168.0.11 is attached to in this case.

I hope this helps.

db
« Reply #4 on: July 03, 2007, 14:08:48 »
javs *
Posts: 4

Thanks a lot Clarknova

Your suggestions have helped me to clarify some concepts regarding
shaper rules and traffic direction (blue arrows).

Ftp upload (lan->dmz) and download (dmz->lan) have been succesfully
shaped at proper rates by setting up correct rules on OPT1 interface.
Now, rules in new test match incoming and outgoing traffic. 


regards


Javs
« Last Edit: July 03, 2007, 14:11:46 by javs »
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines