VLAN Tagging Virtual Interface

QNAP NAS solution for server virtualization and clustering/HA/FT
RHLinux
First post
Posts: 1
Joined: Sun May 03, 2020 1:32 pm

VLAN Tagging Virtual Interface

Post by RHLinux »

Now that QNAP have updated the firmware to include VLAN tagging for a virtual interface, they didn't quite implement it correctly.

You can now create VLAN and connect them to virtual switches, but the main untagged interface disappears and can't be connected to the virtual switches.

Example:

Untagged Interface 1 - VLAN1
Tagged Interface 1 - VLAN10, VLAN20, VLAN30

In the network and virtual switch, only the Tagged Interface appears and you can't connect the untagged interface 1 (VLAN1) to any virtual switches. The reason you might want to do this is to have the untagged interface available for the rest of the QNAP services (sharing, etc...) an also have the ability to use Virtualization station able to use the untagged lan interface, but only the tagged vlans are available.

Why they implemented VLANs like this I have no idea. As soon as you create a vlan in the network and virtual switch, the main interface disappears and you can no longer connect it to any virtual switches.

I have sent QNAP a but report and ticket, but they regard this as a "feature". Why they regard this as a feature is beyond my comprehension. It's basic networking 101 to have the ability to use the untagged interface... It's how network switches work!! Untagged on the base interface port and trunked vlans.

I have no idea when and if QNAP will ever get around to fixing this issue, it is not a feature and it's needed to implement vlans properly on virtual switches.

What are your thoughts and is there a way round this "feature" ;)

RHLinux
zqush
New here
Posts: 6
Joined: Sun Jun 03, 2018 2:08 am

Re: VLAN Tagging Virtual Interface

Post by zqush »

I'm having similar troubles with this. The minute I setup the VLAN on Adapter 2, everything went wrong. The Virtual Adapters of my Containers disappeared and containers fail to start with the following error.

Background task error for create openhab-1: 500 Server Error: Internal Server Error ("IpamDriver.RequestAddress: Qnet IPAM cannot discover any DHCP server")

What I want is to have some containers to connect to my main LAN (untagged) and some containers (OpenHAB to be specific) to use the VLAN 44 which is the VLAN I use for all home automation devices.

Their implementation seems to be broken.
hellokaiser
New here
Posts: 4
Joined: Sat Oct 15, 2016 5:41 am

Re: VLAN Tagging Virtual Interface

Post by hellokaiser »

Similar, but slightly inversed problem here: The physical Adapter (trunked) are set to obtain their IP address via an external DHCP server and the same for DNS. When I add a VLAN (Virtual ) to the trunked Adapter 1+2 and configure it to obtain IPv4/6 and DNS automatically, then I can see the same device two times in the managed switch: One for each interface (MAC address helps identifying it). One device is in the untagged default VLAN1 and the second one is in the tagged VLAN.
The good thing is: If I now add a virtual switch (again: DHCP client, obtain DNS autom.) and attach a virtual adapter, I might be able to add whatever is running on some VM or container and map it to the network on it's own subnet/ attach it to a VLAN and represent it like any physical device to the outside world.
Is this how VLAN segregation works? Not really…

EDIT The virtual adapter has taken down part of my routing. I had to remove it. The feature simply is not ready to get used. That's an alpha version in production.

EDIT 2 While I set everything to "auto obtain DHCP/DNS", my switch detected a rogue DHCP server. And that one came exactly from the tagged VLANs subnet .1-address on top of the Adapters. Nice. Not.
kbyrd
Starting out
Posts: 41
Joined: Sat Feb 02, 2013 10:36 pm

Re: VLAN Tagging Virtual Interface

Post by kbyrd »

So, I'm in sort of the opposite situation. My VLAN trunk port is setup to not have a default VLAN Id, so it expects all traffic to be tagged and doesn't apply any anything to untagged traffic.

I have this working just fine, but what I really want for this trunk port is to have it only used for the containers and VMs I have attached via virtual switches. What I'm finding right now is that I can ssh, use the Web UI, and CIFS shares via any of the DHCP'd IPs that get assigned to the VLAN adapters like "Trunk - VLAN101".

I have enabled service binding and only have check boxes for the main (no VLAN's added) adapter, and unchecked everything for the three other adapters on the QNAP.
Petersonz
First post
Posts: 1
Joined: Mon Jul 13, 2020 6:06 am

Re: VLAN Tagging Virtual Interface

Post by Petersonz »

I managed to work around this limitation/strange issue on my QGD-1600P.

1) I created a virtual switch on Adapter 2 (one of the two listed as QTS interfaces that connect to the QUNET-Switch). That virtual switch I used for untagged traffic.

