->Also, did you find any perfomance delay with multiple QOS
->ACLs on a port within CatOS?
the qos for a port can be either defined as vlan or port based. depending
upon how the port was defined, you can map the qos acl to police ingress
(cust. upstream) traffic on either the port or vlan. ingress being the
operative word. to police a cust. egress (downstream) traffic, we've
managed to work around this applying a second qos acl to the vlan connecting
to our core gsr. traffic coming into the Cat6509 from the gsr (heading
downstream to the cust.) is policed on this vlan.
policing on both ingress and egress (i have heard) will require a new
hardware spin. either a new PCF2 (2a?) or supe 2a, or supe3. maybe someone
can comment on this.
we run a pure fibre metro network and provide transparent lan service in
addition to internet access. customers purchasing both services would
require a dot1q trunk. in that scenario, the port qos must be vlan based
with the acl mapped to the internet vlan of the dot1q trunk. in total we
run approx. 800 vlans on the network and about 200 qos acls for internet in
addition to vacls. policing is all done in silicon with no performance hit
on the cust. traffic or the SP cpu % utilization.
the only "gotcha" we found with a large number of acls in the CatOS is that
it burns up NVRAM on the supe. simply clear the acl from nvram and tell the
supe where it can get the acl file on its next reload.
http://cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_3/confg_gd/acc_
list.htm#31809
->http://www.etestinglabs.com/main/reports/cisco11_01.pdf
thanks for the url. interesting reading.
cheers,
j
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:35 EDT