[LARTC] Priority queuing using tc not working

* [LARTC] Priority queuing using tc not working
@ 2002-10-18 23:43 Neil Aggarwal
  2002-10-24  3:08 ` Neil Aggarwal
  2002-10-24  6:50 ` nitin panjwani
  0 siblings, 2 replies; 3+ messages in thread
From: Neil Aggarwal @ 2002-10-18 23:43 UTC (permalink / raw)
  To: lartc

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

Hello:

I am trying to set up priority based queue for my VOIP traffic.
I am running a RedHat 8.0 machine that is masquerading my internal network
which has my PC and a VOIP phone.  All VOIP traffic goes to and from
my PBX, which is at 10.0.0.20.

When I use my phone and try to download a file via FTP on my PC, 
all of the packets are going into the low priority queue.

I typed these commands:
  echo 1 > /proc/sys/net/ipv4/ip_forward

  # Create the priority queue
  /sbin/tc qdisc add dev eth0 root handle 1: prio
  /sbin/tc qdisc add dev eth0 parent 1:1 handle 10: sfq
  /sbin/tc qdisc add dev eth0 parent 1:2 handle 20: sfq
  /sbin/tc qdisc add dev eth0 parent 1:3 handle 30: sfq

  # Add filters to put high priority packets into queue 1:1
  /sbin/tc filter add dev eth0 pref 1 protocol ip parent 1:0 u32 match ip src 10.0.0.20 flowid 1:10
  /sbin/tc filter add dev eth0 pref 1 protocol ip parent 1:0 u32 match ip dst 10.0.0.20 flowid 1:10

  # Add a filter to put all remaining packets into queue 1:2
  /sbin/tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:20

As you can see, from the output of '/sbin/tc -s qdisc ls dev eth0' 
there are no packets going into the high priority queue:

qdisc sfq 30: quantum 1514b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 qdisc sfq 20: quantum 1514b
 Sent 432501 bytes 5118 pkts (dropped 0, overlimits 0)

 qdisc sfq 10: quantum 1514b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 432501 bytes 5118 pkts (dropped 0, overlimits 0)

Here is the output of /sbin/tc -s filter ls dev eth0:
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 801::800 order 2048 key ht 801 bkt 0                                             flowid 1:20
  match 00000000/00000000 at 16
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0                                             flowid 1:10
  match 0a000014/ffffffff at 12
filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0                                             flowid 1:10
  match 0a000014/ffffffff at 16
filter parent 1: protocol ip pref 2 u32
filter parent 1: protocol ip pref 2 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 2 u32 fh 801::800 order 2048 key ht 801 bkt 0                                             flowid 1:20
  match 00000000/00000000 at 16
filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 800 bkt 0                                             flowid 1:10
  match 0a000014/ffffffff at 12
filter parent 1: protocol ip pref 2 u32 fh 800::801 order 2049 key ht 800 bkt 0                                             flowid 1:10
  match 0a000014/ffffffff at 16

Any ideas why the high priority traffic is not getting separated from the
rest?

Thanks,
  Neil

^ permalink raw reply	[flat|nested] 3+ messages in thread