VLAN Tagging Virtual Interface

[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]

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]

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]

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]

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]

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]

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]

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]

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.

[itsmarcos]

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!

[dolbyman]

did you open a ticket?..yelling around here will do nothing ..as you should know

[itsmarcos]

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.

[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.