NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
LACP no longer working on RN516 running 6.7.5
LACP bonding no longer seems to work with my RN516 on 6.7.5, the switch shows only one interface up, as if the teaming is Active Backup, not LACP. The MTU keeps resetting to 1500 from 9000, as if th...
Hello Tonkinite,
Have you tried removing the bond and connect the NAS just via ethernet and observe if the connection is stable?
Regards,
Marty_M
NETGEAR Community Team
Hello Tonkinite,
What hashing is set on the bonding/teaming? Please try setting different hashing type and check if it will make any difference? Please provide details on how do you test the disconnection problem? For isolation have you tried connecting the NAS to different port on the switch? The LACP setup, is the NAS set on static IP address or it is getting it via DHCP?
Regards,
Marty_M
NETGEAR Community Team
L2 hashing is being used, and the ports on the switch the unit is normally connected to are LAG'd in LACP mode as L2 hashing is the only possibility on the XS series switches at the present time, would appreciate if you would speak to the team in charge of the XS series firmware on behalf of the ReadyNAS community. If I were to change the hashing mode, the LAG'd ports on the switch would simply not see either connection as active, you can look at the thread I opened on Community a while back regarding this.
As to connecting to non LAG'd ports on the switch, the switch then shows both connections as active, but per DaneA, this setup is not optimal, I'm guessing that means failover would work properly, but suspect both connections would not be used simultaneously.
Additionally, the interfaces on the RN unit have fixed DHCP IP assignments (I typically setup all my RN units this way).
As to the status of the lines, I am trusting the XS switch UI panel not to lie, it says only one line is active, varying from one port to the other over time when I reboot the switch or whatever. This is not the case with the other, more recent unit, the RN626X, where the lines are LAG'd identically and both lines are always shown as active. A screenshot follows (the RN626X is connected on 1&2, the RN516 is connected on 3&4):
Switch port status, XS728T
Hello Tonkinite,
It does appear that both links wont go up at the same time. As per the type hashing for the switch it will depend on the type of switch if it is a layer 2 or layer 3. XS728T switch is only a layer 2 by default it only has layer 2 hashing. We can perform an OS re-install on the RN516 which will reset the network setting of the NAS and see if it will help with the address concern, for guide on how to perform OS re-install please go here and make sure to follow the guide carefully. Also for further isolation, if possible to connect the NAS to just a gigabit switch set the LAG and bonding/teaming then observe the connection.
Regards,
Marty_M
NETGEAR Community TeamReinstalling the OS had no effect.
I dissolved the bond and reestablished it. Also nothing.
Setting the link speed to force the ports to 1G on the switch also had no effect.
Dissolving the LAG on the switch and recreating it fixed it.
However, after that I noticed the bond MTU had reset to 1500, I reset it back to 9000 and the link hung, I had to reboot the unit to get it to come back up and it had reset itself to 1500 again.
I suspect this is the problem, not LACP. I think that with the newer firmware bonded interfaces may not allow Jumbo frame MTUs (or some subtypes may work but not others, though it's not clear why this would be). If this is the case, I'd be really surprised if a lot of your enterprise customers hadn't noticed.
If you have any further insights, please let me know.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
