[LARTC] TC Hashing Filters

[zoop@lone.ath.cx]

>	# 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 (adamt@commspeed.net) 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 / LARTC@mailman.ds9a.nl
>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.