bandwidth shaping on asymmetric interfaces

Forums Network Management ZeroShell bandwidth shaping on asymmetric interfaces

  • This topic is empty.
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #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?


    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.


    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: might be my whole subnet, and 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?


    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 and and another rule restricting

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.