If this question is answered in the FAQ, then I apologise. I am using the HTB qdisc (with SFQ underneath it) to shape traffic for an ISP. It works extremely well, certainly much better than the Linux Bandwidth Arbitrator I was using before. However I have a question about setting it up. At present I have a set of filters that allocate one IP address per HTB shaping rule underneath it in the tree structure. There is a HTB at the top of the tree capping the whole lot to the bandwidth of the leased line to the Internet. My current system is similar to this: tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 2048kbit burst 10kbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.1 flowid 1:2 tc class add dev eth0 parent 1:1 classid 1:2 htb rate 512kbit burst 10kbit tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.2 flowid 1:3 tc class add dev eth0 parent 1:1 classid 1:3 htb rate 512kbit burst 10kbit tc qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10 . . . My question is, can I share leaf HTBs with the same characteristics between multiple filters and get the same effect as having one HTB per IP address. To create something like this: tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 2048kbit burst 10kbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.1 flowid 1:2 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.2 flowid 1:2 tc class add dev eth0 parent 1:1 classid 1:2 htb rate 512kbit burst 10kbit tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10 The important point that I want to ensure is that *each* address gets a 512kb bandwidth, and not a single 512kb bandwidth shared between the two (or more) of them. Finally if the above is acceptable, would the following work also. Our addresses are very logical, each class B subnet of the 10.x.y.z address space represents a different speed class, thefore could I do something like: tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 2048kbit burst 10kbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.0/16 flowid 1:2 tc class add dev eth0 parent 1:1 classid 1:2 htb rate 512kbit burst 10kbit tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10 tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.1.0.0/16 flowid 1:3 tc class add dev eth0 parent 1:1 classid 1:3 htb rate 256kbit burst 10kbit tc qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10 . . . I have been reading the section on using hashing tables to manage large tables, but we are well short of needing it so far, and the above if it were to work is a much cleaner configuration AFAICS. Jonathan _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
