Paul, : I have used tcng to help start me with some tc code that i can : put into a bash script and call from a c program. I have to : dynamically : : 1. Add filters for communications between different nodes. : 2. Delete these filters as communications cease between the : nodes and : 3. Make sure they have enough bandwidth by limiting everything : else. : : e.g > Node 1 wants to make a voip call to Node 2. My c program : recieves both ip's, both ports and the bw that the call requires. : I then have to add/change the tc rules/filters to allow this to : happen. Then i recieve a request for another call, same thing. : Then call 1 hangs up, i delete that filter and change other : necessary info. I have seen a number of people try dynamic class and filter insertion. I can't say that I've ever seen it work particularly elegantly. I hope somebody will also show you what s/he has done to deal with this problem, but here's how I'd solve the problem: Build a class hierarchy that accommodates the total number of VoIP calls that your network can support at any one time. class $root, rate $MAX, ceil $MAX | +- classes $voip, rate $VOIPMAX, ceil $VOIPMAX | | | + class $voip.0 rate $PCR, ceil $PCR | + class $voip.1 rate $PCR, ceil $PCR | [ ... ] | + class $voip.N rate $PCR, ceil $PCR | +- class $rest, rate $RESTMIN, ceil $MAX N = total number of VoIP clients PCR = per call rate (64kbit?) VOIPMAX = PCR * N MAX = total bandwidth available to you RESTMIN = minimum guaranteed bandwidth for bulk, should, roughly MAX - VOIPMAX - <a little bit> You simply classify any VoIP UDP flows into the $voip.0, $voip.1 ... $voip.N classes and you forget about it. (See also toward the bottom of this message.) Now every one of your N-VoIP clients can have guaranteed access at per-call-rate (PCR). This is most distinctly not dynamic, and probably rather hackish by comparison to something more RSVP-like. What's the beauty of the above model? First, you don't have to fiddle with it at all once it's installed. Second, HTB will take care of sharing the bandwidth between your VoIP callers and the rest of the traffic ($rest). What's the shortcoming of the model? You have to have enough bandwidth to allocate one VoIP class to each of your VoIP users without hitting your $MAX rate. Viewed from another angle, you must not have more potential VoIP callers than you have available bandwidth. : I am finding this extremely difficult. i.e > I have : little/nothing working. The concept of dynamic traffic control structures has come up periodically on this list, and you may find some benefit to trawling the archives for earlier discussions. I'm quite certain there are some nuggets of knowledge available in the archive. : Do you know what might be the best way to approach this problem ? : : Currently i'm simply trying to write a bash script containing tc : commands and call that bash script from my c code. One other thing you could consider is building the above structure, but not installing any filters. While I have not used the netfilter CLASSIFY target, you could have your bash script insert CLASSIFY rules into a custom chain. Then, you have a set of traffic control structures in the kernel and you use netfilter rules to select which flows go into the VoIP classes. Good luck, -Martin -- Martin A. Brown http://linux-ip.net/ _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc