Synology network bonding with LACP

These are my notes for configuring my HomeLab NAS for LACP (“Link Aggregation“, “network bonding” etc.) to increase bandwidth.

My home lab consists of a couple of Intel NUCs running the free edition of VMware vSphere 6U2, each with 16GB RAM and 256GB SSD. For additional storage, I use a Synology DS1815+ NAS.

As the NUCs have only one 1Gbps network interface, I configured them as a ‘trunk’, carrying all VLANs. The Synology NAS has multiple network interfaces; I started out with a single connection.

To improve NAS bandwidth (and for my own amusement), I decided to upgrade the single 1Gbps connection to 2x 1Gbps using the “LACP” (Link Aggregation) protocol. I use NetGear smart switches with VLAN and LACP support, so this should be easy…

HomeLab setup

  • Step 1: enable bonding on the Synology; log on to the web admin panel and go to Control Panel, Network, Network Interface, Create -> Create Bond. Choose LACP, select the interfaces to bond (I use a static IP address).
  • Step 2: log into the NetGear switch, create a Link Aggregation Group (LAG) consisting of both ports. I used LAG1, with ports 7 and 8.
  • Step 3: connect both network cables, check if everything works.

At this point, I ran into trouble. I couldn’t reach the NAS anymore. Turns out I made a couple of mistakes in my NetGear configuration. The fix was:

  • Specify Jumbo Frames (9216) on the LAG;
    not (just) on the physical interfaces.
  • Specify VLAN settings on the LAG;
    check the VLAN membership as well as the PVID settings.

The NetGear interface doesn’t show LAG settings by default – you need to explicitly select “LAG” or “All” settings. I overlooked this at first:


Incorrect VLAN settings caused the NAS to drop off the network; LAG traffic wasn’t tagged even though both physical interfaces were properly configured. It took me a while to realize and fix.

So, here’s a couple of screenshots:

Step 1: Synology – Create bond, set IP and Jumbo Frames on the bond

Synology bond settings


Step 2: Netgear – Create LAG, set VLAN and Jumbo Frames on the LAG

Create LAG, select members:


Configure VLAN membership and PVID for the LAG as well:



Step 3: Connect and enjoy 2Gbps network bandwidth

I tried copying a couple of large files from the NAS to two different vSphere hosts – bandwidth clearly exceeds 1Gbps now.


Synology DSM 6 – rebalancing BTRFS

I recently upgraded my Synology from 4x 3TiB to 4x 6TiB disks (WD Red).

I could have simply installed the new disks and created a BTRFS volume (which would have become /volume2) but I decided to take a different route:

  1. Install 2x 6TiB disks and format as RAID-0 (mounted on /volume2).
  2. Copy all relevant data from the old disks to the new disks, and verify.
    If anything were to go wrong, I still had my data on the old disks.
  3. Remove the old /volume1 4x 3TiB disks for safekeeping, insert 2x 6TiB disks and create a new /volume1 using BTRFS.
  4. Copy all data from /volume2 (RAID-0) to /volume1 (BTRFS), and verify.
  5. Destroy /volume2 and add the remaining disks to /volume1.

Now, all my data is effectively stored on the first 2 disks in the new volume. BTRFS can rebalance the data chunks across all spindles. Open an SSH connection to the Synology NAS, and issue the following command:

command: btrfs balance start /volume1

This operation took several hours to complete – it had to rebalance about 6 terabytes of data… I opened a second SSH session to monitor progress:

btrfs balance status -v /volume1

SELinux fix: allowing write to /var/lib/mod_security/

There’s a long-standing bug that prevents mod_security from writing to /var/lib/mod_security/.

According to Red Hat Bugzilla this bug should been fixed around May 2013, but it still exists – on fully patched CentOS 6.5. From /var/log/audit/audit.log:

type=AVC msg=audit(1411718594.811:7017): avc: denied { write } for pid=28144 comm="httpd" name="global.dir" \
dev=dm-0 ino=1577960 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file

type=AVC msg=audit(1411718594.812:7018): avc: denied { write } for pid=28144 comm="httpd" name="ip.dir" \
dev=dm-0 ino=1577962 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file

To relabel this directory with the proper “httpd_var_lib_t” context, run the following as root:

semanage fcontext -a -t httpd_var_lib_t "/var/lib/mod_security(/.*)?"
restorecon -Rv /var/lib/mod_security

Running the Archiveteam Warrior on ESXi

The Archiveteam Warrior is available for download as an OVA virtual appliance for use with VirtualBox, VMware Workstation/Player etc.

To use this virtual appliance on VMware ESXi 5.1, you need to make some changes related to unsupported virtual hardware.

The instructions below are for Windows – the VMware vSphere Client doesn’t run on my Mac or Linux boxes, so I keep a Windows VM around just to run the vSphere client.

Download the .OVA file and extract its contents

An OVA file is a TAR file. You can use 7-Zip to unpack the OVA file (to your Desktop). After unpacking, you should see 3 new files:


Modify the .OVF file to make it compatible with ESXi

Open the .OVF file in a text editor (use Notepad or Notepad++). It is an XML formatted file, describing the virtual appliance.

First, change the Virtual Machine type (line 38):




Next, locate the virtual SATA storage controller (starting at line 75):

 <rasd:Description>SATA Controller</rasd:Description>

This virtual SATA controller is not supported by ESXi 5.1, so replace the item with the following:

 <rasd:Description>SCSI Controller</rasd:Description>

Save the OVF file.

Import the Virtual Appliance

  1. Start the vSphere Client and select File > Deploy OVF Template.
  2. Browse to the .OVF file (on your Desktop) and click Next.
  3. Now, vSphere Client will display a warning that the “Debian” OS is unknown, and was remapped to “Other (32-bit)”. You can ignore this warning. Deployment should complete successfully.

Power on the Virtual Machine and follow the instructions on the Console window – happy Archiving!

Fixing corroded battery contacts on the Wii Fit Balance Board

I inadvertently left some Duracell alkaline batteries in the Balance Board. Sure enough, they were already starting to leak – damaging the battery contacts in the Balance Board.

It turns out there is a relatively easy way to remove the gunk from the leaky Duracells: they are alkaline batteries, so a mild acid (household vinegar) should do the trick. After disassembling the Balance Board, carefully remove the corroded metal contacts from the battery holder and drop them in a small jar with household vinegar:

Dip battery contacts in small glass jar with vinegarIMG_5323

Watch the corrosion dissolve; if needed, use a toothbrush or Q-tip to brush the last bits of gunk from the contacts. Rinse with water, and allow the contacts to properly dry before re-assembly.

P.S. It seems that Duracell batteries are quite prone to leaking – quality sure went downhill over the years. I’m replacing all of them to prevent further damage.