> # Create filter to hash out last octet and link to hash table 2: > tc filter add dev eth1 protocol ip parent 1:1 prio 5 u32 ht >800:: match ip src 216.19.49.0/24 hashkey mask 0x000000ff at 12 link 2:
I think this needs to be attached to the root. parent 1:0 Adam Towarnyckyj ([EMAIL PROTECTED]) wrote: > >Hey all, > I had asked a question a little while ago about CPU usage being >outrageous while using tc and a cbq qdisc. Ed was very kind and offered >a few suggestions. One of these was to look at hashing. So after >pounding away at it for about a week, I have a general understanding of >how it works and have tried to implement it. Unfortunately, and quite >obviously since I'm posting here, it does not work for me. > >The Problem: > When implemented, and all the tc commands are entered, I get no >errors or anything for that matter. It looks like everything went in >smoothly. I do a show and sure enough, it is all there and looks good. >However, when I have a computer hooked up on one side of the limiter and >the other side hooked up to the internet, I do a download test and get >the average 35Mbps that I normally see from our office. > >The Situation: > The first step in troubleshooting this problem involved finding >out if tc even limited at all. So I set up a simple class with a 128Kbit >rate and cbq root qdisc like I had originally and all worked well. The >download test showed 128Kbit/s like it should. I was happy that this >part works. > It seems that when I install the hash tables and assign it to >hash based on the last octet in the IP address, it just allows traffic >to pass through without limiting. This is where I run into the trouble. > >The Commands: > Here is what I originally started out with based on the Hashing >Filter How To: > > # Create root qdisc > tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 200Mbit >avpkt 1000 > > # Create a "transit class" > tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth >200Mbit rate 200Mbit allot 1514 weight 2Mbit prio 8 maxburst 10 avpkt >1000 > > # Create hash table attached to transit class > tc filter add dev eth1 parent 1:0 handle 2: protocol ip u32 >divisor 256 > > # Create filter to hash out last octet and link to hash table 2: > tc filter add dev eth1 protocol ip parent 1:1 prio 5 u32 ht >800:: match ip src 216.19.49.0/24 hashkey mask 0x000000ff at 12 link 2: > > # Create class for 128Kbit limit > tc class add dev eth1 parent 1:0 classid 1:2 cbq bandwidth >200Mbit rate 128kbit allot 1514 prio 5 maxburst 20 avpkt 1000 bounded > > # Create filter for IP I'm limiting > tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:8c >match ip src 216.19.49.140 flowid 1:2 > >Troubleshooting: > There are a few things I'd like to point out. First off, I'm >only working with one IP address at the moment and the traffic is coming >from only one Class C at the moment. I've even tried hard setting the >hash ip src to 216.19.49.140/32 and that doesn't work. Second, I've >tried attaching each of these to different parents. I tried attaching >the hash table to the root qdisc as well as the transit class. I've >tried the same for the limiting class and the ip filter. None of this >works. Third, I've also tried it without the transit class at all and >just doing everything direct off the root qdisc. Not only have I used >the Hashing Filter How To but I have also used some suggestions from >Gideon who posted to this list in the past. >(http://mailman.ds9a.nl/pipermail/lartc/2003q2/008516.html). I tried htb >as well and this qdisc didn't work either. Also, I've changed the src to >dst and I originally started out using the hash ip src as our entire >network of 216.19.0.0/18. > If anyone has an understanding of hashing filters, please PLEASE >let me know what I'm doing wrong. I've been working on this for three >days straight now and in the meantime, our bandwidth limiting is not >running which is INCREDIBLY important to my boss. I currently have just >a straight list of 5000 users that I do not want to stray too far from >(the iptables project Ed referred to requires a complete overhaul of my >current implementation). I'm pulling my hair out because according to my >understanding of it and based on what others have done this SHOULD be >working..... > Thank you very much for at least taking the time to read this. I >truly appreciate it. I'm also hoping that this will spark a thread for >future people who run into the same trouble I am having. Thanks. > >Adam Towarnyckyj > > >_______________________________________________ >LARTC mailing list / [EMAIL PROTECTED] >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- When dealing with a slow pipe, never underestimate the throughput of the postal system. _______________________________________________ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
