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 <[email protected]> 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 <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