2) Then I created a VLAN on Adapter 3, then I created a virtual switch connecting the VLAN adapter I created for it.
Even though untagged port 3 cannot be assigned to Virtual Switches, port 2's untagged is in a virtual switch and working fine while port 3's sub-interface VLAN is in a different vitual switch.

3) Then I connected a new virtual to that second Vswitch with just the VLAN interface in it.

Voila. It is not elegant, but it works.

I really wish QNAP would fix this and make it so that untagged interfaces can be added to Virtual Switches when tagged sub-interfaces are created on them.

Then I could trunk 2 and 3 together (it picks 802.3AD automatically and it cannot be changed apparently), which, with MAC or IP hashing LACP load balancing, would balance the load between 2 and 3 while providing a failover, and ultimately, a cleaner configuration could be had that has untagged, and tagged sub-interfaces available to individual virtual switches.

The so-called "guardian" mode is useless since it takes over port management from the 16 port switch for each port that is "guardianed". I tried to add the same group of guardian ports to two different VSwitches (With 2 different VLAN ID's) and all it does is re-assign the ports from one vswitch to another even though they have different VLAN ID's.

Please, QNAP, fix this weird behavior. Even VMWare did not have this oddball limitation over a decade ago...

I know my CentOS 7 box with QEMU/KVM does not have this problem...

So it is not a limit of Linux.

Takeaways:

A) QNAP (QTS Interfaces in Network and Virtual Switch app) interfaces that have sub-interfaces with VLAN ID's cannot belong to a Virtual Switch. This is why they suddenly dropped out when you created a VLAN on it with a virtual switch attached to that port. WEIRD. Needs to be fixed IMHO.
B) QNAP's wizardry, although innovative, cunning, canny, and every other cool description, actually is quite misguided in that it does not warn before re-assigning, or un-assigning virtual ports from virtual switches. Making a change like that can take down your entire system due to wizardry and its unexpected results. There are several other places I found that the wizard paints you into a corner leaving the web interface unavailable.
C) There are at least 2 other places where things appear but are not configurable. For example, the 2 "host ports) between the switch and the NAS show up in the QUNET switch configuration VLAN section, yet they cannot be edited when clicking the pencil. Only the 16 ports in the switch appear, not the host ones. Oversight?
D) Just like the VLAN configuration in QUNET, apparently, the faux host ports cannot be trunked there either, only switch ports visible to the front (16 ports in my case). So, I gotta cross my fingers that the wizards at QNAP got it right when you create a Trunk in QTS, it auto configures it for 802.3AD LACP on BOTH ENDS, (bi directional load balancing requires that both ends are LACP in order to work correctly). Since I cannot configure it at all in QUNET, I hope their wizard does for me.
E) The terminology of "Link Aggregation" and "Port Trunking" are the same, considering the limitations that QNAP's wizards leave us with. Why have different definitions/words? Also, the Link Aggregation in QUNET actually lets you pick LACP or static in the groups.
F) QNAP's Virtual Switch interface allows you to add the two "Host/QTS" ports to one virtual switch without a warning that they will be bridged together which creates a loop and causes all kinds of silent problems. Since, EVEN QNAP's own spanning tree/loop detection does not automatically block one of the two links between the QTS and the QUNET switch. REALLY BAD IDEA! Spanning tree's whole purpose in life is to prevent loops dont ya know? It should automatically place the two or more interfaces into a blocked forwarding mode. I tested this thoroughly and it breaks all my virtuals with "loop detected" errors. An upstream switch of mine, spanning tree enabled, blocked the single uplink port to the entire QNAP switch because it detected a loop. The two port workaround I noted above was the only way to fix it.
Yippym
Starting out
Posts: 46
Joined: Wed Apr 11, 2018 5:49 am

Re: VLAN Tagging Virtual Interface

Post by Yippym »

Petersonz wrote: Mon Jul 13, 2020 7:29 am
I'm currently with QNAP support from 15-06-2020, they still haven't figured out why/how for QTS to edit VLAN for HOST 2 and HOST 3 manually. The only thing that is able to assign HOST 2 and 3 with VLAN is the VM Installer App, but running the wizard twice will only assign one VLAN 'LAN' to Host 3, but you can have multiple VLAN 'WAN' to HOST 2 tagged.

All I wish to do is use Unifi Controller on Docker to assign Private WiFi and Guest WiFi on separate VLAN to one port only, which is the Access Point. But there is no way the port can interact with Host 3 to the Virtual Switch to pfSense VM on the Switch itself.

