Maybe my idea from the other day isn't so simple.
When I run tcpdump and watch my h.323 packet stream, tcpdump shows a
stream that looks like this:
.
.
.
09:16:09.031943 abc.def.ghi.jkl.3230 > mno.pqr.stu.vwx.3230: udp 92 [tos
0xb8]
09:16:09.048128 mno.pqr.stu.vwx.3230 > abc.def.ghi.jkl.3230: udp 92
09:16:09.071137 abc.def.ghi.jkl.3232 > mno.pqr.stu.vwx.3232: udp 245
[tos 0xb8]
09:16:09.071535 abc.def.ghi.jkl.3232 > mno.pqr.stu.vwx.3232: udp 245
[tos 0xb8]
09:16:09.076762 mno.pqr.stu.vwx.3232 > abc.def.ghi.jkl.3232: udp 262
.
.
.
where abc.dev... is the IP Addr of the listening H.323 device and
mno.pqr... is the IP Addr of the calling system.
This spawns 2 questions. First, what's up with the tos bits? The TOS
field is only 5 bits and it's obsolete anyway, so clearly when tcpdump
shows tos bits it must mean something else. Is tcpdump showing me the
whole DS octet? Or the leftmost 6 bits of the DS octet? Or what? From
what I've been reading, that DS octet has been carved up so many
different ways over the years that I am now hopelessly confused.
Next, why don't all packets show a tos field? My iptables rules should
put a value in the DS octet for everything to/from that IP Address (see
below). So why aren't they in there?
Here are some test results.
In the test below, the conversation used 768 packets. Yet it only set
the DSCP bits in 472 packets. And tcpdump shows a different value
anyway.
What's going on here???? (Note that I modified the script from last
night slightly as a troubleshooting step. That's why there are 4 rules
below instead of two rules.)
[root@fw firewall-scripts]# /usr/sbin/tcpdump -i eth0 host
abc.def.ghi.jkl -n
.
.
.
768 packets received by filter
0 packets dropped by kernel
[root@fw firewall-scripts]# /usr/local/sbin/iptables -L -v -n -t mangle
Chain PREROUTING (policy ACCEPT 25M packets, 14G bytes)
pkts bytes target prot opt in out source
destination
293 64981 DSCP all -- * * 192.168.16.4
0.0.0.0/0 DSCP set 0x2e
0 0 DSCP all -- * * 0.0.0.0/0
192.168.16.4 DSCP set 0x2e
0 0 DSCP all -- * * abc.def.ghi.jkl
0.0.0.0/0 DSCP set 0x2e
179 36722 DSCP all -- * * 0.0.0.0/0
abc.def.ghi.jkl DSCP set 0x2e
Here is the exact script that generated the rules above:
[root@fw firewall-scripts]# more vtc-ds.sh
#!/bin/sh
VTC1_PRIVATE="192.168.16.4"
VTC1_PUBLIC="abc.def.ghi.jkl"
IPTABLES="/usr/local/sbin/iptables"
$IPTABLES -t mangle -F
$IPTABLES -t mangle -A PREROUTING -s $VTC1_PRIVATE -j DSCP
--set-dscp-class EF
$IPTABLES -t mangle -A PREROUTING -d $VTC1_PRIVATE -j DSCP
--set-dscp-class EF
$IPTABLES -t mangle -A PREROUTING -s $VTC1_PUBLIC -j DSCP
--set-dscp-class EF
$IPTABLES -t mangle -A PREROUTING -d $VTC1_PUBLIC -j DSCP
--set-dscp-class EF
[root@fw firewall-scripts]#
- Greg Scott
-----Original Message-----
From: lartc-bounces@xxxxxxxxxxxxxxx
[mailto:lartc-bounces@xxxxxxxxxxxxxxx] On Behalf Of Greg Scott
Sent: Sunday, May 29, 2005 11:15 PM
To: lartc@xxxxxxxxxxxxxxx
Subject: Very simple traffic shaping script for H.323
Hello -
What I want to do seems very simple - I want to make sure any H.323
traffic gets processed before anything else entering or leaving this
network. The network has a videoconferencing device on the LAN at
192.168.16.4. A Linux firewall NATs an external IP Address to this
internal address and I have appropriate SNAT and DNAT rules that work.
The NAT and connection tracking rules all work great. Now I need to
make sure other traffic in and out of this network does not interfere
with the H.323 flow.
After pouring over several RFCs, Howto documents, and lots of other
documentation, I think this very simple script will do the trick.
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.
After all the reading and studying, is it really this simple? Does
anyone have ideas on how to test this? How do I watch packets to see
which packets go into what PFIFO band?
#!/bin/sh
VTC1_PRIVATE="192.168.16.4"
VTC1_PUBLIC="abc.def.ghi.jkl"
IPTABLES="/usr/local/sbin/iptables"
$IPTABLES -t mangle -F
$IPTABLES -t mangle -A PREROUTING -s $VTC1_PRIVATE -j DSCP
--set-dscp-class EF
$IPTABLES -t mangle -A PREROUTING -d $VTC1_PUBLIC -j DSCP
--set-dscp-class EF
thanks
- Greg Scott
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
