How do I undo Link Aggregation of my switch dies?

Currently reading
How do I undo Link Aggregation of my switch dies?

2
0
NAS
DS1618+, DS1511+
Operating system
  1. Windows
If I setup all 4 ports of my Synology to be bonded for link aggregation (and then set it up in my managed switch), what happens if the switch dies?

With my old switch I swapped it out for a regular switch and had to re-swap it back in because i could no longer access my synology devices in any way.

If I re-do the link aggregation and my switch dies is there a way for me to get into the synology and undo the bond so that I can access it via a browser again?

I tried googling this but I did not see any results explaining it.

Thanks
 
Hm, I was not aware of this DSM reset mode 1. Trying to determine if it would really mess up my network settings if I had to do that. Thank you for the suggestions.
 
If you chose the variant of LAG that requires your switch to be configured then you have the choice when the switch dies of
  1. Replacing the switch with one that can be configured the same for LAG
  2. Doing a DSM mode 1 reset and using whichever switch is to hand
If you didn’t choose the variant that require switch configuration then just replace the dead switch with another one.

If not losing your NAS’s network settings, of which LAG is part of them, is most important then replicate the switch setup with a new switch. Otherwise your remaining option is to retain the network settings and use the NAS as a doorstop.
 
LAG should still be accessible if you pull out all the cables bar one - it is designed to offer redundancy too.

Using all 4 for LAG is reserved for particularly demanding networks, where multiple clients demand around 1GbE each at the same time and in the same direction. It may give you a theoretical 8 lanes of 1GbE but it does not offer anything above 1GbE to any single client. On a small NAS other bottlenecks would be waiting for you before that point though - CPU capacity, spindle limitations, IOPS, backplane limits, SATA's half-duplex design, read/seek/write latency etc etc.

I am an advocate of 2-port LAGs when possible - both for redundancy and performance corner-cases. For small networks and small SATA NASes anything above 2 tends to be more like 'plunging returns' rather than just 'diminishing returns'.
 
Last edited:
I had used the Adaptive Load Balancing / Balanced-SLB* with my older unmanaged switch. Then Dynamic Link Aggregation / Balanced-TCP* with the managed switch, and it needs switch configuration. Can't recall what happened when pulling cables. Had thought that Active/Standby / Active/Backup* would be required to support cable failure. But did test Dynamic LAG on the NAS to an unmanaged switch and that didn't work.

The easiest way to find out what happen is to move the cables to unconfigured (i.e. like an unmanaged switch has) ports and see if the LAG still works. And do this before the switch dies.

If there's any doubt then leave one port configured as normal and that will work with any switch type.



* first are available when not using vSwitch, second are when using it. vSwitch is enabled if you use VMM.
 
Last edited:
Can't recall what happened when pulling cables. Had thought that Active/Standby / Active/Backup* would be required to support cable failure. But did test Dynamic LAG on the NAS to an unmanaged switch and that didn't work.
I think you may be thinking of the old static link aggregation - it was infamous for sending packets down a dead link for as long as it felt like it before 'curing itself' and using a good port for a while. With an intermittent cable fault It was not a fun protocol to use or fault-find!

Active/Standby just uses a single link at all times, with the second providing a redundant link should the first one have a detected failure. Pretty good for a simple unplug event but not always successful at more subtle faults. It provides no extra / aggregated bandwidth to the network, costs you a port and handicaps the functional switch backplane capacity.
 
I think you may be thinking of the old static link aggregation
That's all my unmanaged switch supports, but seems to work ok as a pseudo trunking to the main managed switch. That unmanaged switch hasn't much contention but I thought 'why not'.

The adaptive load balancing works well with an unmanaged switch: nothing to do on the switch. But I'm using Balanced-TCP now.
 
ALB is pretty-good in it's own right these days, so much so that I tend to use it on managed switches too. As the days of aggregating a switch trunk are receding and being replaced by higher bandwidth dedicated SFPs I would not be surprised if many users/managers don't bother with anything else.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Well for example Snapshot replication can be configured to target specific interface/IP. I have it...
Replies
10
Views
2,814
ALB does work with unmanaged switches as the configuration is managed by the NAS alone. There are other...
Replies
10
Views
20,610

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top