[c-nsp] CoPP for SSH on nexus 7k. Confused!

Wed Oct 20 11:49:13 EDT 2010

On Wed, 20 Oct 2010, Shanawaz wrote:

> Lincoln,
>
> On Wed, Oct 20, 2010 at 7:29 PM, Lincoln Dale <ltd at cisco.com> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>