> Well--I was going to write a short answer, which would have said something > like "look at the parent of the filters". But...that wouldn't have helped > much. So here's a long-winded message about your config file and > situation. Thanks for writing the long version... > I'm going to guess that your configuration for device eth1 looks something > like this: Your guess is amazingly identical to original config file... > - Is this similar to your config file? (I only had your processed > tc output to examine, so I may have gotten it wrong.) Similar as a twin. > - Do you really want to put ( ssh ) and ( ip_tos_delay ) in the same > class? Or did you meant to put ( ssh and ip_tos_delay ) in this > class? Just curious.... Yes, I want... but the main reason behind migrating to tcc is trying to make the traffic control semantics to appear. The obscure tc syntax makes it very hard to know what policy is really in place. > - Why do you use "not_tcp_incoming"? Are you trying to prioritize the > ACKs? If so, just use "if tcp_ACK". (Which leads to the next > question...) Will change that. > - It looks to me as though eth1 must be on the internal interface of a > router with a few servers inside. Is this accurate? If you are > trying to shape your outbound connectivity, you may wish to review > the rules for shaping [0]. Nope. eth1 is the external interface, and is connected to a xDSL modem/router; there are no servers inside, only workstations, but the machine which is doing traffic control is also a mail server reachable from the outside. IMQ is used to get ingress traffic from eth1 in order to apply traffic control to it. > [ important (key, in fact), but repetitive prefix > "tc filter add dev eth1 parent 1:1 protocol all prio 1" > snipped ] > > tc filter add dev eth1 parent 1:1 protocol all prio 1 ... > > They are all attached to the object 1:1, which means that they won't get > called directly by a packet needing to be dequeued! Your filters are > there, though, and you'll be able to see that they are indeed installed if > you examine the filters on object 1:1, as follows: > > tc filter show dev eth1 parent 1:1 Here they are, lost in space... > Frankly, I didn't know how to deal with this "problem" when I first > started playing with tcng, so I made peace with dsmark, and now I use the > class selection path construct in my tcng configurations, which makes for > much less wrangling with tc (the command-line critter). It's not too hard > to get a kernel and iproute2 with dsmark [1]. My first draft used class selection path, but I changed it in order to easy up deployment. My understanding of the tcng docs was that both constructs were valid... is there a BugZilla for tcng ? Main issue in requiring dsmark is kernel/tools changes. For one machine it is not a problem, but for a dozen... and clients don't like getting billed for something with no direct benefit for them. Besides legacy issues, I saw that class selection path establishes an indirection thru set_tc_index. What would be the performance penalty for such a construct ? > After you have your dsmark-capable kernel you need only have a "tc" which > groks dsmark. Many distributions provide modular dsmark support; you can > simply type "modprobe sch_dsmark && modprobe cls_tcindex". We usually rebuild the kernel from original sources... it seems that our defaults also include modular suport for dsmark. > Now, try something like the class selection path example [2], and jump for > joy! Now you can use language constructs that are far more understandable > to humans, and let tcng (tcc) do the heavy lifting. That's the idea. > Suddenly traffic control isn't hard at all! It solves syntax issues, but there is the real ones out there... > * To others reading this list! If you post a question about a tcng > config, please post your tcng config file. The tc-style output can > easily be generated with a working tcc. Thank you! Ooops, I saw few questions regarding tcng and thought it would be a limitation. May be a tcc CGI would be handy ? Thanks a lot. Rubens _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
