VLAN Tagging Virtual Interface
-
- First post
- Posts: 1
- Joined: Sun May 03, 2020 1:32 pm
VLAN Tagging Virtual Interface
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
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
-
- New here
- Posts: 6
- Joined: Sun Jun 03, 2018 2:08 am
Re: VLAN Tagging Virtual Interface
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.
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.
-
- New here
- Posts: 4
- Joined: Sat Oct 15, 2016 5:41 am
Re: VLAN Tagging Virtual Interface
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.
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.
-
- Starting out
- Posts: 41
- Joined: Sat Feb 02, 2013 10:36 pm
Re: VLAN Tagging Virtual Interface
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.
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.
-
- First post
- Posts: 1
- Joined: Mon Jul 13, 2020 6:06 am
Re: VLAN Tagging Virtual Interface
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.
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.
-
- Starting out
- Posts: 46
- Joined: Wed Apr 11, 2018 5:49 am
Re: VLAN Tagging Virtual Interface
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....
Current Systems
QGD-1600P-4G | QNAP TS-1683XU-RP | QNAP TS-EC880U R2 | QNAP TVS-1271U | QNAP TVS-871 | QNAP TS-879 Pro | Full List
Links
QNAP QGD-1600P - First Impression on the QNAP-Guardian Smart Switch | Setting up pfSense | 32GB RAM Upgrade | Assign VLAN
Disassembly - QNAP TVS-871 - Replacing the CPU and RAM | QNAP TS-879 Pro - Replacing the RAM
All - Making the QNAP PSU 20-pin SATA Power Adapter | Setup HomeAssistant on QNAP Container using Docker | How to setup pfSense for QNAP | Run a Geekbench 4 benchmark on QNAP Container Station using Docker| Setup HomeAssistant with Z-Wave on QNAP Container using Docker
QGD-1600P-4G | QNAP TS-1683XU-RP | QNAP TS-EC880U R2 | QNAP TVS-1271U | QNAP TVS-871 | QNAP TS-879 Pro | Full List
Links
QNAP QGD-1600P - First Impression on the QNAP-Guardian Smart Switch | Setting up pfSense | 32GB RAM Upgrade | Assign VLAN
Disassembly - QNAP TVS-871 - Replacing the CPU and RAM | QNAP TS-879 Pro - Replacing the RAM
All - Making the QNAP PSU 20-pin SATA Power Adapter | Setup HomeAssistant on QNAP Container using Docker | How to setup pfSense for QNAP | Run a Geekbench 4 benchmark on QNAP Container Station using Docker| Setup HomeAssistant with Z-Wave on QNAP Container using Docker
-
- New here
- Posts: 6
- Joined: Sat Aug 01, 2020 2:35 pm
Re: VLAN Tagging Virtual Interface
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.
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.
-
- Starting out
- Posts: 46
- Joined: Wed Apr 11, 2018 5:49 am
Re: VLAN Tagging Virtual Interface
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/
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/
Current Systems
QGD-1600P-4G | QNAP TS-1683XU-RP | QNAP TS-EC880U R2 | QNAP TVS-1271U | QNAP TVS-871 | QNAP TS-879 Pro | Full List
Links
QNAP QGD-1600P - First Impression on the QNAP-Guardian Smart Switch | Setting up pfSense | 32GB RAM Upgrade | Assign VLAN
Disassembly - QNAP TVS-871 - Replacing the CPU and RAM | QNAP TS-879 Pro - Replacing the RAM
All - Making the QNAP PSU 20-pin SATA Power Adapter | Setup HomeAssistant on QNAP Container using Docker | How to setup pfSense for QNAP | Run a Geekbench 4 benchmark on QNAP Container Station using Docker| Setup HomeAssistant with Z-Wave on QNAP Container using Docker
QGD-1600P-4G | QNAP TS-1683XU-RP | QNAP TS-EC880U R2 | QNAP TVS-1271U | QNAP TVS-871 | QNAP TS-879 Pro | Full List
Links
QNAP QGD-1600P - First Impression on the QNAP-Guardian Smart Switch | Setting up pfSense | 32GB RAM Upgrade | Assign VLAN
Disassembly - QNAP TVS-871 - Replacing the CPU and RAM | QNAP TS-879 Pro - Replacing the RAM
All - Making the QNAP PSU 20-pin SATA Power Adapter | Setup HomeAssistant on QNAP Container using Docker | How to setup pfSense for QNAP | Run a Geekbench 4 benchmark on QNAP Container Station using Docker| Setup HomeAssistant with Z-Wave on QNAP Container using Docker
-
- New here
- Posts: 7
- Joined: Fri Jan 15, 2016 7:16 pm
Re: VLAN Tagging Virtual Interface
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
- Easy as a breeze
- Posts: 310
- Joined: Thu Sep 29, 2011 5:34 am
Re: VLAN Tagging Virtual Interface
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.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.
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
- dolbyman
- Guru
- Posts: 35275
- Joined: Sat Feb 12, 2011 2:11 am
- Location: Vancouver BC , Canada
Re: VLAN Tagging Virtual Interface
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.
- itsmarcos
- Easy as a breeze
- Posts: 310
- Joined: Thu Sep 29, 2011 5:34 am
Re: VLAN Tagging Virtual Interface
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
-
- Starting out
- Posts: 29
- Joined: Wed Mar 21, 2012 8:10 am
Re: VLAN Tagging Virtual Interface
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:
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.
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:
- Add a virtual switch using Advanced Mode.
- 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).
- Step 3, choose "Do not assign IP addresses (for special...)" and click Next.
- Step 3, leave NAT + DHCP unticked. Click Next.
- Step 4, everything is greyed out. Click Next.
- Step 5, leave DNS as "Obtain DNS server address automatically". Click Next.
- Step 6, click Apply.
- Go to the settings of your VM.
- Under Network > Virtual Switch, choose your newly created vSwitch.
- Got to the vNIC settings. (Windows: Start > Run > ncpa.cpl).
- Right-click the vNIC and choose Properties.
- Click Configure.
- Click Advanced (tab).
- Look for (something like) VLAN ID and enter the VLAN ID.
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
-
- Starting out
- Posts: 41
- Joined: Wed Oct 19, 2022 10:23 pm
Re: VLAN Tagging Virtual Interface
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...
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...
-
- Starting out
- Posts: 41
- Joined: Wed Oct 19, 2022 10:23 pm
Re: VLAN Tagging Virtual Interface
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.
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.