Hi Alejandro, >> Alejandro Ramos Encinosa wrote: >> > tc qdisc add dev eth1 parent 1:20 handle 120: sfq perturb 10 >> > >> > tc class add dev eth1 parent 1:20 classid 1:21 htb rate 49mbit >> >> This is a misconfiguration, it doesn't make sense to add sfq and another >> htb class to 1:20. >...why? The case I am trying to deal with is an scenario where some traffic >goes into 1:20 (something like the traffic from/to the subnet 10.6.70.0/24) >and then, I want to shape specifically some other traffic type (for example, >the ssh connections from/to subnet 10.6.70.0/24). Is there another way to do >it? Please, take a in mind that (in my example) I want to enclose the whole >traffic from/to the subnet 10.6.70.0/24 and from that traffic I want to give >an special treatment to ssh traffic. >> > > Andy. I hope you already managed to find a solution to the above problem. <GENERIC COMMENT> I think a question posted on this list does not get any answer in four main cases: 1- It is not formulated well. 2- No one knows the answer. 3- Everyone knows the answer and thinks someone else will reply sooner or later. 4- The same question has been posted already many times and therefore a simple search in the list archive would be sufficient to find the answer/solution. If you did find a solution to your problem and you think it can come useful to others too, I would kindly suggest you to share it with the list members (especially in the case 2 above). </GENERIC COMMENT> Anyway, let me try to answer your questions. Andy is right: qdisc attached to non-leaf classes are not used by HTB (even though you can configure them). Packets must be queued into the leaf classes' queues. Non-leaf classes are used only for link-sharing (in the case of HTB). Here are two examples of solutions to your problem: 1) You define two filters: - one for the SSH(to/from 10.6.70.0/24) traffic - one for the Not-SSH to/from 10.6.70.0/24 traffic. Both filters would map traffic to 1:20. The first filter must be tested first (therefore you should assign it an higher priority). The rate/ceil parameters configured on 1:20 would apply to all the traffic that goes to 1:20 (SSH and Not-SSH). By assigning a policer to the first filter you would be able to shape the SSH traffic explicitly. 2) Instead of using the same class 1:20 for both SSH and Not-SSH traffic, you can create two classes under 1:20, say 1:21 for SSH and 1:22 for Not-SSH. In this case you would not need to attach any policer to the filters because you can configure two independent rate/ceil parameters for the two classes. Regards /Christian [http://benve.info] _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
