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.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
