Skip to main content

Link aggregation and VLANs on QNAP with firmware 3.4.0

The new QNAP firmware (3.4.0) supports 802.1q VLAN tagging, but you can't create multiple interfaces in different VLANs on the same physical interface through the webinterface.
In the case of link aggregation (LACP 802.3ad for example), that means only 1 VLAN and 1 IP address can be used.
Fortunately, QNAP allows full access to the underlying Linux system. Adding a VLAN interface goes like this (the example uses VLAN 234)
# /usr/local/bin/vconfig add bond0 234
# ifconfig bond0.234 192.168.2.30 broadcast 192.168.2.255 netmask 255.255.255.0

of course, this change is not permanent, a reboot will not automatically start this interface. I'll blog about making it permanent later.
Labels:

Comments

Scott said…
Hey Bert,

I was hoping for multiple virtual interfaces so I could setup a few vlans for my ESXi home lab. i would really like to have one for NFS and one for management. So I look forward to your next post.

On a side note, have you noticed any performance issue on the network interfaces since updating to 3.4. I have noticed my bandwith drop significantly in the resource monitor. My test VMs seem to hang for a few seconds while things get caught up. Have you noticed anything like this?
24/2/11 23:18
Bert de Bruijn said…
Hi Scott,
I haven't configured my VLANs permanently yet, just temporarily as I've shown, and it works very well. I've tested network speed using ping -f. and that pulls 1Gbps without problems. I haven't noticed disk speed issues either, but haven't done real testing yet.
26/2/11 13:01
Bert de Bruijn said…
For future reference, making it permanent is documented on the QNAP wiki: http://wiki.qnap.com/wiki/Running_Your_Own_Application_at_Startup . Have fun !
3/9/11 19:23
pbrunnen said…
Any chance you can post a copy of your vconfig binary? I just got a TS-219P+... while I have got the 8021q kernel module to load, I can't find a copy of the config tool.

Any help is appreciated.
15/9/11 05:51
Post a Comment

Popular posts from this blog

Which vSphere version is my VM running on?

Several years ago, I created a list of ESXi versions with matching VM BIOS identifiers. The list is now complete up to vSphere 8. Your Linux runs on a VMware VM, but on which ESXi version? Even without access to the host nor vCenter, you can see for yourself: run "dmidecode" and look at lines 10, 11 and 12. The BIOS release date, the address and the runtime size are unique for each ESXi version. Starting from 7.0 U3, no address and size is reported, and the "Phoenix Technologies LTD" name changed to "VMware, Inc.". Look up your result in the following table: ESXi version   BIOS release date   Address   Size ESX 2.5 04/21/2004 0xE8480 97152 bytes ESX 3.0 04/17/2006 0xE7C70 99216 bytes ESX 3.5 01/30/2008 0xE7910 100080 bytes ESX 4 08/15/2008 0xEA6C0 88384 bytes ESX 4U1 09/22/2009 0xEA550 88752 bytes ESX 4.1 10/13/2009 0xEA2E0 89376 bytes ESXi 5 01/07/2011 0xE72C0 101696 bytes ESXi 5.1 06/22/2012 0xEA0C0 89920 bytes ESXi 5.5 07...
7 comments
Read more

Volkswagen UHV bluetooth touch adapter & its problems

My Volkswagen car has the "universal cellphone preparation" UHV built-in. This is the main part of a car kit, but requires an additional adapter for connecting to a cellphone. At first, I was using an adapter for my good old Nokia 6310, even after I changed to the Nokia E71. Connecting was easy: pair the phone with the "VW UHV" bluetooth entity, and done. This has the phone connected to the car kit at all times, so even non-call-related functions use the car audio system (e.g. voice recognition). But progress will have its way, no matter what happens. So in comes the "bluetooth touch adapter". Instead of a phone-specific adapter, this is a small touchscreen device that slots into the UHV dashboard mount. Connecting a phone is very different now: the Bluetooth Touch Adapter connects to the "VW UHV" device via bluetooth the phone connects to "Touch Adapter" device, also via bluetooth The device doesn't allow step 2 if step 1 didn'...
13 comments
Read more

GEM WS2 MIDI System Exclusive structure and checksums

MIDI is the standard for communication between electronic music instruments like keyboards and synthesizers. And computers! While tinkering with an old floppy-less GEM WS2 keyboard, I wanted to figure out the structure of their System Exclusive memory dumps. SysEx is the vendor-specific (and non-standard) part of MIDI. Vendors can use it for real-time instructions (changing a sound parameter in real-time) and for non-real-time instructions (sending or loading a configuration, sample set, etc.). In the GEM WS2, there's two ways of saving the memory (voices, globals, styles and songs): in .ALL files on floppy, and via MIDI SysEx. The .ALL files are binary files, 60415 bytes long. The only recognizable parts are the ASCII encoded voice and global names. The SysEx dumps are 73691 bytes long. As always in MIDI, only command start (and end) bytes have MSB 1, and all data bytes have MSB 0. The data is spread out over 576 SysEx packets, preceded by one SysEx packet with header informat...
23 comments
Read more