NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Network connection issues with ReadyNAS RR4360X
My company purchased a ReadyNAS RR4360X a while back and we just put it into production recently in the hopes of eventually replacing a smaller capacity ReadyNAS 4312. The RR4360X is similar to the 4...
emedeiros wrote:
The drops are also evident when I try to manually copy large files from a Windows server to the RR4360X - the transfer speed is around 200 MB/s then suddently drops to 0 bytes/s for 10 or 15 seconds before going back up again - I even notice the ReadyNAS web interface page reload at times (pages changes to "Connecting to the ReadyNAS Admin Page...").
Do you see this when you copy large files from the RR4360x to the Windows server? Or only when the NAS is the destination?
What form of link aggregation are you using? Is the MTU set to the default 1500?
Have you downloaded the full log zip file, and looked for errors in there (from around the time you do the transfer test)? system.log and kernel.log are good places to look for disk or file system errors that might be related to the pauses in the transfer speed.
If you enable ssh, you could also look at the network stats before and after (ifconfig will give you dropped packets, overruns, etc). It's also pretty easy to install iperf, and use that to test the network connection separately from the RAID performance.
What disks are you using?
Have you enabled antivirus or file system indexing?
StephenB wrote:
emedeiros wrote:The drops are also evident when I try to manually copy large files from a Windows server to the RR4360X - the transfer speed is around 200 MB/s then suddently drops to 0 bytes/s for 10 or 15 seconds before going back up again - I even notice the ReadyNAS web interface page reload at times (pages changes to "Connecting to the ReadyNAS Admin Page...").
Do you see this when you copy large files from the RR4360x to the Windows server? Or only when the NAS is the destination?
Yes, I see this happen when copying both to and from the NAS.
What form of link aggregation are you using? Is the MTU set to the default 1500?
We aren't aggregating the links but for failover purposes we have Active Backup set as the Teaming Mode. Yes, the MTU is set to the default 1500.
Have you downloaded the full log zip file, and looked for errors in there (from around the time you do the transfer test)? system.log and kernel.log are good places to look for disk or file system errors that might be related to the pauses in the transfer speed.
I downloaded and looked at the suggested logs today after conducting a test where the speed dropped down to 0 bytes/sec but there are no errors in either log around the time of the test.
If you enable ssh, you could also look at the network stats before and after (ifconfig will give you dropped packets, overruns, etc). It's also pretty easy to install iperf, and use that to test the network connection separately from the RAID performance.
We haven't enabled ssh. I was going to after reading your reply but decided not to after a pop-up warned "Note: NETGEAR might deny support if you enable SSH access." just in case we end up having to purchase support, especially considering I don't have much Linux experience. I would need to get approval from my manager plus a bit of hand-holding to work through that type of testing.
What disks are you using?
We are using 12TB Seagate disks, 24 in total right now in a single volume (12 are ST12000NM001G and 12 are ST12000NM0007).
Have you enabled antivirus or file system indexing
No.
Thanks again for the assistance!
Can you duplicate the problem from a different PC (not necessarily a server)?
Also, is this happening with a share or with an iSCSI Lun?
emedeiros wrote:
What form of link aggregation are you using? Is the MTU set to the default 1500?
We aren't aggregating the links but for failover purposes we have Active Backup set as the Teaming Mode. Yes, the MTU is set to the default 1500.
Have you downloaded the full log zip file, and looked for errors in there (from around the time you do the transfer test)? system.log and kernel.log are good places to look for disk or file system errors that might be related to the pauses in the transfer speed.
I downloaded and looked at the suggested logs today after conducting a test where the speed dropped down to 0 bytes/sec but there are no errors in either log around the time of the test.
Network_settings.log are also a good place to look (errors, dropped, overruns, etc).
Do you have flow control enabled in the switches? That also could result in variable transfer rates.
emedeiros wrote:
We haven't enabled ssh. I was going to after reading your reply but decided not to after a pop-up warned "Note: NETGEAR might deny support if you enable SSH access." just in case we end up having to purchase support, especially considering I don't have much Linux experience. I would need to get approval from my manager plus a bit of hand-holding to work through that type of testing.
There is a clarification on that here: https://kb.netgear.com/30068/ReadyNAS-OS-6-SSH-access-support-and-configuration-guides
The specific things I suggested shouldn't void your ability to get support. But I think it be best to have someone experienced with linux do that troubleshooting, as it is easy to do damage with ssh.
emedeiros wrote:
We are using 12TB Seagate disks, 24 in total right now in a single volume (12 are ST12000NM001G and 12 are ST12000NM0007).
There should be no issue with those.
StephenB wrote:Can you duplicate the problem from a different PC (not necessarily a server)?
Yes, I have reproduced the problem from every computer I've tried my tests from, and I've tried from multiple PCs and servers.
Also, is this happening with a share or with an iSCSI Lun?
Share
emedeiros wrote:What form of link aggregation are you using? Is the MTU set to the default 1500?
We aren't aggregating the links but for failover purposes we have Active Backup set as the Teaming Mode. Yes, the MTU is set to the default 1500.
Have you downloaded the full log zip file, and looked for errors in there (from around the time you do the transfer test)? system.log and kernel.log are good places to look for disk or file system errors that might be related to the pauses in the transfer speed.
I downloaded and looked at the suggested logs today after conducting a test where the speed dropped down to 0 bytes/sec but there are no errors in either log around the time of the test.
Network_settings.log are also a good place to look (errors, dropped, overruns, etc).
Here is the network_settings.log (problematic NAS on the left):
Bond0 is the bonded adapter consisting of eth4 (set as Primary Device) and eth5. Those drops on the secondary interface (eth5) seemed odd to me. However, on my NAS not experiencing the issue there are similar drops (log on the right). Is that just the way the Active Backup mode deals with packets on the secondary inteface?
Do you have flow control enabled in the switches? That also could result in variable transfer rates.
No. Flow Control is disabled globally on both switches, and the NAS that is not experiencing the issue is using these same 2 switches.
emedeiros wrote:We haven't enabled ssh. I was going to after reading your reply but decided not to after a pop-up warned "Note: NETGEAR might deny support if you enable SSH access." just in case we end up having to purchase support, especially considering I don't have much Linux experience. I would need to get approval from my manager plus a bit of hand-holding to work through that type of testing.
There is a clarification on that here: https://kb.netgear.com/30068/ReadyNAS-OS-6-SSH-access-support-and-configuration-guides
The specific things I suggested shouldn't void your ability to get support. But I think it be best to have someone experienced with linux do that troubleshooting, as it is easy to do damage with ssh.
Thanks for the kb link. That makes me feel better about enabling SSH. My manager is willing to do so if necessary but we decided to first try creating a 2nd small volume to rule out having too many disks in one volume being the issue.
emedeiros wrote:
We are using 12TB Seagate disks, 24 in total right now in a single volume (12 are ST12000NM001G and 12 are ST12000NM0007).
There should be no issue with those.
Glad to hear about the disks themselves not being the problem :)
The new volume I created 7 hours ago consist of (4) 12TB ST12000NM0007 disks, RAID 5. It's still "resyncing" and says it has 40 hour remaining before it's complete. Once the resyncing process is complete I'll do more testing. Thanks again for your help!
Here is the network_settings.log (problematic NAS on the left):
Bond0 is the bonded adapter consisting of eth4 (set as Primary Device) and eth5. Those drops on the secondary interface (eth5) seemed odd to me. However, on my NAS not experiencing the issue there are similar drops (log on the right). Is that just the way the Active Backup mode deals with packets on the secondary inteface?
It doesn't look like the network_settings.log screenshot I inserted made it into my post. I've attached it.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
