× NETGEAR will be terminating ReadyCLOUD service by July 1st, 2023. For more details click here.
Orbi WiFi 7 RBE973
Reply

Readynas rn214 lag setup on vlan switch

Leventh
Apprentice

Readynas rn214 lag setup on vlan switch

Dear all,
I have a D-Link dgs-1210-52 smart switch and like to know how can i configure my RN214 Nas Link Aggregation LACP on VLan, eg. maybe someone on this forum using this switch configured lag with vlan...
any idea?
Message 1 of 4
StephenB
Guru

Re: Readynas rn214 lag setup on vlan switch


@Leventh wrote:
Dear all,
I have a D-Link dgs-1210-52 smart switch and like to know how can i configure my RN214 Nas Link Aggregation LACP on VLan, eg. maybe someone on this forum using this switch configured lag with vlan...
any idea?

I don't have a D-link switch, so I can't help you on the switch side.  But you do want to set up the switch so that it doesn't include the VLAN tag on the ethernet frames sent to/from the NAS.  Instead you want the switch to add/remove those tags.  There should be a way to do that (there is on similar Netgear switches).  Then as far as the NAS is concerned, it isn't on a VLAN.

 

Get the VLAN working first with only one ethernet connection to the NAS.  

 

Then add the LAG.  There are two basic choices: 

  • Use LACP on both the NAS and the switch
  • Use a static LAG on the switch and round-robin on the NAS

If this is the only LAG on your network, then just use LACP.  If you have more than one LAG, then the best choice depends on your use case. 

 

LACP is best if you have a lot of clients accessing the NAS simultaneously.  If this is your goal, then setting up the LAG isn't worth the bother unless you have a reasonable number of clients.  If you only have two or three you usually won't see much performance gain (if any).  

 

But if you just want to get the highest throughput to another device that also has a LAG (for instance another NAS), then using static LAGs for both devices and round-robin on the NAS is what you'd need.  LACP is designed to limit the flow between two devices to 1 gigabit. 

 

If you do use the static lag configuration, you should probably enable ethernet flow control on the switch.  That will prevent buffer overrun when 1 gigabit clients are downloading data from the NAS.

 

Be careful on the MTU.  Some switches configure that separately for each link and the LAG, and that can cause trouble.  Personally I'd just go with the default 1500 bytes, and not use jumbo frames at all.  But if you do want jumbo frames, then start with 1500 bytes, and get that working first.

 

Message 2 of 4
schumaku
Guru

Re: Readynas rn214 lag setup on vlan switch


@StephenB wrote:

But if you just want to get the highest throughput to another device that also has a LAG (for instance another NAS), then using static LAGs for both devices and round-robin on the NAS is what you'd need.  LACP is designed to limit the flow between two devices to 1 gigabit. 

Uhhhhh Stephen ... LACP does by default (and on most of these Web/Smart Managed switch model lines of any vendor - which have a lot of common things under thier hoods) make use of an XOR xmit hash based on the L2 MAC. This does indeed limit the speed between the same teo MAC addresses on both ends of the LAN to the speed of one PHY link. In case of a pure GbE switch that's then the 1 Gb mentioned of course.

 

Managed L2+L3 switches allow the configuration of other xmit hash modes basing on MAC+IP address - so this limitation does not apply IMHO. 

PS. On the other hand, I'm lost on how the vendors of Cable Modems and the WAN-aggregation capable routers overcome this limitation - e.g. NTGR does use LACP on the CM1100 - and there are just two MAC addresses involved on that local network: The Cable Modem "LAN" and the router WAN.

Message 3 of 4
StephenB
Guru

Re: Readynas rn214 lag setup on vlan switch


@schumaku wrote:

Managed L2+L3 switches allow the configuration of other xmit hash modes basing on MAC+IP address - so this limitation does not apply IMHO. 


I disagree.  For example, if you are doing a simple SMB transfer changing the xmit hash won't help.  No matter what hash you pick, it's a single flow, and that hash will map the entire flow to a single interface.  And even if you are doing something else on a different port simultaneously, there's still a 50-50 chance that the xmit hash will put both flows on the same interface. 

 

Another complication is that there are two LACP lags (NAS->Switch and Switch-Client), and there is no guarantee that the Switch will use exactly the same hash as the NAS.  So even if the NAS hash puts the two flows on the different links, the switch might not.

 

If you want to guarantee 2 gbit flows through the NAS->switch->client, then round-robin in the NAS and static LAG is the simplest way I know to do that.  In the other direction it depends on how the sending client chooses to load packets onto the two interfaces.

 

BTW, my own switches don't allow me to set the hash with LACP.  The GS728TPv2 is L2+L3, and includes routing functions.  But it doesn't allow me to set the hash.  Though I'm no longer using LACP, since my RN520 NAS both are connected with 10 gigabit.

Message 4 of 4
Top Contributors
Discussion stats
  • 3 replies
  • 677 views
  • 0 kudos
  • 3 in conversation
Announcements