IP QoS doesn't seems to work

An area specifically for port forwarding, firewalls and other (on-line) security related issues.
Post Reply
phoenix_me
Novice
Novice
Posts: 28
Joined: Thu Jun 18, 2009 3:53 pm

IP QoS doesn't seems to work

Post by phoenix_me » Sat Jun 20, 2009 2:48 pm

For example if I set IP QoS as below:

Code: Select all

Name       Source            Source     Destination  Protocol  Priority
           IP                PortStart  PortStart
           Mask              PortEnd    PortEnd

POP3       10.10.1.0                    110          TCP        HIGH
           255.255.255.0                110

TORRENT    10.10.1.0         5555                    TCP        LOW
           255.255.255.0     5666
then regardles of Enable/Disable of IP QoS when connection is under heavy load of torrent files the process of connecting and receiving e-mail is VERY SLOW.
How can I check if rules are working good? Is there any log where I can check if router is really trying to push the TCP 110 at the begining of queue?
phoenix_me
Novice
Novice
Posts: 28
Joined: Thu Jun 18, 2009 3:53 pm

Post by phoenix_me » Sat Jun 20, 2009 2:55 pm

Maybe I found the reason.
In my LAN configuration Ethernet1-4 and WLAN are in 'LAN group 1'

Which connection I should choose when configuring IP QoS? The name of configured WAN connection or 'LAN group 1' ? (rigth now the WAN connection is choosen)
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Mon Jun 22, 2009 8:33 pm

The built in TI QOS doesn't see local addresses when it is applied to outgoing traffic on the internet connection, so you are best to make rules just based on ports/protocols.

Unfortunately just using ports doesn't really work on torrents as many of the connections will not be on the listening port.

There are no easy solutions for QOS as it depends on traffic patterns, but as a start if I used TI's QOS I would make UDP and tcp gameserver dst IPs top, tcp port 80/pop port med and everything else low.

Routertech does have another shaper (rshaper?) which I believe can limit rate by IP, though I have never tried it.
phoenix_me
Novice
Novice
Posts: 28
Joined: Thu Jun 18, 2009 3:53 pm

Post by phoenix_me » Fri Jun 26, 2009 7:22 pm

legume wrote:The built in TI QOS doesn't see local addresses when it is applied to outgoing traffic on the internet connection, so you are best to make rules just based on ports/protocols.
If you are right regarding local addresses, what is the reason to have fields with IP address ports available for outgoing and incoming connections?
legume wrote:Unfortunately just using ports doesn't really work on torrents as many of the connections will not be on the listening port.
What do you mean that connections will not be on the listening port? I know exactly the range of ports in my torrent application, the whole traffic - incoming and outgoing need to go through those ports.
legume wrote:There are no easy solutions for QOS as it depends on traffic patterns, but as a start if I used TI's QOS I would make UDP and tcp gameserver dst IPs top, tcp port 80/pop port med and everything else low.
Isn't it that IP QoS assigns to everything that is not defined by rules a low priority? If so, what is the reason to assign a medium instead of high to the things that we want to have higher priority than anything else, both in outgoing and incoming traffic?
legume wrote:Routertech does have another shaper (rshaper?) which I believe can limit rate by IP, though I have never tried it.
I was never use it before either. Maybe I will try if I loose my fight with IP QoS.

Is it any place where I can check if my rules are working and which packets are processed by which rule?
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Sat Jun 27, 2009 6:19 pm

phoenix_me wrote:
legume wrote:The built in TI QOS doesn't see local addresses when it is applied to outgoing traffic on the internet connection, so you are best to make rules just based on ports/protocols.
If you are right regarding local addresses, what is the reason to have fields with IP address ports available for outgoing and incoming connections?
Not every WAN connection uses NAT - I have a block of static IPs on a home dsl connection.
phoenix_me wrote:
legume wrote:Unfortunately just using ports doesn't really work on torrents as many of the connections will not be on the listening port.
What do you mean that connections will not be on the listening port? I know exactly the range of ports in my torrent application, the whole traffic - incoming and outgoing need to go through those ports.
Well I can't say I've tested that many torrent apps, but the ones I have use the specified ports as listening ports. These get sent to the tracker so others can connect to you. When you first join a torrent, though, what I've seen is that you will get a list of addresses/ports and you will connect to them with source ports other than those specified as listening ports.

You can see details of connections if you telnet/ssh into you router and -

cat /proc/net/ip_conntrack
phoenix_me wrote:
legume wrote:There are no easy solutions for QOS as it depends on traffic patterns, but as a start if I used TI's QOS I would make UDP and tcp gameserver dst IPs top, tcp port 80/pop port med and everything else low.
Isn't it that IP QoS assigns to everything that is not defined by rules a low priority? If so, what is the reason to assign a medium instead of high to the things that we want to have higher priority than anything else, both in outgoing and incoming traffic?
It's been a long time since I tested TI QOS, but IIRC that doesn't happen unless you actually make a rule (preferably the last, I guess) to make tcp low.

