From: Glenn Johnson (gjcomcast@comcast.net)
Date: Thu Jul 17 2003 - 00:32:26 GMT-3
Joe,
Other than your approach of dropping all non-https traffic above a
certain level (theoretically a heavy-handed approach), I agree that CAR is
an odd answer if the question focuses on "guaranteed X" (versus "limited to
X") bandwidth. Normally, I'd be tempted when first seeing particular
bandwidth "guarantee" terms, e.g., 300Kbps, in a requirement (that isn't
RSVP related) to use class based queueing:
Something like:
Access-list 101 permit tcp any any eq 443
Class HTTPSEC
Match ip add 101
Policy-map POLMAP
Class HTTPSEC
Bandwidth 300
Interface FA0/0
Service output POLMAP
(no setup is provided for other classes or the default class)
Sound reasonable?
Thanks
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Joe
Deleonardo
Sent: Wednesday, July 16, 2003 10:42 PM
To: security@groupstudy.com
Subject: Guarantee bandwidth
I have a question in a lab that says, "Guarantee all secure web traffic a
bandwidth of 300kbps gout out of R6."
Their answer is this:
rate-limit output access-group 121 296000 2000 2000 conform-action transmit
exceed-action drop
access-list 121 permit tcp any any eq 443
But that doesn't guarantee that amount of bandwidth, that limits the
bandwidth... right? It doesn't seem right to me.
I was thinking of doing this instead:
rate-limit out access-group 100 1248000 296000 296000 conform-action
transmit
exceed-action drop
access-list 100 deny tcp any any eq 443
access-list 100 permit ip any any
Do you think this is a good idea? It's a serial interface so the default is
1.544Mbps. Do you think there is a better way of doing it?
This archive was generated by hypermail 2.1.4 : Wed Aug 06 2003 - 06:52:42 GMT-3