On 20/10/2010, at 4:42 PM, Shanawaz wrote: > 1. I assume this is happening because all traffic is matching the deny > statement in the ACL copp-system-acl-telnet. What does the deny in an CoPP > ACL do?
in the context of a CoPP policy: nothing. its not valid to have a 'deny' IP ACL matching a CoPP policy. it effectively won't match anything. > 2. Isnt there a 'deny ip any any'by default at the end of all access-lists. > In this case.. even the ACL copp-system-acl-ssh would have a deny ip any any > at the end. implicit deny is not there for CoPP, because CoPP is closer to QoS in behavior that it only 'matches' against permit statements. also note that 'class-default' CoPP class-map may be allowing this traffic although your policy you listed below looks entirely valid. > I have tried my best to explain, but then if you dont understand the > scenario, I can try again ;) your CoPP policy looks valid which makes me think of two possibilities: 1. you are connecting to the vty via out-of-band mgmt0 which is in the management vrf. since its out-of-band the inband CoPP policy does not apply. 2. your new CoPP is not actually applied. you will need to do 'conf t; control-plane; no service-policy input copp-system-policy; service-policy input copp-system-policy' to reapply it. take note of the timestamp on "show copp status" and output/content of "show policy-map interface control-plane". cheers, lincoln. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
