July 10, 2010 at 6:14 am #42498
I have a question about doing bandwidth shaping on an interface where the upload and download speeds are capped at different rates.
I have a machine running ZeroShell as my gateway/firewall, and my ISP gives me a 10Mbit download cap, and a 1.5Mbit upload cap. This is ETH01. My LAN-side NIC is a normal 100Mbit interface, ETH00.
Currently, I have rules setup to route traffic from non-gaming machines through a pair of rate-limiting queues. The download traffic (anything NOT from my LAN that is leaving ETH01 for the non-gaming machines) goes to a 1.5Mbit queue on ETH00. The upload traffic (anything from the non-gaming machines leaving ETH00 for somewhere NOT on my LAN) goes to a 192Kbit queue on ETH01.
This seems to work, keeping the latency for the gaming machines low. However, it’s a pretty blunt instrument. I’d prefer to have a bit more flexibility in controlling traffic by type, but the issue I’m having when I try to do so is that I don’t want to limit LAN to LAN traffic speeds, nor do I want to limit overall download speeds to the 1.5Mbit upload cap rate.
Any suggestions?July 10, 2010 at 5:50 pm #50691
How about excluding the LAN-to-LAN traffic from your packet matching rule of the QoS? Apply the rate of 1,5Mbps only to traffic with source IP not in your LAN.July 11, 2010 at 6:02 am #50692
I guess that’s a thought. I had been letting anything not in the super-restricted class use the default classifier, but I guess I could put anything not matching those into a new pair of classes.
Would I put the catch-all rules before or after the more restrictive ones?
IE: 192.168.13.0/24 might be my whole subnet, and 192.168.13.100-192.168.13.110 might be the restricted guys.
I used to use OpenBSD’s pf, so I’m wondering if this has rules working as “first match wins”, or as “last match wins”.
Thanks for the idea!
EDIT: Oh, I remembered another question I had after looking at this. Wouldn’t this prevent the “guarenteed bandwidth” feature from working properly?July 16, 2010 at 12:01 pm #50693
iptables work with the “first match wins” logic. So first put the most specific network and then the more general.
No I don’t think it would prevent the guaranteed rate work properly. If in doubt create 3 rules, 2 allowing 192.168.13.0-99 and 192.168.13.111-254 and another rule restricting 192.168.13.100-192.168.13.110.
You must be logged in to reply to this topic.