As for setting medium - it's a matter of choice I suppose. High will totally block lower traffic so I personally would not, on a shared connection, assign anything I expected to max the bandwidth to that so as not to totally starve out other users/traffic. You can, as I guess you've seen, adjust the proportions of bandwidth distribution between medium and low.
phoenix_me wrote:
legume wrote:Routertech does have another shaper (rshaper?) which I believe can limit rate by IP, though I have never tried it.
I was never use it before either. Maybe I will try if I loose my fight with IP QoS.

Is it any place where I can check if my rules are working and which packets are processed by which rule?
Unfortunately not, unlike normal Linux QOS the TI seems to have stats disabled (well it does on my old 2meg flash firmware)

In case it's different for your firmware try (assuming your wan is ppp0) -

tc -s qdisc ls dev ppp0

tc -s filter ls dev ppp0

The filter command will show the rules, but there is duplication which makes it very hard to see what's going on - it's not exactly user friendly even without the duplication.
phoenix_me
Novice
Novice
Posts: 28
Joined: Thu Jun 18, 2009 3:53 pm

Post by phoenix_me » Sun Jun 28, 2009 7:53 pm

legume wrote:
phoenix_me wrote:
legume wrote:The built in TI QOS doesn't see local addresses when it is applied to outgoing traffic on the internet connection, so you are best to make rules just based on ports/protocols.
If you are right regarding local addresses, what is the reason to have fields with IP address ports available for outgoing and incoming connections?
Not every WAN connection uses NAT - I have a block of static IPs on a home dsl connection.
So, you meant local addresses as NAT and not as entity within your local Router ports. Anyway still one of the Router ports will be a WAN connection and rest of them will be a local ports/connections. Only difference is that they will visible from outside because of public ip. Therefore there will be a direct addressing and not NAT.
So in your case it will be - RECEIVE a packet, check IP, check if there is a rule for that IP, apply rule and SEND packet to destination.
In My case - RECEIVE a packet - do NAT - check if there is a rule for that NAT IP, apply rule and SEND packet to destination.
Can't see any reason why it should not work for local addresses.
legume wrote:
phoenix_me wrote:
legume wrote:Unfortunately just using ports doesn't really work on torrents as many of the connections will not be on the listening port.
What do you mean that connections will not be on the listening port? I know exactly the range of ports in my torrent application, the whole traffic - incoming and outgoing need to go through those ports.
Well I can't say I've tested that many torrent apps, but the ones I have use the specified ports as listening ports. These get sent to the tracker so others can connect to you. When you first join a torrent, though, what I've seen is that you will get a list of addresses/ports and you will connect to them with source ports other than those specified as listening ports.

You can see details of connections if you telnet/ssh into you router and -

cat /proc/net/ip_conntrack
Looks like netstat statistics.
On my list all used ports are exactly in range specified in my torrent application. No other ports are used and I can't see anything strange.
legume wrote:
phoenix_me wrote:
legume wrote:There are no easy solutions for QOS as it depends on traffic patterns, but as a start if I used TI's QOS I would make UDP and tcp gameserver dst IPs top, tcp port 80/pop port med and everything else low.
Isn't it that IP QoS assigns to everything that is not defined by rules a low priority? If so, what is the reason to assign a medium instead of high to the things that we want to have higher priority than anything else, both in outgoing and incoming traffic?
It's been a long time since I tested TI QOS, but IIRC that doesn't happen unless you actually make a rule (preferably the last, I guess) to make tcp low.

As for setting medium - it's a matter of choice I suppose. High will totally block lower traffic so I personally would not, on a shared connection, assign anything I expected to max the bandwidth to that so as not to totally starve out other users/traffic. You can, as I guess you've seen, adjust the proportions of bandwidth distribution between medium and low.
I am assigning only high to those I am sure that will not use a 100% of bandwidth
legume wrote:
phoenix_me wrote:
legume wrote:Routertech does have another shaper (rshaper?) which I believe can limit rate by IP, though I have never tried it.
I was never use it before either. Maybe I will try if I loose my fight with IP QoS.

Is it any place where I can check if my rules are working and which packets are processed by which rule?
Unfortunately not, unlike normal Linux QOS the TI seems to have stats disabled (well it does on my old 2meg flash firmware)

In case it's different for your firmware try (assuming your wan is ppp0) -

tc -s qdisc ls dev ppp0

tc -s filter ls dev ppp0

The filter command will show the rules, but there is duplication which makes it very hard to see what's going on - it's not exactly user friendly even without the duplication.
Now I can see what you mean 'not exact user friendly'.
First command:

Code: Select all

/var # tc -s qdisc ls dev ppp0
qdisc priowrr 51: weightmap 100 100 50 50 qlenmap 30 15 27 28
statistics truncated
It seems that for some reason statistic is truncated...

next one

Code: Select all