Currently waiting for their team to respond to my topology, they did state it can be manually be done. But they have yet to tell me how....
fun__key
New here
Posts: 6
Joined: Sat Aug 01, 2020 2:35 pm

Re: VLAN Tagging Virtual Interface

Post by fun__key »

I am in the same situation as OP. I did open a support case as well (still ongoing), I cannot imagine this behavior being a feature.

Features should be driven by customer, why would anyone ask for such a limitation? As for technical feasibility - I don't know about the underlying linux component that are used behind the scene here, but I am pretty sure that it should work fine. Exposing the native VLAN to a VM can be done without any sweat with ESXi or KVM.

This limitation severely reduce the attractivity of 2.5/10gbit NIC and link aggregation.
Yippym
Starting out
Posts: 46
Joined: Wed Apr 11, 2018 5:49 am

Re: VLAN Tagging Virtual Interface

Post by Yippym »

I've managed to get VLAN to work on the QNAP QGD-1600P, QNAP Support giving me a detailed tutorial. Turns out you don't need to assign the VLAN in pfSense, the Virtual Switch handles the VLAN.

Made a post on my site on how VLAN works with pfSense in QNAP QGD-1600P, the way it works is that the Virtual Switch auto filter the VLAN. Just need to assign the interface.
https://poyu.co.uk/2020/08/16/qnap-qgd- ... h-pfsense/
DroboDongo
New here
Posts: 7
Joined: Fri Jan 15, 2016 7:16 pm

Re: VLAN Tagging Virtual Interface

Post by DroboDongo »

This ridiculous design still persists a year later....seriously QNAP, get onboard with how everyone else has been doing L2 Ethernet networking for the last decade or two; ridiculous.
User avatar
itsmarcos
Easy as a breeze
Posts: 310
Joined: Thu Sep 29, 2011 5:34 am

Re: VLAN Tagging Virtual Interface

Post by itsmarcos »

DroboDongo wrote: Wed Jun 09, 2021 12:08 pm This ridiculous design still persists a year later....seriously QNAP, get onboard with how everyone else has been doing L2 Ethernet networking for the last decade or two; ridiculous.
Same here. Recently bought a small Ubiquity switch. I added VLANs on an interface and then created additional virtual switches for those VLANs. The new virtual switches work ok but the virtual switch that is serving the untagged LAN stops working. I lose connectivity on the pre-existing VMs using the untagged LAN. Reconfiguring them is a huge pain PLUS I want my VMs reachable via an untagged LAN for fault tolerance purposes.

As previously said, this is NOT a linux limitation.

QNAP PLEASE FIX THIS!

Primary

QNAP TVS-951N [latest QTS 5.0.x]
- disk 1: WDC Red WD80EFZX
- disk 2: WDC Red WD80EFZX
- disk 6: Samsung SSD Evo 500GB, SSD Cache
- disk 7:Samsung SSD Evo 500GB, HybridMount Cache
- External disk: WDC Red WD60EFRX
Dead one
QNAP TS-253B [4.4.x] - now dead


Remote backup
QNAP TS-219 P+ [latest 4.3.x]
- disk 1: HGST Deskstar 7K3000 HDS723030ALA640 3TB
- disk 2: WDC Red WD40EFRX
User avatar
dolbyman
Guru
Posts: 34986
Joined: Sat Feb 12, 2011 2:11 am
Location: Vancouver BC , Canada

Re: VLAN Tagging Virtual Interface

Post by dolbyman »

did you open a ticket?..yelling around here will do nothing ..as you should know
Last edited by dolbyman on Wed Jul 07, 2021 8:15 pm, edited 1 time in total.
User avatar
itsmarcos
Easy as a breeze
Posts: 310
Joined: Thu Sep 29, 2011 5:34 am

Re: VLAN Tagging Virtual Interface

Post by itsmarcos »

dolbyman wrote: Wed Jul 07, 2021 7:44 am did you open a ticket?..yellong around here will do nothing ..as you should know
Not new around here. I know that 'officially' QNAP doesn't read the forum. Ticket is in place.
Bare in mind that a public outcry does have it's value (qnap not exempted). Much more effective on reddit though.

Primary

QNAP TVS-951N [latest QTS 5.0.x]
- disk 1: WDC Red WD80EFZX
- disk 2: WDC Red WD80EFZX
- disk 6: Samsung SSD Evo 500GB, SSD Cache
- disk 7:Samsung SSD Evo 500GB, HybridMount Cache
- External disk: WDC Red WD60EFRX
Dead one
QNAP TS-253B [4.4.x] - now dead


