Re: [LARTC] Problem deleting tc rules

[Emmett Culley <emmett@webengineer.com>]

Szymon Stefanek wrote:
> On Wednesday 21 November 2007 00:47, Emmett Culley wrote:
> 
>> Szymon Stefanek wrote:
>>> I have an imq device with dynamically attacched classes/qdiscs/filters.
>>> There is a hashing filter that 
>>> [...]
>>> So finally, can I programmatically remove a filter without knowing
>>> exactly its handle ? How ? Is there another way to match filters ? Maybe
>>> on flowid... ? Add/remove by using direct syscalls ?
>> I resolved this by adding "pref <LASTIPOCTETHEX>" to the filter rule:
>>
>> tc filter add dev <iface> parent 1:0 protocol ip pref <user_id> u32 match
>> ip dst <user_ip> flowid 1:<user_id (HEX)>
>>
>> replacing "add" with "del" to remove filter.
>>
>> In my case I used the last two octets to create a user_id value as I am
>> serving DHCP to subnet 172.16.128.0/17
>>
>> Note that the pref value has to be in base 10.
> 
> Hum. I have tried this.
> 
> Or better, my problem manifests when there are collisions of filters
> inside a single hashtable bucket. Since the ht is hashing by last octet
> then a single bucket can contain 2^24 ip addresses (the remaining octets).
> I have then tried using (ipaddress >> 8) as preference value.
> 
> Here comes the first problem: priority values seem to be limited to 16 bits.
> That is, if you add something with priority 0xaffff you'll end up with
> real priority 0xffff which will collide with 0xbffff, for example.
> 
> The second problem is that if I use priority then I get a very different
> filter layout. For each different priority used two additional filter
> lines are printed by "tc filter show"...
> The difference is between:
> 
> filter parent 1: protocol ip pref 5 u32
> filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
> filter parent 1: protocol ip pref 5 u32 fh 2:1:800 order 2048 key ht 2 bkt 1 
> flowid 1:4098  (rule hit 0 success 0)
>   match 0a050001/ffffffff at 16 (success 0 )
> filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 
> 0 link 2:  (rule hit 0 success 0)
>   match 00000000/00000000 at 12 (success 0 )
>    hash mask 000000ff at 16
> 
> where priority wasn't used (and it's working) and
> 
> filter parent 1: protocol ip pref 5 u32
> filter parent 1: protocol ip pref 5 u32 fh 2: ht divisor 256
> filter parent 1: protocol ip pref 5 u32 fh 2:1:800 order 2048 key ht 2 bkt 1 
> flowid 1:4098  (rule hit 0 success 0)
>   match 0a050001/ffffffff at 16 (success 0 )
> filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 
> 0 link 2:  (rule hit 0 success 0)
>   match 00000000/00000000 at 12 (success 0 )
>     hash mask 000000ff at 16
> filter parent 1: protocol ip pref 7 u32
> filter parent 1: protocol ip pref 7 u32 fh 801: ht divisor 1
> 
> where a different priority was used.
> 
> Hm? Looks ugly.
> 
> Now, I'm not a tc expert but the output suggests that a complexier filter
> hierarchy is created in this case and an additional "fh 801:" jumps
> out from nowhere. In both cases the filter I've just added is the third line 
> of the listing: in the second listing it STILL has pref of 5! (????)
> 
> Since I tend to not trust stuff that I don't understand
> at the moment I've choosen the very-dirty-but-at-least-undestandable solution
> of using some grep & sed to get back the filter handle.
> 
> To add:
> 
> tc filter add dev @IMQDEV@ protocol ip parent 1:0 prio 5 u32 ht
>       2:@LASTIPOCTETHEX@: match ip src @IPADDRESS@ flowid 1:@TCCLASSID@
> 
> To remove:
> 
> tc filter del dev @IMQDEV@ parent 1:0 handle
>       $(
>         tc -s filter show dev @IMQDEV@ | grep 'flowid 1:@TCCLASSID@' |
>         sed -e 's/filter[A-Za-z0-9: ]*fh//' | sed -e 's/order.*//'
>        )
>        prio 5 u32
> 
> This forces me to spawn several children through a shell, is strongly
> dependant on tc output (that might change in a future version) and makes batch 
> processing impossible...but at least it works and *maybe* I'll undestand it 
> in one year from now :D
> 
> ...but if somebody comed out with a nicer solution I'd happily use it...
> 
> 
Here's what I show (for one connection):

[root@lab1 ~]# tc filter show dev eth0
filter parent 1: protocol ip pref 65004 u32
filter parent 1: protocol ip pref 65004 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 65004 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:fdec
  match ac13fef6/ffffffff at 16
[

This is with the last two octets (254.246 in this case).

I understand from the docs and much googling that the pref parameter is only to give priority within a class, but in this case each user has it's own qdisc and class rule.  And it seems to be working.

I'd be happy to send you the entire configuration...

Regards,
 Emmett
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc