Linux Router, QoS and tc

Hi

I am doing some lab setup in which I am running Fedora 9 as Linux
Router and for traffic shaping I am using tc. I am testing some QoS
benchmarks for the VoIP and Normal Data traffic.


The traffic which I am sending are already marked with the ToS values
and I dont need Nating. Therefore I am not using any postrouting or
mangling.

The problem is that I have created the following rules both script 1
and script 2. The VoIP traffic delay is suffered 4000 times more than
that of the normal traffic.

I dont know what is the problem. Do I need to place the tc on the
ingress interface as well?

Script 1
# tc qdisc add dev eth1 root handle 1: htb default 20
# tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit ceil
100mbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1mbit ceil
100mbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 99mbit ceil
99mbit
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip
tos 46 0xff flowid 1:10
# tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip
tos 0 0xff flowid 1:20

Script 2
# tc qdisc add dev eth1 root handle 1: htb default 20
# tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit ceil
100mbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1mbit ceil
100mbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 99mbit ceil
99mbit
# tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip
tos 46 0xff flowid 1:10
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip
tos 0 0xff flowid 1:20



I have seen the filter, and class are matching with the respected flow
(by sending only the single flow at a time).

Thanks in advance. Need it urgently.

Asif wrote:
> Hi
>
> I am doing some lab setup in which I am running Fedora 9 as Linux
> Router and for traffic shaping I am using tc. I am testing some QoS
> benchmarks for the VoIP and Normal Data traffic.
>
>
> The traffic which I am sending are already marked with the ToS values
> and I dont need Nating. Therefore I am not using any postrouting or
> mangling.
>
> The problem is that I have created the following rules both script 1
> and script 2. The VoIP traffic delay is suffered 4000 times more than
> that of the normal traffic.
>
> I dont know what is the problem. Do I need to place the tc on the
> ingress interface as well?

Maybe but you need to do things differently for ingress and if it's a
lab test you should know if you are flooding inbound or not.

>
> Script 1
> # tc qdisc add dev eth1 root handle 1: htb default 20
> # tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit ceil
> 100mbit

I already suggested 95mbit in your other thread.
You could look up the real overheads on eth and use the htb overhead
parameter. When placed on eth tc will see the frame length as ip+14, but
there are more than that on the wire (preamble,CRC,interframe gap).
There is also by default an 8 byte granularity in the rate lookup
tables, on older kernels/tc the error resulted in overrate, more
recently it has been changed to underrate.

> # tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1mbit ceil
> 100mbit
> # tc class add dev eth1 parent 1:1 classid 1:20 htb rate 99mbit ceil
> 99mbit
> # tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip
> tos 46 0xff flowid 1:10

If this the voip, tos 46=0x2e doesn't seem quite right according to

http://www.networksorcery.com/enp/protocol/ip.htm

It doesn't matter as you are matching anyway. If it is voip then why do
you need to limit it to 1 meg? HTB works better if you give the
interactive class more bandwidth than it's ever going to use and also
use the prio parameter on the classes 0 is top.

> # tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip
> tos 0 0xff flowid 1:20

redundant as default is 20 which means non ip aswell, personally
assuming non ip on the network is just arp, I would not use htb default
but make a catch all ip filter instead.

I guess this is just a test, what I would do in practise would depend on
the problem you are trying to fix and the traffic patterns you are
dealing with.