-------- Original Message --------> From: Tom Eastep <teastep@shorewall.net>
> Sent: Saturday, June 20, 2009 4:45 PM
> To: Shorewall Users <shorewall-users@lists.sourceforge.net>
> 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