Traffic Shaping not working correctly after ipfw coverted to
use pfil_hooks API
Vincent Poy
vincepoy at gmail.com
Thu Oct 21 14:47:50 PDT 2004
On Thu, 21 Oct 2004 15:24:41 +0200, Andre Oppermann <andre at freebsd.org> wrote:
> 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.
Yeah, it's weird since I was trying to fine tune the bandwidth size of
the upstream pipe but noticed the download side was now only
delivering 1/3rd the speed it used to no matter what I set the
upstream side to since I'm only using ipfw/dummynet on the upstream
side as the downstream packets go directly from my ISP to the other
machines on the /29. How do I verify all dummynet queues and pipes
are in use though? this is the output from ipfw show:
root at bigbang [2:45pm][/home/vince] >> ipfw show
00039 42198 13780001 divert 8668 ip from 10.0.0.0/8 to any via xl0
00040 24 3864 divert 8668 ip from 172.16.0.0/12 to any via xl0
00041 339407 102789289 divert 8668 ip from 192.168.0.0/16 to any via xl0
00042 102 5342 divert 8668 ip from 208.201.244.224/29 to
10.0.0.0/8 via xl0
00043 4 188 divert 8668 ip from 208.201.244.224/29 to
172.16.0.0/12 via xl0
00044 300 15126 divert 8668 ip from 208.201.244.224/29 to
192.168.0.0/16 via xl0
00045 102 5342 divert 8668 ip from any to 10.0.0.0/8 via xl0
00046 4 188 divert 8668 ip from any to 172.16.0.0/12 via xl0
00047 2478 725705 divert 8668 ip from any to 192.168.0.0/16 via xl0
00048 213878 49058139 divert 8668 ip from any to 208.201.244.224/29 via xl0
00049 5407521 3326832795 skipto 100 ip from 208.201.244.224/29 to any
00050 680842 218217038 divert 8668 ip from any to any via xl0
00100 78346 20803996 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
63000 51 2671 allow ip from any to 10.0.0.0/8 out
63001 2 94 allow ip from any to 172.16.0.0/12 out
63002 431 26717 allow ip from any to 192.168.0.0/16 out
63003 58516 5627106 allow ip from any to 208.201.244.224/29 out
63004 2190398 1646865637 queue 1 tcp from any to any tcpflags ack out
63005 223 19476 queue 2 tcp from any to any dst-port 22,23 out
63006 345875 32423679 queue 2 udp from any to any not dst-port 80,443 out
63007 36129 11266686 queue 3 ip from any to any dst-port 80,443 out
63008 10031 3528577 queue 4 ip from any to any out
65000 3289575 1832553695 allow ip from any to any
65535 1 46 deny ip from any to any
Cheers,
Vince
More information about the freebsd-current
mailing list