[c-nsp] CoPP IS-IS traffic on N7k

[Matthew Melbourne]

As a follow-up to this, I've discovered that the CPU utilisation for
'netstack' process jumps to 100% for ~5 mins. High ping times are
observed to the L3 connected addresses (over which IS-IS runs). This
is almost certainly responsible for the loss of IS-IS adjacencies.

Cheers,

Matt

On 24 January 2011 13:23, Matthew Melbourne <matt at melbourne.org.uk> wrote:
> Thanks Lincoln.
>
> I've manually added the CoPP entries for IS-IS/FabricPath to the
> policy, but we are still seeing IS-IS adjacencies drop, so I'm not
> convinced CoPP is the issue here. There are no other errors in the log
> at the time of the adjacency loss to point towards a cause.
>
> Very occasionally we're seeing:
>
> %MODULE-4-MOD_WARNING: Module 2 (serial: JAF1419BGPK) reported warning
> due to EOBC heartbeat failure in device 10 (device error 0xc000904d)
>
> However, these alerts are not co-incident with the loss of IS-IS
> adjacencies (though these alerts are seen for all modules), and the
> helpful advice so far is to "reseat all the modules to clear the ASIC
> buffers".
>
> Cheers,
>
> Matt
>
> On 16 January 2011 23:28, Lincoln Dale <ltd at cisco.com> wrote:
>> On 17/01/2011, at 7:02 AM, Matthew Melbourne wrote:
>>
>>> We are currently seeing IS-IS adjacencies flap on one of our pair of
>>> N7k boxes (eachN7k is dual-attached to two upstream edge routers):
>>> [..]
>>> I am wondering whether the default CoPP policy is classifying IS-IS
>>> CLNS traffic its class-default class and causing random instability
>>> (which is also visible on our ICMP monitoring):
>>>
>>> class-map class-default (match-any)
>>>      police cir 100 kbps , bc 310 ms
>>>      module 1 :
>>>        conformed 62024128193 bytes; action: transmit
>>>        violated 470896229 bytes; action: drop
>>
>> depending on when you applied the CoPP policy to the system (e.g. if this switch has been deployed for a while), it may well be that the CoPP policy wasn't specific enough to have ISIS explicitly mapped to its own class.
>>
>> over time we've added more & more classes into CoPP to make it more granular, but unless you've run the 'setup' script you won't pick those changes up with newer releases, as it would be bad practice for us to be changing users' configurations on ISSU.
>>
>>> Is there any way of specifiying IS-IS traffic within a CoPP class, in
>>> order to prevent it being policed in any way?
>>
>> ISIS uses a well know set of mac-addresses (0180.c200.0014/15) which you can use with a mac ACL for CoPP.
>>
>> most recent NX-OS 5.1 has this as the default CoPP policy:
>>
>>        mac access-list copp-system-acl-mac-fabricpath-isis
>>          10 permit any 0180.c200.0015 0000.0000.0000
>>          20 permit any 0180.c200.0014 0000.0000.0000
>>        !
>>        class-map type control-plane match-any copp-system-class-critical
>>          [..]
>>          match access-group name copp-system-acl-mac-fabricpath-isis
>>        !
>>        policy-map type control-plane copp-system-policy
>>          [..]
>>          class copp-system-class-critical
>>            set cos 7
>>            police cir 39600 kbps bc 250 ms conform transmit violate drop
>>          [..]
>>
>> if you wish to see the most recent iteration of the default policy, its in the documentation.
>> <http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/security/configuration/guide/Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_5.x_chapter24.html#con_1072128>
>>
>>
>> cheers,
>>
>> lincoln.
>
>
>
> --
> Matthew Melbourne
>



-- 
Matthew Melbourne