Nexus 7K UDLD Err-Disabled Ports

[Alex Pfeil]

We have four Nexus 7Ks connected as a core network with vPC redundancy between all four.  Two of the 7Ks are connected to a 6513.  The 6513 was the spanning-tree root for the network.  Power to the 6513 was cut.  Approximately 8 ports between the 7Ks went UDLD err-disabled.  I found information on a Nexus 7K best practices guide which states:

UDLD is processed directly by the NEXUS 7000 SUPERVISOR CPU. It is not hardware off-loaded down to individual line cards. In case the CPU gets overloaded, UDLD messages may not be processed or sent, which can lead to an error-disable situation if UDLD is set to aggressive mode. To prevent such false positive situation, recommendation is to use UDLD in normal mode.

I was wondering if this would be the explanation for the UDLD err-disabled state of the ports in this example?

Thanks,

Alex Pfeil

[LA-Engineer]

If UDLD was enabled in aggressive mode on the ports then going into err-disabled would be expected behavior.  The Nexus did not receive UDLD packets from the neighbor and determined that something is wrong with the link.

Just shut and no-shut the ports to bring them back up after the 6513s are back online.

[Alex Pfeil]

The ports that went err-disabled were the Nexus ports that were connecting to other Nexus ports, not the 6513s.

[LA-Engineer]

Sorry, misunderstood that line. 

[washingtonsc]

Hi,

I had the same issue where there was a several arp requested due to CSCuj80949 bug. I don't know if the same problem occurs with you, but this is a ideia.

I needed to do a ios upgrade to 6.2(6) version

NXOS/OTV: low performance of pktmgr high cpu when continuous arp burst

CSCuj80949

Description

Symptom:
High cpu on pktmgr process (mts-data thread) and consequently drop of ARP packet and slow or no responses for ARP request. This affecting data path traffic as well as remote ARP entries will start time out on local devices, hence traffic will not be sent due to incomplete ARP.

Conditions:
This can happen when OTV unicast mode is used and there is constant rate or constant burst rate of broadcast ARP traffic send from remote sites to ADJ server (approx 1000 arp request per second)

Workaround:
Disable arp suppression by configuring in overlay interface "no otv suppress-arp-nd"