Hello All-
I''m relatively new to iptables, new to shorewall and very new to this
list, so I hope I''m not bringing up an overly dead-horse subject...
I am running Shorewall 3.0.8 on Gentoo Linux with a 2.6.17-r8 kernel,
alongside dnsmasq for DHCP and local DNS forwarding.
I am trying to set up traffic control on my Shorewall box so that my
voip ATA (an IAX-based adapter that lives at 192.168.0.148 and uses UDP
and port 4569 exclusively) receives priority over other traffic.
I set up the configs in tcclasses, tcdevices and tcrules sticking very
close to the examples. I''ll refrain from posting specific lines here,
since presumably the attached shorewall dump should capture those
configs as well as the netfilter and kernel capabilities. [If this is
not the case, please {gently} let me know and I will be happy to post
the relevant portions of my config files!]
Upon testing the attached configuration, I find that my voip performance
is very poor: outbound audio becomes very choppy when, for example, an
outbound FTP transfer is started or a number of p2p connections are
active. Additionally, a significant delay (upwards of 2-3 seconds)
develops on the voip outbound audio when competing traffic is present.
Meanwhile, if I start the same FTP transfer, I can observe the outgoing
bandwidth indicators on my p2p transfers dropping. For a steady
40kbyte/second outgoing FTP transfer, the p2p outgoing bandwidth might
drop from 8kbyte/second (the userspace limit) down to about
2-3kbyte/second. This seems to indicate that my tcrules marking p2p
traffic for tcclass "4" are working, but my tcrules marking voip
traffic
for tcclass "1" are not.
My question is not as much "how do I fix it?" as "how do I
diagnose the
problem?" I have set outgoing voip packets to be logged at the
''info''
level, but this does not appear to include the packet or connection
marks, so I can''t verify that my voip traffic is being marked
correctly.>From there, I don''t know how to verify that marked traffic is being
correctly controlled by the appropriate classes.
Thanks in advance for any help you''re able to render,
[Dave]
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
David Rea wrote:> > My question is not as much "how do I fix it?" as "how do I diagnose the > problem?" I have set outgoing voip packets to be logged at the ''info'' > level, but this does not appear to include the packet or connection > marks, so I can''t verify that my voip traffic is being marked correctly. >>From there, I don''t know how to verify that marked traffic is being > correctly controlled by the appropriate classes. > > Thanks in advance for any help you''re able to render,The VOIP traffic seems to be originating on your firewall and you are not marking traffic from fw->net. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
On Fri, 2006-10-13 at 07:49 -0700, Tom Eastep wrote:> The VOIP traffic seems to be originating on your firewall and you are not > marking traffic from fw->net.My problem was indeed that the packets were not being correctly marked. By creating the following rules, I cover all my network''s IAX voip traffic: 1 $FW 0.0.0.0/0 tcp 4569 1 $FW 0.0.0.0/0 udp 4569 1 192.168.0.148 0.0.0.0/0 tcp 4569 1 192.168.0.148 0.0.0.0/0 udp 4569 The first pair covers traffic between asterisk (running on the firewall) and the remote IAX carrier server, and the second pair covers traffic originating at my IAX ATA. My diagnostic technique, while a bit kludgy, eventually got me to the answer: 1) Restart shorewall, clearing all packet counters. 2) Run `shorewall dump` to verify packet counters for each class are zero. 3) Make a voip call with no competing traffic. 4) Run `shorewall dump` again to see which class the traffic fell into. By repeating this procedure and changing the config files, I was able to determine that my traffic was all falling into class 3, which is both the default class in tcclasses, and which has a rule in tcrules to catch other unmarked traffic. By commenting out the class 3 rule, and observing that the traffic was still falling into class 3, I realized that the rules to catch voip traffic in class 1 were not effective.>From there, it was just a matter of realizing that "$fw" is NOT THE SAME THING as "$FW"! I can now make a voip call with a large (>500KiB/sec) FTP transfer ongoing, and suffer no loss in quality and negligble voice delay.Thanks for pointing me in the right direction, Dave ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
David Rea wrote:> > 1) Restart shorewall, clearing all packet counters.''shorewall reset'' does that a lot faster.> 2) Run `shorewall dump` to verify packet counters for each class are zero.''shorewall show tc'' produces much less output (and shows all of the classes). ''Shorewall show mangle'' shows all of the marking rules (see http://www.shorewall.net/PacketMarking.html).> 3) Make a voip call with no competing traffic. > 4) Run `shorewall dump` again to see which class the traffic fell into. >> >>From there, it was just a matter of realizing that "$fw" is NOT THE SAME THING as "$FW"!Indeed! This is Unix, where almost everything is case-sensitive.> I can now make a voip call with a large (>500KiB/sec) FTP transfer ongoing, and suffer > no loss in quality and negligble voice delay.Excellent. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Tom Eastep wrote:> David Rea wrote: > >> 1) Restart shorewall, clearing all packet counters. > > ''shorewall reset'' does that a lot faster.Ah -- but it doesn''t reset the tc class counters. Only the Netfilter counters. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642