3

For traffic shaping I'm currently using a setup that looks exactly like the setup from LARTC, on this page:

http://lartc.org/howto/lartc.adv-filter.hashing.html

I have a simple problem with that - everytime I want to modify something in the hash table (like assign a IP to different flowid), I need to delete the whole filter table and add it again filter by filter. (I actually don't do it by hand, I have a nice program that does it for me... but still...) There is a problem - I got roughly 10k filters allocated this way and deleting and refilling the whole filtertable can get pretty lengthy, which is not exactly good for traffic shaping. My program could easily manage to delete only the rules that need to be deleted (thus reducing the whole problem to several commands and miliseconds), but I simply don't know the command that deletes only the one hashing rule.

My tc filter show:

filter parent 1: protocol ip pref 1 u32 
filter parent 1: protocol ip pref 1 u32 fh 2: ht divisor 256 
filter parent 1: protocol ip pref 1 u32 fh 2:a:800 order 2048 key ht 2 bkt a flowid 1:101 
  match 0a0a0a0a/ffffffff at 16
filter parent 1: protocol ip pref 1 u32 fh 2:c:800 order 2048 key ht 2 bkt c flowid 1:102 
  match 0a0a0a0c/ffffffff 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 link 2: 
  match 00000000/00000000 at 16
    hash mask 000000ff at 16 

The wish: 'tc filter del ...' command that removes only one specific filter (for example the 0a0a0a0a IP match (IP address 10.10.10.10)). Removal of some small subgroup would also be good - for example I could still recreate a bucket (bkt a) pretty fast.

My attempts: I tried to number all the filters using prio, but with no help -- they just create something unusuable (but deletable) below, but the bucketed filters remain there after that gets deleted.

Any ideas?


edit - I'm adding a simplified tl;dr description of the problem:

  1. I created hash filter on some interfce just like in this http://lartc.org/howto/lartc.adv-filter.hashing.html

  2. I want to find a command that deletes one rule (e.g. 1.2.1.123) from the table, leaving the rest untouched and working.

exa
  • 571
  • 4
  • 14

3 Answers3

3

I know this is an old post but I'm using this and it seems to work well:

Add filter:

tc filter add dev eth1 parent 1: handle ::100 prio 1 protocol ip u32 match ip dst 10.10.10.10/32 flowid 1:100

Delete filter:

tc filter del dev eth1 parent 1: handle 800::100 prio 1 protocol ip u32

Just change the number '100' for each filter you need

Jak
  • 998
  • 9
  • 12
  • Works! thanks very much. I had some mess in actual prio's and other stuff, this clarified all of that. – exa Jul 14 '12 at 10:56
0

I know this is an old question, but I just want to post this here for anyone looking for a detailed answer. The accepted answer works, but does not explain how it works.


A filter handle (e.g 2:a:800) has 3 parts being:

  • the hashtable 2
  • the bucket a (inside hash table 2)
  • the filter index 800 (inside bucket a)

These 3 are all in hex. A hash table can have many buckets. A bucket can have many filters.

If not defined during creation, TC will create default handle for you which is 800:0:800, 800:0:8001 and so on.

To delete the filter 800 inside bucket a of hash table 2, you will do:

tc filter del dev eth1 handle 2:a:800 prio 1 u32
0

I tried the following command and it seems working:

$ sudo tc filter delete dev eth1 protocol ip parent 1: prio 1 u32 match ip src 10.10.10.10 flowid 1:2

The same command worked with add, replace and delete options after the word filter.

Khaled
  • 35,688
  • 8
  • 69
  • 98
  • Nope, this deletes all filters for me :( What is your kernel/iproute version combination? maybe it's some kind of bug after all... – exa Nov 15 '11 at 12:49
  • Linux kernel 2.6.32 and iproute2 – Khaled Nov 15 '11 at 13:41
  • Strange, I got the same kernel. Could you provide the whole code you used for doing the test? Maybe I'm creating the rules wrong way... – exa Nov 16 '11 at 09:03