-------- Original Message -------- > From: Tom Eastep <[email protected]> > Sent: Saturday, June 20, 2009 4:45 PM > To: Shorewall Users <[email protected]> > Subject: Re: [Shorewall-users] Traffic Shaping > > Tom Eastep wrote: > > Mike Lander wrote: > >> Think I found the trouble, I was wondering if tcrules could be interfering > >> so I commented out my old qos as follows > >> This is out of the box sending 1c tos > >> > >> #The next lines define class 1 for VOIP > >> 3:11 10.19.227.18 10.192.139.240 ALL > >> 2:11 $FW eth1 udp 1194 > >> 4:11 10.19.227.18 10.194.244.240 ALL > >> 2:11 $FW eth1 udp 7799 > >> #5:11 10.19.227.18 10.143.99.241 ALL > >> #2:11 $FW eth1 udp 7788 > >> # > >> The latter rules are for the tunnel I am experimenting with which are > >> commented out now. See results below. > >> > >> Here is show clasifiers on this box > >> Note that the other end of the tunnel is sending 14 tos which to this > >> box is a download, does shorewall disreagard this because the packet > >> is already accross the tunnel? Because neither box seems to match > >> the others tos after the packet is through the internet. > >> > >> Device eth1: > >> filter parent 2: protocol all pref 1 fw > >> filter parent 2: protocol all pref 1 fw handle 0x1 classid 2:11 > >> filter parent 2: protocol all pref 1 fw handle 0x2 classid 2:12 > >> filter parent 2: protocol all pref 1 fw handle 0x3 classid 2:13 > >> filter parent 2: protocol all pref 1 fw handle 0x4 classid 2:14 > >> filter parent 2: protocol ip pref 10 u32 > >> filter parent 2: protocol ip pref 10 u32 fh 800: ht divisor 1 > >> filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 > >> bkt 0 flowid 2:11 (rule hit 470 success 0) > >> match 00140000/00fc0000 at 0 (success 0 ) > >> filter parent 2: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 > >> bkt 0 flowid 2:11 (rule hit 470 success 42) > >> match 001c0000/00fc0000 at 0 (success 42 ) > >> filter parent 2: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 > >> bkt 0 flowid 2:12 (rule hit 428 success 0) > >> match 00060000/00ff0000 at 8 (success 0 ) > >> match 05000000/0f00ffc0 at 0 (success 0 ) > >> match 00100000/00ff0000 at 32 (success 0 ) > >> filter parent 2: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 > >> bkt 0 flowid 2:12 (rule hit 428 success 0) > >> match 00100000/00100000 at 0 (success 0 ) > >> > >> Device tun2: > >> filter parent 5: protocol all pref 1 fw > >> filter parent 5: protocol all pref 1 fw handle 0x1 classid 5:11 > >> filter parent 5: protocol all pref 1 fw handle 0x2 classid 5:12 > >> filter parent 5: protocol all pref 1 fw handle 0x3 classid 5:13 > >> filter parent 5: protocol all pref 1 fw handle 0x4 classid 5:14 > >> filter parent 5: protocol ip pref 10 u32 > >> filter parent 5: protocol ip pref 10 u32 fh 800: ht divisor 1 > >> filter parent 5: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 > >> bkt 0 flowid 5:11 (rule hit 13 success 0) > >> match 00140000/00fc0000 at 0 (success 0 ) > >> filter parent 5: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 > >> bkt 0 flowid 5:11 (rule hit 13 success 13) > >> match 001c0000/00fc0000 at 0 (success 13 ) > >> filter parent 5: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 > >> bkt 0 flowid 5:12 (rule hit 0 success 0) > >> match 00060000/00ff0000 at 8 (success 0 ) > >> match 05000000/0f00ffc0 at 0 (success 0 ) > >> match 00100000/00ff0000 at 32 (success 0 ) > >> filter parent 5: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 > >> bkt 0 flowid 5:12 (rule hit 0 success 0) > >> match 00100000/00100000 at 0 (success 0 ) > >> > >> > >> Will this work to priotize these voip packets? > >> With the old way I was using the remote desktop users over these tunnels > >> went into class <device>:11 class one > >> Not sure why tc rules was doing this since the tos bit was preserved all > >> the way to the lan interface. > > > > Look at the classifiers -- the fw (mark) classifiers have priority 1 > > while the TOS classifiers have priority 10. That's backwards from the > > way that it should ideally be. > > > > I added a TOS column to /etc/shorewall/tcfilters so that the > > classification by TOS can be moved ahead of the mark classifiers. > > > > In the meantime, see if the attached patch corrects your problem. > > > > patch /usr/share/shorewall-perl/Shorewall/Tc.pm < tcpriority.diff > > > > Also in 4.4, the priority of the fw and the option-generated classifiers > are adjusted in a way that is similar to the simple patch I posted.
I think I will try 4.4 and I will let you know. Thank you, Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
