On Mon, 21 Dec 2009 07:20:07 -0800 Tom Eastep <[email protected]> wrote:
> 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. Sorry -- with the assumption that MARK_IN_FORWARD_CHAIN=Yes, those are traffic shaping rules -- TC rules using RFC 1918 addresses cannot be specified in the tcfilters file because those rules are invoked after SNAT/MASQUERADE. Since you seem to have a preference for the provider with mark 256, you could specify 'balance' on that provider and mark the other provider's as 'fallback' (see my config at the bottom of the Multi-ISP doc). -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
