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

[Shanawaz]

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.

   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.
>
>
>