Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Emmett Culley <emmett@webengineer.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Problem deleting tc rules
Date: Tue, 20 Nov 2007 23:47:07 +0000	[thread overview]
Message-ID: <474371FB.60404@webengineer.com> (raw)
In-Reply-To: <200711201843.13299.pragma@omnikron.net>


Szymon Stefanek wrote:
> Hi all! :)
> 
> I see that this is partially covered in the mailing list archive
> but at the moment I can't find a straight & working answer.
> 
> I have an imq device with dynamically attacched classes/qdiscs/filters.
> There is a hashing filter that maps the last octet of an user's IP address
> to a class (and associated qdisc). The "empty" filter looks like this:
> 
> 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 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
> 
> I'm adding the hash entries dynamically, as users get attacched to the system 
> (this is a dynamic PPPoE access concentrator).
> 
> tc filter add dev imq0 protocol ip parent 1:0 prio 5 u32 ht 
> 2:<LASTIPOCTETHEX>: match ip dst <IPADDRESS> flowid 1:<CLASSID>
> 
> <IPADDRESS> is the address of the newly attacched user, <CLASSID> is
> a dynamically assigned unique identifier and <LASTIPOCTETHEX> is the
> last octet of the user's IP address.
> 
> This works and I get a tc tree like this:
> 
> 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
> 
> Nice.
> 
> If another user gets added to the same hash bucket I get something like:
> 
> 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 2:1:801 order 2048 key ht 2 bkt 1 
> flowid 1:4099  (rule hit 0 success 0)
>   match 0a060001/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
> 
> 
> Now when the users go away I want to _programmatically_ remove the associated 
> filter entries. This doesn't work unless I manually specify the filter handle 
> (handle 2:1:801). The problem is that I actually don't know the filter
> handle since its last part is assigned automatically by tc. I would need
> to relaunch tc with the show option, capture its output and parse it...
> this is an overkill. If I try to delete handle 2:1: (just like in the add 
> command) then ALL the rules with handle 2:1:* get deleted (and this is 
> obviously not what I want).
> 
> Trying to add filters with completly specified handle (like fh 2:1:4098)
> doesn't work unless the last part is EXACTLY what tc would set automatically 
> (this is 800, 801 etc...). But since I have multiple unsynchronized processes
> that do the adding job then I don't know which handles have been already
> used and thus can't guess what which handle to add next. Synchronizing
> the processes and sharing a database would be again a very huge overkill.
> 
> Trying to assign an unique filter id by using pref creates a mess since it 
> adds three filters at once for every preference value. And removing doesn't 
> work either with tc complaining about "No such file or directory".
> 
> I have read somewhere that deleting a qdisc will also delete the filters
> attacched to it but this doesn't seem to work: the qdisc is deleted
> but the filter in the hash bucket is not.
> 
> 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.

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

  reply	other threads:[~2007-11-20 23:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 17:43 [LARTC] Problem deleting tc rules Szymon Stefanek
2007-11-20 23:47 ` Emmett Culley [this message]
2007-11-21  1:27 ` Szymon Stefanek
2007-11-21 21:57 ` Emmett Culley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=474371FB.60404@webengineer.com \
    --to=emmett@webengineer.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox