-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I''ve written a minimal sort of Perl module that dynamically creates
and destroys traffic control rules for specific IPs. I''m currently
using it for a user bandwidth control application at a client site.
The module essentially gets Ethernet device(s), IP address and in/out
speeds as input and dynamically creates classes, queues and filters
for controlling speeds on the incoming and outgoing interfaces. It
calls /sbin/tc internally to make the rules. Similarly, when the user
is logged out, the module deletes the rules that it made earlier.
There are two issues I''m facing:
1. Is there any way remove filter rules without knowing the handle?
I''d like to be able to remove the filter rule using the same set of
data that I used to create it, but there doesn''t seem to be any way to
do that. Currently I''m parsing the whole ``tc filter
show'''' output to
find out the handle of the rule I''m interested in, then using that
handle in the ``tc remove'''' command to delete the rule.
Inelegant and
inefficient, to say the least.
2. Can one have filter rules with handles > 800:fff? After the
program has run for a while, the filter handle hits 800:fff, and then
I can not delete any of the new rules at all. I''d be interested in
knowing how to make tc reuse handles; failing that, increasing the
number of unique handles would at least prevent my client from having
to reboot the server every day.
I''ll be releasing the module under GPL once I''ve cleaned up
the code
and documented the methods a bit. Help on doing that appreciated.
Regards,
- -- Raju
- --
Raj Mathur raju@kandalaya.org http://kandalaya.org/
GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F
It is the mind that moves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFE5b66yWjQ78xo0X8RAvNpAJ9kfvotl0Ife92qoyBPlqxC5G+cYACeNvAG
rJT3lU8kd46ymbYcJwhb7e0=oJKh
-----END PGP SIGNATURE-----
> Hi,Hi there!> > I''ve written a minimal sort of Perl module that dynamically creates > and destroys traffic control rules for specific IPs. I''m currently > using it for a user bandwidth control application at a client site.Been there, done that... Better regenerate whole tc config and load it using "tc -b". It''s faster then many calls to tc binary (no context switching overhead). cheers -- Marek Kierdelewicz Kierownik Dzia?u Systemów Sieciowych, KoBa Manager of Network Systems Department, KoBa tel. (85) 7406466; fax. (85) 7406467 e-mail: admin@koba.pl
>>>>> "Marek" == Marek Kierdelewicz <marek@piasta.pl> writes:>> I''ve written a minimal sort of Perl module that dynamically >> creates and destroys traffic control rules for specific IPs. >> I''m currently using it for a user bandwidth control application >> at a client site. Marek> Been there, done that... Marek> Better regenerate whole tc config and load it using "tc Marek> -b". It''s faster then many calls to tc binary (no context Marek> switching overhead). I don''t really know what effect resetting the tc configuration every few seconds would have on logged in users. What happens to the existing connections when the whole thing is reloaded? Will they jitter? Or roll over and die, or just continue behaving as they were? Wouldn''t writing out commands for a few hundred connections into a file and loading that file take a significant amount of time? On the whole I''d prefer to do each connection as it comes up, so if that''s possible at all. Regards, -- Raju -- Raj Mathur raju@kandalaya.org http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F It is the mind that moves
Dnia piątek, 18 sierpnia 2006 21:16, Raj Mathur napisał(a):> >>>>> "Marek" == Marek Kierdelewicz <marek@piasta.pl> writes: > >> I''ve written a minimal sort of Perl module that dynamically > >> creates and destroys traffic control rules for specific IPs. > >> I''m currently using it for a user bandwidth control application > >> at a client site. > > Marek> Been there, done that... > > Marek> Better regenerate whole tc config and load it using "tc > Marek> -b". It''s faster then many calls to tc binary (no context > Marek> switching overhead). > > I don''t really know what effect resetting the tc configuration every > few seconds would have on logged in users. What happens to the > existing connections when the whole thing is reloaded? Will they > jitter? Or roll over and die, or just continue behaving as they were? > > Wouldn''t writing out commands for a few hundred connections into a > file and loading that file take a significant amount of time?I''m generating huge tc setup from database and loading it (which takes significant amount of time) only on router startup or reloading whole router configuration. To change speed limit of single host in network I''m using `tc class change`, which goes fast. -- | pozdrawiam / greetings | powered by Trustix, Gentoo and FreeBSD | | Kajetan Staszkiewicz | jabber,email,www: vegeta()tuxpowered net | | Vegeta | IMQ devnames: http://www.tuxpowered.net | `------------------------^------------------------------------------'' _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>> "Kajetan" == Kajetan Staszkiewicz <kajtek@biezanow.net> writes:Kajetan> Dnia piątek, 18 sierpnia 2006 21:16, Raj Mathur Kajetan> napisał(a): >> >>>>> "Marek" == Marek Kierdelewicz <marek@piasta.pl> writes: >> >> I''ve written a minimal sort of Perl module that dynamically >> >> creates and destroys traffic control rules for specific IPs. >> >> I''m currently using it for a user bandwidth control >> application >> at a client site. >> Marek> Been there, done that... >> Marek> Better regenerate whole tc config and load it using "tc Marek> -b". It''s faster then many calls to tc binary (no context Marek> switching overhead). >> I don''t really know what effect resetting the tc configuration >> every few seconds would have on logged in users. What happens >> to the existing connections when the whole thing is reloaded? >> Will they jitter? Or roll over and die, or just continue >> behaving as they were? >> >> Wouldn''t writing out commands for a few hundred connections >> into a file and loading that file take a significant amount of >> time? Kajetan> I''m generating huge tc setup from database and loading it Kajetan> (which takes significant amount of time) only on router Kajetan> startup or reloading whole router configuration. As I suspected... I wonder if Marek''s solution would work in a significantly dynamic environment? Any thoughts Marek? Kajetan> To change speed limit of single host in network I''m using Kajetan> `tc class change`, which goes fast. I have to keep adding and deleting classes as users login and logout. I''m afraid change is not an option for me. Regards, -- Raju -- Raj Mathur raju@kandalaya.org http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F It is the mind that moves
> Kajetan> I''m generating huge tc setup from database and loading it > Kajetan> (which takes significant amount of time) only on router > Kajetan> startup or reloading whole router configuration. > > As I suspected... I wonder if Marek''s solution would work in a > significantly dynamic environment? Any thoughts Marek?Just try it... Generating large file with tc classes and filters and then loading it with "tc -b" takes less then 1s on most system. If you''re worried about active connections - don''t be. Shaping restart won''t break them. I use this solution on routers with thousands of filters and classess and full restart intervals as low 1 min. It works well.> > Kajetan> To change speed limit of single host in network I''m using > Kajetan> `tc class change`, which goes fast. > > I have to keep adding and deleting classes as users login and logout. > I''m afraid change is not an option for me.Whatever you do, change/add/delete you can always pack commands in one file and load them with "tc -b". Again, it''s faster.> > Regards, > > -- RajuRegards, -- Marek Kierdelewicz Kierownik Dzia?u Systemów Sieciowych, KoBa Manager of Network Systems Department, KoBa tel. (85) 7406466; fax. (85) 7406467 e-mail: admin@koba.pl