Re: Traffic Shaping not working correctly after ipfw coverted touse pfil_hooks API

From: Andre Oppermann <andre_at_freebsd.org>
Date: Thu, 21 Oct 2004 15:24:41 +0200
Vincent Poy wrote:
> 
> Greetings everyone:
> 
> I've recently updated from a March 6, 2004 -CURRENT to a October 19,
> 2004 -CURRENT and this appears to have broken my traffic shaping using
> ipfw/dummynet.  According to /usr/src/UPDATING, these are the changes.
> 
> 20040817 - IPFW has been converted to use PFIL_HOOKS.
> 20040827 - PFIL_HOOKS are a fixed part of the network stack now
> 20040828 - Network stack runs without Giant lock
> and also GENERIC kernel is now using the 4BSD scheduler instead of the
> ULE scheduler.
> 
> I'm on a 6Mbps/608Kbps ADSL connection with a 8 static IP's CIDR/29
> block so what I am doing is using the FreeBSD box as the router for
> outgoing packets with traffic shaping limiting the upstream at 480Kbps
> so that when I upload, the downloads do not slow down.  I have tested
> and the speeds I get is as follows without traffic shaping:
> 
> Downloading only: 650KB/sec
> Uploading only: 65KB/sec
> 
> When traffic shaping was working correctly, downloading/uploading at
> the same time with the bandwidth limit at 480Kbps would show 500KB/sec
> down and 52KB/sec up.
> 
> However, after the latest -CURRENT upgrade, it will do 200KB/sec down
> and 52KB/sec up.  If I only download only, then it does show
> 650KB/sec.  Normally, when I change the bandwidth to a number lower
> than 480Kbps for the pipe, the download speeds would go up when
> downloading.  However, I have tried in 10kbps steps down to 350kbps
> but it still did not top 200KB/sec in downloading.

Interesting.  I have just looked through the ipfw to pfil_hooks changes
as they relate to dummynet.  The only change to dummynet is to remove a
stored pointer to the rtentry.  This doesn't influence the shaping and
limiting of dummynet in any way.  Other than that the way ipfw gets
called has changed and thus how dummynet is invoked too.

Can you verify that all dummynet queues and pipes are in use?  The only
thing I can imagine is that somehow the dummynet info gets mangled and
everything goes into the same queue/pipe.  Although that is unlikely.

-- 
Andre


> My rc.firewall is basically set to open but with the following
> modifications and there is only one NIC (xl0) on this notebook
> machine:
> 
> # Traffic Shaping for DSL connection 6.016Mbps/608Kbps
> #
> # Make packets exiting dummynet not continue down the chain
> # If this is not enabled, then packets leaving an early
> # queue might enter a later queue if the conditions for
> # the later queue are met, which would be completely
> # devastating to all the prioritizing we're doing
> ipfw enable one_pass
> # Define our upload pipe at 480Kbps
> ipfw pipe 1 config bw 480Kbit/s
> # Define a high-priority queue
> ipfw queue 1 config pipe 1 weight 100
> # Define a medium-high-priority queue
> ipfw queue 2 config pipe 1 weight 66
> # Define a medium-low-priority queue
> ipfw queue 3 config pipe 1 weight 33
> # Define a low-priority queue
> ipfw queue 4 config pipe 1 weight 1
> # Add rules so that local routable IP LAN traffic does not use natd
> ipfw add 39 divert natd all from 10.0.0.0/8 to any via xl0
> ipfw add 40 divert natd all from 172.16.0.0/12 to any via xl0
> ipfw add 41 divert natd all from 192.168.0.0/16 to any via xl0
> ipfw add 42 divert natd all from 208.201.244.224/29 to 10.0.0.0/8 via
> xl0
> ipfw add 43 divert natd all from 208.201.244.224/29 to 172.16.0.0/12 via xl0
> ipfw add 44 divert natd all from 208.201.244.224/29 to 192.168.0.0/16
> via xl0         ipfw add 45 divert natd all from any to 10.0.0.0/8 via
> xl0
> ipfw add 46 divert natd all from any to 172.16.0.0/12 via xl0
> ipfw add 47 divert natd all from any to 192.168.0.0/16 via xl0
> ipfw add 48 divert natd all from any to 208.201.244.224/29 via xl0
> ipfw add 49 skipto 100 ip from 208.201.244.224/29 to any
> # Network Address Translation.
> ipfw add 50 divert natd all from any to any via xl0
> # Default rules
> ipfw add 100 pass all from any to any via lo0
> ipfw add 200 deny all from any to 127.0.0.0/8
> ipfw add 300 deny ip from 127.0.0.0/8 to any
> # Route LAN and RFC1918 networks without Traffic Shaping
> ipfw add 63000 allow all from any to 10.0.0.0/8 out
> ipfw add 63001 allow all from any to 172.16.0.0/12 out
> ipfw add 63002 allow all from any to 192.168.0.0/16 out
> ipfw add 63003 allow all from any to 208.201.244.224/29 out
> # Assign outgoing empty/small ACK packets to the high-priority queue
> ipfw add 63004 set 0 queue 1 tcp from any to any tcpflags ack out
> # Assign outgoing UDP (DNS/gaming) and SSH traffic to the
> medium-high-priority queue
> ipfw add 63005 set 0 queue 2 tcp from any to any 22,23 out
> ipfw add 63006 set 0 queue 2 udp from any to any not 80,443 out
> # Assign outgoing HTTP/HTTPS WEB traffic to the medium-low-priority queue
> ipfw add 63007 set 0 queue 3 all from any to any 80,443 out
> # Assign all other outgoing traffic to the low-priority queue
> ipfw add 63008 set 0 queue 4 all from any to any out
> # End of Traffic Shaping
> ipfw add 65000 pass all from any to any
> 
> Cheers,
> Vince
Received on Thu Oct 21 2004 - 11:24:36 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC