On Wed, 20 Oct 2010, Shanawaz wrote:
Lincoln,
On Wed, Oct 20, 2010 at 7:29 PM, Lincoln Dale <[email protected]> wrote:
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.
I will disagree with you here (and I will make my disagreement conditional
;) pending some testing tomorrow). When I removed the deny acl, the CoPP was
behaving as expected. However when I added the deny acl, I could SSH from
networks outside of 129.63.8.0/24. I have a feeling the deny is playing the
same role as a deny in an access-list which is referenced in a route-map. I
understand the deny will exempt traffic from having the policy applied.
I could be way off the mark here, I will check the rest of the CoPP policy
and also perhaps conclusively know by putting a log at the end of that deny
statement to see if there are any matches. Interestingly I am not seeing any
matches whatsoever on my default class which again makes me suspect the
only deny ip any any statement I have got.
It's my understanding that more IOS-like VTY ACLs are coming NX-OS 5.1,
which was supposed to be out last month, but wasn't on CCO the last time I
looked (late last week).
In CoPP, the pass/drop action is controlled by the policy itself, based on
the ACLs/classes you define.
I ended up implementing SSH access control through CoPP like this:
1. Create an access list to define hosts/networks that are allowed to
connect:
ip access-list MGMT-ALLOW
10 remark Limit management access to trusted hosts
20 permit tcp 10.1.1.0/24 any eq 22
30 permit tcp 10.2.1.0/24 any eq 22
...
no explicit deny at the end
2. Create an access list to define traffic to deny
ip access-list MGMT-ACCESS-DENY
statistics per-entry
10 remark Deny all management traffic that is not explicitly permitted
20 permit tcp any any telnet
20 permit tcp any any 22
...
no explicit deny at the end
3. Create a CoPP class map to allow management access, based on the ACL
above
class-map type control-plane match-any COPP-SYSTEM-CLASS-MGMT-ALLOW
match access-group name MGMT-ALLOW
4. Create another class-map to deny management access, based on your deny
ACL
class-map type control-plane match-any COPP-SYSTEM-CLASS-MGMT-DENY
match access-group name MGMT-DENY
5. Add these class maps to the system CoPP policy
policy-map type control-plane copp-system-policy
class COPP-SYSTEM-CLASS-MGMT-ALLOW
police cir 10000 kbps bc 250 ms conform transmit violate drop
class COPP-SYSTEM-CLASS-MGMT-DENY
police cir XXX kbps bc 250 ms conform drop violate drop
On the deny policy, since you're dropping all traffic, I would think you
can make the CIR pretty much whatever you want.
The order is important. Your deny policy must be after your allow
policies.
jms
class-map class-default (match-any)
police cir 100 kbps , bc 375 ms
module 1 :
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
module 2 :
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
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.
I am ssh'ing to various interfaces on the router, not to mgmt0 ip address
which is out of band
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".
Now thats interesting, I did make changes today to the copp policy and yet
it says
test-router#sh copp status
Last Config Operation: no match access-group name copp-system-acl-icmp
Last Config Operation Timestamp: 09:11:14 AEST Sep 21 2010
Last Config Operation Status: Success
Policy-map attached to the control-plane: copp-system-policy
Does that mean that everytime I change the copp policy I have to do no
service-policy and enable it again?
Thanks for your time once again, I can send the full CoPP policy off-list if
needed
Regards,
Shanawaz
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/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
