VLAN Tagging Virtual Interface

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

VLAN Tagging Virtual Interface

Post by RHLinux » Sun May 03, 2020 1:44 pm

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 » Sun Jun 28, 2020 1:43 pm

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 » Tue Jun 30, 2020 5:10 am

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: 32
Joined: Sat Feb 02, 2013 10:36 pm

Re: VLAN Tagging Virtual Interface

Post by kbyrd » Fri Jul 10, 2020 4:56 am

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 » Mon Jul 13, 2020 7:29 am

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: 35
Joined: Wed Apr 11, 2018 5:49 am

Re: VLAN Tagging Virtual Interface

Post by Yippym » Sat Jul 18, 2020 6:40 am

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: 3
Joined: Sat Aug 01, 2020 2:35 pm

Re: VLAN Tagging Virtual Interface

Post by fun__key » Thu Aug 06, 2020 3:24 am

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.

Post Reply

Return to “Server Virtualization & Clustering”