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

[Matthew Melbourne]

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):

2011 Jan 14 21:32:55 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.sitea over Ethernet2/1 - INIT (Revive Lost)
2011 Jan 14 21:32:55 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.sitea over Ethernet2/1 - UP
2011 Jan 15 07:31:37 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- DOWN (Hold timer expired)
2011 Jan 15 07:31:47 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- INIT (Revive Lost)
2011 Jan 15 07:31:47 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- UP
2011 Jan 15 16:03:19 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- DOWN (Hold timer expired)
2011 Jan 15 16:03:21 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- INIT (Revive Lost)
2011 Jan 15 16:03:21 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- UP
2011 Jan 15 21:32:12 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- DOWN (Hold timer expired)
2011 Jan 15 21:32:13 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- INIT (Revive Lost)
2011 Jan 15 21:32:13 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.siteb over Ethernet1/32- UP
2011 Jan 16 17:32:16 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.sitea over Ethernet2/1 - DOWN (Hold timer expired)
2011 Jan 16 17:32:17 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.sitea over Ethernet2/1 - INIT (Revive Lost)
2011 Jan 16 17:32:17 nx02.sitea %ISIS-5-ADJCHANGE:  isis-1 [1]  LAN
adj L2 rt0.sitea over Ethernet2/1 - UP

The 10G optical links between nx02.sitea and rt0.sitea/rt0.siteb (7600
edge routers) are free from errors (one uses LR optics, and the other
SR).

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

      module 2 :
        conformed 225684048 bytes; action: transmit
        violated 1729533 bytes; action: drop

      module 3 :
        conformed 870447416 bytes; action: transmit
        violated 947495183 bytes; action: drop

      module 4 :
        conformed 19261199 bytes; action: transmit
        violated 2022 bytes; action: drop


Is there any way of specifiying IS-IS traffic within a CoPP class, in
order to prevent it being policed in any way?

Cheers,

Matt

-- 
Matthew Melbourne