Switch is not forwarding traffic

[davidj_cogliane]

A customer reported a lack of connectivity to one of their closets. We saw link, and EDP on both ends of the link but the devices could not ping each other. We moved the link to slot 1 of the 2 slot X670G2-48x-4q stack and were immediately able to ping and ssh across the link.

I looked around a little more and found the below errors after a reboot caused by a power outage.

I also discovered I could not ping other devices connected to slot 2. I rebooted slot 2 and was then able to ping the devices connected to it.

These switches are plugged into a UPS.

Are we confident this was an anomaly caused by the power related reboot?
Is there anything else I should check?

Thanks,

[Patrick_Voss]

Hello David,

What version is this stack running?

[davidj_cogliane]

If I am understanding your correctly I think we are in agreement that the error messages could be the result of the slots powering up in an unconventional manner.

Both slots are 670G-2s and the stack links are clean.
Slot-1 50_Rochester_670s.4 # sho slotSlots Type Configured State Ports
--------------------------------------------------------------------
Slot-1 X670G2-48x-4q X670G2-48x-4q Operational 64
Slot-2 X670G2-48x-4q X670G2-48x-4q Operational 64
Slot-3 Empty 0
Slot-4 Empty 0
Slot-5 Empty 0
Slot-6 Empty 0
Slot-7 Empty 0
Slot-8 Empty 0

Slot-1 50_Rochester_670s.5 # sho port stack-p rxerrors
Port Rx Error Monitor Tue Aug 16 07:46:18 2016
Port Link Rx Rx Rx Rx Rx Rx Rx
State Crc Over Under Frag Jabber Align Lost
================================================================================
1:1 A 0 0 0 0 0 0 0
1:2 A 0 0 0 0 0 0 0
2:1 A 0 0 0 0 0 0 0
2:2 A 0 0 0 0 0 0 0

======================================================

Just to confirm, we are saying that slot 2 was not forwarding traffic because it was out of sink with the master.
Further more we believe the slots became out of sink because of the power related reboot, because the stack ports are error free.

Correct?

[Tripathy__Priya]

Hello David,

Looking at the logs for the errors noticed :

Slot-4: Failed to get hash control on unit 0: Operation timed out:

Under normal circumstances when X670G2 stacked with say X770, non unicast traffic flowing across the slot. When slot (X670G2) rebooted above error is thrown in to log.

Slot-2: mcmgr cannot write msg_id 5 to MASTER connection 0:

The above DM warning was because a message sent from mcmgr in back up to primary failed. Note this should have happened during the bootup scenario where the backup was not connected yo primary (mcmgr) yet.

Going forward kindly check if the stack used in the network of X670 and X770 connected each other or any other stack switch. Moreover i could see you are running with Exos15.7.3.1 version. Whereas the recommended release for X670 stack switch is Exos16.1.3.6 p1-7.

Also you need to check the stacking cable connected between them to isolate any power usage issue.

[davidj_cogliane]

summitX-15.7.3.1-patch1-6.xos