Hello, Elison Niven a écrit :
I have an ARM based board with 2 ethernet interfaces eth0 and eth1. eth0 - LAN interface. 192.168.2.149 eth1 - WAN interface. 192.168.1.149 I have setup a simple router using iptables that allows PCs on the LAN to browse the internet via the WAN. I want to limit incoming bandwidth on the LAN interface to about 8mbit/s as when there are massive data transfers initiating from the PCs on the LAN, the system is under heavy load and is not able to execute any applications. I tried to limit the bandwidth using tc's tbf and ingress but it isn't really working well. For example from a PC on the LAN (ip 192.168.2.13, default gw 192.168.2.149) # ping -f -s 1000 192.168.1.3 This is correctly limited and ping results show the loss. # ping -f -s 1 192.168.1.3 Here the system is under heavy load and is not able to execute any applications. No loss in ping.
This result may indicate that the router's load depends more on the packet rate than the bandwidth, which makes sense. So it may be more efficient to limit the packet rate instead of the bandwidth.
Also when I create a udp socket from this PC to an address on the WAN, the rate is not limited. #./udpclient 20000 192.168.1.3 20000 1000 This utility sends 20000 packets of 1000 bytes each to 192.168.1.3. Here also the rate is not limited.
I did not understand well whether you want to limit incoming (WAN to LAN) or outgoing (LAN to WAN) traffic. The ping test above does not tell whether incoming (echo reply) or outgoing (echo request) traffic is limited.
Also, remember that by definition received traffic rate cannot be directly controlled. All you can do is drop incoming packets. Due to TCP acknowledgement and congestion control mechanism, the sender will interpret the packet loss as congestion and reduce the sending rate. But UDP has no such mechanism. Anyway, does this really matter ? If the heavy data transfers use TCP, it should work. Did you test it ?
-- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
