Link aggregation (LACP) problems

what does your network > interfaces show in frontview?

mine shows:

Online (Redundant) / 2 Gbit / Full-Duplex

along with 802.3add lacp, xmit hash policy set for layer 3+4

it works with my linksys srw2008 switch

TeknoJnky wrote:
Online (Redundant) / 2 Gbit / Full-Duplex

I've got that too.

along with 802.3add lacp, xmit hash policy set for layer 3+4

I've just got 802.3ad lacp. No second 'd' and there's not xmit hash policy options anywhere on the ReadyNAS page.

it works with my linksys srw2008 switch

I've got a couple of those too: I love them. Even more now I've learned from you they support LACP. I didn't know that, but it's worth an experiment.

What's weird is that my SBS2008 server doesn't seem to suffer from this problem: I have been copying files from my old NAS to my ReadyNAS for a whole day without this problem. I hope I didn't loose any data: I thought I had 2.5TB of data, but it turned out to be only 1.5TB :roll:

sorry late night typing, 802.3ad

I think maybe the xmit has policy is part of the .16 beta.

I know when I tested my lacp, I could have a tranfer going and pull either cable and it would keep going.

You might want to try that, and also test pinging the nas and doing cable pulls.

when in lacp, the switch is suppsoed to see only 1 mac address, it sounds like either the nas or the switch is still seeing/broadcasting both mac.

also, you may want to double check that you have the nas plugged into the same ports that you have set for LACP on the switch.. I have screwed that up my self in the past, when testing different ports/cables, I did not have the nas on the same ports as the switch set for lacp.

TeknoJnky wrote:
I think maybe the xmit has policy is part of the .16 beta.

Is there any risk for my date to upgrade to .16 beta?

I know when I tested my lacp, I could have a tranfer going and pull either cable and it would keep going.

So does mine, when checkin on my server. But depending on which connection I plug it first, the DHCP server hands it out another IP address.

when in lacp, the switch is suppsoed to see only 1 mac address, it sounds like either the nas or the switch is still seeing/broadcasting both mac.

Perhaps, but the wrong IP address reported belonged to the machine I tested on...

also, you may want to double check that you have the nas plugged into the same ports that you have set for LACP on the switch.. I have screwed that up my self in the past, when testing different ports/cables, I did not have the nas on the same ports as the switch set for lacp.

That I got. I did get side-tracked however, by upgrading my switch' firmware. The new firmware no longer showed the WebView interface, so I had to downgrade again, something not supported by Cisco. I've spent the whole morning with Cisco support and they will send me a new switch. Top notch service, that's why I buy professional equipment. I doubt however is this replacement switch will also cure this problem...

MindBender wrote:
Is there any risk for my date to upgrade to .16 beta?

You can't downgrade after upgrading to the beta. Your data should be O.K. but it is more risky running betas than production firmware. If you try the beta please backup your data first.

re .16 beta

well, I had problems some of the betas, I guess something with addon changes.

I'm running T58 now on both my devices, which seem to be working ok, BUT I had to factory default both of them to get them working right.

I doubt xmit transmit policy would make a difference in your case though.

I assume you have rebooted device at least once since enabling lacp?

mdgm wrote:
Your data should be O.K. but it is more risky running betas than production firmware. If you try the beta please backup your data first.

Backing up 6TB of data; I wonder where I'm supposed to put that. I know why you say that, but it makes me rather nervous. I guess I'll be fine with production software. I have to admit: It makes a solid impression. No sloppy errors found yet. Though it hurts to see a volume named 'c' on a Linux machine :wink:

TeknoJnky wrote:
well, I had problems some of the betas, I guess something with addon changes.

Well, my life is depending on the SVN add-ons, so I suppose I'd better stay clear of the betas then.

I'm running T58 now on both my devices, which seem to be working ok, BUT I had to factory default both of them to get them working right.

Doesn't that clear all data?

I doubt xmit transmit policy would make a difference in your case though.

I agree. At least I'm going to wait for the new switch to arrive. I'm messing around for three solid days now, and I still don't have the AD access rights correctly. This is a lot more work than I thought.

I assume you have rebooted device at least once since enabling lacp?

Uhm, no. Should I? I was surprised I had to reboot the machine to get the extra space on the bigger disks I slipped in available. But it does a really nice job with that.

yes factory default clears all data, thats what backups are for. Although restoring 4+ tb is no fun either.

well your supposed to reboot if/when you enable jumbo frames, I don't remember if it prompts for reboot for bonding or not.

But I always like to reboot when making network changes to ensure they 'stick' and to clear out any old info/config in memory or elsewhere.

Just reviving this old thread to post the solution. I have had weird network problem on and off, but I never correlated them to link aggregation configuration. But this morning only have of my network was reachable and links seemed to be severed asymmetrically (A can pin B, but B cannot ping A). I noticed that one of my aggregated links defaulted back to 100MB/s and after re-patching a faulty wire, nothing worked anymore.

It turned out that I had configured a static link aggregation, which is not supported by ReadyNAS. It should be a dynamic link aggregation, and the difference is not obvious in my switch's web front-end.

When configuring link aggregation on a LinkSys/Cisco SRW2024P for ReadyNAS, open a webpage, navigate to your Switch's web front-end and log in. Now select the 'Port Management'-tab and in there the 'LCAP'-sub-tab. Note: Do NOT create a link aggregation under the 'Link Aggregation'-sub-tab, as this will create a static aggregation.
In the 'LCAP'-sub-tab, enable the port you'd link to aggregate and select an identical LAG and priority for all of them:
<Can't seem to upload screenshot>
After clicking the 'Save Settings'-button, go to the 'Link Aggregation'-sub-tab. Here a new aggregation should appear with the LAG selected. The type should be 'LACP'. With the 'Details'-button, the aggregation can be configured and an name can be added. If the type says 'static', it's an old aggregation created in this sub-tab with the create button. This type is not supported by ReadyNAS.
<Can't seem to upload screenshot>
After clicking the 'Save Settings'-button, go to the 'Port Settings'-sub-tab. Here all ports assigned to the freshly created aggregation should state 'IEEE802.3x' under Flow Control. If this is the case, you have successfully configured a link aggregation compatible with ReadyNAS.
<Can't seem to upload screenshot>