SOLVED: Traffic control / shaping / tc filter

[DerReisende]

Hi everybody,

I'm trying to do some traffic control on a network interface but after two days full of Google I'm really stuck.

Interface eth1 leads to a VPN appliance which is connected to internet by 1 MBit/sec sync. DSL.

This is what's on my mind:
1. Traffic to appliance itself is not to be limited (internal webserver for configuration)
2. Traffic to VPN is to be sent before traffic to appliance itself
3. Certain packets on VPN (especially Citrix) are to be sent before other VPN packets

At this time my script looks like this:

[frostschutz]

It's usually a bad idea to not put the rate limiting scheduler at the top. How can HTB guarantee a rate of 1000kbit if it does not control everything, i.e. there is other traffic that can take away bandwidth? Having a prio inside a prio again is questionable, without additional code it does not even have an effect because it will end up all in the same prio band. Then assigning SFQ to every child is dangerous; every SFQ is a queue by itself, by default it holds 128 packets, with three sfq queues you will hold up to 384 packets (read: in worst case 1 packet has to wait for 383 other packets to be sent first), introducing lag. You can limit the queue size with the limit parameter, but SFQ is always a fairness / lag tradeoff.

tc filters always go to the qdisc. So if you have a qdisc that is a child of a class of another qdisc, you need a filter for each qdisc. In other words, a filter of qdisc A can not put packets into a class of qdisc B. Instead A puts them in the class that has B assigned and then B puts it into its own class with its own filter. In other words, your parent 1: flowid 4: is wrong.

[DerReisende]

Using multiple tc filter commands for each qdisc, traffic control finally works fine for several days now. Latency improvement and connection reliability exceed all expectations.

For those who are interested in the final configuration: