bandwidth shaping on asymmetric interfaces

Home Page Forums Network Management ZeroShell bandwidth shaping on asymmetric interfaces

This topic contains 2 replies, has 0 voices, and was last updated by  quixadhal 9 years, 2 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #42498

    quixadhal
    Member

    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?

    #50691

    ppalias
    Member

    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.

    #50692

    quixadhal
    Member

    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?

    #50693

    ppalias
    Member

    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.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.