RATE-Limiting and

Vandy Hamidi vandy.hamidi at markettools.com
Thu Jul 3 20:40:07 UTC 2003


>From what I'm gathering, it's probably best to mark and police based on an access list similar to From Any to <web server> eq 80, or something to that effect.  Maybe something like From <Firewal NAT IP> to Any eq any for internal users and police based on that.
I don't think you can police based on individual flows that are defined by an aggregate ACL.
So basically you can prevent public site traffic and Internal traffic from affecting each other, but not from affecting itself.  An internal high-load user can slow down other users, but can be stopped from affecting web site performance.

Scott M, do you think the Microflow policer you referred to can limit traffic based on individual flows within a defined range (acl)?

	-=Vandy=-

-----Original Message-----
From: Scott McGrath [mailto:mcgrath at fas.harvard.edu]
Sent: Thursday, July 03, 2003 12:53 PM
To: Vandy Hamidi
Cc: Jack Bates; Andy Dills; prue; nanog at merit.edu
Subject: Re: RATE-Limiting and 



Depends on the equipment you have installed.  If you are running a
65xx/76xx if you are running mls with full flow masks you can set up a
microflow policer which would allow you to mark or drop traffic on a per
flow basis

                            Scott C. McGrath

On Thu, 3 Jul 2003, Vandy Hamidi wrote:

>
> Excellent point.  It does depend on the traffic type.
> Though I don't like to complicated my configs, you can always use CAR (cisco rate limiting) through an ACL to protect against the file transfer from the core servers issue you referred to below.  It can make sure a high bandwidth xfer won't suck up all your available B/W.
>
> Does anyone out there know how to limit B/W based on Flow or individual sessions?  Or even just source (where source is random).  For example, a CAR where each IP source gets no more than X% of B/W (still allowing bursts if bandwidth is available).  I think some QOS tagging and queuing would have to be involved.
>
> 	-=Vandy=-
>
> -----Original Message-----
> From: Jack Bates [mailto:jbates at brightok.net]
> Sent: Thursday, July 03, 2003 4:43 AM
> To: Andy Dills
> Cc: Vandy Hamidi; prue; nanog at merit.edu
> Subject: Re: Newbie network upgrade question, apologies in advance to
> NANOG
>
>
> Andy Dills wrote:
> >
> > Yes, but the original poster was dealing with DS3s connected to different
> > NAPs, which is why the packet out-of-order issue can be significant.
> >
>
> I'd say that a more significant issue is customer throughput. The nice
> aspect of per conn is that it not only tends to keep a decent load
> balance, it also limits bandwidth hogs from saturating all circuits.
> This of course depends on your desired result. An example in my case is
> my helpdesk. They are off two t1's with dsl and dialup customers. I'd
> prefer them not to tank both t1's when transfering files to and from the
> core servers.
>
> -Jack
>




More information about the NANOG mailing list