Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 2508 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Source Prioritization

TheDrew
Morning,

I have a little problem I'm trying to solve and I think QoS is where I'll find an answer but I'm not sure.

The scenario is this. I have a remote office that accesses resources at our main office(my location) over a VPN link. The link normally works fine as the office typically shows 1-2Mbps with occasional spikes to 6-7Mbps when the remote office is pulling down largish files. We're on a 10Mbps Fiber so I have some overhead to work with.

Occasionally however I need to make downloads through tools that don't have any sort of rate limiter and if I pick the wrong time of day, I can cripple that office. The traffic is bursty and random so I never know when is a bad time to download large files.

Is there a way I can either rate limit one PC, or preferably, give priority to VPN traffic so that my downloads scale back when the remote office starts pounding the tunnel?


This thread was automatically locked due to age.
  • 0
    My understanding is that you could set up a QoS pool, and assign, say, 6mb for that pool.  Define a traffic selector that matches hosts at the other end, to match traffic destined for the VPN.  Any unused bandwidth is available for generic traffic.  I'm not sure I read you right - you download stuff to the remote office from sites other than the main office?  (e.g. those bulk downloads do not use the VPN)?  If so, this should just work...
  • 0 in reply to dswartz
    I should have been clear on that. My bulk downloads(ISO's, VM images, etc) are into head office and that is interfering with the remote office's ability to download from internal servers here.

    Essentially I'm swamping the 10Mbps pipe and the VPN is suffering for it.
  • 0
    The problem still isn't clear, Drew.  I'm assuming you aren't downloading VMs and ISOs from a server in the remote office.

    You have a 10Mbps symmetrical pipe.  When your downloads hit the External interface, how can that affect the upload speed from that interface experienced by the remote office?

    Cheers - Bob
  • 0 in reply to TheDrew
    Hi Bob,

    What's happening is when I'm busy downloading large files off the Internet (here in my office at HQ) to my workstation, I get complaints from the remote office that their file browsing and programs (Word, Excel, etc) slow down drastically. As soon as I pause my download, their apparent speed picks up.

    The girls at the remote office have several mapped drives that correspond to file shares on the servers at HQ. I suspect whats happening is when they hit save, the files have to be uploaded over the VPN and because my download is reaching 9.3Mbps, they're only using using .5 or .7Mbps. Because Word, Excel, etc usually wait while the save is completed, we're seeing this pause of several seconds that the girls figure is their PC being slow.
  • 0
    Bob, this makes sense.  If he is maxing out the pipe inbound into the head office, uploads to the remote office require ACKs to come back, and those ACKs have to compete with the bulk traffic.  Only thing I can think of is to set the Download Equalizer mode, and set the downlink to somewhat less than the real speed (like maybe 9mb or so?)  Then, if you are railing the link inbound, the bulk tcp packets will get dropped to keep you under the limit - the ACKs from the remote office will not suffer (technically, the QoS manager should not even see them as ACKs, since they are in the VPN tunnel, but still not part of the bandwidth hog.)  Does this make sense?
  • 0
    Agreed.  In any case, the only explicit QoS rule that might help in this situation would be one on the Internal interface that limited traffic to Drew's PC*, but I'd certainly try your suggestion first, maybe trying to get a little closer to the actual max.

    Cheers - Bob
    * 'Internet -> Any -> {Drew's PC}' limit to 6mb
  • 0 in reply to BAlfson
    Agreed.  In any case, the only explicit QoS rule that might help in this situation would be one on the Internal interface that limited traffic to Drew's PC*, but I'd certainly try your suggestion first, maybe trying to get a little closer to the actual max.

    Cheers - Bob
    * 'Internet -> Any -> {Drew's PC}' limit to 6mb


    I'm a bit confused by that. It sound's like you're suggesting rate limiting my connection so as to give the VPN some overhead, which works but isn't really what I'm trying to achieve.

    I do occasionally pull files down off the 'Net during off-peak hours and I'd rather not limit my rate during those times. I guess I just want to prioritize VPN traffic so that when the VPN(s) ramp up, my download rate goes down.

    In any event, I'm going to have to put this to the test in my lab and see what happens.
  • 0
    The limitation is that you only can make explicit QoS rules for traffic leaving an interface.  That's why dswartz' Download Equalizer suggestion for the External interface is a good thing to try before limiting traffic leaving the Internal interface to you.

    Unfortunately, unlike some other rules, QoS rules can't be used with time events.

    Cheers - Bob
  • 0
    Basically, throttling inbound TCP (forget UDP) can only really be done one of two ways (AFAIK): slowing down ACKs we send back, or occasionally dropping inbound TCP packets, which will make the other end retransmit (hence, slowing down.)  It's more complicated than that, but I don't know if you really want the "inside baseball" stuff here [:)].  RED (Random Early Discard) is a trick whereby as the inbound rate gets closer and closer to max, you increase the probability of dropping random packets, to put more and more pressure on the brake pedal.