[LARTC] Re: Policing based on port numbers

[Andy Furniss]

Christian Benvenuti wrote:

>> I've never managed to find a way to use the word tcp in a filter without 
>> getting an illegal match - I know it's in the help.
> 
> The reason it does not work is that the keywords that refer to the L4
> protocols (such as tcp) are supposed to be used when:
> 1) the u32 filter is inserted into a u32 hash table
> AND
> 2) you jump to the above hash table from a u32 filter configured with
>    the "offset" option.
> 
> (unfortunately the U32 classifier is not well documented)

Ahh thanks I'll have to try some hashing tests. Last time I tried I 
found that going above 512 buckets didn't work so I gave up and still 
haven't looked into turning things up (I assume that's possible)

> 
>> If you want to match tcp use the ip protocol match
>>
>> tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match
>> ip dport 0xXYZ 0xFFFF match ip protocol 0x06 0xff police .....
> 
> You should invert the order of the two "match" conditions: first you make
> sure it is TCP, and then you test the destination port number.
> 

Hmm - does that really matter - I did it that way because, judging by 
filter counters the first match that fails stops further matching. It 
depends on what you match and your traffic patterns, but it seemed like 
it would be more efficient.

> This filter works in most cases, but not always: it does not take into
> account the IP options. IP packets with options in the IP header will
> not match.
> The reason is that "ip dport" is equivalent to "offset 22" from the
> beginning of the IP header.

I wonder how many packets there are like that in the wild - I don't have 
  much traffic to test. It's possible to make a fall through counter by 
making a match and not specifying a class/flowid, though ISTR seeing a 
patch recently that made me think that won't work anymore.

Andy.