Linux Router, QoS and tc - Networking

This is a discussion on Linux Router, QoS and tc - Networking ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Linux Router, QoS and tc

  1. 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.

  2. Re: Linux Router, QoS and tc

    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.

+ Reply to Thread