Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Stop one user from using all Bandwidth? Traffic Shape?

Reply
Thread Tools

Stop one user from using all Bandwidth? Traffic Shape?

 
 
Scooter133
Guest
Posts: n/a
 
      06-02-2009
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<-
 
Reply With Quote
 
 
 
 
Christoph Gartmann
Guest
Posts: n/a
 
      06-02-2009
In article <(E-Mail Removed)>, Scooter133 <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Scooter133
Guest
Posts: n/a
 
      06-02-2009
On Jun 2, 8:35*am, Artie Lange <(E-Mail Removed)> wrote:
> u will have to upgrade the OS
>
> http://supportwiki.cisco.com/ViewWik...x.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<-
 
Reply With Quote
 
Thrill5
Guest
Posts: n/a
 
      06-03-2009
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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<-



 
Reply With Quote
 
Rob
Guest
Posts: n/a
 
      06-03-2009
Thrill5 <(E-Mail Removed)> 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.
 
Reply With Quote
 
bod43
Guest
Posts: n/a
 
      06-03-2009
On 3 June, 12:16, Rob <(E-Mail Removed)> wrote:
> Thrill5 <(E-Mail Removed)> 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.

 
Reply With Quote
 
alexd
Guest
Posts: n/a
 
      06-03-2009
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) ((E-Mail Removed))
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


 
Reply With Quote
 
fugettaboutit
Guest
Posts: n/a
 
      06-03-2009
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 <(E-Mail Removed)> 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.

 
Reply With Quote
 
Thrill5
Guest
Posts: n/a
 
      06-04-2009

"Rob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)4all.nl...
> Thrill5 <(E-Mail Removed)> 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.


 
Reply With Quote
 
Scooter133
Guest
Posts: n/a
 
      06-04-2009
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/1...aping-and.html
http://blog.internetworkexpert.com/2...ffic-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<-
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FTP outward traffic causing "Unidentified IP traffic" error on ISA 2004 server connected to a PIX quentinhudson@hotmail.com Cisco 0 05-31-2006 11:43 AM
How does typical ISP traffic shaping/bandwidth limiting work ? Do ISP's allow bursty traffic per second ? Skybuck Flying Cisco 0 01-19-2006 08:50 PM
traffic-shaping limit ftp traffic Hypno999 Cisco 5 10-08-2005 07:25 AM
f2.8 vs f3.7- Is it one stop or 2 stop difference zxcvar Digital Photography 12 05-20-2004 06:28 PM
How to stop a thread without using stop() Son KwonNam Java 11 04-09-2004 08:01 PM



Advertisments