Stop one user from using all Bandwidth? Traffic Shape?

Discussion in 'Cisco' started by Scooter133, Jun 2, 2009.

  1. Scooter133

    Scooter133 Guest

    We have a Few offices connected via PIX v7.0.4 Some have 3Meg, some
    have 9meg connection to the internet.

    If someone from the 9Meg connection starts to transfer a file to the
    3meg site, it makes the 3Meg site's intenet connection pretty
    useless.

    From the 9Meg site if someone starts a transfer from one of the fast
    download sites and transfers a 9gb file, the 9meg internet connection
    becomes useless.

    The Traffic above is business related, so its not like I can tell them
    to stop.

    Though I'd like a way to limit the bandwidth that one user can
    consume. If there are no other users, use the whole pipe, though if
    ohers jump on, then limit the traffic so its usable for the others.

    Is there a way to do this on the PIX?

    Thanks,
    Scott<-
     
    Scooter133, Jun 2, 2009
    #1
    1. Advertising

  2. In article <>, Scooter133 <> writes:
    >We have a Few offices connected via PIX v7.0.4 Some have 3Meg, some
    >have 9meg connection to the internet.
    >
    >If someone from the 9Meg connection starts to transfer a file to the
    >3meg site, it makes the 3Meg site's intenet connection pretty
    >useless.
    >
    >From the 9Meg site if someone starts a transfer from one of the fast
    >download sites and transfers a 9gb file, the 9meg internet connection
    >becomes useless.
    >
    >The Traffic above is business related, so its not like I can tell them
    >to stop.
    >
    >Though I'd like a way to limit the bandwidth that one user can
    >consume. If there are no other users, use the whole pipe, though if
    >ohers jump on, then limit the traffic so its usable for the others.
    >
    >Is there a way to do this on the PIX?


    None that I am aware of. What you want is usually found in routers.

    Regards,
    Christoph Gartmann

    --
    Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
    Immunbiologie
    Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
    D-79011 Freiburg, Germany
    http://www.immunbio.mpg.de/home/menue.html
     
    Christoph Gartmann, Jun 2, 2009
    #2
    1. Advertising

  3. Scooter133

    Scooter133 Guest

    On Jun 2, 8:35 am, Artie Lange <> wrote:
    > u will have to upgrade the OS
    >
    > http://supportwiki.cisco.com/ViewWiki/index.php/ASA_QoS- Hide quoted text -
    >
    > - Show quoted text -


    Looks like my PIX Supports those commands, though I'm not sure how to
    impliment them in my case.
    They are doing priority for voice traffic. I guess It is a start..

    Thanks!

    Scott<-
     
    Scooter133, Jun 2, 2009
    #3
  4. Scooter133

    Thrill5 Guest

    By virtue of the way TCP/IP works, one user can't use all the bandwidth.
    They can make things slower because you have maxed out the available
    bandwidth, but other flows will take bandwidth from the high bandwidth flow.
    On a congested pipe (as you have when a user is doing a big FTP transfer),
    the pipe will start to drop packets, and when a TCP packet is dropped, the
    flow rate (bandwidth) of that TCP flow is cut in HALF. Now if you have one
    flow using 2 MB/s and 10 others using the other 1 MB/s, odds are 1 out of
    every 2 dropped packets will come from the 2MB/s flow. As soon as the first
    packet is dropped, the flow rate of the 2MB/s flow will be cut to 1MB/s
    (beause the window size is cut in half). TCP increases the window size by
    one MTU (or one packet) each time that an ACK is received and the window is
    not full. This is alsotrue of every other flow, so the other TCP flows can
    increase their bandwidth usage as well. In the real world, this can make
    HTTP traffic very slow because web pages are small and the ramp up in the
    flows is relatively slow.

    Your best option here is to implement QoS and put FTP traffic in lower queue
    than your other traffic. In this fashion you can rate-limit the FTP traffic
    when there is congestion, but allow it to use as much bandwidth as it can if
    other traffic isn't using the pipe. I've never used a PIX so I don't know
    if they have this capability or if it does, how to configure it. Basically
    QoS will start to drop packets from the lower queues before the pipe is
    full, so you still have bandwidth available to the higher priority queues.



    "Scooter133" <> wrote in message
    news:...
    > We have a Few offices connected via PIX v7.0.4 Some have 3Meg, some
    > have 9meg connection to the internet.
    >
    > If someone from the 9Meg connection starts to transfer a file to the
    > 3meg site, it makes the 3Meg site's intenet connection pretty
    > useless.
    >
    > From the 9Meg site if someone starts a transfer from one of the fast
    > download sites and transfers a 9gb file, the 9meg internet connection
    > becomes useless.
    >
    > The Traffic above is business related, so its not like I can tell them
    > to stop.
    >
    > Though I'd like a way to limit the bandwidth that one user can
    > consume. If there are no other users, use the whole pipe, though if
    > ohers jump on, then limit the traffic so its usable for the others.
    >
    > Is there a way to do this on the PIX?
    >
    > Thanks,
    > Scott<-
     
    Thrill5, Jun 3, 2009
    #4
  5. Scooter133

    Rob Guest

    Thrill5 <> wrote:
    > Your best option here is to implement QoS and put FTP traffic in lower queue
    > than your other traffic. In this fashion you can rate-limit the FTP traffic
    > when there is congestion, but allow it to use as much bandwidth as it can if
    > other traffic isn't using the pipe. I've never used a PIX so I don't know
    > if they have this capability or if it does, how to configure it. Basically
    > QoS will start to drop packets from the lower queues before the pipe is
    > full, so you still have bandwidth available to the higher priority queues.


    I would think that in this case, where you don't want to limit traffic
    of a certain class but only need to give everyone fair share of the limited
    bandwidth, the use of "(weighted) fair queuing" is much more suitable.
     
    Rob, Jun 3, 2009
    #5
  6. Scooter133

    bod43 Guest

    On 3 June, 12:16, Rob <> wrote:
    > Thrill5 <> wrote:
    > > Your best option here is to implement QoS and put FTP traffic in lower queue
    > > than your other traffic.  In this fashion you can rate-limit the FTP traffic
    > > when there is congestion, but allow it to use as much bandwidth as it can if
    > > other traffic isn't using the pipe.  I've never used a PIX so I don't know
    > > if they have this capability or if it does, how to configure it.  Basically
    > > QoS will start to drop packets from the lower queues before the pipe is
    > > full, so you still have bandwidth available to the higher priority queues.

    >
    > I would think that in this case, where you don't want to limit traffic
    > of a certain class but only need to give everyone fair share of the limited
    > bandwidth, the use of "(weighted) fair queuing" is much more suitable.


    As already observed TCP is very good at apportioning the
    bandwidth between competing streams. This was what it
    was designed to do.

    The file transfer method has not been mentioned. Some
    systems deliberately work round the TCP fair sharing
    system by either using multiple TCP streams or UDP.
    I believe that some FTP clients use multiple
    streams, and of course the modern p2p software does
    multiple streams and UDP too. In the latter case you
    could try to block the UDP. For the case where
    multiple TCP streams are in use you will either
    need fancy firewall software (no idea if any exists)
    or ask them nicely to desist.

    For example MS Exchange by default used up to
    10,000 TCP sessions to send mail. One mail server I
    had to troubleshoot was used to send mailsots to a
    few hundred people. This totally filled the
    DSL internet link such that nothing worked, not
    even the mailshot. Of course almost no one *needs*
    that many sessions so we used to set it to 3 or 5.
     
    bod43, Jun 3, 2009
    #6
  7. Scooter133

    alexd Guest

    bod43 wrote:

    > For the case where multiple TCP streams are in use you will either
    > need fancy firewall software (no idea if any exists) or ask them nicely to
    > desist.


    Is it possible to limit the number of concurrent TCP connections per host
    [or host + dest port] on ASA [or IOS]?

    --
    <http://ale.cx/> (AIM:troffasky) ()
    13:59:34 up 27 days, 18:03, 3 users, load average: 0.03, 0.04, 0.05
    A few flakes working together can unleash an avalanche of destruction
     
    alexd, Jun 3, 2009
    #7
  8. I agree with Rob. A big problem that occurs is fair allocation of the
    bandwidth, and, the issue of global synchronization from interface-level
    packet drop. WFQ and WRED would be good options, but I don't believe
    either is implemented on the PIX. I'd look at a traffic shaping device
    (specialized appliance or router) that allows you to implement a global
    traffic policy. WFQ will help with flow starvation, and WRED will
    address global sync issues.

    Since this is an Internet pipe, I'd consider the appliance approach.
    Some appliances out there manipulate the TCP parameters, perform UDP
    shaping via buffering, ACK pacing, and such...a little more "creative"
    than a straight MQC Cisco router policy.


    Rob wrote:
    > Thrill5 <> wrote:
    >> Your best option here is to implement QoS and put FTP traffic in lower queue
    >> than your other traffic. In this fashion you can rate-limit the FTP traffic
    >> when there is congestion, but allow it to use as much bandwidth as it can if
    >> other traffic isn't using the pipe. I've never used a PIX so I don't know
    >> if they have this capability or if it does, how to configure it. Basically
    >> QoS will start to drop packets from the lower queues before the pipe is
    >> full, so you still have bandwidth available to the higher priority queues.

    >
    > I would think that in this case, where you don't want to limit traffic
    > of a certain class but only need to give everyone fair share of the limited
    > bandwidth, the use of "(weighted) fair queuing" is much more suitable.
     
    fugettaboutit, Jun 3, 2009
    #8
  9. Scooter133

    Thrill5 Guest

    "Rob" <> wrote in message
    news:4all.nl...
    > Thrill5 <> wrote:
    >> Your best option here is to implement QoS and put FTP traffic in lower
    >> queue
    >> than your other traffic. In this fashion you can rate-limit the FTP
    >> traffic
    >> when there is congestion, but allow it to use as much bandwidth as it can
    >> if
    >> other traffic isn't using the pipe. I've never used a PIX so I don't
    >> know
    >> if they have this capability or if it does, how to configure it.
    >> Basically
    >> QoS will start to drop packets from the lower queues before the pipe is
    >> full, so you still have bandwidth available to the higher priority
    >> queues.

    >
    > I would think that in this case, where you don't want to limit traffic
    > of a certain class but only need to give everyone fair share of the
    > limited
    > bandwidth, the use of "(weighted) fair queuing" is much more suitable.


    WFQ is just one of several queue management methods that you can also use
    with QoS. QoS is only in affect when the bandwidth on the pipe reaches
    around 80% utilization. When applying bandwidth to the various queues, only
    the priority queue (of which there can only be one) has reserved bandwidth.
    The other queues only specify the minimum bandwidth available to each queue.
    QoS starts managing the drops of the various types of traffic just before
    the pipe is congested and does this in a way so that higher priority traffic
    has bandwidth at the expense of lower priority traffic before the pipe is
    congested. If the pipe is 100% congested it applies a more refined approach
    than dropping traffic at random.
     
    Thrill5, Jun 4, 2009
    #9
  10. Scooter133

    Scooter133 Guest

    Thank you all for your replies.

    The Type of traffic seems to come from many sources. We have out Sites
    connected via VPN with the PIXs. So the traffic could be a simple file
    transfer from one client to a server or vise versa. It could be a
    large email attachment, Someone from a remote office uploading a file
    to our own FTP Server, or connection to a Vendor's FastDownload
    (Aspera) site to get a 8gigabyte file.

    So we are talking UDP & TCP. I'm sure the Aspera Client does some
    funny things to get around typical TCP stuff too.

    A good example was someone from the 3Meg Office (remote) started to
    transfer a file from the 9meg office(HQ). The file was 7gigabytes...
    Everyone in the 3meg office could hardly get a packet in edge wise to
    the 9Meg Office to get to the HQ intranet Website. It was faster on
    their Cell Phones.

    I did find this : http://brahmamlv.blogspot.com/2008/10/qos-on-pixasa-part-4traffic-shaping-and.html
    http://blog.internetworkexpert.com/...–-part-4traffic-shaping-and-traffic-policing/

    It looks like I'd be able to do some shaping with the 7.x IOS on the
    PIX, though to get to the different types of Traffic I would need to
    upgrade.

    I'll see if I can put my SmartNet to use and see what TAC says...

    I'd love to put this on my Edge Router, though My new ISP wont let me
    have access to it to make the change...

    Scott<-
     
    Scooter133, Jun 4, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris
    Replies:
    0
    Views:
    609
    Chris
    Dec 23, 2003
  2. JP Morgan

    Traffic Shape/Limit?

    JP Morgan, Nov 16, 2004, in forum: Cisco
    Replies:
    1
    Views:
    3,083
    Ivan Ostreš
    Nov 17, 2004
  3. Giannici Federico

    Traffic-shape on ATM interface

    Giannici Federico, Mar 30, 2005, in forum: Cisco
    Replies:
    1
    Views:
    1,648
    thrill5
    Mar 31, 2005
  4. netproj

    show traffic-shape stat

    netproj, Dec 22, 2005, in forum: Cisco
    Replies:
    2
    Views:
    1,737
    netproj
    Dec 29, 2005
  5. Peter Danes
    Replies:
    1
    Views:
    405
    Peter Danes
    Mar 2, 2007
Loading...

Share This Page