Running the latest firmware. We have had a periodic issue with losing network connectivity to the NAS. The only way this can be restored is to power restart the NAS. After logging back in the gui logs don't show any issues, they do show the system restarting etc.
The NAS is connected via four ethernet links setup as two Bonds. Each bond of two ethernet links terminates on a separate Cisco 3560G switch which is setup with a port channel. Each Bond has it's own IP address.
When the issue occurs both switches show the port channels going down at exactly the same time. Other port channels on the switches remain up with no issues including those that carry the same vlan's as the port channel connected to the NAS.
The Cisco switches show the two physical ethernet interfaces dropping a few seconds apart and then the Port channel dropping immediately after they both go down, the weird this is that the two physicals come straight back up but the port channel remains down until we power reset.
I have tried manually shutting and no shutting the interfaces to try and get them to come back up but no luck.
What logs on the NAS should I be looking at to try and identify what's going on?
Cheers
Matt
Model: RR4312X| ReadyNAS 10GbE 12 Bays with up to 120TB total storage
As the switch is a layer 2 it doesn't have the option for layer 4. The load balance methods are not the same at each end however that shouldn't be causing any issues. We can certainly change it to layer 2+3 so both ends match however as we are running ISCSI most of the connections will end up running on a single link which defeats the purpose of link aggregation.
The same method should be in use at both ends, I think. That's definitely worth trying.
In 6.9.4 (coming soon) we currently plan to add the option to restrict the use of an iSCSI group to an individual interface which you may also find useful.
The same method should be in use at both ends, I think. That's definitely worth trying.
It doesn't really matter to LACP, it is just a transmit policy to load-balance the physical links. It isn't negotiated, and the receiver needs to handle whatever transmit policy the sender chooses.
The disadvantage of layer 3+layer 4 is that it can result in overrunning a client gigabit link. That shouldn't drop the interface, but it would force the switch to drop packets (and TCP flow control to kick in) unless ethernet flow control is enabled.
Switching to layer 2 xmit hash is probably worth a try. But I think I'd remove one of the bonds next, and see if those physical ports remain up (and actually connected) when the other bond drops. It's not clear to me that this problem is actually related to the link aggregation.
Thanks for all the replies. Because both bonds drop I lose visibility of what's occuring on the NAS but the logs don't show anything once I have power restarted it.
If I drop one of the Bonds then I don't have any redundancy whilst I am testing and this issue appears to be random and sometimes doesn't occur for three weeks so I am a little loathe to have no redundancy whilst I am waiting for this to recur.
I will definitely change the lacp configurations to match however I don't think this is the issue.
If I drop one of the Bonds then I don't have any redundancy whilst I am testing and this issue appears to be random and sometimes doesn't occur for three weeks so I am a little loathe to have no redundancy whilst I am waiting for this to recur.
