[59517] in North American Network Operators' Group
RE: RATE-Limiting and
daemon@ATHENA.MIT.EDU (Vandy Hamidi)
Thu Jul 3 16:40:43 2003
Date: Thu, 3 Jul 2003 13:40:07 -0700
From: "Vandy Hamidi" <vandy.hamidi@markettools.com>
To: "Scott McGrath" <mcgrath@fas.harvard.edu>
Cc: "Jack Bates" <jbates@brightok.net>, "Andy Dills" <andy@xecu.net>,
"prue" <prue@usc.edu>, <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu
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)?
-=3DVandy=3D-
-----Original Message-----
From: Scott McGrath [mailto:mcgrath@fas.harvard.edu]
Sent: Thursday, July 03, 2003 12:53 PM
To: Vandy Hamidi
Cc: Jack Bates; Andy Dills; prue; nanog@merit.edu
Subject: Re: RATE-Limiting and=20
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.
>
> -=3DVandy=3D-
>
> -----Original Message-----
> From: Jack Bates [mailto:jbates@brightok.net]
> Sent: Thursday, July 03, 2003 4:43 AM
> To: Andy Dills
> Cc: Vandy Hamidi; prue; nanog@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
>
