You should really consider shaping as opposed to policing. You can do CAR
without the PFC, just like you would a router, however this is slower and
much more processor intensive. You can police with hardware but need a PFC.
Shaping will provider a much more elegant approach to limiting the amount of
bandwidth for whatever you need to limit (VLAN, protocol, etc). If you
police traffic you end up forcing TCP/IP to re-transmit, however if you
shape, traffic is queued and you will not get the re-transmits. Your
traffic curve smoothes out and reduce your re-transmits. Shaping requires a
PFC.
with the msfc2/pfc2 car does not work. been there, done that and found out
the hard way. we migrated from a 7200 platform and modified the config from
"int fast 0/0.xxx" to int "Vlan xxx" and pasted all of the cust. configs
into the msfc2...including CAR statements. CAR had no effect on traffic
policing.
this was about a year ago and our local cisco se talked to a product manager
and dev eng about the issue. i ?believe? packets are switched in the PFC2
(TCAM) and CAR policy is not downloaded into it. ACL's are downloaded as
policy into the PFC2, however, i believe unless the acl has a "log"
statement, it doesn't touch the msfc2 either.
policing (qos acl's) in the CatOS works well for us. some of the IOS acl
features do not exist yet (i.e. time-of-day).
cheers,
j
BTW: i thought CAR *was* a policer...
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:07 EDT