Remote backup
QNAP TS-219 P+ [latest 4.3.x]
- disk 1: HGST Deskstar 7K3000 HDS723030ALA640 3TB
- disk 2: WDC Red WD40EFRX
woter
Starting out
Posts: 29
Joined: Wed Mar 21, 2012 8:10 am

Re: VLAN Tagging Virtual Interface

Post by woter »

If I understand the problem correctly, the ability to apply a VLAN tag at the vSwitch level is missing. Certainly something I am trying to do with my TS-h686 (QuTS hero h5.0.0.1986 Build 20220324) and cannot find a way to do this from QNAP. However, I have managed to achieve what I want by applying the VLAN ID on the virtual NIC from within the VM's OS. Not ideal, but if QNAP is dragging their feet doing this properly, it will have to do for now.

Coming from VMware, one would create a vSwitch which gives layer 2 connectivity to one or more physical NICs of ESX host. The physical NIC is connected to a physical switch port. The switch port is configured as a Trunk port (Cisco term) and VLAN ID's are tagged to the Trunk. One would create what VMWare call a Port Group, where one defines the VLAN ID. Normally, there is a Port Group for each required VLAN. The VM's vNIC is assigned a Port Group.

In QNAP-world, the only place to assign a VLAN ID is on the physical NIC. Often the number of VLANs in a given network are far greater than the number of physical NICs available to the QNAP. The job of a switch. IMHO, we should be able to apply the VLAN ID to the vSwitch. It also appears that there is a one-to-one relationship between the pNIC and the vSwitch. I don't have VMWare ESX to hand to confirm if this is the same. Probably.

My workaround is thus:
On the QNAP:
  1. Add a virtual switch using Advanced Mode.
  2. Step 1, select your adapter(s). (I have pNIC 3 + 4 in a, confusingly named "Port Trunk". Basically Teamed or Link Aggregation. IEEE 802.3ad).
  3. Step 3, choose "Do not assign IP addresses (for special...)" and click Next.
  4. Step 3, leave NAT + DHCP unticked. Click Next.
  5. Step 4, everything is greyed out. Click Next.
  6. Step 5, leave DNS as "Obtain DNS server address automatically". Click Next.
  7. Step 6, click Apply.
In VirtualisationStation:
  1. Go to the settings of your VM.
  2. Under Network > Virtual Switch, choose your newly created vSwitch.
On the VM:
  1. Got to the vNIC settings. (Windows: Start > Run > ncpa.cpl).
  2. Right-click the vNIC and choose Properties.
  3. Click Configure.
  4. Click Advanced (tab).
  5. Look for (something like) VLAN ID and enter the VLAN ID.
Each NIC manufacturer has a list of different advanced options. I am using the Red Hat VirtIO drivers.

Not ideal as it means console access to the VM is required before connectivity can be established, making automation harder. However, I hope this may help some of you.
TS-h686
SnArL817
Starting out
Posts: 41
Joined: Wed Oct 19, 2022 10:23 pm

Re: VLAN Tagging Virtual Interface

Post by SnArL817 »

I'm in the same boat. Adapter 3+4 is my primary LACP uplink to my Cisco. Untagged is 172.16.0.0/23. VLAN 50 is 172.16.50.0/24. I created a virtual switch with VLAN 50, and that's working (I was able to bridge Adapter 1 in as a 2.5Gbps uplink to another host, which can ping everything on VLAN 50), but I'm unable to create a virtual switch on the untagged interface to allow any virtualization to bridge in to 172.16.0.0/23.

What's frustrating is that I know EXACTLY how to implement this on a RedHat-type system by manually creating the interface config files. bond0 gets reconfigured as a bridged device slaved to qvs1, and qvs1 gets created as basically having all of the config from the previous bond0 config. The ifup bond0/ifup qvs1.


...though, doing so would drop my network connection to the NAS. I suppose that's what subshell and nohup is for. I've done blind network reconfigs before with a DeadMan switch that reverts the configs if something goes wrong. The problem is I don't see the config files anywhere...
SnArL817
Starting out
Posts: 41
Joined: Wed Oct 19, 2022 10:23 pm

Re: VLAN Tagging Virtual Interface

Post by SnArL817 »

I found the config file: /mnt/HDA_ROOT/.config/nm.conf

This file is used by a python script that looks like it manages the network. Being compiled, I don't feel like trying to reverse engineer its functionality. I am reluctant to manually edit the file, as I don't know if it needs a reboot for those changes to take effect, or if they just take effect immediately on updating the file, OR if the changes would just get overwritten by nmd. I don't even know HOW to restart the networking services from the CLI.
Post Reply

Return to “Server Virtualization & Clustering”