Yup, Andy is right. This is traffic to/from the Internet. After brooding all day about this, my simple scheme to set TOS bits and let nature take its course had major holes: (1) Other apps could set the same TOS bits to any value they want, and those apps would slog it out with my H.323 stuff. Some apps, such as telnet, ssh, and others behave this way by default. This is not good. (2) I could not come up with any way to see what bands the packets were really going to anyway. So I could have the best settings in the world, but with no way to monitor them, they are useless. I needed a way to really control which packets go to what queues and I need a mechanism to monitor the results. So I threw everything out and started over again. Here's the latest script: Thanks to Bert H for that howto. I lifted code directly from chapter 9 and I'm standing on the shoulders of a giant. I set up PRIO qdiscs on each interface and even waded into some details around the u32 filter. Each PRIO qdisc has 3 bands. I set up PFIFO qdiscs for each band. The idea is, traffic will flow with its default behavior within each band. So traffic to/from the VTC device will hopefully honor the TOS bits inside its band, and lower priority traffic will also sort itself out within its band. If I'm reading all the documentation correctly, that's what PFIFO is supposed to do, right? I got really gutsy and used U32 for my filter. I may change this to use FWMARK later on. I read that U32 is the fastest filter - and this is good. But I couldn't come up with a good way to directly monitor which packets hit what filter. But if I use FWMARK, I can log packets for debuggig purposes, and I track exactly which packets trigger what filter if I want. This would be extremely useful for debugging. With U32, the best I can do is watch the end result by looking at qdisc statistics. But I haven't found a direct way to tell which filter sent what packets to which band. Well, here is the script. If anyone else is trying to shape H.323, I would love to hear your ideas. [root@fw firewall-scripts]# more priotest3.sh #!/bin/sh # Useful commands: # # $TC qdisc show Show the various qdiscs # $TC -s qdisc ls dev eth0 Show packet stats on eth0 # $TC filter show Show filters # $TC qdisc del dev eth0 root Set eth0 back to its defaults # # This script sets up 3 band PRIO qdiscs on both the external and # internal interfaces. Each band, in turn, has a PFIFO qdisc. # I chose PFIFO qdiscs in each band to preserve default behavior # within each band. Any traffic to/from the VTC device is # directed to the highest priority PRIO band. Hopefully, within # that band, the trafic follows default behavor and prioritizes # according to the TOS bits set by the application. # Everything else goes to the next priority band, # which should also follow default behavior within that # band. The idea is, we want the VTC traffic to get the highest # priority service, no matter what. Everything else should # follow default behavior, underneath the VTC flow. # # Greg Scott May 31, 2005 # IPTABLES="/usr/local/sbin/iptables" TC="/sbin/tc" INET_IFACE="eth0" TRUSTED1_IFACE="eth1" VTC1_PUBLIC="abc.def.ghi.jkl" VTC1_PRIVATE="192.168.16.4" $TC qdisc del dev $INET_IFACE root $TC qdisc del dev $TRUSTED1_IFACE root $TC qdisc add dev $INET_IFACE root handle 1: prio # This *instantly* creates classes 1:1, 1:2, 1:3 $TC qdisc add dev $TRUSTED1_IFACE root handle 2: prio # This *instantly* creates classes 2:1, 2:2, 2:3 $TC qdisc add dev $INET_IFACE parent 1:1 handle 11: pfifo $TC qdisc add dev $INET_IFACE parent 1:2 handle 12: pfifo $TC qdisc add dev $INET_IFACE parent 1:3 handle 13: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:1 handle 21: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:2 handle 22: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:3 handle 23: pfifo # # This assigns traffic to/from $VTC1_PUBLIC and $VTC1_PRIVATE # to the highest priority band of the queue for the appropriate # interface, and the rest to the next-highest proirity band. # $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $VTC1_PUBLIC flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $VTC1_PUBLIC flowid 1:1 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 1 u32 \ match ip src $VTC1_PRIVATE flowid 2:1 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 1 u32 \ match ip dst $VTC1_PRIVATE flowid 2:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 1:2 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 2:2 [root@fw firewall-scripts]# -----Original Message----- From: Andy Furniss [mailto:andy.furniss@xxxxxxxxxxxxx] Sent: Monday, May 30, 2005 5:59 PM To: Greg Scott Cc: lartc@xxxxxxxxxxxxxxx Subject: Re: Very simple traffic shaping script for H.323 Greg Scott wrote: > The theory - by default, all interfaces have a classless PFIFO queue > with three bands. So all I need to do is set the appropriate DS bits > in the packet header to the EF (Expedited Forward) value and > everything else will just work. Linux will put the packets in the top > PFIFO priority band and they'll go thru my Firewall at Warp 9.9 > regardless of other traffic from other users. > > Assumptions: > (1) I don't care about slowing down other traffic flows. H.323 > packets should be serviced first no matter what. > (2) Any traffic with source or destination public IP Address > "abc.def.ghi.jkl" or private IP Address 192.168.16.4 is to/from from > the videoconference device. I can't really explain all what you see playing with dsmark - but you may have to do things differently anyway. The pfifo fasts that default on interfaces are not going to help you if the link you are shaping has less bandwidth than your eths are capable of. I assume you want to shape traffic that is going over the internet? Andy. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