/var # tc -s filter ls dev ppp0                             
filter parent 51: protocol ip pref 3 u32                     
filter parent 51: protocol ip pref 3 u32 fh 80c: ht divisor 1 
filter parent 51: protocol ip pref 3 u32 fh 80c::800 order 2048 key ht 80c bkt 0 flowid 51:4 
  match 0a0a0100/ffffff00 at 16                                                              
  match 00000000/00000000 at 8                                                               
  match 00001cfd/00001d73 at 20                                                              
filter parent 51: protocol ip pref 3 u32 fh 80b: ht divisor 1                                
filter parent 51: protocol ip pref 3 u32 fh 80b::800 order 2048 key ht 80b bkt 0 flowid 51:4 
  match 0a0a0100/ffffff00 at 12                                                              
  match 00000000/00000000 at 8                                                               
  match 1cfd0000/1d730000 at 20                                                              
filter parent 51: protocol ip pref 3 u32 fh 80a: ht divisor 1                                
filter parent 51: protocol ip pref 3 u32 fh 80a::800 order 2048 key ht 80a bkt 0 flowid 51:2 
  match 0a0a0100/ffffff00 at 12                                                              
  match 00060000/00ff0000 at 8                                                               
  match 00000050/00000050 at 20
and so on for several pages... don't understand it even a little bit. I can't see and association to rule, ip, anything
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Mon Jun 29, 2009 5:22 pm

Linux QOS sees traffic closer to the wire than iptables, so if you are doing NAT then it will only see the public address.

On a full Linux setup the workaround is to use iptables to mark the packets, then use tc to match those marks.
Unless things have changed, you can't do that with routertech kernel as the iptables mark/ tc fw mark match are not compiled in.

filter parent 51: protocol ip pref 3 u32 fh 80a: ht divisor 1
filter parent 51: protocol ip pref 3 u32 fh 80a::800 order 2048 key ht 80a bkt 0 flowid 51:2
match 0a0a0100/ffffff00 at 12
match 00060000/00ff0000 at 8
match 00000050/00000050 at 20
flowid 51:2 is high prio, 51.3 med and 51.4 low. There is a 51.1 that's really high, but TI reserve this (IIRC for routers with voip)

match 0a0a0100/ffffff00 at 12

Source address is 12 bytes into an IP packet this matches 10.10.1.0/24 as ffffff00 is a mask.

match 00060000/00ff0000 at 8

10th byte is protocol 6 = tcp

match 00000050/00000050 at 20

IP header is normally 20 bytes next is tcp header first 8 bytes are source/dest port 0x50 = dst port 80.

I don't understand why the mask is not 0000ffff maybe TI logic is buggy (assuming intention was to match just port 80)

I notice one of your matches is -

match 0a0a0100/ffffff00 at 16

which is dst address 10.10.1.0/24 - just in case you don't know when you apply qos to ppp0 it only sees outgiong packets.
phoenix_me
Novice
Novice
Posts: 28
Joined: Thu Jun 18, 2009 3:53 pm

Post by phoenix_me » Tue Jun 30, 2009 5:02 pm

legume wrote: I notice one of your matches is -

match 0a0a0100/ffffff00 at 16

which is dst address 10.10.1.0/24 - just in case you don't know when you apply qos to ppp0 it only sees outgiong packets.
I am pasting below my rules as a screenshot. Maybe my mistakes are because of misunderstanding of IP QoS or maybe because of implementation in RouterTech.

What I was trying to achieve was: Ports for torrent should have low priority. When available they can go on full throttle upload/download. But when I will be using web browser (80,443) e-mail (110,25,995,465) etc then those should have a higher priority over torrent traffic.
Attachments
IP_QoS_rules.jpeg
dataman
Novice
Novice
Posts: 26
Joined: Wed May 24, 2006 10:50 am
Location: UK

Post by dataman » Wed Jul 01, 2009 12:06 pm

One possible problem.
torrent in should have 10.10.1.0 as DESTINATION IP
torrent out should have 10.10.1.0 as SOURCE IP
in both cases only destination ports are defined ports (4217-5397), source ports are always random available ports.
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Thu Jul 02, 2009 9:01 pm

I've played about a bit with this and had a look at the sources, so I now know that TI have modified the u32 match, so it's not buggy and I can get ports to go to high OK.

I am still a bit curious about how your torrent client can choose src port for outbound connections is it linux rtorrent from http://libtorrent.rakshasa.no/ ?

When applied to ppp0 the queue will only see outgoing packets, so there is no point trying to make a rule to catch inbound traffic.

If you need to shape inbound traffic then you'll need to use rshaper and set it to about 80% of your bandwidth. Shaping from the wrong end of the bottleneck is not as easily done as outbound where you are at the right end.

Looking at the rules you posted, I think the thing that's stopping them working is the addresses - if you just use the ports alone it should work. Work meaning that the acks for those ports will get prio which should speedup things - but that's assuming you are not flooded with inbound traffic.
Post Reply