QOS Rule to Limit Upload Traffic

Home Page Forums Network Management ZeroShell QOS Rule to Limit Upload Traffic

This topic contains 3 replies, has 0 voices, and was last updated by  bendiets 7 years, 11 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #42906

    bendiets
    Member

    I’ve been teaching myself zeroshell and linux for almost a year now but I’m certainly still a novice.
    However I have searched considerably for an answer to what I think is a pretty straightforward question, so hopefully someone here can be so kind as to give me some advice.

    Basic Setup:

    ETH00 – interface connected to LAN, the gateway. [192.168.0.1]
    ETH01 – interface connected to DSL modem #1
    ETH02 – interface connected to DSL modem #2
    ppp0 – multilink bundle (My ISP provides me with MLPP DSL service)
    [inet addr:69.165.170.xxx P-t-P:206.248.154.xxx (PPPoE: ETH01, ETH03)

    Assymetric MLPPP DSL service, measured bandwith is 11mb/s downstream, 1.2mb/s upstream.

    Situation:
    When a user uploads via FTP or HTTP (we have online backup services) it saturates the entire uplink bandwith and as a result slows both upstream and downstream traffic. Web browsing slows to a crawl, etc.

    For various reasons it is not practical to limit the upload at the client level (via FTP client settings for example).
    It is also not useful to permenantly divide up the upstream bandiwth between clients (by ip address for example).

    Solution:
    To create a QOS rule that will limit the upload bandwith per connection after 5mb of bandwith has been transferred.

    I created a QOS rule in order to capture all upload traffic, after the 5mb per connection limit had been reached.

    I then created a QOS class for this traffic to limit the bandwith.

    The Problem:
    Is that for some reason this rule limits BOTH the downstream and upstream traffic on the network.
    I only have QOS enabled on the external ppp0 interface, which I thought meant that my QOS policies should only apply to outgoing traffic.

    Any ideas from the many intelligent minds on this forum?

    Thanks in advance!

    Ben

    #51646

    AtroposX
    Member

    Looks like you’d want ETH01 and ETH02. ETH00, your lan side, would be your download. ETH01 and ETH02 are your uplinks.

    Enable QoS on those two interfaces, apply the classes to both interfaces in the QoS manager, and only enter in the source address in the classifier, NOT the destination, leave it blank, apply the classifier and class, save

    #51647

    bendiets
    Member

    Thanks for the suggestion, much appreciated.

    I set it up as you described enabling the QOS classes on the outgoing interfaces ETH01 and ETH02 instead of the MLPPP DSL interface ppp0. Since each physical interface would be receiving about half the bandwidth of ppp0 I simply adjusted the bandwidth limits in the QOS class to reflect that.

    Seemed like it should work however…

    It seems that the QOS engine seems unable to classify ANY packets leaving from ETH01 and ETH02. Perhaps this is because in a MLPPP setup the packets are split across those interfaces. I’m using multi-link PPP, not regular load balancing.

    Enabling the rule with your corrections but putting it back on ppp0 brings me back to my original problem as it seems to limit both the upstream and downstream traffic.

    Seems like I must be missing something obvious here but…???

    Any ideas?

    #51648

    AtroposX
    Member

    Is the class added to the interface manager for the interfaces?, and saved at the top?

    Is the load balancing enabled at all on the load balancing section? if so, i don’t think qos can work then? you’d need Atheling’s NB-QoS patch to make both work at the same time. To be honest I’ve only used QoS in bridge-mode to shape transparently. I have used the NB or in route mode at all, but i would think it would be very similar setups.

    #51649

    mgibbons
    Member

    Why is the destination filled in with 192.168.0.0/24

    Surely this will match no packets as the destination ip will be out on the internet somewhere i.e 0.0.0.0/0

    Since you are multilink, it is the output on the ppp0 link that you should be interested in (which is what you had)

    Forget eth01 and eth02 they are irrelavent.

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

You must be logged in to reply to this topic.