On Sun, 20 Dec 2009 19:34:49 -0500 "Brian J. Murrell" <[email protected]> wrote: > > That said, here is what I do: > > In tcclasses I have: > > eth0.1 1 full*98/100 full 1 > eth0.1 2 full/100 full 2 > eth0.1 3 full/100 full 3 default > > Which AFAIU is as close to what I really want as I can get, which is > to give the highest priority traffic 100% (98% in practise) of the > bandwidth if it needs it. I don't really believe that dividing the > bandwidth up to provide VOIP with what it needs is ideal or what VOIP > really wants. > > I think VOIP is happy to be in the same bandwidth allocation as the > rest of the traffic as long as it's traffic gets handled first. ISTR > prior to Shorewall, I was doing VOIP prioritization simply with FIFO > disciplines or some such.
Probably 'prio'. > > I imagine QOS of this nature to be more like queues where VOIP always > goes into the express queue and the express queue is always emptied > first and only when there is no express queue items, is the next > highest queue used. I could see perhaps that in that queue, some > divisions of bandwidth into different priorities with minimums and > maximums might be useful more along the lines of what is being done > now with tcclasses in Shorewall. > > > Policy routing *may* use firewall marks. > > My particular use of policy routing is multi-isp where of course I > need to ensure the same Internet connection is used persistently for > a given TCP/UDP connection. I also have a preference to push all > internally generated outbound traffic via one of my two connections > and leave the other to only service what comes in on it. > > For QOS, I want ping to represent what the highest priority traffic is > experiencing. Also, VOIP traffic should be handled with > "band"/priority "1". > > I achieve all of this with (in my tcrules) file: Which is impossible to decode without knowing the setting of MARK_IN_FORWARD_CHAIN -- I'll assume that option is set. > > CONTINUE:P 0.0.0.0/0 0.0.0.0/0 > all - - - !0/0x300 # default routing of > everything through xxx (put exceptions # below since last match wins) > 256:P 0.0.0.0/0 > 256 $FW > > # restore any existing marks in connection to the packet > RESTORE 0.0.0.0/0 0.0.0.0/0 > all - - - 0 # and we are done if we > copied a mark from the connection to the # packet CONTINUE > 0.0.0.0/0 0.0.0.0/0 > all - - - !0 > > # Ping > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request > 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply > > # IAX traffic (this is actually moot with the below, but leave it > here for illustration) 1 10.75.22.8 0.0.0.0/0 > udp 4569 4569 1 0.0.0.0/0 > 10.75.22.8 udp 4569 4569 > > # PBX > 1 10.75.22.8 0.0.0.0/0 > 1 0.0.0.0/0 10.75.22.8 > > Given my policy routing portion of the above, is there any way other > than tcrules to handle it (in respect to your "*may*" comment above)? The PBX rules can be encoded in the route_rules file. Anything having to do with specific protocols must be done using firewall rules. > > > For historical reasons, > > firewall marks in Shorewall are assigned in the tcrules file. > > Yeah. I would just like to see multi-isp and policy routing done in a > way that hides all of this packet marking (including the CONTINUE, > RESTORE goop). I don't know why you are using RESTORE in your rules above. You never SAVE or mark any connections so that appears superfluous. The 'track' option hides all of the 'CONTINUE, RESTORE goop' for multi-ISP. Do you set TC_EXPERT=Yes for some reason? > Something more along the lines of the rules file > syntax where the actions are which interface to route via rather than > whether to allow or disallow packets, etc. > > As for QOS, I add one other bit of magic sauce to all of the above and > that's the following in the started file: > > # need the SIP helper to mark all SIP connections for priority > num_tcfor_rules=$(($($IPTABLES -t mangle -L tcfor -n | wc -l) - 2)) > if [ $num_tcfor_rules -gt 0 ]; then > echo "Installing sip helper before rule $num_tcfor_rules in the > tcfor chain" $IPTABLES -t mangle -I tcfor $num_tcfor_rules -m helper > --helper sip -j MARK --set-mark 0x1 else > echo "WARNING: not installing sip helper as we couldn't find a > tcfor chain" fi That's a very convoluted way of writing this tcrule: 1 0.0.0.0/0 0.0.0.0/0 - - - - - - - - sip > > This has the effect of putting the RTP that results of a SIP > connection into the high-priority band as well. > > > One thing that I plan to do in Shorewall 4.6 is to take advantage of > > the fact that later kernels allow packet marks to be assigned in the > > filter table. This will allow for the eventual obsolescence of the > > tcrules file in favor of the rules file. > > That sounds like it will be nice, but my itch is not so much just that > they are different files, just that I (perhaps naively) think that all > of this packet marking can be hidden from the general config and > handled by the Shorewall compiler. I just think the tc* files are > too "raw". I agree and I'll do what I can.... > > Shorewall does a nice job of putting a shiny interface on top of > iptables. I think it could do the same for policy routing and QOS > (i.e. TC). ... but when I had the inspiration for Shorewall 9 years ago, it was with respect to iptables. I've had no such flashes of insight when it comes to policy routing and especially traffic shaping. > But as you say, I think we need a working tc* files example before we > can go further. I have posted what I use here (albeit I do some > cheating by doing QOS to an entire IP which I have dedicated to my PBX > and a more complete solution would break that down into ports). > > Does anyone else want to throw their $0.02 in here? > > Perhaps as a group we can get to this first step, which is the ideal > Shorewall config for VOIP. > Indeed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
