# Limit bandwidth per ip

## lagalopex

Hello!

I have a list of ips (in the LAN) where I would like to limit the upload.

At first I tried to do this with iptables RATEEST and DROP everything over the rate. But it does not work very well. Some get twice the speed they should get and some get only a tenth...

But I know RATEEST is not recommanded for traffic-shaping, so I am now looking at tc.

I can mark the connections (no problem) and create a filter for each ip with tc.

But I would like to know if there is a more generic and simpler way of doing this. Perhaps something like hashlimit over dest-ip for iptables.

I dont want multiple ips to share one "upload limit". Every ip in the list should get the set rate (as long as its possible).

Its damn cpu-expensive to have a filterline for every ip...

I hope someone understands my problem and can perhaps help me.

----------

## ZeuZ_NG

I've seen that being one qdisk for each IP, inside each of those qdisk, others who specify the traffic.

There's a script I have been using for some time now, it's called htb-gen, who's also got a web-based-interface.

It uses HTB, CBQ and SFQ in it's latest version to create what you're trying to achieve.

This, matching both hosts in a LAN and comming from the WAN/MAN.

It's kind of expensive, CPU-wise, to have one qdisk for each host, but it's at the end of the day the only real solution that I explored that worked.

Also, there's Master Shaper (for wich you'll have to add some patches to your kernel, and settings will be stored in MySQL, so that's a LOT more expensive. However it comes with things incorporeted as traffic graphing (using mrtg last time I checked) wich are cool, but don't at expenses of mysql..)

Hope this helps, and I'll also be wanting to check out other alternatives..

----------

## ptcracker

You can use hashlimit.

----------

## ZeuZ_NG

 *ptcracker wrote:*   

> You can use hashlimit.

 

Care to give me an example of how could hashlimit be implemented to achieve this?

----------

## ptcracker

 *ZeuZ_NG wrote:*   

>  *ptcracker wrote:*   You can use hashlimit. 
> 
> Care to give me an example of how could hashlimit be implemented to achieve this?

 

 *Quote:*   

> 
> 
> # iptables -m hashlimit -h
> 
> hashlimit v1.4.0 options:
> ...

 

And thers is an example.

```

iptables -A INPUT -p tcp --dport 22 -m hashlimit --hashlimit-name foo --hashlimit 100/sec --hashlimit-mode srcip -j ACCEPT  

iptables -A INPUT -p tcp --dport 22 -j DROP

```

That means that I wanna to limit the packet where dport = 22 and tcp, name = foo, speed: 100/sec. (I care soure IP only.)

But, this module only can match and handle "packet", but "bytes".

You can use another module named "hashspeed" modified by a Chinese.

http://linux.chinaunix.net/bbs/viewthread.php?tid=918056

----------

## ZeuZ_NG

But ain't it a little unconfortable to be matching against packet number burst?

Anyways, it's really nice to see it, and I'd like to implement it to test.

But doesn't this not allways assure that the limit will be the same? 

Suppose you want to limit to a top of 128kbps from source to any destination, this can't assure me that the speed won't go over that limit, ain't I right? Given the proper ammount of package per second (by the way, how'd you match ammount of packages to limit speed?)

----------

## ptcracker

 *ZeuZ_NG wrote:*   

> But ain't it a little unconfortable to be matching against packet number burst?
> 
> Anyways, it's really nice to see it, and I'd like to implement it to test.
> 
> But doesn't this not allways assure that the limit will be the same? 
> ...

 

You are right.

Because "packet" != "byte", so you can't accurately limit the speed to 128kbps.

In our standard ethernet, the MTU is 1500.

Netfilter handles IP packet only, so the biggest IP packet is 1500 bytes and the smallest is 46 bytes without to enable nf_conntrack_ipv4.

Usually, the average packet size in our network is about 700 bytes.

Based on this concept, we can count on how many packets will be transfer per secend.

128kbps = (128 / 8)kBytes/s = 16kBytes/s

16 * 1024 / 700 = 23.4pps

Based on this concept, we set the limit speed to 24/s.

This is just a disguised way to achieve, not necessarily accurate.

I suggest you use "hashspeed". It's more accurate.

----------

## ZeuZ_NG

I can't really understand much of the chinesse there, even passing it through google's translator...

But, it says there that it's focused on 2.6.25 and 2.6.26. Is there some official site for this? Is the patch more or less safe?

----------

## ptcracker

 *ZeuZ_NG wrote:*   

> I can't really understand much of the chinesse there, even passing it through google's translator...
> 
> But, it says there that it's focused on 2.6.25 and 2.6.26. Is there some official site for this? Is the patch more or less safe?

 

Since kernel 2.6.24, the struct of sk_buff changed a lots. I'm not sure whether "hashspeed" can works on 2.6.25 and 2.6.26.

I pathed it on kernel 2.6.23 and it works well.

I'm Chinese and I have been deeply studied it. I'll try to help you if you have any questions.

----------

## lagalopex

The hashspeed-match for iptables looks quite nice. But I would think, its quite similar to RATEEST (and that did not work for me). I tried to build hashspeed, but it failed. Comparing hashspeed and hashlimit (where its forked from) shows major differences.

A offical homepage with the current development would be nice...

And I think the normal traffic-shaping is not done by dropping everything exceeding the limit... I dont even know if its packet based or if it builds packets on its own to fit the bandwidth...

I wonder if thats a problem nobody had before...

----------

## ZeuZ_NG

 *lagalopex wrote:*   

> The hashspeed-match for iptables looks quite nice. But I would think, its quite similar to RATEEST (and that did not work for me). I tried to build hashspeed, but it failed. Comparing hashspeed and hashlimit (where its forked from) shows major differences.
> 
> A offical homepage with the current development would be nice...
> 
> And I think the normal traffic-shaping is not done by dropping everything exceeding the limit... I dont even know if its packet based or if it builds packets on its own to fit the bandwidth...
> ...

 

In the case of HTB qdisks, for example, they're queued(as in delayed), and the reply time is increased on both sides, so the flow becomes "slower". Effectively, there's no dropping as I understand it from what I've read at lartc.org

Dropping could result on unexpected connection termination I beleave.

If you are able to build it, and get it to work, let me know please...

----------

## ptcracker

 *lagalopex wrote:*   

> And I think the normal traffic-shaping is not done by dropping everything exceeding the limit... 

 

Certainly, if the queue is not full, the packets will not be droped. But, the queue size is limited.

You can't buffer packets unlimited. When the queue is full, QoS must drop some olds.

Hashspeed is based on kernel 2.6.23 and iptables v1.3.8.

And it also can words on kernel 2.6.25/2.6.26 and iptables 1.4.1 now.

You can use the command "diff" to see the differences between the original and modified.

----------

## ZeuZ_NG

Sorry to bump this, but after all, it looks like the best way to achieve this kind of limits in Linux is still using queues like HTB.

I've been trying to get hashspeed running but it also does miss the point sometimes.

Has there been any notice? Since it seems I'm unable to find news about hashspeed..

----------

