DSCP and TOS values
Hi,
I am using IPSEC tunnels to connect my home office to our work site.
I am using a cisco voip phone which uses the vpn to talk to the call
manager.
I have worked for a bit to try to give the voip traffic highest priority
with ALTQ.
I have gotten some headway to what I want, but limitations brought on
from the
IPSEC link limits the effectivness of doing this. My VPN link is a gif
tunnel
To a PIX.
Basically, I cannot distinguish general vpn traffic from voip traffic
because pf
Cannot do filtering or classification on gif interfaces.
What does work though, is the DSCP values the voip phone sets on its way
out are
Transferred to the gif tunnel, ie the DSCP value for Expidite Forwarding
(0x2e) is set
On outgoing voip packets.
I also am aware that pf can look at the TOS values for lowdelay to
classify latency sensitve
Packets and queue them appropriatly.
Is it possible, or likely to be possible for pf to be able to examine
the TOS and DSCP
Fields to use for matching rulesets. Also, it would also be desirable
to rewrite these
Values.
If not, I would think that these features would be very desirable for
this software to consider implementing.
I know in the past that ISP's were less that reliable in utilizing
packet classification, but now that voip has become more popular, using
DSCP values set in packets may become more prevailent.
Also, given that there is somewhat support for doing this, it may be a
simple implementation to
Add in rules that may be utilized in the following way:
altq on $ext_if priq bandwidth 10Mb queue { std_out , tcp_ack_out ,
ef_out }
queue std_out priq(default)
queue tcp_ack_out priority 4
queue ef_out priority 7
pass out on $ext_if proto tcp from ($ext_if) to any modulate state flags
S/SA queue ( std_out , tcp_ack_out )
pass out on $ext_if proto { udp, icmp } from ($ext_if) to any keep state
pass out on $ext_if from ($ext_if) to any dscp 0x2e modulate state queue
( ef_out )
Or even if you have some hosts that are setting incorrect dscp values
pass in on $inf_if proto tcp from $internal_net to any port www dscp
0x2e set_dscp 0x00
These are features already available on commercial products like cisco
gear that allow traffic prioritisation
On standard IP attribtues.
Thanks for your time
Adam Clark
Network Administrator
National Gallery of Victoria
PO Box 7259 Melbourne Vic 8004
Telephone: +61 3 8620 2369
Fax: +61 3 8620 2565
www.ngv.vic.gov.au
Keep informed of the latest NGV exhibitions, special events and programs at The
Ian Potter Centre: NGV Australia and NGV International by subscribing to [EMAIL
PROTECTED], the NGV's free e-newsletter.
DISCLAIMER: This email and any files transmitted with it are confidential and
intended solely for [EMAIL PROTECTED] If you are not the named addressee you
should not disseminate, copy or alter this email. WARNING: Although National
Gallery of Victoria has taken reasonable precautions to ensure no viruses are
present in this email, the organisation cannot accept responsibility for any
loss or damage arising from the use of this email or attachment.
Re: DSCP and TOS values
Adam Clark wrote: Hi, I am using IPSEC tunnels to connect my home office to our work site. I am using a cisco voip phone which uses the vpn to talk to the call manager. I have worked for a bit to try to give the voip traffic highest priority with ALTQ. I have gotten some headway to what I want, but limitations brought on from the IPSEC link limits the effectivness of doing this. My VPN link is a gif tunnel To a PIX. Basically, I cannot distinguish general vpn traffic from voip traffic because pf Cannot do filtering or classification on gif interfaces. pf can filter fine on gif interfaces, including matching ToS. You have to apply your rules on the gifN interface, e.g. pass in on gif0 from any to any tos 0x08 pass in on $inf_if proto tcp from $internal_net to any port www dscp 0x2e set_dscp 0x00 IMO It would be very nice if pf supported dscp matching and mangling. -d
RE: DSCP and TOS values
pf can filter fine on gif interfaces, including matching ToS. You have
to apply your rules on the gifN interface, e.g.
pass in on gif0 from any to any tos 0x08
Ahh, I assumed that because no traffic was listed when I tcpdump'd my
gif interface that nothing could be done about it. Its ok as the ToS
values are passed up from the gif interface to the tun interface, so it
doesn't matter where I match it.
But anyway, for some reason the tos matching is only somewhat working.
relevant rules are as follows:
pass out on $ext_if proto esp from ($ext_if) to $cobalt
pass in on $ext_if proto esp from $cobalt to ($ext_if)
pass out on $ext_if proto { tcp , udp } from ($ext_if) to $cobalt port
500
pass in on $ext_if proto { tcp , udp } from $cobalt to ($ext_if) port
500
pass out on $ext_if proto esp from ($ext_if) to $cobalt tos 0x68 queue (
high_out )
pass out log on $ext_if proto esp from ($ext_if) to $cobalt tos 0xb8
queue ( ef_out )
and the queue stats give me the following:
[EMAIL PROTECTED] pfctl -s q -v
queue std_out priq( default )
[ pkts:146 bytes: 37840 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 ]
queue low_out priority 2 priq( red )
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 ]
queue high_out priority 4
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 ]
queue tcp_ack_out priority 5
[ pkts: 50 bytes: 2200 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 ]
queue ef_out priority 6
[ pkts:317 bytes: 75228 dropped pkts: 0 bytes:
0 ]
[ qlength: 0/ 50 ]
Logs show that both ToS values are present:
7. 707142 rule 13/0(match): pass out on tun0: (tos 0x68, ttl 64, id
19839, offset 0, flags [none], proto: ESP (50), length: 136)
203.214.76.15 cobalt: ESP(spi=0x32502e5f,seq=0x942), length 116
059524 rule 13/0(match): pass out on tun0: (tos 0xb8, ttl 64, id 19840,
offset 0, flags [none], proto: ESP (50), length: 264) 203.214.76.15
cobalt: ESP(spi=0x32502e5f,seq=0x943), length 244
Note how the high_out queue has nothing against it. My general traffic
over the VPN is put into std_out, which is fine, but all voice traffic
from my voip phone is places into the ef_out queue, I only want the
traffic with 0x68 to be put there.
pf version is whatever is with FreeBSD 6.0
The TOS/DSCP byte in the packet is somewhat confusing, and maybe I don't
realise what is being matched.
Correct me if I am wrong, but the ToS byte is built as follows:
3 bit IP Precedence value, followed by a 4 bit ToS value, followed by a
zero
P2 P1 P0 T3 T2 T1 T0 zero
Is the tos statement matching on all 8 bits, just the P bits or just the
T bits?
I have investigated this somewhere, and no matter what the answer is,
none of the methods described above with provide the same match.
0x68 011 0100 0
0xb8 101 1100 0
And given the ToS field is actually described in the logs as 0x68 and
0xb8 you would assume it would use all 8 bits to match against.
Adam Clark
Network Administrator
National Gallery of Victoria
PO Box 7259 Melbourne Vic 8004
Telephone: +61 3 8620 2369
Fax: +61 3 8620 2565
www.ngv.vic.gov.au
Keep informed of the latest NGV exhibitions, special events and programs at The
Ian Potter Centre: NGV Australia and NGV International by subscribing to [EMAIL
PROTECTED], the NGV's free e-newsletter.
DISCLAIMER: This email and any files transmitted with it are confidential and
intended solely for [EMAIL PROTECTED],[EMAIL PROTECTED] If you are not the
named addressee you should not disseminate, copy or alter this email. WARNING:
Although National Gallery of Victoria has taken reasonable precautions to
ensure no viruses are present in this email, the organisation cannot accept
responsibility for any loss or damage arising from the use of this email or
attachment.
