I am trying limit the amount of bandwidth users consume for services other than VOIP. I want all other internet traffic to be capped at a max of 30% of total bandwidth. I have followed the guide for setting up IFB Traffic shaping, but when I perform a "wget" from kernel to org, I am still getting 100% of traffic. Is it wrong to assume that the TC Filters will apply to the firewall itself? My configs are here: -------------- tcdevices ---------------- 1:eth1 - 1500kbit classify 2:ifb0 - 1500kbit - eth1 --------- tcclasses ---------- 1:110 - 768kbit full 1 tos=0x68/0xfc,tos=0xb8/0xfc,tos=0x48/0xfc 1:120 - 2*full/10 3*full/10 2 tcp-ack,tos-minimize-delay 1:130 - 1*full/10 3*full/10 3 default 2:110 - 768kbit full 1 tos=0x68/0xfc,tos=0xb8/0xfc,tos=0x48/0xfc 2:120 - 2*full/10 3*full/10 2 tcp-ack,tos-minimize-delay 2:130 - 1*full/10 3*full/10 3 default ------------ tcfilters ------------ 1:110 - - udp 4569 1:120 - - icmp echo-request 1:120 - - icmp echo-reply # # INCOMING TRAFFIC 2:110 - - udp 4569 2:120 - - icmp echo-request 2:120 - - icmp echo-reply ------------------------------------------------------------------------------ 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
On Sun, 20 Dec 2009 16:47:28 +0000 redbaron73@gmail.com wrote:> I am trying limit the amount of bandwidth users consume for services > other than VOIP. I want all other internet traffic to be capped at a > max of 30% of total bandwidth. I have followed the guide for setting > up IFB Traffic shaping, but when I perform a "wget" from kernel to > org, I am still getting 100% of traffic. Is it wrong to assume that > the TC Filters will apply to the firewall itself? > > My configs are here:Please forward the output of ''shorewall show tc''. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Sun, 2009-12-20 at 16:47 +0000, redbaron73@gmail.com wrote:> I am trying limit the amount of bandwidth users consume for services > other than VOIP.Which seems to be 90% of the requests for TC/QOS to this list. Tom: I wonder if the TC/QOS stuff can be abstracted (read: dumbed down) into more simple configuration for the usual cases, like VOIP (for one). For example, it seems that given this very frequent case, VIOP, I would think that one wants to always give highest priority to VIOP (to the limit of 100% of the bandwidth I would think[1]) and let everything else fight it out the remaining bandwidth (i.e. like most people without VOIP needs do for 100% of their bandwidth). IOW, for VOIP situations, it seems more appropriate to simply prioritize traffic rather than creating minimum/maximum/lending/borrowing bands for it. Given that policy routing also utilizes the TC configuration files, it would be nice to see a simpler, more rule based policy routing configuration as well. One that mimics a regular routing file but allows port specification, etc. Given that I don''t do routing/qos for a living (i.e. keeping my knowledge cache of TC in Linux fresh) and only ever visit periodically, the tc{classes,rules} file gives me a headache every time I do have to go back to it and realize I have forgotten what I had to re-learn the last time I wanted to fiddle with it. In any case, it just seems to me that probably 90% of the QOS and policy routing use-cases out there could be satisfied with a much simpler configuration syntax -- one that insulates the user from the terseness of Linux TC. Perhaps it''s a case of yes, this is all a good idea -- somebody just needs to find the time to implement it. :-) Thots? b. [1] One probably doesn''t really want to be using 100% of their bandwidth for VOIP as the VOIP application''s call-quality will probably suffer from the congestion of that. But IMHO it''s the VOIP application''s task (not Shorewall''s) to limit use to some reasonable percentage of available bandwidth and/or the administrator''s responsibility to ensure that the available bandwidth meets the VIOP application''s configuration and requirements with appropriate overhead to avoid call-quality affecting congestion. ------------------------------------------------------------------------------ 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
On Sun, 20 Dec 2009 13:31:00 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> wrote:> On Sun, 2009-12-20 at 16:47 +0000, redbaron73@gmail.com wrote: > > I am trying limit the amount of bandwidth users consume for services > > other than VOIP. > > Which seems to be 90% of the requests for TC/QOS to this list. > > Tom: I wonder if the TC/QOS stuff can be abstracted (read: dumbed > down) into more simple configuration for the usual cases, like VOIP > (for one).I think an excellent first step would be for someone who successfully uses Shorewall traffic shaping with VOIP to write a HOWTO. I don''t have VOIP and I refuse to install it just so I can write such a HOWTO.> > For example, it seems that given this very frequent case, VIOP, I > would think that one wants to always give highest priority to VIOP > (to the limit of 100% of the bandwidth I would think[1]) and let > everything else fight it out the remaining bandwidth (i.e. like most > people without VOIP needs do for 100% of their bandwidth). IOW, for > VOIP situations, it seems more appropriate to simply prioritize > traffic rather than creating minimum/maximum/lending/borrowing bands > for it.This requires someone who has the problem (has VOIP and wants to handle it with Shorewall Traffic Shaping) and has the talent to implement a better solution *and has the time to support the code once it is released*.> > Given that policy routing also utilizes the TC configuration files, it > would be nice to see a simpler, more rule based policy routing > configuration as well. One that mimics a regular routing file but > allows port specification, etc.Policy routing *may* use firewall marks. For historical reasons, firewall marks in Shorewall are assigned in the tcrules file. 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.> > Given that I don''t do routing/qos for a living (i.e. keeping my > knowledge cache of TC in Linux fresh) and only ever visit > periodically, the tc{classes,rules} file gives me a headache every > time I do have to go back to it and realize I have forgotten what I > had to re-learn the last time I wanted to fiddle with it.I don''t do anything even related to networking for a living. And I have the same problem with QOS (I have to go back to first principles each time I want to change it).> > In any case, it just seems to me that probably 90% of the QOS and > policy routing use-cases out there could be satisfied with a much > simpler configuration syntax -- one that insulates the user from the > terseness of Linux TC. > > Perhaps it''s a case of yes, this is all a good idea -- somebody just > needs to find the time to implement it. :-)And document it. And support it. Those take much more effort than writing the code... -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Sun, 2009-12-20 at 11:52 -0800, Tom Eastep wrote:> > I think an excellent first step would be for someone who successfully > uses Shorewall traffic shaping with VOIP to write a HOWTO.Good point. I hardly consider myself an expert though. What I have here I have gleaned from threads posted here. So we can start with my sharing mine and see what criticisms and/or enhancement folks have.> I don''t have > VOIP and I refuse to install it just so I can write such a HOWTO.That''s fair enough.> This requires someone who has the problem (has VOIP and wants to handle > it with Shorewall Traffic Shaping)/me raises hand> and has the talent to implement a > better solution *and has the time to support the code once it is > released*./me wavers hand. As I said, I really don''t consider myself at all a traffic shaping expert and do my traffic shaping by following example. 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. 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: 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)?> 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). 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 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". 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).> I don''t do anything even related to networking for a living. And I have > the same problem with QOS (I have to go back to first principles each > time I want to change it).Heh.> And document it. And support it. Those take much more effort than > writing the code...Indeed. 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. b. P.S. One thing I have not done any research into is how all of this could work when encapsulating prioritized traffic into a tunnel like openvpn. It''s all fine and dandy for the VOIP traffic to have priority while it''s unwrapped, but it would be nice if that priority could translate into an encryption tunnel like openvpn. I suspect that''s a particularly unsolvable problem though. ------------------------------------------------------------------------------ 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
On Sun, Dec 20, 2009 at 07:34:49PM -0500, Brian J. Murrell wrote:> P.S. One thing I have not done any research into is how all of this > could work when encapsulating prioritized traffic into a tunnel like > openvpn. It''s all fine and dandy for the VOIP traffic to have priority > while it''s unwrapped, but it would be nice if that priority could > translate into an encryption tunnel like openvpn. I suspect that''s a > particularly unsolvable problem though.It should be easy, just do the shaping on the TUN device. Depending on the details of your setup, perhaps also put the remote VPN host(s)'' external IP tcp/1194 into a high-priority class for the external interface with a guaranteed minimum RATE sufficient to handle such high-prio traffic. Justin ------------------------------------------------------------------------------ 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
On Sun, 2009-12-20 at 19:47 -0700, Justin Pryzby wrote:> > It should be easy,Careful. :-)> just do the shaping on the TUN device.Which achieves the goal of prioritizing within the tunnel, yes. However...> Depending > on the details of your setup, perhaps also put the remote VPN host(s)'' > external IP tcp/1194 into a high-priority class for the external > interface with a guaranteed minimum RATE sufficient to handle such > high-prio traffic.No. That''s unacceptable. That would mean that all traffic in the OpenVPN tunnel (including bulkish transfers, like say site->site backup, etc.) would get the priority of VOIP (or whatever else you decided your priority band was for) and starve out other equally low priority traffic outside the tunnel. What needs to happen is that marking for priority needs to be carried up from the unencapsulated packet to the corresponding openvpn packet, but given that openvpn is userspace, I don''t see that likely to happen. I wonder if IPsec, with the luxury of being all in the kernel supports such a thing. I wonder if there is any API support at all for being able to push a packet into kernel-space from user-space including a mark, even if run as root. b. ------------------------------------------------------------------------------ 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
Brian J. Murrell wrote:> > Depending >> on the details of your setup, perhaps also put the remote VPN host(s)'' >> external IP tcp/1194 into a high-priority class for the external >> interface with a guaranteed minimum RATE sufficient to handle such >> high-prio traffic. > >No. That''s unacceptable. That would mean that all traffic in the >OpenVPN tunnel (including bulkish transfers, like say site->site backup, >etc.) would get the priority of VOIP (or whatever else you decided your >priority band was for) and starve out other equally low priority traffic >outside the tunnel.Would the answer there be to route both the normal and tunneled traffic through an IFB (or 2 ?) so that you can shape the aggregate traffic ? Ie, the tunnel and ethernet interfaces would be unshaped, only a virtual ''choke point'' where all the traffic has to go through would be shaped. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ 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
On Mon, 2009-12-21 at 09:08 +0000, Simon Hobson wrote:> > Would the answer there be to route both the normal and tunneled > traffic through an IFB (or 2 ?) so that you can shape the aggregate > traffic ?Hrm. I don''t know zilch about IFB but I think I am getting your point. If one had a single point that represented the traffic using the Internet connection and that represented both local traffic and remote openvpn traffic, after it comes out of openvpn, if you could choke it all through a single policy which slowed down the non-priority traffic. I suppose that could indeed work. I have no idea how to implement it though. But I must admit that this whole shaping of traffic inside an openvpn connection is a digression of where I had hoped this thread might go. Although, in coming up with the right solution, perhaps it needs to be recognized as a variable in the whole TC solution, better sooner than later. Cheers, b. ------------------------------------------------------------------------------ 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
On Sun, 20 Dec 2009 23:20:23 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> wrote:> On Sun, 2009-12-20 at 19:47 -0700, Justin Pryzby wrote: > > > > It should be easy, > > Careful. :-) > > > just do the shaping on the TUN device. > > Which achieves the goal of prioritizing within the tunnel, yes. > However... > > > Depending > > on the details of your setup, perhaps also put the remote VPN > > host(s)'' external IP tcp/1194 into a high-priority class for the > > external interface with a guaranteed minimum RATE sufficient to > > handle such high-prio traffic. > > No. That''s unacceptable. That would mean that all traffic in the > OpenVPN tunnel (including bulkish transfers, like say site->site > backup, etc.) would get the priority of VOIP (or whatever else you > decided your priority band was for) and starve out other equally low > priority traffic outside the tunnel. > > What needs to happen is that marking for priority needs to be carried > up from the unencapsulated packet to the corresponding openvpn > packet, but given that openvpn is userspace, I don''t see that likely > to happen.The solution here is to use IPSEC rather than OpenVPN; packet marks are preserved when IPSEC encrypts and encapsulates a packet. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Sun, 20 Dec 2009 19:34:49 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> 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" fiThat''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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Mon, 21 Dec 2009 07:20:07 -0800 Tom Eastep <teastep@shorewall.net> wrote:> On Sun, 20 Dec 2009 19:34:49 -0500 > "Brian J. Murrell" <brian@interlinx.bc.ca> 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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Mon, 2009-12-21 at 07:39 -0800, Tom Eastep wrote:> > 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''Ahhh. fallback. Another new (to me) option. I relish the idea of making my tcrules simpler so I will look into migrating some of these features into my own config.> (see my config at the bottom of the Multi-ISP > doc).Wow. It is simply uncanny how that diagram reflects my configuration. One less interface, where I don''t have a server on a dedicated interface, but I have the ports (and vlan capability) on the router to do it if I wanted. But that whole explanation of the slow DSL vs. the high-speed cable connection and using the latter for all traffic except connections that originate from the Internet and are destined via the DSL to a static IP (only one in my case). Simply uncanny. Ahh. One fairly significant difference is that my router is the endpoint (i.e. has the static address assigned from) of the DSL connection, not a path to the static IP as in our case. Although from your route_rules file, it appears that your DSL IP is 206.124.146.180, yes? Cheers and much thanx for the heads up on all of this! b. ------------------------------------------------------------------------------ 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
On Mon, 2009-12-21 at 07:20 -0800, Tom Eastep wrote:> > Probably ''prio''.That could be it. It rings a bell. It was so long ago though. But a short bit of googlin'' came up with this: http://www.voip-info.org/wiki/view/QoS+with+Linux+using+PRIO+and+HTB This is exactly my position on QOS with VOIP. I don''t think I even bothered with an HTB in the second class. But seeing this, pfifo was the mechanism I used. That allowed what I wanted, which the writer of the above page describes exactly: The problem is that they [wondershaper] all use fair queing schemes where one connection cannot steal all the bandwidth, but this is exactly what I want. When I use VoIP I don''t want any other traffic sent out on my link when there is VoIP data that wants to go out. I tend to think that this is what most people using VOIP want.> Which is impossible to decode without knowing the setting of > MARK_IN_FORWARD_CHAIN -- I''ll assume that option is set.Good assumption: shorewall.conf:MARK_IN_FORWARD_CHAIN=Yes> The PBX rules can be encoded in the route_rules file.But only because I have a dedicated IP for the PBX, yes? That is more a product of simplicity (in the Shorewall TC configuration) than necessity.> Anything having > to do with specific protocols must be done using firewall rules.It may be that a lot of people can simply say that an IP address is VOIP. In my case, I set up an alias and binded Asterisk to it. Others though may be in a simpler, SIP client only situation with an ATA, but they are also in the "entire IP address is VIOP" situation. The people who don''t fall into that are people doing VOIP on their workstations that also browse and do other bandwidth intensive things. So I think ultimately we need both.> I don''t know why you are using RESTORE in your rules above. You never > SAVE or mark any connections so that appears superfluous.Yeah, more than likely historical. I do note some commented out: # Bitorrent #RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 #CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 #4 0.0.0.0/0 0.0.0.0/0 ipp2p:all bit #SAVE:P 0.0.0.0/0 0.0.0.0/0 tcp - - - 1 That was at the top of the file, prior to what I sent previously> The ''track'' > option hides all of the ''CONTINUE, RESTORE goop'' for multi-ISP. Do you > set TC_EXPERT=Yes for some reason?Nope: shorewall.conf:TC_EXPERT=No Which is good, because I am a far cry from it. :-)> That''s a very convoluted way of writing this tcrule: > > 1 0.0.0.0/0 0.0.0.0/0 - - - - - - - - sipAhhh. Sweet. Seems this is new in 4.2.0. I will have to make use of that.> I agree and I''ll do what I can....Great! You are the compiler man after-all, doing a wonderful job of taking a working config and turning into configuration and compiler code!> ... but when I had the inspiration for Shorewall 9 years ago, it was > with respect to iptables.Absolutely understood.> I''ve had no such flashes of insight when it > comes to policy routing and especially traffic shaping.I have a very fuzzy picture in my mind. Nothing I can put to paper yet of how I think the configuration could look. I''ve scratched the surface on describing it here, but it''s just a seed of an idea yet. Likely it will evolve as we find out way through this quagmire. b. ------------------------------------------------------------------------------ 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
On Mon, 21 Dec 2009 19:08:59 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> wrote:> > I have a very fuzzy picture in my mind. Nothing I can put to paper > yet of how I think the configuration could look. I''ve scratched the > surface on describing it here, but it''s just a seed of an idea yet. > Likely it will evolve as we find out way through this quagmire. >I''ve started with something very simple. a) New value for TC_ENABLED option -- ''Simple''. b) tcinterfaces file -- Columns are ''INTERFACE'' and ''TYPE''; the type may be ''Internal'', ''External'' or left empty. The type determines if and how the ''flow'' classifier is applied. c) tcpri file -- Columns are ''PRIORITY'', ''PROTO'' and ''PORTS(S). PRIORITY is 1, 2 or 3. Traffic not listed in tcpri is placed in priority bands based on the standard TOS priomap. This is basically what is provided by the QOS screen on LinkSys commodity routers. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Fri, 25 Dec 2009 08:33:52 -0800 Tom Eastep <teastep@shorewall.net> wrote:> On Mon, 21 Dec 2009 19:08:59 -0500 > "Brian J. Murrell" <brian@interlinx.bc.ca> wrote: > > > > > I have a very fuzzy picture in my mind. Nothing I can put to paper > > yet of how I think the configuration could look. I''ve scratched the > > surface on describing it here, but it''s just a seed of an idea yet. > > Likely it will evolve as we find out way through this quagmire. > > > > I''ve started with something very simple. > > a) New value for TC_ENABLED option -- ''Simple''. > b) tcinterfaces file -- Columns are ''INTERFACE'' and ''TYPE''; the type > may be ''Internal'', ''External'' or left empty. The type determines if > and how the ''flow'' classifier is applied. > c) tcpri file -- Columns are ''PRIORITY'', ''PROTO'' and ''PORTS(S). > PRIORITY is 1, 2 or 3. Traffic not listed in tcpri is placed in > priority bands based on the standard TOS priomap. > > This is basically what is provided by the QOS screen on LinkSys > commodity routers.I''ve added the ability to specify a priority to traffic from individual interfaces and addresses as well. This provides the complete set of features offered by my Linksys. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Fri, 25 Dec 2009 15:13:18 -0800 Tom Eastep <teastep@shorewall.net> wrote:> On Fri, 25 Dec 2009 08:33:52 -0800 > Tom Eastep <teastep@shorewall.net> wrote: > > > On Mon, 21 Dec 2009 19:08:59 -0500 > > "Brian J. Murrell" <brian@interlinx.bc.ca> wrote: > > > > > > > > I have a very fuzzy picture in my mind. Nothing I can put to > > > paper yet of how I think the configuration could look. I''ve > > > scratched the surface on describing it here, but it''s just a seed > > > of an idea yet. Likely it will evolve as we find out way through > > > this quagmire. > > > > >The simplified tc facility in my current 4.5.0 thread is described at http://www.shorewall.net/simple_traffic_shaping.html. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Sat, 2009-12-26 at 11:09 -0800, Tom Eastep wrote:> > The simplified tc facility in my current 4.5.0 thread is described at > http://www.shorewall.net/simple_traffic_shaping.html.The turn-around on this is awesome Tom! So is band 1 traffic really able to *completely* (as opposed to only *virtually* -- i.e. leaving a small percentage available) starve bands 2 and 3? If so, I think this is good -- I think this is what most people expect. And if so, this sounds like it''s using priority queues instead of one of the borrowing/lending classifiers (to completely butcher the nomenclature). Tom, do you have this installed on your machine? Could you give us a dump of what it ends up looking like in terms of linux''s TC configuration? Or give a brief overview of the TC mechanisms at use here? Again, awesome work. Not that that is any surprise to anyone here who has been hanging around a while. :-) b. ------------------------------------------------------------------------------ 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
On Tue, 29 Dec 2009 15:41:20 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> wrote:> On Sat, 2009-12-26 at 11:09 -0800, Tom Eastep wrote: > > > > The simplified tc facility in my current 4.5.0 thread is described > > at http://www.shorewall.net/simple_traffic_shaping.html. > > The turn-around on this is awesome Tom! > > So is band 1 traffic really able to *completely* (as opposed to only > *virtually* -- i.e. leaving a small percentage available) starve > bands 2 and 3?Yes> If so, I think this is good -- I think this is what > most people expect. And if so, this sounds like it''s using priority > queues instead of one of the borrowing/lending classifiers (to > completely butcher the nomenclature). >As described in the document, it is using PRIO(8). It attaches an SFQ qdisc (tc-sfq(8)) to each of the three classes that PRIO generates. If IN-BANDWIDTH is given, it also invokes ingress policing.> Tom, do you have this installed on your machine? Could you give us a > dump of what it ends up looking like in terms of linux''s TC > configuration? Or give a brief overview of the TC mechanisms at use > here?See attachement. It shows the configuration for one interface (I have it configured on 4).> > Again, awesome work.Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Tue, 29 Dec 2009 15:23:14 -0800 Tom Eastep <teastep@shorewall.net> wrote:> > See attachement. It shows the configuration for one interface (I have > it configured on 4).Hmmm -- looks like I neglected to add the attachment. -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 \________________________________________________ ------------------------------------------------------------------------------ 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